From owner-freebsd-performance@FreeBSD.ORG Mon Jan 28 14:23:47 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B07D16A46C for ; Mon, 28 Jan 2008 14:23:47 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from mail.sweeplist.com (mail.sweeplist.com [77.93.199.51]) by mx1.freebsd.org (Postfix) with ESMTP id 0D87613C455 for ; Mon, 28 Jan 2008 14:23:46 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from [192.168.1.2] (r3a200.net.upc.cz [213.220.192.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sweeplist.com (Postfix) with ESMTPSA id 1349367808; Mon, 28 Jan 2008 15:23:46 +0100 (CET) Message-ID: <479DE578.7060202@quip.cz> Date: Mon, 28 Jan 2008 15:23:52 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: freebsd-performance@freebsd.org References: <479B1185.8020604@quip.cz> <479D89C9.7060300@chistydom.ru> <479DD94C.7010409@mawer.org> In-Reply-To: <479DD94C.7010409@mawer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexey Popov , Antony Mawer Subject: Re: PHP with open_basedir performance problem X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2008 14:23:47 -0000 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