Date: Wed, 28 Aug 2013 15:56:30 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-fs@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Message-ID: <kvkvi7$iv7$1@ger.gmane.org>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2KORNWEXCTJDANISUNQEX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Prodded by davide@, I'd like to collect opinions about raising the vfs.ufs.dirhash_reclaimage sysctl from 5 to 60, committed at: http://svnweb.freebsd.org/changeset/base/254986 What it does: Used in lowmem handler at http://fxr.watson.org/fxr/source/ufs/ufs/ufs_dirhash.c#L1247 when determining which cache entries to evict; it skips (keeps in the cache) entries which are younger than this number of seconds. This lowmem handler only frees up to 10% of the dirhash cache at a time. A real-life example: a PHP server with session files on local storage. Even a moderately busy server will usually have several GB of these small files sharded in directories containing few hundred files each, up to several hundred thousand files total. It is a standard practice for admins to increase the dirhash if they notice PHP/apache processes stuck in the "ufs" state for too long. Why: Without ufs_dirhashreclaimage, it is possible that UFS dirhash entries will get evicted immediately after they are created if a lowmem situation occurs. The previous ufs_dirhashreclaimage value was 5, keeping the entries for at least 5 seconds before allowing them to get evicted (Reclaim Age). Why the change: Dirhash is a cache. Keeping as large number of entries as possible for as large amount of time as possible is a good thing. It can be done either by increasing maxmem or by increasing reclaimage. A scenario where increasing reclaimage helps: when a load spike happens, the following happens: 1) memory gets used up, 2) lowmem is signalled 3) dirhash entries get evicted 4) processes get slower (this can be observed in "top" as being in the "ufs" wchan) waiting for the data which could have been cached. Increasing reclaimage during a spike situation has the effect of clearing up processes faster. Why not leave it for sysadmins to tune it themselves if they want it: 1) They usually don't know about it until it's too late. 2) Dirhash is typically miniscule compared to todays memory sizes - a few dozen MBs even on very busy systems, and there are no typical situations where a large number of entries are filled in at the same time which block eviction of a large-ish amount of memory, so having reclaimage higher will automatically help in file-system intensive spikes without harming other uses. ------enig2KORNWEXCTJDANISUNQEX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIeAY8ACgkQ/QjVBj3/HSzEfACgjc4tpCc9AiqrPej/QFki0vH8 u+YAoI67IgN3kTH2GptadAKQgQ5TYTnT =aryY -----END PGP SIGNATURE----- ------enig2KORNWEXCTJDANISUNQEX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?kvkvi7$iv7$1>