Running out of memory on SG-1100 on pfblockerng updates
-
@nicheath said in Running out of memory on SG-1110 on pfblockerng updates:
to add some swap space on the SG-1110?
The SG-1100 has its limitations, if you want to manage a huge pfBlockerNG list, you need a unit with more memory and/or a more powerful pfSense box
The SWAP area is most often used when the RAM is exhausted.
It may help if you increase the default "2GB" and use the OP system as temporary storage when reloading and analyzing lists.
(but this is not the real solution)Always keep in mind what you want to achieve and what the current hardware is...
SG-1100 1GB of RAM - you cannot enable all pfBlockerNG feeds for this.
The mistake is also common to think that the more lists we have, the more secure we are.
It is not the reality - that well-chosen lists provide security.The few - many times - more
btw:
In addition, -when the lists and database check are complete, even UNBOUND is reloaded, ergo no DNS resolution during this time -
It depents on your settings.
I run my SG-1100 with some lists, (Deny:106965, Native:29861, DNSBL:368371) and the stabel pfblocker verison with 39% Ram.
I dont use CIDRs and TDL.
But it you run the dev version, it will use mutch more Ram and overload my SG-1100, so i be back to the tabel version.
-
Enabling SWAP on the SG-1100 would not be at all straight forward if it's in fact possible.
But it would be a bad idea anyway. The eMMC would likely be horribly slow for use as SWAP and it would massively increase the write cycles.In general if you see pfSense using SWAP on systems that have it enabled it's usually a sign that something is misconfigured anyway.
Steve
-
@stephenw10 That is what I was curious about.
The data point about unbound being stopped during the update may be the actual issue as it takes the SG-1110 a long time to parse.
-
Exact.
The size of this list :
should be reasonable.
That is, a "8 core 3Ghz 32 Gbytes RAM" system could handle more as a SG 1100. Up to you to decide when you reach the point of saturation.
Normally, pfBlockerNG-devel shouldn't restart unbound to often :/var/log: grep 'Restart' resolver.log ..... Oct 16 16:01:02 pfsense unbound: [68926:0] notice: Restart of unbound 1.10.1.= 7 days for me.
-
@Gertjan I was under the impression that it reloads unbound on the cron schedule (though I thought I have mine set for 3am but it seems to do it at midnight still) and the update schedule for each list (weekly, daily).
-
Check who is actually restarting Unbound ;)
-
Unbound loads a test file before it restarts to be sure it is valid and that requires holding double the config in RAM at that point. That's why it sometimes fails to update but RAM usage looks OK once it's running.
pfBlocker updates the lists on the Cron schedule but will not restart Unbound if there has been no change to them.Steve
-
@stephenw10 said in Running out of memory on SG-1100 on pfblockerng updates:
pfBlocker updates the lists on the Cron schedule but will not restart Unbound if there has been no change to them.
Hi Steve,
yes this is true, but honestly -when there is no change (a tiny) in the lists...?
I have to say, that out of the 100 update forced by cron the UNBOUND restarts 90 times...
-
For most lists that's true, they are usually quite dynamic. But certainly not all. It just depends what lists you're using. And remember that's only the lists for DNS-BL not the IP lists.
Steve
-
@stephenw10 said in Running out of memory on SG-1100 on pfblockerng updates:
But certainly not all.
Yes, yes I agree, but
I will only present the facts which we observed....
My opinion is, use a list that is well maintained, so your/his/her "update frequency" should be at least a couple of days or a weekotherwise the lists, which are old or unmaintained, do not serve their purpose and not to mention the many FPs they can cause....
-
I agree. But if you have pfBlocker set to update lists every hour I would not expect it to restart Unbound every time.
Steve
