TLD shutting down on pfBlockerNG-dev?

[nopro]

I am running pfSense 2.4.4 (p3) with pfBlockerNG-devel 2.2.5_29 on an 8- core Atom box with 8 GB of memory. The only other active package is Snort.

• With TLD disabled and pfBlockerNG enabled with some common lists and GeoIP, I run on 15-20% memory saturation
• With TLD enabled immediately after install or force-reload, I run on 80-85% memory saturation
• When I revisit dashboard a few hours or a day later, memory saturation is back down to 15-20%, while TLD is still enabled in the GUI
• I have set cron update frequency to ‚daily‘, so no updates/reloads have occurred inbetween
• After yet another force-reload, mem sat is again 80-85%; reload log looks OK

(EDIT: The timescale of memory usage decreasing gradually after a force reload from 85% down to 25% is about two hours (I repeatedly checked the dashboard). I had expected that pfBlockerNG with TLD would occupy the memory persistently. Please bear with me, if I am missing something obvious!)

I had the same effect on pfBlockerNG (non-devel) with TLD enabled.

Is this a known issue? Is there a way to check what is going on? Is TLD shutting down along the way?

Although off topic: kudos and many thanks @BBcan177 for pfBlockerNG which is such a great extension of pfSense‘s capabilities!

[NollipfSense]

@nopro To me, it seems that you might have hardware issue such as a memory module going bad or you need to increase firewall maximum state...since the memory usage does down from 85% to 25% on reload, I believe it could be the latter...I am on pfSense 2.5-dev which has a higher default in image below...when I was on V.2.4.4, I had mine at two millions.

[nopro]

@NollipfSense Thanks for the suggestion of increasing states/table entries. I will give it a try.

Although, as described in my initial post, my system seems to use a disproportionately low amount of memory about two hours after reload, it seems to apply TLD filtering adequately, as far as I can discern from looking at my Reports/Alerts/DNSBL log... Still puzzled...

EDIT: Of course, I might not know about packets escaping filtering and thus logging, yet the log appears to be populated in a plausible manner.