Submitted by pban02 on Thu, 09/20/2012 - 06:54 Pro Licensee
Versions where the problem was observerd:
<
blockquote> - Virtualmin: 3.93.gpl or 3.94.gpl - Webmin 1.590 - Linux: Debian 6 (Kernel: 2.6.32-5-openvz-amd64)
<
blockquote>
Status:
Active
Comments
Submitted by andreychek on Thu, 09/20/2012 - 08:35 Comment #1
Howdy -- we've occasionally seen that behavior on OpenVZ based systems... it's typically a sign of a resource problem.
What output do you see from this command:
free -m
And can you paste in the contents of the file "/proc/user_beancounters"? Thanks!
Submitted by pban02 on Thu, 09/20/2012 - 13:47 Pro Licensee Comment #2
# free -mtotal used free shared buffers cached
Mem: 6144 3966 2177 0 0 0
-/+ buffers/cache: 3966 2177
Swap: 0 0 0
# cat /proc/user_beancountersVersion: 2.5
uid resource held maxheld barrier limit failcnt
378: kmemsize 32721366 63490091 9223372036854775807 9223372036854775807 0
lockedpages 0 973 9223372036854775807 9223372036854775807 0
privvmpages 1015967 1631647 1572864 1572864 22436
shmpages 329418 723277 9223372036854775807 9223372036854775807 0
dummy 0 0 0 0 0
numproc 98 166 9223372036854775807 9223372036854775807 0
physpages 457687 788223 0 9223372036854775807 0
vmguarpages 0 0 9223372036854775807 9223372036854775807 0
oomguarpages 461906 801823 9223372036854775807 9223372036854775807 0
numtcpsock 20 140 1801439850948198 1801439850948198 0
numflock 308 323 9223372036854775807 9223372036854775807 0
numpty 2 6 9223372036854775807 9223372036854775807 0
numsiginfo 4 98 9223372036854775807 9223372036854775807 0
tcpsndbuf 362144 6732368 4611686018427387903 9223372036854775807 0
tcprcvbuf 327680 8518208 4611686018427387903 9223372036854775807 0
othersockbuf 175712 3263848 4611686018427387903 9223372036854775807 0
dgramrcvbuf 0 4360 9223372036854775807 9223372036854775807 0
numothersock 144 558 1801439850948198 1801439850948198 0
dcachesize 889403 1384340 9223372036854775807 9223372036854775807 0
numfile 5772 11422 9223372036854775807 9223372036854775807 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 14 20 9223372036854775807 9223372036854775807 0
Submitted by andreychek on Thu, 09/20/2012 - 14:12 Comment #3
Okay, you do have a decent amount of RAM in your "free" output, it looks like about 6GB.
However, note the "failcnt" field in the user_beancounters file... that's showing that your "privvmpages" resource has had "22436" failures.
Memory failures are pretty harsh, and can lead to services crashing when they don't get the RAM they request.
You may want to talk to your provider, and ask about raising your resource limits.
Submitted by pban02 on Thu, 09/20/2012 - 14:17 Pro Licensee Comment #4
I am my own provider :) But I haven't found a sensible way to prevent these PRIVVMPAGES failcounts from staying at 0. However much memory one gives the system, it always seems to run up against the limit.
Do you have any tips?
Submitted by andreychek on Thu, 09/20/2012 - 14:26 Comment #5
Sorry, I'm unfortunately not familiar with setting up OpenVZ :-)
I'll offer that I prefer Xen and KVM, as they seem a little more, well, welcoming to the various processes running within them :-)
Were you to use those, you could even use the free version of Cloudmin to provision them.
Each of those supports using swap space as well, so you don't have to rely fully on RAM. That makes it so that even if you were to temporary run low on RAM, that's not an emergency that would cause processes to start crashing (since they could begin using that swap).
Submitted by pban02 on Thu, 09/20/2012 - 17:16 Pro Licensee Comment #6
I wanted to go for KVM but wasn't able to get the bridged routing working and went with openvz as a temporary measure. was having trouble making the kvm visible to the outside world on a public ip. will be happy to try cloudmin if I can get around this issue.
didn't realize that openvz doesn't swap.
thanks for the advice.