Messages in this thread | | | Date | Fri, 19 Jul 2002 16:27:02 -0700 | From | J Sloan <> | Subject | Re: 2.4.19rc2aa1 VM too aggressive? |
| |
I've seen several mentions of 2.4.19-rc1aa2 -
FYI, 2.4.19-rc2aa1 came out a few days ago -
I've been running it and it seems to perform even better under pressure than 2.4.19-rc1aa2, at least in my workloads...
Joe
Johannes Erdfelt wrote:
>On Fri, Jul 19, 2002, Austin Gonyou <austin@digitalroadkill.net> wrote: > > >>On Fri, 2002-07-19 at 16:03, Johannes Erdfelt wrote: >> >> >>>Web server. The only writing is for the log files, which is relatively >>>minimal. >>> >>> >>But IMHO, you are using prefork, and not a threaded model correct? >> >> > >Yes, it's a prefork. > > > >>>One thing also, is there is lots of process creation in this example. >>>For a variety of reasons, PHP programs are forked often from the Apache >>>server. >>> >>> >>Also, here, even as a DSO, which I think you may not be running PHP as, >>(cgi vs. dso), you will use a bit of memory, on top of apache, every >>time the new child is created by apache to handle incoming requests. >> >> > >Use both, but for legacy reasons there's still a signficant amount of >children being forked for the CGI like version (caused by SSI). > >The memory size for these children is about 40MB (which is strange in >itself), and a couple per second get executed. However, they are very >quick and typically won't see any in ps, but occassionally 1 or 2 will >be seen. > > > >>>The systems running an older kernel (like RedHat's 2.4.9-21) are much >>>more consistent in their usage of memory. There are no 150MB swings in >>>cache utiliziation, etc. >>> >>> >>Hrrmmm....I'd suggest a 2.4.17 or 2.4.19-rc1-aa2 in that case. I promise >>you'll see drastic improvements over that kernel. >> >> > >2.4.17 wasn't good last time I tried it, but I've have much better results >from Andrea's patches. I'll create 2.4.19-rc1-aa2 kernel and see how >that fares. > > > >>>What's really odd in the vmstat output is the fact that there is no disk >>>I/O that follows these wild swings. Where is this cache memory coming >>>from? Or is the accounting just wrong? >>> >>> >>I think the accounting is quite correct. Let's look real quick. >> >> > >I suspect it's correct as well, but that doesn't mean something else >isn't wrong :) > > > >><vmstat> >> >> >>>>> procs memory swap io system cpu >>>>> 3 0 0 106036 502288 10812 67236 0 0 0 0 802 494 46 37 17 >>>>> 5 0 2 106032 476188 10844 91496 0 0 4 316 905 573 54 37 8 >>>>>16 0 2 106032 355400 10844 203880 0 0 4 0 909 540 51 49 0 >>>>>10 0 2 106024 340108 10852 221548 0 0 28 0 975 659 36 64 0 >>>>> 0 0 0 106024 528340 10852 43572 0 0 4 0 569 426 17 17 67 >>>>> 0 1 0 106024 531304 10852 43612 0 0 4 0 542 342 9 14 >>>>> >>>>> >></vmstat> >> >>Now let's take a closer look.... >> >><vmstat2> >> >> >>>>>16 0 2 106032 355400 10844 203880 0 0 4 0 909 540 51 49 0 >>>>>10 0 2 106024 340108 10852 221548 0 0 28 0 975 659 36 64 0 >>>>> >>>>> >></vmstat2> >> >>Notice you're memory utilization jumps here as your free is given to >>cache. >> >> > >Are you saying that the cache value is the amount of memory available to >be used by the cache, or actually used by the cache? > >It was my understanding that it's the memory actually used by the cache. >If that's the case, I don't understand where the data to fill the cache >is coming from with these blips. > > > >><vmstat3> >> >> >>>>> 0 0 0 106024 528340 10852 43572 0 0 4 0 569 426 17 17 67 >>>>> 0 1 0 106024 531304 10852 43612 0 0 4 0 542 342 9 14 >>>>> >>>>> >></vmstat3> >> >>And then back again, probably on process termination. >> >> > >There are couple per second of those processes, so I would expect this >to happen all of the time or atleast much more often. > > > >>At that rate, it's all in-memory shuffling going on, and for preforks, >>that very likely is the case. >> >> > >One thing to note as well is a significant amount of system time spent >during these situations as well. It looks like a lot of time is spent >managing something. > >It's obvious the workload is inefficient, but it's constantly >inefficient which is why these blips are strange. > >JE > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |