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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
