CentOS 5.5 +Virtualmin slowdowns

12 posts / 0 new
Last post
#1 Thu, 05/19/2011 - 05:05

CentOS 5.5 +Virtualmin slowdowns

Hello, To cut the chase : The server has some slowdowns ( most of the time). I got some 500 error until yesterday when i changed some settings here and there following what i found with the help of google here and on some other forums. I got rid of the 500 error but the slowdowns are still there and i have no clue what to look for any more. - i have 56 running processes - 1 domain +1 subdomain (virtual server + sub virtual server) - 1 small website with 4-5 pages on the main domain - 1 forum ( not running - still working on it) on the subdomain)

System configuration : - CentOS 5.6 - Webmin version 1.540
- Virtualmin version 3.84 - Kernel and CPU Linux 2.6.18-238.5.1.el5.028stab085.3 on i686 - VPS 1GB RAM, 2GHz CPU

Other info that may help : CPU load averages => 0.40 (1 min) 0.89 (5 mins) 1.09 (15 mins) Running processes => 56 Apache version => 2.2.3 MySQL version => 5.0.77 BIND version => 9.3.6

My question : Is there a way to get rid of the slowdowns ? (or should i back up the virtual servers and just reload the OS, update the restore the Virtual servers)

Thank you,

PS. I forgot to add that i'm new to Linux and hosting.

Thu, 05/19/2011 - 13:15


Can you describe the slowdowns you're seeing? What's slow exactly? Is it one or two sites in particular, or everything?

If you run the commands "uptime" and "free -m", what output do you receive?


Thu, 05/19/2011 - 14:24

I run the commands and i get the following output : [root@v-470 ~]# free -m total used free shared buffers cached Mem: 2048 363 1684 0 0 0 -/+ buffers/cache: 363 1684 Swap: 0 0 0

[root@v-470 ~]# uptime 23:15:36 up 20:00, 1 user, load average: 0.36, 0.72, 0.57

The slowdowns usually lock me out of the system. Meaning that the SSH session usually gives me time out's, if i try to use the virtualmin web interface i get the same thing. If i'm lucky after a few attempts i manage to reboot it and the everything is ok for a while. The websites are loading very slow ( that is if they are loading at all). I have Ajax chat in one subdomain ( maximum 4 users online), a forum ( not launched yet so has little or no traffic at all) 1 website on the main domain that has no fancy scripts. ( Now it's 19.21 GMT and the fun is on again :(.

Thu, 05/19/2011 - 14:37

Well, your load average and available memory all look okay.

You may be resource constrained in some way. Based on your "free" output, I have a suspicion that you're using a VPS of some sort... perhaps OpenVZ?

It's possible that you aren't being given enough CPU or disk resources. If your load average isn't going above a 1.00, the sites on your server really aren't generating much of a load.

Another avenue to explore is that it's possible that your available bandwidth is the issue.

Does your provider offer bandwidth (and other resource) graphs? If so, you may want to review them and see if they show that you're using a lot of resources. And if you aren't, you may want to speak with them about how slow things are for you.


Thu, 05/19/2011 - 16:05

Bandwidth is not the issue. I have attached a screenshot from the VE Portal interface and one from the Virtualmin interface with the resources.
I just noticed one thing my Virtualmin interface ( and webmin) was shut down. [root@v-470 ~]# /etc/init.d/webmin restart Stopping Webmin server in /usr/libexec/webmin /etc/webmin/stop: line 4: kill: (1791) - No such process Starting Webmin server in /usr/libexec/webmin

Thu, 05/19/2011 - 16:12

Yeah, it's certainly sounding like you could be running into resource problems with your VPS or provider. Those are all very atypical issues :-)

What output do you receive if you run this command:

cat /proc/user_beancounters

Thu, 05/19/2011 - 16:14
I got lost on this. Thank you for all the help. Hope it's not too much trouble.

[root@v-470 ~]# cat /proc/user_beancounters

Version: 2.5
       uid  resource                     held              maxheld                                      barrier                limit              failcnt
      154:  kmemsize                  8614151             11161711             1                        1055923             11377049                38955
            lockedpages                     0                    8                                          256                  256                    0
            privvmpages                 91981               169025                                       524288               524288                    0
            shmpages                     5353                 5721                                        21504                21504                    0
            dummy                           0                    0                                            0                    0                    0
            numproc                        71                  109                                          240                  240                    0
            physpages                   39002                97416                                            0           2147483647                    0
            vmguarpages                     0                    0                                       262144               262144                    0
            oomguarpages                39084                97416                                       262144               262144                    0
            numtcpsock                     24                   66                                          360                  360                    0
            numflock                        8                   21                                          188                  206                    0
            numpty                          1                    1                                           16                   16                    0
            numsiginfo                      0                   92                                          256                  256                    0
            tcpsndbuf                  214984               731072                                      1720320              2703360                    0
            tcprcvbuf                  214112              1728112                                      1720320              2703360                    6
            othersockbuf               255288              1127248                                      1126080              2097152                   16
            dgramrcvbuf                     0               262104                                       262144               262144                  209
            numothersock                  149                  283                                          360                  360                    0
            dcachesize                 862002               979447                                      3409920              3624960                    0
            numfile                      2673                 3406                                         9312                 9312                    0
            dummy                           0                    0                                            0                    0                    0
            dummy                           0                    0                                            0                    0                    0
            dummy                           0                    0                                            0                    0                    0
            numiptent                      26                   26                                          128                  128                    0
Thu, 05/19/2011 - 16:31

That output shows various limits that are imposed on you by the OpenVZ container your provider has setup.

We can then use that output to see if you're seeing failures due to those limits.

And it does look like you are, although not the ones I expected to see :-)

