Re: ARM64 hosts eventually lockup running net-mgmt/unifi
Josh Howard <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 03 Aug 2020 10:44:01 -0700, Ronald Klop wrote: > > On Mon, 03 Aug 2020 18:59:26 +0200, Josh Howard <[email protected]> wrote: > > > This one has been sort of a pain to narrow down, but on any of: > > RockPro64, > > RockPi4b, or RPI4, if I run net-mgmt/unifi eventually the host just hard > > locks. Nothing over serial, nothing interesting in the logs, no > > other hints, > > so it's not clear what precisely is causing it. For those > > unfamiliar, unifi > > runs both a Java app and a mongodb server. I've tried with openjdk8 > > (their > > only supports version) and openjdk11, neither one made any > > difference. I'm > > not totally sure how a userland app like this could cause this to happen, > > but it's getting consistent that it eventually does kill my host. > > > > Any ideas or hints would be great! > > > I had the same problem. The default amount of nmbclusters is too > low. If they are full the OS becomes very unresponsive. > > I run this script hourly. It doubles the amount of nmbclusters if more > than half are occupied. > > @hourly bin/nmbclustercheck.sh > [root@rpi3 ~]# more bin/nmbclustercheck.sh > #! /bin/sh > > LINE=$( netstat -m | grep "mbuf clusters" | cut -d ' ' -f 1 ) > CURRENT=$( echo $LINE | cut -d '/' -f 1 ) > MAX=$( echo $LINE | cut -d '/' -f 4 ) > > if test $CURRENT -gt $(( $MAX / 2 )) > then > NEW_MAX=$(( $MAX * 2 )) > echo Increase kern.upc.nmbclusters from $MAX to $NEW_MAX > sysctl kern.ipc.nmbclusters=$NEW_MAX > fi > > > Current amount after 14 days of uptime: > [root@rpi3 ~]# sysctl kern.ipc.nmbclusters > kern.ipc.nmbclusters: 19250 > Thanks for the lead! I did attempt this, sadly it didn't change anything. I graphed the nmbcluster usage over about 12 hours, but at some point the system simply hanged and there was no recovering short of a hard reboot. The number of used clusters did increase gradually, but never got close to the limit. I agree it does seem likely to be somehow related to some resource exhaustion, but just not getting any indication of what it is. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"