What is maximum feasible/safe value of vm.pmap.shpgperproc
Subject says it all. When I originally installed pfsense with this hardware there was some jamming problem and then we resized this value from 200(default) to 500.
Today I checked dmesg and I had same problem as back then that value of vm.pmap.shpgperproc is insufficient.
I already changed new value to 850 and restarted pfsense after this. Problem doesn't exist anymore, but I just want to be sure, that there is no risk that I could broke something.
What packages do you have installed?
I've seen references around to people setting that >= 2048 so it may be fine even higher than that but it may depend on how much RAM you have.
I'm not running anything fancy atm, maybe the worst is L7-filtering for one of three subnets i'm having
There came some other errors, but then i changed structure from queue to action block and that fainted away.
OpenVPN Client Export Utility
Amount of ram:
real memory = 4294967296 (4096 MB) avail memory = 3400409088 (3242 MB)
I'm not familiar with how strikeback works in terms of ram/process usage, but it could be either that or L7 to blame there.
I can live without strikeback, but L7-filtering for two machines is causing this?
I admit that you didn't know the amount of clients in that subnet.
When I used L7 with structure queue there came some other errors, not this.
The load for L7 isn't really about how many machines there are, but the amount of bandwidth run through it.
Though as I said, it could be either one. Only way to know would be to set that value back down low, and deactivate one or the other and see if it comes back.
Strikeback is now removed. I'll wait if that error come back again.
But for future use, is there any rule of thumb that what value you can give to vm.pmap.shpgperproc?
Meaning that if you have this some/enough RAM or vm.pmap.something valued of something
The default is sufficient for most people, there really isn't any one "good" value for a tunable like that, it really depends on the specific situation.