There's a "failcnt" column at the very end that you can use to see if OpenVZ has prevented you from getting a resource that your system requested. Anytime that happens, something bad can occur :-)

The "kmemsize" has gotten quite a few, which is troubling. That's a kernel memory related parameter.

You're also seeing some failures with "dgramrcvbuf", "othersockbuf", and "tcprcvbuf". Those parameters are all related to networking.

What each of those means is all described in more detail here:


The thing to note though is that what you're seeing doesn't occur on a normal system :-) Something abnormal is going on, which is likely related to the limits setup for your system by your provider.

You may need to talk to them about the trouble you're seeing.

However, also note that these problems don't tend to come up on, say, Xen-based VPS's :-) So if you continue to have problems, you may want to consider a different type of VPS.


Thu, 05/19/2011 - 16:36

Now i finally got it. Well . The VPS is less 4£ / month but i will talk to them as it's not what they advertise. I will e-mail them right now. On the other hand i'll try to find another cheap unmanaged VPS ASAP as i can't afford a dedicated one now.

Once again thank you very much for all your help.

Thu, 05/19/2011 - 17:04

Forgot to ask. Would loading another OS then restoring my backups solve the problem ?

Small edit. I read some stuff on a few forums about fanatical VPS and i'll give them a go if the guys here do not solve the problem until tomorrow noon.

Thu, 05/19/2011 - 18:14


Well, it sounds like the problems you're having are issues with resources... so no, loading another OS wouldn't help that issue, unfortunately.

As far as VPS providers -- I can't speak to that one in particular... the only thing I can offer is that the forums here are littered with people who ran into the strangest of issues on OpenVZ based VPS's. With the way it handles limits, strange things can come up in varying circumstances.

There are of course folks who've had great luck with OpenVZ. The experience folks have may well be in how well the setup is of a particular provider.

But, I've heard of very few complaints from people on Xen-based VPS's :-)

When choosing a provider -- one thing I'll offer is that, at a minimum, you'd want 512MB of dedicated RAM.

Xen-based VPS's allow you to have swap, so even when they offer only 512MB of RAM, you can use a lot more than that.

OpenVZ systems don't have swap, they instead offer "burst" RAM. But burst RAM isn't dedicated memory, and any process using burst RAM could be killed off at any point to make room for processes on another users VPS if the host runs low on memory. Which can lead to really strange things happening :-)

If you're interested in learning a bit more about what goes on under the hood, there's a nice writeup on how all that works here:


Fri, 05/20/2011 - 02:59

As fas as i understand they are way better so now i'm looking for a cheap unmanaged XEN one. Thank you for the tip. I'll post back after i find one in case anyone else is interested.

Topic locked