pfSense running out of memory and locking up
-
@stephenw10 , I am almost always at
7% of 2020 MiBwhen I log into the web GUI. I'm barely using the features of this box. A couple of VLANs, DNS, DHCP. That's about it. The only indication I've ever found of something being wrong are the systems logs I've pasted above.~Dan
-
Hmm. Well I guess if it is kernel memory that's harder to see.... try checking the output of
sysctl vm.kmem_map_free.First thing you will see is that on the 32bit arm system that is much smaller than other architectures so far easier to hit an issue. See if hat value decreases over time.
Steve
-
@stephenw10 , I explored the web GUI a bit more and found the Status: Monitoring section. This seems interesting, but I have no idea what it means. I mean, I can see that all free memory suddenly became unavailable, but no idea why.
I ran your suggested command:
[2.4.5-RELEASE][admin@pfSense.localdomain]/root: sysctl vm.kmem_map_free vm.kmem_map_free: 141295616I'll try to log in every now and again and continue to monitor.
~Dan
-
Here is a higher fidelity snapshot around the period of interest. It appears it just happened very suddenly, not ramping up over time.
~Dan
-
That is it failing to log anything, likely when it exhausted the kernel memory.
However before that you can see the free memory ramping down. If you click on the orange 'free' button to de-select it that will show the other data in more detail.
Any idea what happened on June 17th to free some memory?Steve
-
@stephenw10 , unfortunately, no. I really don't do anything on this box; I just let it do its thing. I pretty much only log in when I suddenly lose Internet connectivity. What's interesting is, based on these graphs, I'm in a pretty bad state for several days before the box ceases to route.
Here is the graph without the free memory line:
~Dan
-
@serbus , thank you for putting out this idea. I'm definitely considering it.
Cheers,
Dan -
Hello, just a meeto post.
SG-3100 firewalls running 2.4.5-P1.
I have 9 SG-3100 boxes that don't run Nut, they do use ramdisks, no problem with those.
I have another 6 SG-3100 boxes that have Nut setup with USB Cyberpower OR500.
This morning I noticed that two that were installed on the same day, 13 days ago, both failed an automated config backup because ssh failed. I was able to reboot one of them, the other I'm still fighting with. These are 45 and 60 miles away, so I cannot just power cycle them.
I'm trying to figure out how to tell which processes are using kmem.
Josh
-
Speculating here, I had one of the SG-3100 boxes run into the IPV6 bogons issue, where it couldn't load the bogonsv6 table because it didn't have enough memory. Even after upping the max table entries value... so I'm wondering if the bogons tables use kmem also? Maybe my setup of ramdisks + arpwatch + nut didn't leave enough kmem for the bogon table refresh, which is why it didn't matter how much I increased max table entries.
I'm wondering if this was triggered after a month because the bogonv6 table gets reloaded via cron once a month, and takes 2x the memory for a reload(I read that in one of the threads about the bogonsv6 table reload issue).
I've since disabled ipv6 on my SG3100 boxes, so maybe that will take care of this for me? I didn't have it disabled on the two that locked up today.
<someone upvote me so I can get enough reputation to change my old signature>
Josh
-
What size ram disks are you using?
There was a change the kmem setup for armv6 in pfSense 2.4.5p1. We discovered that earlier versions would allow you to allocate more ram disk than is actually available. An update to the driver in FreeBSD 11.3 prevents that. Ram disks in 2.4.5 in the SG-3100 is fairly limited, I found anything over ~125MB total could hit the limit. The default values should be OK though.
Steve
-
@stephenw10 Hello Stephen, thanks for the reply.
I had my ramdisks set way too large (I now understand).
I took the minimum sizes not as the recommended size, just as the bare minimum, and set them up to use just about all the memory.
The config page doesn't really indicate that a user shouldn't set the ramdisks to use up all the kernel memory. Maybe some general guidance language would be good there?
But since the OP wasn't using a ramdisk at all, this may not really be relevant to the original issue. Other than causing me to hit the issue sooner, but I think I was just asking for trouble with my original ramdisk config.
I'm going to setup zabbix to log the kmem values, or just grab them occasionally with a script.
I have been looking to try and find a way to show how the kmem is allocated, but haven't found anything yet.
Josh
-
Indeed, it may not be but you should set them correctly in 2.4.5. f they are too big the setup code simply won't create them at boot. It logs that.
Steve
