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

    pfSense 2.4.5 running only 1 CPU core = no problemos. Multiple cores = Grandes problemos.

    Scheduled Pinned Locked Moved Virtualization
    12 Posts 5 Posters 1.3k 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.
    • Cool_CoronaC
      Cool_Corona
      last edited by

      pfsense_CORE.JPG

      Idling along. Will post with multiple cores later.

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

        Running on what ?
        Have one running on a native device : 2006 Intel(R) Pentium(R) 4 CPU 3.20GHz : dual core : it rocks.
        Another one : Hyper-V Windows 10 Pro : attributes dual core, same result : just perfect.

        I don't know how to interpret your image ....

        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
        • Cool_CoronaC
          Cool_Corona
          last edited by Cool_Corona

          Vsphere 5.5U3 as of now. :)

          Currently testing 2 core setup.

          pfsense_CORE_Version.JPG

          pfsense_2CORE.JPG

          Very responsive and running almost idle now. Will monitor this for the next couple of hours.

          1 Reply Last reply Reply Quote 0
          • Cool_CoronaC
            Cool_Corona
            last edited by

            Upgraded to 4 CORES. Still stable so far.

            8 CORES next.

            pfsense_4CORE.JPG

            NollipfSenseN 1 Reply Last reply Reply Quote 0
            • NollipfSenseN
              NollipfSense @Cool_Corona
              last edited by

              @Cool_Corona 2.4.4 had been stable with eight cores for so long I think you'll find the same with 2.4.5.

              pfSense+ 23.09 Lenovo Thinkcentre M93P SFF Quadcore i7 dual Raid-ZFS 128GB-SSD 32GB-RAM PCI-Intel i350-t4 NIC, -Intel QAT 8950.
              pfSense+ 23.09 VM-Proxmox, Dell Precision Xeon-W2155 Nvme 500GB-ZFS 128GB-RAM PCIe-Intel i350-t4, Intel QAT-8950, P-cloud.

              Cool_CoronaC 1 Reply Last reply Reply Quote 0
              • Cool_CoronaC
                Cool_Corona @NollipfSense
                last edited by

                @NollipfSense said in pfSense 2.4.5 running only 1 CPU core = no problemos. Multiple cores = Grandes problemos.:

                @Cool_Corona 2.4.4 had been stable with eight cores for so long I think you'll find the same with 2.4.5.

                You could easily be right.

                This is an 8 core boot vs a 4 core boot.

                It takes significantly longer before it becomes stable and traffic starts flowing. GW is offline 3 times during boot with 8 cores.

                pfsense_8CORE.JPG

                1 Reply Last reply Reply Quote 0
                • Cool_CoronaC
                  Cool_Corona
                  last edited by

                  8 Core running unstable.

                  Apr 15 22:11:29 xinetd 13368 Reconfigured: new=0 old=4 dropped=0 (services)
                  Apr 15 22:11:29 xinetd 13368 readjusting service 19001-udp
                  Apr 15 22:11:29 xinetd 13368 readjusting service 19001-tcp
                  Apr 15 22:11:29 xinetd 13368 readjusting service 19000-udp
                  Apr 15 22:11:29 xinetd 13368 readjusting service 19000-tcp
                  Apr 15 22:11:29 xinetd 13368 Swapping defaults
                  Apr 15 22:11:29 xinetd 13368 Starting reconfiguration
                  Apr 15 22:11:29 php-fpm 36720 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
                  Apr 15 22:11:28 check_reload_status Reloading filter
                  Apr 15 22:11:28 check_reload_status Restarting OpenVPN tunnels/interfaces
                  Apr 15 22:11:28 check_reload_status Restarting ipsec tunnels
                  Apr 15 22:11:28 check_reload_status updating dyndns WANGW
                  Apr 15 22:11:28 rc.gateway_alarm 90930 >>> Gateway alarm: WANGW (Addr:81.19.224.67 Alarm:0 RTT:1.874ms RTTsd:.091ms Loss:7%)
                  Apr 15 22:09:36 xinetd 13368 Reconfigured: new=0 old=4 dropped=0 (services)
                  Apr 15 22:09:36 xinetd 13368 readjusting service 19001-udp
                  Apr 15 22:09:36 xinetd 13368 readjusting service 19001-tcp
                  Apr 15 22:09:36 xinetd 13368 readjusting service 19000-udp
                  Apr 15 22:09:36 xinetd 13368 readjusting service 19000-tcp
                  Apr 15 22:09:36 xinetd 13368 Swapping defaults
                  Apr 15 22:09:36 xinetd 13368 Starting reconfiguration
                  Apr 15 22:08:54 xinetd 13368 Reconfigured: new=0 old=4 dropped=0 (services)
                  Apr 15 22:08:54 xinetd 13368 readjusting service 19001-udp
                  Apr 15 22:08:54 xinetd 13368 readjusting service 19001-tcp
                  Apr 15 22:08:54 xinetd 13368 readjusting service 19000-udp
                  Apr 15 22:08:54 xinetd 13368 readjusting service 19000-tcp
                  Apr 15 22:08:54 xinetd 13368 Swapping defaults
                  Apr 15 22:08:54 xinetd 13368 Starting reconfiguration
                  Apr 15 22:08:23 php-fpm 53814 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
                  Apr 15 22:08:23 php-fpm 53814 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WANGW'
                  Apr 15 22:08:22 check_reload_status Reloading filter
                  Apr 15 22:08:22 check_reload_status Restarting OpenVPN tunnels/interfaces
                  Apr 15 22:08:22 check_reload_status Restarting ipsec tunnels
                  Apr 15 22:08:22 check_reload_status updating dyndns WANGW
                  Apr 15 22:08:22 rc.gateway_alarm 64256 >>> Gateway alarm: WANGW (Addr:81.19.224.67 Alarm:1 RTT:790.111ms RTTsd:4265.232ms Loss:20%)
                  Apr 15 22:08:12 xinetd 13368 Reconfigured: new=0 old=4 dropped=0 (services)
                  Apr 15 22:08:12 xinetd 13368 readjusting service 19001-udp
                  Apr 15 22:08:12 xinetd 13368 readjusting service 19001-tcp
                  Apr 15 22:08:12 xinetd 13368 readjusting service 19000-udp
                  Apr 15 22:08:12 xinetd 13368 readjusting service 19000-tcp
                  Apr 15 22:08:12 xinetd 13368 Swapping defaults
                  Apr 15 22:08:12 xinetd 13368 Starting reconfiguration
                  Apr 15 22:08:03 php-fpm 93487 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
                  Apr 15 22:08:03 php-fpm 93487 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WANGW'
                  Apr 15 22:08:02 check_reload_status Reloading filter
                  Apr 15 22:08:02 check_reload_status Restarting OpenVPN tunnels/interfaces
                  Apr 15 22:08:02 check_reload_status Restarting ipsec tunnels
                  Apr 15 22:08:02 check_reload_status updating dyndns WANGW
                  Apr 15 22:08:02 rc.gateway_alarm 21233 >>> Gateway alarm: WANGW (Addr:81.19.224.67 Alarm:1 RTT:690.025ms RTTsd:4175.215ms Loss:20%)
                  Apr 15 22:07:34 php-fpm 93487 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
                  Apr 15 22:07:34 php-fpm 93487 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WANGW'
                  Apr 15 22:07:33 check_reload_status Reloading filter
                  Apr 15 22:07:33 check_reload_status Restarting OpenVPN tunnels/interfaces
                  Apr 15 22:07:33 check_reload_status Restarting ipsec tunnels
                  Apr 15 22:07:33 check_reload_status updating dyndns WANGW
                  Apr 15 22:07:33 rc.gateway_alarm 97853 >>> Gateway alarm: WANGW (Addr:81.19.224.67 Alarm:1 RTT:393.502ms RTTsd:3043.836ms Loss:21%)
                  Apr 15 22:07:30 xinetd 13368 Reconfigured: new=0 old=4 dropped=0 (services)
                  Apr 15 22:07:30 xinetd 13368 readjusting service 19001-udp
                  Apr 15 22:07:30 xinetd 13368 readjusting service 19001-tcp
                  Apr 15 22:07:30 xinetd 13368 readjusting service 19000-udp
                  Apr 15 22:07:30 xinetd 13368 readjusting service 19000-tcp
                  Apr 15 22:07:30 xinetd 13368 Swapping defaults
                  Apr 15 22:07:30 xinetd 13368 Starting reconfiguration
                  Apr 15 22:07:30 php-fpm 93487 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
                  Apr 15 22:07:30 php-fpm 93487 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WANGW'
                  Apr 15 22:07:29 check_reload_status Reloading filter
                  Apr 15 22:07:29 check_reload_status Restarting OpenVPN tunnels/interfaces
                  Apr 15 22:07:29 check_reload_status Restarting ipsec tunnels
                  Apr 15 22:07:29 check_reload_status updating dyndns WANGW
                  Apr 15 22:07:29 rc.gateway_alarm 64838 >>> Gateway alarm: WANGW (Addr:81.19.224.67 Alarm:0 RTT:385.349ms RTTsd:3012.481ms Loss:19%)
                  Apr 15 22:06:38 xinetd 13368 Reconfigured: new=0 old=4 dropped=0 (services)
                  Apr 15 22:06:38 xinetd 13368 readjusting service 19001-udp
                  Apr 15 22:06:38 xinetd 13368 readjusting service 19001-tcp
                  Apr 15 22:06:38 xinetd 13368 readjusting service 19000-udp
                  Apr 15 22:06:38 xinetd 13368 readjusting service 19000-tcp
                  Apr 15 22:06:38 xinetd 13368 Swapping defaults
                  Apr 15 22:06:38 xinetd 13368 Starting reconfiguration
                  Apr 15 22:06:38 php-fpm 348 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
                  Apr 15 22:06:38 php-fpm 348 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WANGW'
                  Apr 15 22:06:37 check_reload_status Reloading filter
                  Apr 15 22:06:37 check_reload_status Restarting OpenVPN tunnels/interfaces
                  Apr 15 22:06:37 check_reload_status Restarting ipsec tunnels
                  Apr 15 22:06:37 check_reload_status updating dyndns WANGW
                  Apr 15 22:06:37 rc.gateway_alarm 73139 >>> Gateway alarm: WANGW (Addr:81.19.224.67 Alarm:1 RTT:1.891ms RTTsd:.098ms Loss:19%)
                  Apr 15 22:04:46 xinetd 13368 Reconfigured: new=0 old=4 dropped=0 (services)
                  Apr 15 22:04:46 xinetd 13368 readjusting service 19001-udp
                  Apr 15 22:04:46 xinetd 13368 readjusting service 19001-tcp
                  Apr 15 22:04:46 xinetd 13368 readjusting service 19000-udp
                  Apr 15 22:04:46 xinetd 13368 readjusting service 19000-tcp
                  Apr 15 22:04:46 xinetd 13368 Swapping defaults
                  Apr 15 22:04:46 xinetd 13368 Starting reconfiguration
                  Apr 15 22:04:09 php-fpm 349 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
                  Apr 15 22:04:09 php-fpm 349 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WANGW'
                  Apr 15 22:04:07 check_reload_status Reloading filter
                  Apr 15 22:04:07 check_reload_status Restarting OpenVPN tunnels/interfaces
                  Apr 15 22:04:07 check_reload_status Restarting ipsec tunnels
                  Apr 15 22:04:07 check_reload_status updating dyndns WANGW
                  Apr 15 22:04:07 rc.gateway_alarm 2355 >>> Gateway alarm: WANGW (Addr:81.19.224.67 Alarm:1 RTT:526.670ms RTTsd:3263.185ms Loss:21%)
                  Apr 15 22:04:02 xinetd 13368 Reconfigured: new=0 old=4 dropped=0 (services)
                  Apr 15 22:04:02 xinetd 13368 readjusting service 19001-udp

                  pfsense_8CORE_1.JPG

                  1 Reply Last reply Reply Quote 0
                  • Cool_CoronaC
                    Cool_Corona
                    last edited by

                    After a full night running very stable with 8 cores

                    pfsensen_GW_timeout.JPG

                    And the only thing I saw in the logs from last night when booting.

                    An initial conclusion:

                    I couldnt get pfsense to run stable in any way before with 32cores. After the upgrade to 2.4.5 and setting it to 1 core only, then it booted quickly and with no errors.

                    By adding cores over time, it is still stable and the UX is good.

                    I couldnt have done this without downgrading the number of cores. I have tried multiple times....

                    S 1 Reply Last reply Reply Quote 0
                    • Bob.DigB
                      Bob.Dig LAYER 8
                      last edited by Bob.Dig

                      Hyper-V on Win10:
                      1 Core - boot time 2.5 minutes until utilization goes down.
                      2 Core - boot time 4 minutes, utilization stays at 100%.

                      Cool_CoronaC 1 Reply Last reply Reply Quote 0
                      • Cool_CoronaC
                        Cool_Corona @Bob.Dig
                        last edited by

                        @Bob-Dig said in pfSense 2.4.5 running only 1 CPU core = no problemos. Multiple cores = Grandes problemos.:

                        Hyper-V on Win10:
                        1 Core - boot time 2.5 minutes until utilization goes down.
                        2 Core - boot time 4 minutes, utilization stays at 100%.

                        How long has it been running?

                        Bob.DigB 1 Reply Last reply Reply Quote 0
                        • Bob.DigB
                          Bob.Dig LAYER 8 @Cool_Corona
                          last edited by

                          @Cool_Corona said in pfSense 2.4.5 running only 1 CPU core = no problemos. Multiple cores = Grandes problemos.:

                          @Bob-Dig said in pfSense 2.4.5 running only 1 CPU core = no problemos. Multiple cores = Grandes problemos.:

                          Hyper-V on Win10:
                          1 Core - boot time 2.5 minutes until utilization goes down.
                          2 Core - boot time 4 minutes, utilization stays at 100%.

                          How long has it been running?

                          Can't say now, but I remember that it stayed like that all the time. And it is my only router so I have to reboot.

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

                            @Cool_Corona said in pfSense 2.4.5 running only 1 CPU core = no problemos. Multiple cores = Grandes problemos.:

                            setting it to 1 core only

                            Believe that's been replicated per https://forum.netgate.com/topic/151819/2-4-5-high-latency-and-packet-loss-not-in-a-vm/79 (despite the title of the thread)

                            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
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.