Updated today to latest snap - very slow
-
It seems that the bug still exist interface is very slow unless I execute /etc/rc.conf_mount_rw in ssh. So workaround is to run /etc/rc.conf_mount_rw before making any changes
-
We're still aware it's an issue, there is an open bug in redmine for it.
-
I noticed that Seth Mos has committed "Hopefully tackle the slow nanobsd writes. Redmine ticket #2401" on Github. I guess this is probably built in the version I just updated to:
2.1-BETA0 (i386)
built on Tue Jun 19 20:53:01 EDT 2012
FreeBSD 8.3-RELEASE-p3Is there any particular sequence of operations that we can/should test to help to see if the issue is resolved or improved?
(I must say, I haven't really noticed the issue on various test nanoBSD installs on my Alix 2D3 in recent weeks!) -
It didn't help, unfortunately.
Timing the mount rw then ro calls is sufficient, see the existing redmine ticket for it.
-
Just installed snapshot pfSense-2.1-DEVELOPMENT-2g-i386-nanobsd-20120629-1927
still the same problem -
Same here … had no problems with 2.0.X on my alix. After upgrading to 2.1 about 1 month ago WebGUI is very slow from that point, especially when making changes. After upgrading to latest snapshot and reboot now i'd to restart Webconfigurator via console to have access to my pfSense. I hope the issue can be solved in 2.1, cause i have many alix boards out at customers and this behavior would prevent me to upgrade these boxes ...
-
I also noticed that on recent updates (I think from the beginning of July), after the install reboot, I have to use the console to restart the web configurator. Reboots after that have been fine. So something is happening on the first reboot (of course it reinstalls packages at that time, but that should not kill the web configurator). This web configurator restart issue is probably a different thing to the slow RW mounting. I have also had other web configurator issues recently - see http://forum.pfsense.org/index.php/topic,51188.0.html - maybe there is some common issue here in a recent build that is effecting the web configurator?
-
Any news on that? I've updated yesterday to 2.1-BETA0 (i386) built on Thu Oct 11 and having the sames issues like described by you all. The GUI is very fast but when I have to do some changes or for example creating a new OpenVPN account, I have to wait like 1-2 minutes until one step finishes. I'm running on nanobsd (4g).
Cheers,
Szop -
Any news on that? I've updated yesterday to 2.1-BETA0 (i386) built on Thu Oct 11 and having the sames issues like described by you all. The GUI is very fast but when I have to do some changes or for example creating a new OpenVPN account, I have to wait like 1-2 minutes until one step finishes. I'm running on nanobsd (4g).
Cheers,
Szopthe bug report is still open, no progress on it as of now, seems something from freebsd
-
Okay, thanks for the fast reply. Can you provide me a link to the bug report?
Cheers,
Szop -
-
Only nanobsd affected?
-
at least for now
-
I don't see any freebsd bugs that clearly jump out, but this has been reported in the forums:
http://forums.freebsd.org/showthread.php?t=33021&highlight=remountNo other replies, and with USB rather than CF, but maybe a hint it's something in 8.3
-
Today I updated from 2.0.1 to 2.1-BETA0 snapshot from 2 days ago. Disastrous. Both the web UI and the shell are unresponsive for several seconds at a time. Reloading the web configurator didn't help. When I was able to run top, both CPU cores are showing 90%+ idle.
As a bonus, several of my local networks have no internet, for reasons that aren't immediately apparent. Also, the traffic graphs on the dahsboard, other than those for the WAN and LAN interfaces, are displaying their OPTx names rather than their assigned aliases, but this is the least of my concerns.
Thank goodness for dual slices.
-
Today I updated from 2.0.1 to 2.1-BETA0 snapshot from 2 days ago. Disastrous. Both the web UI and the shell are unresponsive for several seconds at a time. Reloading the web configurator didn't help. When I was able to run top, both CPU cores are showing 90%+ idle.
As a bonus, several of my local networks have no internet, for reasons that aren't immediately apparent. Also, the traffic graphs on the dahsboard, other than those for the WAN and LAN interfaces, are displaying their OPTx names rather than their assigned aliases, but this is the least of my concerns.
Thank goodness for dual slices.
The top problem might be the CF - as mentioned throughout this thread. The system shows idle, because it's all in i/o during the rw to ro switch.
The second issue, not sure, might be the limiter issue some others are having. Check other threads (but it's not related to this one directly)
-
I can cofirm there must be a problem with the CF card r/w operations in the recent version (2.1BETA).
Right now I'm trying to upgrade to today's snapshot and the image is being downloaded from a local server via 1Gb/s connection… at ~15kB/s.
Granted, that's a 100Mb/s port in my firebox doing the job, but the result is a bit below that threshold as well. I downloaded the same file from the update server at 300kB/s, going in the WAN interface and going out the very same LAN interface, so it's not the network at fault.
Also getting the very slow response time whenever I change something or remount the root FS. Reason for upgrading again is that now the firebox is causing random loss of connectivity, noticeable when downloading large files and online gaming... most aggravating.
Before upgrading from 2.0.1 to 2.1BETA, pfsense on the firebox was a bit slow, but not sluggish... And there were no problems with connectivity (unless I caused them myself playing with all the fancy options...).
I've yet to look at the logs to see what's wrong... Assuming I could tell... Between the inconmpatible realtek NIC, watchdog timeouts, some fuss over MTU sizes and now the nanobsd issues, this box is starting to sport too many points of failure...
-
It's probably the CF, as mentioned in the ticket linked earlier in this thread.
Some CF cards are perfectly fine, others are very very slow…
-
Any progress to report here?
-
No, or the ticket would have been updated.
