Date: Tue, 18 Nov 2003 14:02:41 -0700 (MST) From: Scott Long <scottl@freebsd.org> To: =?iso-8859-1?q?Claus=20Guttesen?= <cguttesen@yahoo.dk> Cc: current@freebsd.org Subject: Re: FreeBSD current, apache and php4 woes Message-ID: <20031118135038.T34253@pooker.samsco.home> In-Reply-To: <20031118193749.22575.qmail@web14107.mail.yahoo.com> References: <20031118193749.22575.qmail@web14107.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Nov 2003, [iso-8859-1] Claus Guttesen wrote: > Hi. > > > > > > >>>panic: kmem_malloc(4096): kmem_map too small: > > >>>275251200 total allocated cpuid = 0; lapic.id = > > >>>00000000 > > >> > > You'll either want to raise the size of the kmem_map > > pool or decrease the maximum number of vnodes > allowed > > (vnodes get allocated out of the kmem_map and are > > likely depleating it > > Add one of the two lines to /boot/loader.conf: > > > > kern.vn.kmem.size=350000000 > > or > > kern.maxvnodes=150000 > > > > The first one is probably the better choice for you > > since > > the very nature of what you are doing demands that > > you touch a lot of vnodes. > > > > Scott > > It seems that your advice helpted cure the patient. I > did two things: > > 1. added kern.vm.kmem.size=450000000 > 2. clean up tmp-files older than 4 hours every hour > (previous was files older than 12 h.). > > Now the servers has been quite stable, no reboot in > almost two days! My problem appears to be too many > files in /tmp and /var/tmp (50.000 or more) which made > the kernel puke. I forgot to mention in the last email that kern.maxvnodes will still scale upwards as you increase kern.vm.kmem.size. So you might want to set a hard limit on it so you don't continue to run into problems. A value of 200,000 is probably good in your case. > > I guess this is a scenario which we will see more > often. Would it be possible to output this situation > to the message-log before the server simply reboots? It might be useful for this particular panic message to print out the value of maxvnodes, numvnodes, and/or other metrics to help with debugging. We need to also review the scaling algorithm and tweak it back into line. A more complex solution would be to create a way for the vfs system to get feedback on KVA and kmem_map pressure and auto-tune itself. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031118135038.T34253>