Ram alocation
-
I have a Pfsense box with 32 Gb of Ram
Currently under System - Advanced - Miscellaneous
I have set
/TMP at 512 K
/VAR at 8096 K
Under STATUS : DASHBOARD I am showing memory usage of 27% of the full 32718 MB
VAR Directory size while sitting at 88%
116K /var/run
88K /var/etc
40K /var/unbound
9.6M /var/log
8.0K /var/tmp
8.0K /var/lightsquid
8.0K /var/cron
8.0K /var/at
6.8M /var/dhcpd
6.4G /var/db
4.0K /var/empty
1.3M /var/squidQuestion 1 clearly this calculation does not include the 2 ram disks correct?
Question 2 This machine is used for a public Wi-Fi network supporting up to 500-600 simultaneous users and as many as a 1000 different connection thorough out a Midnight to midnight day. When I have 2 different back to back large groups meaning that in a 24 hour period there may be 2000 different devices. Everything works fine until the /var directory becomes full and locks the system up. How large can I set the /VAR ram drive given the above parameters?
Question 3 Does it make more sense to move some of the NTOP or other Data to the SSD drive with the OS and if so which data and can you point me in the direction to figure out he proper procedure?
Thank you in advance
gsdelong
-
It makes sense to move ALL the data to HDD/SSD. Stop doing unsupported hacks with partitioning and moving things around selectively. Stop placing things into ramfs that you expect to exist after reboot.
-
I value your response although I am having a hard time understanding it.
I am confused by your statement, This was a straight install.
What unsupported hack in specific are you talking about so that I can reverse it?
This box has been up and running for about a year supporting 100's of users on a daily basis with only 2 incidents as described so I do not think anything too stupid was done
-
So what "moving" are you talking about? If that's a full install, simply forget about the /var ramdisk. Not usable until it's separated from /tmp (there's a pull request somewhere on GitHub.)
-
Again, I may be dense but I do not see how your reply helps me solve my problem at all.
I have preformed what I think is a standard install
I posted the parameters I have set using the PFsense management interfaces and under the described conditions I run out of space in the /VAR directory causing the system to stop handing out DHCP address and eventually it appears will not renew existing ones.
If your reply does have my answer in it can you simplify it for me so I know where to look for resolution?
The "moving" i was talking about was simply that there seems to be two ways to resolve this issue double the size allocated for /VAR or move something so it does not use space on /Var.
I suppose a third option may be to try to understand what is making the /var/db directory so big.
As I believe in your approach of not making unsupported alterations I reached out to knowledgeable people to find their suggestions.
-
You have no problem. Unconfigure the ramdisk, reinstall packages and forget that the option exists there in the GUI. /var/db is of course big due to packages, notably ntop*. Again, those are data you do NOT want to lose on reboots.
-
it does make sense :-)
enabling /var ramdisk is very risky.On the other hand, because pfSense support packages like HTTP proxy that may generate significant amount of log and because there is, as fat as I know, now process aiming to automatically perform any clean-up, it would make sense, at least to me, to benefit from install "out-of-the-box" creating at least different partitions so that pfSense doesn't crash because system partition is full.
Am I correct or is there something I've missed?
-
Well, not sure what proxy we are talking about. The Squid3 package will log access to /dev/null if access log is disabled (surely could be extended to other logs) and has the logs location configurable (though, it will refuse to manage the dirs in any way if they're outside of /var/squid, so whatever mounts should be under that dir.)
For ntop* packages, the ramdisk thing is outright broken, there's nothing implemented to deal with it, so the packages are not available on nanobsd installs at all.
-
You have no problem. Unconfigure the ramdisk, reinstall packages and forget that the option exists there in the GUI. /var/db is of course big due to packages, notably ntop*. Again, those are data you do NOT want to lose on reboots.
I am following you now.
One point of clarification, the environment this is in can have a couple of hundred users or more (450) this morning walk into a room and connect to the Wi-Fi at the same time.
Do you think that moving from ram disk will negatively impact the speed of the DHCP server which I believe is why I choose Ram-disk to begin with after research?
This is a public network and I really don't need the data after a reboot. I occasionally use the data to blacklist a down loader or file sharing user. But since I may see the average user once a year if ever again it seems to be of little value.
-
With SSD? Surely not… (Also, DHCP has something implemented to dump the leases DB to HDD periodically, IIRC, see System: Advanced: Miscellaneous.)
-
OK
So simply uncheck the use ram disk for /TMP and /VAR and reboot
then reinstall any packages I previously installed?
-
Yeah, sounds like a plan. (If you want a separate ramdisk for /tmp only, perhaps dig up the pull request on GitHub.)