Does memory upgrade require reinstall?
-
I have just started using pfSense 2.0.1 - great product and very impressed with performance.
I am running it on low power hardware - PII-350, 6GB HDD, 128MB RAM. Setup is basic dual wan - two PPPoE connections; one 40MB/10MB and one 10MB/1MB feeding a single LAN with multiple users - mainly http, ftp, p2p.
Two questions if anyone can help:
-
Plan to increase RAM to 256MB (Maximum allowed on old pc), hoping this will help general speed - especially when CPU maxed out.
QUESTION: If I simply swap RAM will BSD/pfs recognise and use it - or will I have to reconfigure / reinstall? -
Currently have dual wan set up with 5:1 ratio and latency/packet loss detection so that if one of the WAN's (The slower one :)) gets overloaded and latency increases it is removed from group.
QUESTION: Is this the correct way to do it - or should I use limiter/shaping on the slower WAN to avoid saturation?
Thanks in advance for any help
-
-
Well I will answer #1.
Upping the ram will help it out if it is in a situation where it doesnt have enough ram and it needs to swap to hard-disk. If that isnt ever happenning (ie everything you do can fit in 128MB) then it will make no difference really. If you have stuff like squid or snort running then the extra ram will help quite a bit.
-
QUESTION: If I simply swap RAM will BSD/pfs recognise and use it - or will I have to reconfigure / reinstall?
If the RAM is suitable and correctly plugged in etc, the extra RAM will be recognised on the next restart.
-
No need to reinstall. The only consideration there is (assuming a full install) the swap file size. The swap file has to be big enough to contain all of the RAM's contents if you ever want to do a full memory dump in case of a crash. The installer by default makes the swap file 2 x RAM. That's something largely specific to developers' needs though, I can't remember the last time I heard of or needed that on a real world install.
-
Running snort on that hardware seems… ambitious! ;)
Steve
-
Thanks for the confirmation on the memory. I went ahead and installed 256MB (2 x 128MB) memory - all worked well initially.
Unfortunately after running for a short period I kept getting errors - php crashing and then one of the interfaces disappearing. As I had not changed anything else I reverted to old (2 x 64MB) memory - and all systems fine again.
Testing "new" memory using memtest86+ I found one of the new sticks of memory to be bad, the other good. Serves me right for not testing it before. When I get a replacement I'll be sure to test it before upgrading again.
On the second question - no intent or desire to use squid/snort etc. - agreed the hardware is too underpowered. Still interested to know whether limiting/shaping would be a better option to manage high latency on slower wan when saturated?
Thanks again
-
I'd consider limiters or shaper on to avoid the congestion, though that sort of solves a different issue in that it'll just rate limit what's on that connection, rather than stop using the connection when it's heavily loaded (or otherwise degraded). Of course you can keep what you have and add limiters and/or shaping on it if you want.
-
Thanks for the confirmation on the memory. I went ahead and installed 256MB (2 x 128MB) memory - all worked well initially.
Unfortunately after running for a short period I kept getting errors - php crashing and then one of the interfaces disappearing. As I had not changed anything else I reverted to old (2 x 64MB) memory - and all systems fine again.
Testing "new" memory using memtest86+ I found one of the new sticks of memory to be bad, the other good. Serves me right for not testing it before. When I get a replacement I'll be sure to test it before upgrading again.
On the second question - no intent or desire to use squid/snort etc. - agreed the hardware is too underpowered. Still interested to know whether limiting/shaping would be a better option to manage high latency on slower wan when saturated?
Thanks again
You should still be able to use the good 128MB stick with a good 64MB stick to get 192MB, which is better than 128MB. If it isn't just a 2 slot board, you would likely be able to use the 3 good sticks to still get to 256MB.
-
I plan to wait until I get the replacement and then try again with 256MB.
I had been worried that the hardware wasn't sufficient - with high load averages al the time. Then I realised that it was primarily due to continuously running dashboard / monitoring. By stopping that load averages have dropped from >1 to <0.1!!
Only problem I have now is a weird repetition of
miniupnpd[23638]: recv (state0): Operation timed out
Should I just kill PID and let it reload - or leave it alone?(No matter - it has disappeared)
Meantime I did try limiting - but really not effective - reverted back to simple setup - seems to work best
Thanks again
-
On such hardware you might actually look in to trying m0n0wall. It's not as robust, but it's more catered to lower end hardware like you're running. It runs fine with 64MB on original Pentium speeds, some people run it on 486 class hardware. It would run perfectly fine in 128MB that you have.
m0n0wall and pfSense are very similar, in fact, pfSense is a fork off of the m0n0wall project.
-
I would put int all 4 sticks of ram if you can, get 384mb in there.
-
matguy - thanks for the suggestion. Have now looked at m0n0wall - if I had found it first I might have gone that way - but I am now more than convinced that pfSense is the way to go - even if I have to scale-up hardware a little. For now it seems to be very happy - as long as I don't hit the php too hard.
extide - nice suggestion but difficult with only two slots :) Seems in any case to be running smoothly with 128MB for now. Hopefully even better with 256MB when I get replacement. That will probably last for a while - until I can get the higher spec hardware sorted.
Thanks again for suggestions / help
What a great product - and an even greater community!!