There’s about a million failures for private virtual memory page allocations, so it indeed it is a memory related issue.
I guess you need to save memory in Virtualmin, or ask your hoster to increase the “privvmpages” limit for you. Eric might have some ideas too, since I’m not familiar with this kind of virtualization.
(Didn’t know that other services besides OpenVZ use the beancounter file, otherwise I’d have asked for it immediately without the “if you’re running under OpenVZ” restriction.)
If the memory is now free, do you have any ideas why Virtualmin/Webmin wouldn’t be staying up after I run /etc/init.d/webmin start? Or is trying to pull it up perhaps responsible for the memory spike recorded in this beancounters output? It seems like rebooting might help if it’s a memory related issue? Assumedly SpamAssassin is down because its process is resource-intensive too? I’ve never had similar trouble over the past year+ (everything typically ticks along fine around 1GB of memory usage out of my guaranteed 2GB… in fact I already have the server tuned for minimal memory usage as I used just to have 1GB of guaranteed memory before I got a free upgrade).
Unfortunately I’m not really familiar with OpenVZ and related virtualization systems that use the beancounters file, so I can’t really say why the memory allocation requests fail. Eric might be able to say more about this.
The general consensus and suggestion is (considering the myriad of problems we’ve seen in this forum that are related to OpenVZ-like systems) to not use such a virtualization hoster with Virtualmin.
It might be as simple as asking your hoster to increase the beancounter limits that fail for you. It might also be that there’s no real solution and you need to find another hoster. But as I said, I can only guess here, Eric might know more.
Thank you @Locutus for taking your time during the holidays with this thread… and you were right all along about it being a memory/resource issue 
The latest message to root was fatal: couldn't execute /usr/bin/gpg: Cannot allocate memory Rebooting the server brought Virtualmin and SpamAssassin back up and everything is running as normal again.
Howdy,
Yeah, as Locutus mentioned, you are seeing resource failures with your VPS.
It appears that your provider is either using OpenVZ or Virtuozzo, and those VPS types can have issues where even if you aren’t technically out of RAM, if you’re using what they call “burst memory”, memory can be taken away from one of the processes on your server using that RAM to give to another user on that host, if they need it.
What you’d want to do is ask your provider for more guaranteed RAM, as you seem to frequently be running out of RAM.
Each time a failure shows up in that user_beancounters file – that failure represents a process that may be killed off due to a resource problem.
-Eric
I’ve noticed some oddities actually in Virtualmin with my reported memory usage. It was after some upgrade or other (some Virtualmin upgrade in the past maybe six months or so?) The issue is that Virtualmin started reporting real memory usage at half its actual usage. Right now it says: Real memory 3.42 GB total, 590.42 MB used but in fact I’m using twice that much memory. The memory available is correct, however… I’m actually supposed to get 2GB of memory guaranteed, up to 4GB burstable, and it never appears (in the historical data within Media Temple’s control panel) as if I’ve gone over 50% usage of my guaranteed allocation, so it’s odd that the beancounters file indicates these RAM usage problems… but perhaps it’s that Plesk Virtuozzo software, I’m not any fan of their software.
Here’s the current state of the beancounters file, no failures so far… I’ll definitely keep an eye on this file from time to time now I know it exists!
Version: 2.5
uid resource held maxheld barrier limit failcnt
90999: kmemsize 69569131 70860800 228000000 240000000 0
lockedpages 0 0 1200 1200 0
privvmpages 276047 277960 896536 943718 0
shmpages 1206 1206 90000 90000 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numproc 104 135 600 600 0
physpages 261641 265441 896536 943718 0
vmguarpages 0 0 524288 2147483647 0
oomguarpages 157361 157361 524288 2147483647 0
numtcpsock 47 47 2000 2000 0
numflock 10 11 1000 1100 0
numpty 1 1 100 100 0
numsiginfo 0 30 1024 1024 0
tcpsndbuf 948552 948552 10000000 20000000 0
tcprcvbuf 770048 770048 10000000 20000000 0
othersockbuf 383792 388464 5000000 10000000 0
dgramrcvbuf 0 0 10000000 10000000 0
numothersock 300 302 2000 2000 0
dcachesize 39941079 40034396 57000000 60000000 0
numfile 4115 4165 40000 40000 0
dummy 0 0 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numiptent 34 34 500 500 0Depending on usage (number of websites, use of PHP, FTP uploads, incoming emails, spam and virus scanning, other general activity), the server’s memory usage could over time easily peak over 2 GB, even if the average is lower. “Burstable” memory is very unreliable, as you’ve seen, and can lead to processes being killed randomly if they hold that memory for too long.
Having burstable memory is even counter-productive in this case. The OS sees that it has 4 GB of memory, and wants to make use of it. It does not know that half of that memory is dangerously unreliable.
Also note that you’re already using about one third of the allowed privvmpages, so with some time of usage, the limit could be reached again.
I suppose the only way to somewhat reliably prevent that (aside from not using Virtuozzo/OpenVZ) would be to regularly reboot the server. Or have a script monitor the beancounters and reboot the server if some limit is being reached. Both of which I’d not recommend for serious web hosting.