pfsense 2.5.2 slowly leaking memory
-
@murzik said in pfsense 2.5.2 slowly leaking memory:
memory usage grow over the time
I was assuming there was a particular process increasing in size. If it's multiple processes that would make it a bit harder to diagnose, perhaps just watch over time. But if it isn't happening to everyone then it seems like it's not a generic FreeBSD/pfSense problem...
That said unbound on the two routers I just looked at is much smaller than 700 MB, around 30-50 MB. We don't have pfBlocker's DNSBL running though.
-
pfBlockerNG, the DNSBL part : you're using the python mode ?
My unbound process is one of the biggest (but not the biggest) process in my system, but stays at around 100 Mbytes :
96339 unbound 2 20 0 101M 95M kqread 0 0:03 0.37% unbound -
@murzik said in pfsense 2.5.2 slowly leaking memory:
I have to reboot every other day.
What happens if you do not reboot it?
That is something leaking quite fast if you are using 8GB in 2 days.
Steve
-
@stephenw10
If I do not reboot, pfsense will use up all the memory and swap and crash. -
@gertja
Yes, I do use DNSBL in python mode. But I've been using it in python mode since it become available without any issues.... Also disabling DNSBL, restarting unbond, snort etc, does not free any memory.... -
@murzik said in pfsense 2.5.2 slowly leaking memory:
pfsense will use up all the memory and swap and crash
We can't see your process list...you'll need to tell us which processes are using up the memory.
-
@steveits Unfortunately I am not able to tell. When system crashes it is too late to check. However, I am starting to suspect that ntopng could be the problem. I remoted ntopng yesterday, so far memory usage stays around 30% . Will see in few days.
-
@murzik said in pfsense 2.5.2 slowly leaking memory:
ntopng
Aha !
You to forget to mention that you were using the big resource hog, the beast that should be set up carefully, and has to be managed 24/24h.
Tools like ntopng should not be left alone, as it files up files rapidly.
Most 'space' issues are not the RAM that starts too be consumed, but your entire disk space.
The result is the same : booooom.
With a full RAM and swap : the system goes down - but can restart it without issues. That is, if the file system wasn't corrupted when doing the unplanned system reboot.
A full file system : your system won't boot any more. -
@gertjan
Apparently ntopng was not the cause. As of right now
-
If it doesn't show in the process list it's probably something in kernel like a driver.
Are all the affected systems running on the same hardware?
Steve
