Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Jan 2008 15:23:52 +0100
From:      Miroslav Lachman <000.fbsd@quip.cz>
To:        freebsd-performance@freebsd.org
Cc:        Alexey Popov <lol@chistydom.ru>, Antony Mawer <fbsd-performance@mawer.org>
Subject:   Re: PHP with open_basedir performance problem
Message-ID:  <479DE578.7060202@quip.cz>
In-Reply-To: <479DD94C.7010409@mawer.org>
References:  <479B1185.8020604@quip.cz> <479D89C9.7060300@chistydom.ru> <479DD94C.7010409@mawer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Antony Mawer wrote:

> On 28/01/2008 6:52 PM, Alexey Popov wrote:
> 
>> The problem is that concurrent lstat()'s are very slow on FreeBSD now.
>>
>> Possibly you can decrease the number of lstat() calls by tuning 
>> realpath cache size in PHP. Just add "realpath_cache_size=512k" to 
>> php.ini. However I'm not sure this cache is used in open_basedir.
>>
>> See the following thread for details:
>> http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038371.html 
>>
> 
> 
> ... so how does one go about profiling lstat() to find out where the 
> source of the slowness originates from? Is pmc profiling the way to do 
> this?
> 
> The last thread on this topic (referenced above) seemed to point the 
> finger at the default value of vfs.ufs.dirhash_maxmem being too small... 
> which would suggest this is an inherit limitation in UFS(2?) and/or its 
> default tuning.
> 
> If you try increasing the amount of memory allocated for dirhash, does 
> this improve performance at all? eg:
> 
>     # sysctl vfs.ufs.dirhash_maxmem=10240000
>     vfs.ufs.dirhash_maxmem: 2097152 -> 10240000
> 
> ... and then re-run the benchmarks to see if this makes any noticeable 
> difference. The fact that it was indicated that Mac OS X also suffers 
> the same problems suggests this may be a VFS issue rather than UFS 
> specific...?

I tried sysctl vfs.ufs.dirhash_maxmem=10240000 and 
realpath_cache_size=512k in php.ini and sysctl vfs.lookup_shared=1
but all without any significant impact on performance with open_basedir 
enabled.
I also tried this patch for vfs_cache 
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_cache.c.diff?r1=1.114;r2=1.115 
but again without success.

top shows following CPU usage for synthetic test with PHP 5.2.5 on 
7.0-BETA4 with SCHED_ULE an vfs_cache patch + both sysctl tunables and 
php.ini directive:
CPU states:  8.1% user,  0.0% nice, 88.6% system,  0.2% interrupt,  3.2% 
idle

Does somebody have any other ideas?

Miroslav Lachman



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?479DE578.7060202>