1. Home
  2. pfSense® Software
  3. Virtualization
  4. pfSense 2.4.5 running only 1 CPU core = no problemos. Multiple cores = Grandes problemos.

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

  • C

    pfsense_CORE.JPG

    Idling along. Will post with multiple cores later.

    0
  • Gertjan

    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 ....

    0
  • C

    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.

    0
  • C

    Upgraded to 4 CORES. Still stable so far.

    8 CORES next.

    pfsense_4CORE.JPG

    0 NollipfSense 1 Reply
  • NollipfSense

    @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.

    0 C 1 Reply
  • C

    @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

    0
  • C

    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

    0
  • C

    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....

    0 T 1 Reply
  • 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%.

    0 C 1 Reply
  • C

    @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?

    0 Bob.Dig 1 Reply
  • Bob.Dig

    @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.

    0
  • T

    @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)

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

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.

© 2020 Rubicon Communications, LLC | Privacy Policy