David, yes, there are next changes in sysctl.conf, but kernel options were untouched (again it was GENERIC.MP -stable).
$ cat /etc/sysctl.conf net.inet.ip.forwarding=1 net.inet.carp.preempt=1 net.inet6.ip6.forwarding=1 kern.maxfiles=5048026 kern.maxclusters=2000000 On Tue, Apr 7, 2015 at 9:37 AM, David Gwynne <da...@gwynne.id.au> wrote: > >> On 6 Apr 2015, at 05:32, Evgeniy Sudyr <eject.in...@gmail.com> wrote: >> >> Mark, I will dig in to this. >> >> Sorry, but can someone give a hint what are "unusual" values for pools >> there which can be related to kernel panic Iv'e reported at the very >> beginning? >> >> Current vmstat -m output is: > > the abbreviated version below is kind of interesting. > > are you setting the kern.maxclusters sysctl? if so, to what value? > >> >> Memory Totals: In Use Free Requests >> 76695K 862K 24831415 >> Memory resource pool statistics >> Name Size Requests Fail InUse Pgreq Pgrel Npage Hiwat Minpg Maxpg >> Idle >> mbpl 256 2741641011 0 346 4789 0 0 4789 1 >> 125000 4767 >> mcl2k 2048 1108887843 0 183 10052 0 0 10052 4 >> 1000000 9959 >> >> In use 210238K, total allocated 0K; utilization inf% >> >> >> Will update if will find something... >> >> On Sun, Apr 5, 2015 at 6:59 PM, Mark Kettenis <mark.kette...@xs4all.nl> >> wrote: >>>> Date: Sun, 5 Apr 2015 18:44:43 +0200 >>>> From: Evgeniy Sudyr <eject.in...@gmail.com> >>>> >>>> Stuart, >>>> >>>> as part of troubleshooting, BIOS was upgraded from R 3.0 to latest R 3.2 >>>> >>>> http://www.supermicro.com/products/motherboard/Xeon/C600/X9SRW-F.cfm >>>> X9SRW5.115 >>>> >>>> How big chances are it hitted bug which was fixed in latest BIOS >>>> relase and this will not occurs again? Did you noticed something we >>>> can check with Supermicro support to make sure? >>> >>> So far I've not seen any real evidence that the BIOS is causing >>> problems. Ted noticed the higher-than-usual ACPI memory usage, >>> suggesting a memory leak. This made Stuart suggest that it might be >>> worth updating your BIOS. But we haven't actually established that >>> there is indeed a memory leak. In fact the information you posted >>> earlier suggests that there is no ACPI memory leak, or at least not >>> one directly related to executing AML. >>> >>> You'll really need to do some digging yourself here. Look at the >>> vmstat -m output immediately after booting your machine. Then keep >>> looking at it periodically and identify the memory types and pools >>> that keep growing. For malloc'ed memory look at the "MemUse" column >>> under "Memory statistics by type". For pools, look at the "InUse" >>> column under "Memory resource pool statistics". >> >> >> >> -- >> -- >> With regards, >> Eugene Sudyr >> > -- -- With regards, Eugene Sudyr
