pfSense 2.4.5 running only 1 CPU core = no problemos. Multiple cores = Grandes problemos.
-
Vsphere 5.5U3 as of now. :)
Currently testing 2 core setup.
Very responsive and running almost idle now. Will monitor this for the next couple of hours.
-
Upgraded to 4 CORES. Still stable so far.
8 CORES next.
-
@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.
-
@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.
-
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
-
After a full night running very stable with 8 cores
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....
-
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%. -
@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?
-
@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.
-
@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)
