text: TLD shutting down on pfBlockerNG-dev? | Netgate Forum
  TLD shutting down on pfBlockerNG-dev?
  nopro last edited by 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 last edited by @nopro
  @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 last edited by nopro @NollipfSense
  @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.