Recently, i installed Virtualmin on a VPS from GoDaddy. The problem i have been facing is that the Bind DNS Server automatically stops after some time.
The website is then not accessible until i manually start the Bind DNS Server.
I have 1 GB of RAM on my server and usually the complete RAM is being used (as shown by the welcome screen of Virtualmin). Is this problem because of RAM overload? or some other problem?
Please Help.
Howdy,
What kind of VPS do you have? Is it Xen, KVM, OpenVZ?
Also, if you run “dmesg” and review the end of the output, do you see any errors that suggest there was a memory problem?
Lastly – what output do you see if you run “free -m”?
-Eric
Thanks for the reply
Its an OpenVZ VPS.
When i run “dmesg”, there is no output!!
When i run “free -m”, i see the following output
total used free shared buffers cached
Mem: 1024 928 95 0 0 0
-/+ buffers/cache: 928 95
Swap: 0 0 0
Thanks for the info! Can you paste in the output of the file /proc/user_beancounters? That’s an OpenVZ-specific file for showing certain types of resource usage.
-Eric
This message looked like I could have written that I had the exact same problem.
Was there a resolution to this problem? Is it a Go Daddy related issues ? While searching I found for other similar messages all related to the VPS at Go Daddy. Could the fact that . ram is showing full is closing bind. My bind stops every five minutes
Yeah, unfortunately, the forums and support tracker are full of folks who’ve had similar problems with OpenVZ-based VPS’s.
The issue is that OpenVZ allows Linux to allocate memory for services, using non-guaranteed RAM.
If another user on the host requires RAM, OpenVZ can take away your non-guaranteed RAM to give it to someone else.
Doing that will cause any service that was using that RAM to crash.
There’s unfortunately no fix for that. As a workaround, you can reduce how much RAM you’re using… but it’s often just a matter of time until your Linux system begins using non-guaranteed RAM, since it’s all presented to the Linux kernel as available RAM.
While you’re looking into all that, one thing you could do to help with services crashing is to go into Webmin -> Others -> System and Server Status, and in there you can configure it to restart services that stop.
-Eric
I upgraded the RAM from 1GB to 2GB hand the server has run 20 hours without Bind crashing. That seems to have solved the problem which I can now see with the extra RAM. Named service is using 1.4GB of RAM memory which seems very high.
9744 named 1326096 kB /usr/sbin/named -u named
If I change ClamAV to Standalone scanner (clamscan) move Clam AV out of RAM?
The system is still running from 1.6GB to 2GB.
I confirmed with GD support that the RAM shown is actual used not RAM assigned.
total used free shared buffers cached
Mem: 2048 1998 49 0 0 0
-/+ buffers/cache: 1998 49
Swap: 0 0 0
Added output:
/proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
10086860: kmemsize 40065171 40340654 9223372036854775807 9223372036854775807 0
lockedpages 0 0 9223372036854775807 9223372036854775807 0
privvmpages 522138 522495 1048576 1048576 0
shmpages 1192 1192 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numproc 111 112 32567 32567 0
physpages 381297 381596 9223372036854775807 9223372036854775807 0
vmguarpages 0 0 524288 9223372036854775807 0
oomguarpages 381297 381596 9223372036854775807 9223372036854775807 0
numtcpsock 42 44 9223372036854775807 9223372036854775807 0
numflock 119 120 9223372036854775807 9223372036854775807 0
numpty 1 1 255 255 0
numsiginfo 0 1 1024 1024 0
tcpsndbuf 736512 771584 9223372036854775807 9223372036854775807 0
tcprcvbuf 688128 720896 9223372036854775807 9223372036854775807 0
othersockbuf 260032 293984 9223372036854775807 9223372036854775807 0
dgramrcvbuf 0 8480 9223372036854775807 9223372036854775807 0
numothersock 152 169 9223372036854775807 9223372036854775807 0
dcachesize 2456984 2481398 9223372036854775807 9223372036854775807 0
numfile 10263 10336 9223372036854775807 9223372036854775807 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 14 14 9223372036854775807 9223372036854775807 0
To follow up - the server with the upgrade to 2gb of RAM is still running with no problems. That seems to have solved the problem.