BIND DNS Server Stops on its own

8 posts / 0 new

Topic locked

#1 Thu, 04/18/2013 - 15:50

vitulgoyal

BIND DNS Server Stops on its own

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.

#2 Thu, 04/18/2013 - 20:58

andreychek

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

#3 Thu, 04/18/2013 - 23:55

vitulgoyal

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

#4 Fri, 04/19/2013 - 07:59

andreychek

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

#5 Thu, 04/25/2013 - 13:36

calderwood

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

David Calderwood - Euro-Pacific Digital Media

#6 Thu, 04/25/2013 - 22:18

andreychek

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

#7 Fri, 04/26/2013 - 09:48 (Reply to #6)

calderwood

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

David Calderwood - Euro-Pacific Digital Media

#8 Wed, 05/01/2013 - 06:09 (Reply to #7)

calderwood

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.

David Calderwood - Euro-Pacific Digital Media

Topic locked