2.4.5 New Install Slow to boot on Hyper-V 2019
-
I've got a basic install with no packages and noticed this too. It takes much longer to boot than 2.4.4 and configuration changes take quite a while to save. The last change I made was just to switch to dark theme and even that caused the box to freeze up for a bit stopping traffic flow.
It appears to only be my VM on Server 2019 as my other VM on Windows 10 (1909) doesn't seem to have this issue (or it isn't noticeable). Both systems have lots of resources and are on SSD's with pfSense setup using UFS.
-
@Com-DAC said in 2.4.5 New Install Slow to boot on Hyper-V 2019:
Windows 10 (1909)
Thanks for detailing the OS used.
I'm using 1909 Windows 10 Pro (only Pro has the Hyper thing I guess) using SSD.
I allocated it 500 Mbytes space and just 1 core. UFS also.pfSense enables Internet access through my AP even before I can login into Windows This AP hooked up to one of the NIC's reserved strictly for the VM/pfSense - and that is in less ten 15 seconds (thanks SSD !) after a system (device !) boot.
edit : https://forum.netgate.com/topic/149595/2-4-5-a-20200110-1421-and-earlier-high-cpu-usage-from-pfctl/18 - and one more for one core !
-
I've got 2 cores assigned to each pfSense VM. The Server 2019 instance has 1GB ram and the Windows 10 instance has 512MB ram.
I'm also using the classic scheduler on Server 2019 as I trust all the VM's I'm running and I got better performance from pfSense using that scheduler.
https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-scheduler-typesI'm wondering if this is a scheduler issue as Server 2019 does default to a different scheduler than previous server versions and Windows 10 uses the root scheduler which is quite different than the server defaults.
-
@Com-DAC Possible, I've just tried 2.4.5 on 2019 with Classic scheduler. Seems to be better. I'll test more next week.
-
i just did a fresh install on hyper-v server 2019. (I5 2405s 32 gb ram and an ssd
Standard install with ufstakes 30-35s to mount filesystems
-
@Mats said in 2.4.5 New Install Slow to boot on Hyper-V 2019:
i just did a fresh install on hyper-v server 2019. (I5 2405s 32 gb ram and an ssd
Standard install with ufstakes 30-35s to mount filesystems
that was about the time I was seeing.
-
I just did another test and had two browser windows open. In one window I was watching the Diganostics / System Activity page and in the other window I just went to System / General Setup changed nothing and clicked save. In system activity I saw this:
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 31257 root 90 0 8828K 4832K CPU1 1 0:10 63.96% /sbin/pfctl -o basic -f /tmp/rules.debug 98023 root 52 0 10288K 5724K select 1 0:09 58.98% /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
During this time my pings went way up until the save completed (at least no packet loss happened). It only lasted about 4 seconds but I don't recall this happening when making changes in 2.4.4.
-
-
I did a test VM install of just vanilla FreeBSD 11.3 with the same parameters as my pfsense install, and the FreeBSD VMdoes not seem to have any of the issues at boot that the pfsense has.
So not sure what to do after this?
-
1 core work-around in https://forum.netgate.com/topic/149595/2-4-5-a-20200110-1421-and-earlier-high-cpu-usage-from-pfctl/17# resolved here;
On-top of slow very slow boot, I also found dropping back to 1 CPU also resolved an issue of system dropping offline post any change of network settings or FW rules. -
HyperV scheduler change does seem to help much. It behaves inconsistently. I have 2 VMs on 2 hosts both changed to Classic scheduler. One is fine. Second one has the issue.
-
I see this issue too (lockups, no network for long duration's randomly, overall slowness) on my server 2016 datacenter hyper-v pfsense vms,
but not on my windows 10 1909 x64 hyper-v pfsense vms with 2.4.5.doing more tests, reloading the firewall filter does cause the issue on windows 10 1909 hyper-v as well. vm config: gen 2, zfs, 6GB ram, 4x cpu cores assigned.
gonna try the same vm in virtual box and see if the issue exists there too. at this point i've seen the issue on 2016 server hyper-v and windows 10 1909.