Date: Thu, 22 Nov 2007 21:25:23 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: Alexey Popov <lol@chistydom.ru> Cc: Attilio Rao <attilio@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD Message-ID: <4745E5B3.6060200@FreeBSD.org> In-Reply-To: <47456B71.5040205@chistydom.ru> References: <4741905E.8050300@chistydom.ru> <fhs3s5$knj$1@ger.gmane.org> <47419AB3.5030008@chistydom.ru> <fhs7hp$2es$2@ger.gmane.org> <4741A7DA.2050706@chistydom.ru> <4741DA15.9000308@FreeBSD.org> <47429DB8.7040504@chistydom.ru> <4742ADFE.40902@FreeBSD.org> <4742C46A.1060701@chistydom.ru> <47432F77.3030606@FreeBSD.org> <474339E9.4080301@FreeBSD.org> <4743629B.9090408@FreeBSD.org> <47456B71.5040205@chistydom.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexey Popov wrote: > Hi. > > Kris Kennaway wrote: >>>> In the meantime there is unfortunately not a lot that can be done, >>>> AFAICT. There is one hack that I will send you later but it is not >>>> likely to help much. I will also think about how to track down the >>>> cause of the contention further (the profiling trace only shows that >>>> it comes mostly from vget/vput but doesn't show where these are >>>> called from). >>> >>> Actually this patch might help. It doesn't replace lockmgr but it >>> does fix a silly thundering herd behaviour. It probably needs some >>> adjustment to get it to apply cleanly (it is about 7 months old), and >>> I apparently stopped using it because I ran into deadlocks. It might >>> be stable enough to at least see how much it helps. >> Try this one instead, it applies to HEAD. You'll need to manually >> enter the paths though because of how p4 mangles diffs. > Finally I tried your patch and it seems to help a little. > > Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP > realpath_cache_size (producing 2000+ lstats per request) can handle up > to ~24 rps as opposed to max. 17 rps without your patch. %sys never > grows over %user with your patch. On the server with optimized > realpath_cache_size there's no visible influence of your patch. You said "20" before for this configuration, so I'm a bit suspicious about how seriously to treat your measurements :) Anyway, please obtain another lock profiling trace using the same conditions as the previous one (same workload & duration, etc), so we can compare what changed. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4745E5B3.6060200>