Updated today to latest snap - very slow
-
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
-
Sometime during the beta testing of 2.0, Beta 5 I think it was, the scripts for remounting the file system became broken for some reason. Generally speaking it didn't cause any problems, the only way you could tell they were broken was that the file system in Nano remained RW after boot. That was all fine until some people started using a package (not a proper package!) that didn't follow the rules and instead of calling /etc/rc.conf_mount_ro it issued the mount command directly. This still worked and mounted everything RO. Much complaining commenced as anyone who had run the script could no longer make any changes. ::)
Just thought I'd add that.
Steve
-
Enjoy:
https://github.com/bsdperimeter/pfsense/commit/7b2290139d7a52e2a77b76dcae6a524c1d959ecd -
Thanks Jimp, it works nicely.
My MO is to switch to RW before making a bunch of changes, then switch back to RO after the changes are done. Now this works from the GUI, no need to run the scripts from the command line. -
Thanks Jimp, it works nicely.
My MO is to switch to RW before making a bunch of changes, then switch back to RO after the changes are done. Now this works from the GUI, no need to run the scripts from the command line. -
works great, mine set to rw permanent, is there any issues setting it to rw permanent as i use only the cron package, the rest is all pfsense only?
-
Hard to say for sure, for a while there was a bug that was leaving it rw completely and people barely noticed. But there is always the risk that something will try (and succeed) to write to the media then.
