Navigation

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

    New install isn't idling correctly

    Installation and Upgrades
    3
    6
    1566
    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.
    • S
      SnowGhost last edited by

      I'm using a C2D on an intel brand board and 2 intel Gbit NICs, using PFSense 2.2 amd64.  1G RAM (2x 512M Sticks)  There is nothing exciting about this machine.    There are no packages installed.

      I grabbed a spare HDD and installed 2.2 to that, and have the 2.1.5 HDD sitting to revert. 
      I did several backups of 2.1.5 (full, no RRD, no Packages, and no RRD & Packages).
      I restored the "no packages" backup.
      Everything else works the way I expect.

      The only slightly odd thing I did is move from i386 to AMD64.  But it is a new install, not an upgrade.
      I'm now seeing, load average above 1.0, elevated temps (52c, when before it was always sub 30c), the fan is spinning faster and it feels warmer.  So, the machine is definitely working more.

      Using 2.1 through 2.1.5 I never had an issue with idle.

      I've checked the BIOS, and the only setting that seems relevent is the IEST setting, which is enabled.

      On the front page of the web interface the CPU Type is

      Intel(R) Core(TM)2 CPU 4400 @ 2.00GHz
      2 CPUs: 1 package(s) x 2 core(s)
      

      The speed with 2.1.5 varied down to 400Mhtz.  It isn't with 2.2

      The "top" command gives  (And remember it's a Core 2 duo, so load average of 1 means 1 core is fully loaded)

      $ top
      last pid: 98592;  load averages:  1.01,  1.04,  0.87  up 0+00:25:00    20:52:59
      28 processes:  1 running, 27 sleeping
      
      Mem: 41M Active, 29M Inact, 91M Wired, 1768K Cache, 69M Buf, 790M Free
      Swap: 
      
        PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
      90963 root        1  20    0   219M 37824K piperd  1   0:00   0.39% php-fpm
      15544 root        1  20    0 12464K  2172K select  1   0:01   0.00% apinger
      12894 root        1  20    0 16812K  2344K bpf     0   0:00   0.00% filterlog
        278 root        1  28    0   219M 23676K kqread  0   0:00   0.00% php-fpm
      36717 root        1  52   20 17144K  2488K wait    1   0:00   0.00% sh
      20363 root        1  20    0 46700K  5796K kqread  1   0:00   0.00% lighttpd
      64604 root        1  20    0 28172K 18060K select  0   0:00   0.00% ntpd
      44259 root        1  20    0 14548K  2060K select  1   0:00   0.00% powerd
      46825 root        1  20    0 21160K  4360K select  1   0:00   0.00% miniupnpd
      26974 nobody      1  23    0 30264K  4336K select  1   0:00   0.00% dnsmasq
       6391 root        1  20    0 43612K  6300K select  0   0:00   0.00% mpd5
      15565 root        1  20    0 28332K  3012K piperd  1   0:00   0.00% rrdtool
      61695 root        1  52    0 43576K  2768K wait    1   0:00   0.00% login
      98592 root        1  21    0 21996K  2812K CPU0    0   0:00   0.00% top
      61844 root        1  52    0 17144K  2752K wait    1   0:00   0.00% sh
        294 root        1  40   20 19032K  2528K kqread  1   0:00   0.00% check_reload_status
      54472 root        1  20    0 16672K  2408K nanslp  1   0:00   0.00% cron
      62108 root        1  52    0 17144K  2636K ttyin   1   0:00   0.00% sh
      
      

      System activity gives

      last pid: 11971;  load averages:  1.25,  1.09,  0.90  up 0+00:26:52    20:54:51
      80 processes:  8 running, 59 sleeping, 13 waiting
      
      Mem: 41M Active, 29M Inact, 91M Wired, 1768K Cache, 70M Buf, 790M Free
      Swap: 
      
        PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
         11 root     155 ki31     0K    32K RUN     0  16:24  60.99% [idle{idle: cpu0}]
         11 root     155 ki31     0K    32K RUN     1  16:07  40.97% [idle{idle: cpu1}]
          0 root       8    0     0K   192K CPU0    0   6:29  35.99% [kernel{acpi_task_0}]
          0 root       8    0     0K   192K RUN     0   6:58  34.86% [kernel{acpi_task_2}]
          0 root       8    0     0K   192K RUN     1   6:46  34.57% [kernel{acpi_task_1}]
       1486 root      24    0   219M 32780K RUN     0   0:00   0.49% php-fpm: pool lighty (php-fpm)
          0 root     -16    0     0K   192K swapin  1   0:36   0.00% [kernel{swapper}]
          4 root     -16    -     0K    32K -       0   0:02   0.00% [cam{scanner}]
          0 root     -92    0     0K   192K -       0   0:01   0.00% [kernel{em1 taskq}]
          0 root     -92    0     0K   192K -       1   0:01   0.00% [kernel{em0 taskq}]
         12 root     -60    -     0K   208K WAIT    0   0:01   0.00% [intr{swi4: clock}]
      15544 root      20    0 12464K  2172K select  0   0:01   0.00% /usr/local/sbin/apinger -c /var/etc/apinge
          5 root     -16    -     0K    16K pftm    0   0:01   0.00% [pf purge]
      12894 root      20    0 16812K  2344K bpf     0   0:00   0.00% /usr/local/sbin/filterlog -i pflog0 -p /va
        278 root      28    0   219M 23676K kqread  1   0:00   0.00% php-fpm: master process (/usr/local/lib/ph
      36717 root      52   20 17144K  2488K wait    1   0:00   0.00% /bin/sh /var/db/rrd/updaterrd.sh
      20363 root      20    0 46700K  5844K kqread  1   0:00   0.00% /usr/local/sbin/lighttpd -f /var/etc/light
         15 root     -16    -     0K    16K -       1   0:00   0.00% [rand_harvestq]
      
      

      It's clear that something is pegging one core, but I"m stuffed if I can see what.

      A possible, but probably not related problem, is I no longer see traffic grahps.  But RRD Graphs work.  I can see 50% CPU load there as well.

      1 Reply Last reply Reply Quote 0
      • S
        SnowGhost last edited by

        I think this was a case of co-incidence.  Or the hardware didn't like having the HDD changed.  But something jammed one core on, at 100% load and speed.  Something low level, because the effect was also present just in the BIOS.

        I swapped back to 2.1.5 and the issue remained.

        I jiggered in the BIOS, but couldn't make any difference.

        Eventually I did a full power off, pulled the power lead, tried to power back up (to drain the capacitors in the PSU) and then powered back up, and all is good in 2.1.5

        I'll swap back to 2.2 in the near future.

        So, probably not related to 2.2.

        1 Reply Last reply Reply Quote 0
        • S
          SnowGhost last edited by

          I strongly suspect I'm just talking to myself.  But just for completion ….

          I swapped back to the 2.2 AMD64 disk and the thing is correctly idling and changing speeds up and down as it should.  So, just some stupidity in the BIOS.

          It seems to run at a slightly higher base rate (ie, 450mhtz is the more common minimum now, than 300mhtz).  But I put that down to a slightly higher base load in FreeBSD 10 over 8.  Or unbound, or the new PHP or something else.

          1 Reply Last reply Reply Quote 0
          • C
            cmb last edited by

            You definitely were chewing a good deal of CPU in the one post above, nearly all in something to do with ACPI from the looks of it.

                0 root       8    0     0K   192K CPU0    0   6:29  35.99% [kernel{acpi_task_0}]
                0 root       8    0     0K   192K RUN     0   6:58  34.86% [kernel{acpi_task_2}]
                0 root       8    0     0K   192K RUN     1   6:46  34.57% [kernel{acpi_task_1}]
            

            @SnowGhost:

            It seems to run at a slightly higher base rate (ie, 450mhtz is the more common minimum now, than 300mhtz).  But I put that down to a slightly higher base load in FreeBSD 10 over 8.  Or unbound, or the new PHP or something else.

            All else being equal, all of those things actually use less hardware resources in 2.2 than in 2.1.x versions. FreeBSD 10's packet filter is more efficient, other parts of the network stack are more efficient, in some cases drivers are better. Switching to PHP-FPM reduced its resource utilization. Unbound uses a trivial amount of resources.

            If your CPU usage still seems high, monitor "top -SH" via SSH. Maybe something like the above acpi stuff going on. If there's a BIOS update available, installing it would probably be a good idea, as it might be some hardware bug that just wasn't exposed by FreeBSD 8 for some reason. Any time ACPI and "stupidity in the BIOS" come up in a thread, a BIOS update comes to mind.

            1 Reply Last reply Reply Quote 0
            • stephenw10
              stephenw10 Netgate Administrator last edited by

              You may also want to check your powerd settings in System > Advanced, Miscellaneous tab.
              2.2 introduced a new power mode, 'unknown', and that defaults to HiAdaptive. If you were previously using Adaptive and the new power mode is what's detected then the box will average a higher CPU frequency.

              That clearly doesn't explain your >1 load average though.

              Steve

              1 Reply Last reply Reply Quote 0
              • S
                SnowGhost last edited by

                The BIOS for such an old board (remember it's a core 2 duo system) is as up to date as it's going to get.

                I had seen the unknown power management option, and now all are set the same, to adaptive.

                It seems to run at about the same temperature, or maybe even slightly cooler.  So maybe the displayed current CPU speed is calculated differently, between FreeBSD 8 & 10.  I assume there is lots of scope for such a minor change to have been made.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post

                Products

                • Platform Overview
                • TNSR
                • pfSense
                • Appliances

                Services

                • Training
                • Professional Services

                Support

                • Subscription Plans
                • Contact Support
                • Product Lifecycle
                • Documentation

                News

                • Media Coverage
                • Press
                • Events

                Resources

                • Blog
                • FAQ
                • Find a Partner
                • Resource Library
                • Security Information

                Company

                • About Us
                • Careers
                • Partners
                • Contact Us
                • Legal
                Our Mission

                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                Subscribe to our Newsletter

                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                © 2021 Rubicon Communications, LLC | Privacy Policy