Date: Fri, 12 May 2006 20:13:52 +0300 From: Iasen Kostov <tbyte@otel.net> To: Mike Silbersack <silby@silby.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Heavy system load by pagedaemon Message-ID: <1147454032.827.18.camel@DraGoN.OTEL.net> In-Reply-To: <20060512112629.B1879@odysseus.silby.com> References: <1147264089.51661.10.camel@DraGoN.OTEL.net> <1147264379.51661.14.camel@DraGoN.OTEL.net> <1147265038.51661.19.camel@DraGoN.OTEL.net> <1147361590.33341.19.camel@DraGoN.OTEL.net> <20060512071711.GA714@turion.vk2pj.dyndns.org> <1147428461.98918.10.camel@DraGoN.OTEL.net> <20060512112809.GD714@turion.vk2pj.dyndns.org> <1147437061.98918.24.camel@DraGoN.OTEL.net> <20060512102305.T1879@odysseus.silby.com> <1147448667.99925.11.camel@DraGoN.OTEL.net> <20060512112629.B1879@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2006-05-12 at 11:28 -0500, Mike Silbersack wrote: > On Fri, 12 May 2006, Iasen Kostov wrote: > > > On Fri, 2006-05-12 at 10:27 -0500, Mike Silbersack wrote: > >> Can you provide instructions on how to create a testbench that exhibits > >> these same problems? Can eAccelerator + PHP + Apache + some simple script > >> + apachebench do the trick? > >> > > Nope, apache probaly needs to use many pages of shared memory to > > exhaust the PV Entries (as I understand it). eAccelerator uses shm when > > it has something to put there and most porbably apache does the same. So > > I think You'll need a lot of different scripts (and many apache > > processes) to make eAccelerator cache them and probaly some other media > > to make apache use shm on it own (I'm realy not sure how apache uses > > shared memory but it probably does because this problem apears when > > people are using forking apache). > > Well, let me restate what I said above. If nobody else is running into > this, nobody else will be motivated to fix it. On the other hand, if you > put in the time to figure out how others can reproduce it, others then > will be able to try to help fixing it. If you don't show a to reproduce > it, there's no way it can be fixed. > The problem is not realy hum problem. I think the only way to "fix" this (probably) is to have vm zones to auto scale their sizes and KVA_PAGES should probaly tune itself on boot time according to available memory (that's ofcourse are just thoughts I'm don't know anything about pros and cons of this situation). But it's too fundamental may be as there is no even tunable for KVA_PAGES. And something else - on heavyly loaded machine the message about collecting pv entries is disapearing to fast from the dmesg buffer and there are only 5 of them. They probably should be limited to some number per min (may be as a part of some kernel logging system). And when You don't see the message you start wandering what is happening - plenty of RAM , no swapping and machine freezes on 30sec to 5min intervals for ~5 sec. Not fun realy :). Regards.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1147454032.827.18.camel>