Date: Tue, 29 Jul 2008 02:50:53 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-fs@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: ZFS patches. Message-ID: <g6lphl$i9g$1@ger.gmane.org> In-Reply-To: <488E647C.7@mawer.org> References: <20080727125413.GG1345@garage.freebsd.pl> <g6ln6j$c7k$2@ger.gmane.org> <488E647C.7@mawer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9B6970F9B2FA78EA05CFCCB7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Antony Mawer wrote: > Ivan Voras wrote: >> I currently don't have high-end (4 CPU+) AMD64 machines to test, but=20 >> with 1 CPU i386 virtual machine in VMWare, with 1 GB of memory,=20 >> kmem_size=3Dkmem_size_max=3D512M and no other tuning, with latest zpoo= l=20 >> format (11) it took about 15 minutes to get a "kmem_map too small"=20 >> panic on a mixed load (buildkernel + blogbench + bonnie++). >> >> I've then tried the same load on the "real" hardware, 2 CPU, 2 GB=20 >> memory, kmem_size=3Dkmem_size_max=3D512M, and no other tuning, with th= e=20 >> older zpool format (6) i get the same panic, though it takes about=20 >> twice as long to happen. >=20 > Have you tried tuning arc_max and/or monitoring vmstat -m to see what i= s=20 > happening? What does arc_max get auto-tuned to at the moment (ie.=20 > without manually specifying)? >=20 > One of the things I recall reading that arc_max is more like a guide, a= s=20 > some ZFS threads can exceed the max whilst other thread(s) go around=20 > cleaning up and freeing memory once the limit is hit. >=20 > Maybe some better smarts are needed in auto-tuning arc_max so that it=20 > leaves more of a buffer zone than it does at the moment...? I think speculation in the same direction was discussed with the=20 original port of ZFS - I don't know the details but if it arc_max could=20 be better auto-tuned, I think it should be by now. I'm more concerned about the "quiet period" before the panic. I notice=20 ZFS threads have the same priority (PRI field in top) as userland=20 threads (e.g. 44, 55...), while GEOM threads have it different (-8). I=20 don't have the McCusicks book about it so I don't know how priorities=20 whould work, but is this situation OK? I will monitor vmstate -m if it will help Pawel. Should I? --------------enig9B6970F9B2FA78EA05CFCCB7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIjmlzldnAQVacBcgRAvZnAJ4tBkASbaRrvFGqTDz/5d1f7PaTgQCdHTza D9T0FRoCMiScrv4wdKugRX8= =GSUG -----END PGP SIGNATURE----- --------------enig9B6970F9B2FA78EA05CFCCB7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?g6lphl$i9g$1>