Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Very high Ram usage

    Scheduled Pinned Locked Moved pfBlockerNG
    7 Posts 4 Posters 1.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      txdk
      last edited by txdk

      im running pfsense 22.09 on a Hp 8300 sff.
      with a I7 - 3770 and 16Gb of ram with standard pfBlockerNG-devel 3.1.0_4 setup.
      And it totally trashes my memory to the point that if i dont stop it i will loose all contact to pfsense webgui and i will need to reboot.
      pfsense1.jpg pfsense3.jpg pfsense2.jpg

      S 1 Reply Last reply Reply Quote 0
      • S
        SteveITS Galactic Empire @txdk
        last edited by

        @txdk 3.1.0_5 was just released for 2.6 CE. I would think a version for 22.05 would be coming shortly. Not sure what/when they release for dev versions of pfSense, haven't used any of those. _5 fixes a logging/CPU bug on 22.05. Might help you as well.

        Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
        Upvote 👍 helpful posts!

        1 Reply Last reply Reply Quote 0
        • N
          NOCling
          last edited by

          If you use large lists it could happen in unbound mode.
          Switch to python mode in pfbocker and the amound of memory is signifikant lower.

          Netgate 6100 & Netgate 2100

          T 1 Reply Last reply Reply Quote 0
          • T
            txdk @NOCling
            last edited by txdk

            @nocling i have tryed both in standard mode and in unbound pyton mode theres no diffrence it takes 2-3 days to fill my ram and to crash my system witch makes PFblocker rather useless for me.

            its the standard list i havnt changed anything there and concedering people is running it on systems with way less ram with no problems.

            GertjanG 1 Reply Last reply Reply Quote 0
            • GertjanG
              Gertjan @txdk
              last edited by

              @txdk

              This :

              0d22a563-a124-4f10-aafd-6dbb0b3ee961-image.png

              is not normal.
              There should be at most two instances of unbound running.
              Not 7.

              I advise you to stop unbound in the GUI, goto console/ssh, and kill all the instances that are still running.
              When done, start unbound in the GUI and check that there is one or two instances running.

              IMHO: the best thing to do is :
              Use Python mode, as the unbound authors invented it so unbound can handle "huge"** DNSBL lists.
              Memory usage is less.
              unbound stops and starts (restarts) are faster.

              nevertheless, everything should be done to make unbound happy.
              Using phyton mode is one thing.
              This implies also :
              a7a0900f-1831-45f6-bab6-8dfdd4d0b414-image.png

              Line 2 and 3 are very important !

              I also advise to re download pfBlockerng-devel DNSBL and IP feeds one a week, not every hour, as these lists rarely change every hour. It's not a big deal you were missing just two DNSBL host names in a list of 100 000 for a day or two.

              Doing all this, and unbound will only restart ones a week or so, and your pfSense becomes stable, DNS has no more issues, and you can start doing other things.

              ** don't be foolish. two, three hundred thousand is enough. Trying to get them all will cripple your pfSense as the entire list has to be walked through on every DNS request.
              If you really want to go big, consider not using pfBlockerng-devel, but a dedicated pihole system on steroids.

              No "help me" PM's please. Use the forum, the community will thank you.
              Edit : and where are the logs ??

              T 1 Reply Last reply Reply Quote 0
              • T
                txdk @Gertjan
                last edited by txdk

                @gertjan said in Very high Ram usage:

                @txdk

                This :

                0d22a563-a124-4f10-aafd-6dbb0b3ee961-image.png

                is not normal.
                There should be at most two instances of unbound running.
                Not 7.

                if i stop it via the gui it will kill all instances of unbound.
                and when restarted there will be 8 instances of unbound.

                my cpu does have 4 cores and 4 hypertread cores making it 8 in total

                and i am using pyton mode in PfblockerNG thats the only change i have made to pfblocker no big lists or anything just standard with Pyton activated

                GertjanG 1 Reply Last reply Reply Quote 0
                • GertjanG
                  Gertjan @txdk
                  last edited by

                  @txdk said in Very high Ram usage:

                  my cpu does have 4 cores and 4 hypertread cores making it 8 in total

                  👍 I guess I learned something.
                  A process per core : why not. Although I see on my '4100', a 2 core atom, mostly one bound thread, not two.
                  I'm actually not sure that all your unbound instances are separate memory spaces, as they all have the same PID : 45676.

                  So : to be sure : shut down pfBlocker, the DNSBL part : if memory goes down a lot, and stays down, over a day or so, you know it is pfBlocker. And in that case : RAM usage is related to 'how many DNSBL you have'.

                  No "help me" PM's please. Use the forum, the community will thank you.
                  Edit : and where are the logs ??

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.