From owner-freebsd-performance@FreeBSD.ORG Mon Jan 28 13:37:46 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 7A14216A41A for ; Mon, 28 Jan 2008 13:37:46 +0000 (UTC) (envelope-from fbsd-performance@mawer.org) Received: from outbound.icp-qv1-irony-out1.iinet.net.au (outbound.icp-qv1-irony-out1.iinet.net.au [203.59.1.108]) by mx1.freebsd.org (Postfix) with ESMTP id F263313C4E8 for ; Mon, 28 Jan 2008 13:37:45 +0000 (UTC) (envelope-from fbsd-performance@mawer.org) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGpnnUd8qoGx/2dsb2JhbAAIqms X-IronPort-AV: E=Sophos;i="4.25,260,1199631600"; d="scan'208";a="279790971" Received: from unknown (HELO [10.4.1.1]) ([124.170.129.177]) by outbound.icp-qv1-irony-out1.iinet.net.au with ESMTP; 28 Jan 2008 22:27:41 +0900 Message-ID: <479DD94C.7010409@mawer.org> Date: Tue, 29 Jan 2008 00:31:56 +1100 From: Antony Mawer User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Alexey Popov References: <479B1185.8020604@quip.cz> <479D89C9.7060300@chistydom.ru> In-Reply-To: <479D89C9.7060300@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> 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 13:37:46 -0000 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...? --Antony