Updated today to latest snap - very slow
-
-
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.
-
I had the same problem using SanDisk 1GB and 8GB USB sticks and a Transcend 1 GB 40-pin IDE flash module. I was adding rules and wondering why it was taking 20 to 30 seconds to apply. I then noticed mounting rw from console allowed rules to apply immediately. So, for now I just used Acronis to clone my partitions to an OCZ Vertex 3 SATA III SSD 60GB drive and the problem is gone. An eventual fix or other drive recommendation would be nice since the OCZ is overkill.
-
went back to 2.0.1 and problem is gone with Transcend 1 GB 40-pin IDE
-
Okay,
I've been facing this problem since the very first update to 2.1 snapshot. I've tried out a lot and nothing helped, but today I had to restore a backup because of missconfiguration. What can I say: The applying/saving changes on the pfsense are much faster now! Now it takes like 5 seconds to save a change, where I had to wait up to 40 seconds. Please try following thing:
1. Create a full backup
2. Make some minor, not important change
3. Login to the pfsense console and choose to restore a backup
4. Restore the latest backup and restart
5. Check if you see any changesHope this can help someone out.
Cheers,
Szop -
Hmm, interesting.
So the original backup your restored from had been created under 2.1? From what date/snapshot?Steve
-
i think this would be temporary and with more and more changes u do it keeps getting slower coz i had setup a new alix board recently and for a few days it was fast then later it became slow
-
I guess, I wasn't clear enought. The version I'm running on is the latest snapshot: 2.1-BETA0 (i386) built on Sat Nov 10 18:43:12 EST 2012. Today, 11.11.12, I made some changes which doesn't worked out and I had to restore to the last change via console and restart once (I guess it's point 15 in the console, sorry but I'm not in front of the pfsense). Anyway, I'm still on the latest snapshot but the sluggish behaviour is gone. I've also made more than enough changes and it's still fast (created over 15 different VLAN's and also set them up to static IP's). I'll keep you up to date, would be nice to see if someone can reproduce/try this out.
Cheers,
Szop -
@xbipin: Unfortunately you've been right :'(. My pfSense is becomming sluggish again. I'll keep you up to date aboute the situation and I'll try to speed my pfSense up again with this restore function. Thanks for listening ;)
Cheers,
Szop -
better solution for now would be to avoid the rw and then ro calls, simply provide an option in the GUI to permanently set it to rw for now coz being on nanobsd its probably not going to write much to the CF card or whatever storage u use until u make some config change as most will be in the ramdisk so if devs r listening, just avoid the rw and then back to ro call, set it explicitly to rw mode, atleast things will get faster for now, once there is a solution u can switch back to the general behavior
-
I've had a "permanent rw" feature on my to-do list for a while now but haven't had a chance to do it.
It's not really a solution, it just masks the problem.
-
yes indeed its not a solution but for time being u can simply change the rw and ro not do anything but exit silently and on boot simply set the system to rw
