Page 1 of 2 12 LastLast
Results 1 to 40 of 43

Thread: VPS Load

  1. #1

    VPS Load

    Hello,

    I am currently a customer of slhost, which has been excellent, in all but one regard. Often (almost daily, and sometimes several times a day) the CPU load climbs between 1 - 4 for a number of minutes. While this happens, the VPS is unusable.

    I feel a bit petty complaining about 5 - 10 minutes of unusable time a day, but I find it very frustrating none the less. Their support team has been able to do nothing to correct this issue - even after many attempts.

    Is this normal? Should I expect this with all similar VPS plans?

    I am on a plan with 256MB Ram, for about $25/month.


    Thanks,
    Ron

  2. #2
    Join Date
    Dec 2005
    Posts
    3,077
    You really need to track down the cause of the load spikes. It's quite likely to be statistics or log rotation software running on your VPS.

    Are you running any control panels or Awatsts/Webalizer etc?

    Although the VPS is Unusable under load, try to get into ssh and grab the output of "top -c" so you can get an idea on what processes are causing the high load/cpu usage.

  3. #3
    Hi Chris,

    Thanks for the reply. I have looked at top, and my processes are normal. The CPU load seems to be coming from another node.

    I have created an 'uptime' log that notes CPU use every minute. This log reveals that a cron job is one culprit - the load spikes every 10 minutes. This spike is even greater after a moderate load has been on the CPU for some time. It would seem to me this is a stats job running on an active web server. I have pointed this out to slhost support, but they have not resolved the issue even armed with this information.

    Other times I just experience heavy load without any pattern. Again, it all seems to be coming from another node.

    Do any plans at this level (256MB ram for $25/mo.) offer CPU fair share? Is this kind of experience just to be expected for a low end VPS?

    Thanks,
    Ron

  4. #4
    Join Date
    Feb 2004
    Location
    Sacramento CA
    Posts
    3,342
    What has SLhost said about these spikes?

  5. #5
    Join Date
    Jan 2006
    Location
    Sydney, Australia
    Posts
    251
    Load spike on Linux can be caused by I/O wait, which is often the case on VPS. If one VPS is trying to take all the CPU time, the load rise should be more gradual as scheduler will ensure fairshare on CPU time. However VZ3 (which I think is what SLHost is using) doesn't really have a IO scheduler so someone doing a heavy backup for a few minutes can easily kill other VE on the same host. All your processes will bank up waiting on IO, which causes the sudden spike.

  6. #6
    SLHost normally replies by saying they have taken a look at it, and the load is normal now. I have complained a bit, saying of course it is normal, it only lasts a few minutes... but annoying still. They never really get past the fact that it seems fine now... I don't think they get the fact that the persistence of the problem has worn on my nerves.

    As far as I/O goes, I have definitely seen that on occasion. Once I emailed them with a load average of 40! Their response was fsck was being run, and to be patient.

    I am not sure if I/O would be causing my every day complaints though. I have pasted a 2 hour snippet of my 'uptime' log. This log is only showing lines where the load is above 1 (using grep to cut out the others).

    Does this look normal? Does it look like I/O?

    Thanks,
    Ron

    13:32:01 up 1 day, 32 min, 0 users, load average: 1.24, 0.51, 0.22
    13:33:01 up 1 day, 33 min, 0 users, load average: 1.17, 0.62, 0.27
    13:34:01 up 1 day, 34 min, 0 users, load average: 1.03, 0.71, 0.32
    14:07:26 up 1 day, 1:08, 0 users, load average: 1.31, 0.47, 0.22
    14:07:26 up 1 day, 1:08, 0 users, load average: 1.31, 0.47, 0.22
    14:10:05 up 1 day, 1:10, 0 users, load average: 2.71, 1.08, 0.45
    14:10:08 up 1 day, 1:10, 0 users, load average: 2.89, 1.14, 0.48
    14:11:02 up 1 day, 1:11, 0 users, load average: 2.67, 1.37, 0.59
    14:12:01 up 1 day, 1:12, 0 users, load average: 1.61, 1.30, 0.62
    14:13:01 up 1 day, 1:13, 0 users, load average: 1.22, 1.25, 0.64
    14:14:01 up 1 day, 1:14, 0 users, load average: 1.14, 1.21, 0.66
    14:15:01 up 1 day, 1:15, 0 users, load average: 1.05, 1.17, 0.68
    14:16:01 up 1 day, 1:16, 0 users, load average: 1.94, 1.42, 0.79
    14:17:01 up 1 day, 1:17, 0 users, load average: 2.04, 1.54, 0.87
    14:18:01 up 1 day, 1:18, 0 users, load average: 1.20, 1.42, 0.87
    15:17:05 up 1 day, 2:17, 0 users, load average: 1.26, 0.56, 0.26
    15:21:01 up 1 day, 2:21, 1 user, load average: 1.45, 0.83, 0.42
    15:22:41 up 1 day, 2:23, 1 user, load average: 2.80, 1.40, 0.66
    15:23:03 up 1 day, 2:23, 1 user, load average: 2.64, 1.46, 0.69
    15:24:03 up 1 day, 2:24, 1 user, load average: 2.63, 1.65, 0.80
    15:25:01 up 1 day, 2:25, 1 user, load average: 2.86, 1.87, 0.93
    15:26:01 up 1 day, 2:26, 1 user, load average: 2.98, 2.07, 1.06
    15:27:01 up 1 day, 2:27, 1 user, load average: 3.14, 2.28, 1.19
    15:28:05 up 1 day, 2:28, 1 user, load average: 2.26, 2.19, 1.23
    15:29:01 up 1 day, 2:29, 1 user, load average: 2.02, 2.15, 1.27
    15:30:01 up 1 day, 2:30, 1 user, load average: 1.80, 2.04, 1.29
    15:31:02 up 1 day, 2:31, 1 user, load average: 1.18, 1.85, 1.27

  7. #7
    Join Date
    Jan 2006
    Location
    Sydney, Australia
    Posts
    251
    Quote Originally Posted by rfulkerson View Post
    Does this look normal? Does it look like I/O?
    It is very difficult to see from loadavg. The easiest way to analyse is to use tools like vmstat. Run something like this during high-load time

    Code:
    $ vmstat 5
    It will produce a new line of stats every 5 seconds. Run it for a few minutes. On Virtuozzo it is a bit crippled so you can't see the swap activity nor block I/O, but the right-most column "wa" should still give you how much time CPU is waiting for IO.

  8. #8
    Thanks for the tip! Here is what it looks like with corresponding load.

    Thanks,
    Ron


    Uptime:
    11:22:32 up 1 day, 22:23, 2 users, load average: 4.73, 3.56, 1.95

    Vmstat:
    procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
    r b swpd free buff cache si so bi bo in cs us sy id wa
    0 3 973540 161776 57564 1029808 0 0 0 0 0 19176 0 0 75 25
    0 3 971060 167760 58608 1034076 0 0 0 0 0 18968 0 0 72 28
    0 3 970840 175480 59616 1029792 0 0 0 0 0 18951 0 0 78 22
    0 2 970824 148448 60316 1035804 0 0 0 0 0 17781 0 0 57 43
    0 2 970776 136704 61020 1041008 0 0 0 0 0 19370 0 0 74 26
    0 5 970616 122616 61964 1068404 0 0 0 0 0 20109 0 0 76 24
    0 3 969180 119896 63180 1061500 0 0 0 0 0 20653 0 0 67 33
    0 2 950388 135648 64164 1060280 0 0 0 0 0 18652 0 0 70 30
    0 2 950388 121752 65240 1082736 0 0 0 0 0 19450 0 0 74 25
    0 2 949372 166272 66036 1044584 0 0 0 0 0 19952 0 0 61 39
    0 3 949336 188768 67056 1012572 0 0 0 0 0 20044 0 0 55 44
    0 2 949328 225888 67944 982488 0 0 0 0 0 20145 0 0 60 40
    0 2 939792 268648 68840 959984 0 0 0 0 0 19629 0 0 41 59
    0 1 939768 267368 69704 968552 0 0 0 0 0 20730 0 0 71 29
    0 1 933136 318488 70716 948300 0 0 0 0 0 20587 0 0 83 17
    0 2 933136 337176 71576 918952 0 0 0 0 0 19918 0 0 73 27
    0 5 933108 324304 72656 926400 0 0 0 0 0 20296 0 0 35 65
    0 9 933036 317960 74112 939752 0 0 0 0 0 23042 0 0 28 72
    0 1 932772 494920 75008 913556 0 0 0 0 0 20673 0 0 60 40
    0 3 918376 551080 75944 878612 0 0 0 0 0 20216 0 0 61 39

  9. #9
    Join Date
    Nov 2005
    Location
    Michigan, USA
    Posts
    3,872
    The load average is per VPS, so the load you are seeing is load running on your VPS, not on the main physical server or any other VPS.

    It could be many different things like others have said, you can't determine something by just looking at your load average. When you have a slowdown or spike next time, open up top and see what is using your CPU.

    If the CPU is being used in wa (wait) then it could be something with the disk i/o.


  10. #10
    I am fairly confident this is not the case for my VPS. On occasion, slhost has had a meaningful response - for instance another VE was under a DDOS attack. That effected my VE - and the cpu load shown in uptime reflected that.

    In the past top has not shown any of my processes to be extremely busy. That said, I am eager to take a snapshot of it next time the load shoots up. I think this thread has been very informative and I hope the discussion will continue till a solution is found!

    Thanks,
    Ron

  11. #11
    Also, here is the (typical) response from SLHost. Please realize I think these guys are great (at least the first 6 months were), but this seems to be a persistent problem on the main node.

    Is this what I can expect from all VPS plans? Do I just have live with it, or would another host (possibly Xen based) be better?

    Thanks,
    Ron

    SLHost Response:

    Hello,
    Load on your server was high because the load on the main node was high. Central node has been stabilised now and the load on your server too is very normal. Please check.

  12. #12
    Join Date
    Nov 2005
    Location
    Michigan, USA
    Posts
    3,872
    The differences between Xen and VZ would not be noticed in this situation. This could happen anywhere I suppose, but if it is a persistent problem caused by the main node then KnownHost should be able to track down the usage and find which VPS is causing the problem.

    The only reason the VPS load average would go up because of the node is because it is waiting for disk, that is why I said to open up top and see where the usage is. If their is a lot of CPU under the wait (wa) category then the problem is being caused by the main node's disks. If not, then their could also be a problem within your VPS.

    Is this a managed VPS? If so, they should track it down for you, if not, you may want to look into a managed solution if it does not resolve.


  13. #13
    Join Date
    Jan 2006
    Location
    Sydney, Australia
    Posts
    251
    Quote Originally Posted by rfulkerson View Post
    Thanks for the tip! Here is what it looks like with corresponding load.
    Yeah. Very obvious isn't it? CPU spends at least 1/4 of its time waiting for IO and that's why the load shoots up, and us/sy is always almost 0 which means your VPS is hardly using any CPU at all. Also note the column "b" (second from the left) -- that is the number of processes blocked on IO (instead of number of processes fighting for CPU time, which is under "r" column). It certainly looks bad on your VPS.

    Someone is doing some heavily I/O stuff on the host node. Swap at around 900MB might be contributing to it but I doubt it is the cause, as cached is at ~1GB. I seriously have no idea. It could be someone running a constant backup, or someone running a busy site with a badly configured MySQL, or someone running a BitTorrent client that steals all the disk IO (and IMHO all VPS providers should ban BitTorrent clients).

    Quote Originally Posted by devonblzx View Post
    The differences between Xen and VZ would not be noticed in this situation. This could happen anywhere I suppose...
    True.

    However at least on Xen hosts the bi/bo columns will show the correct figure, so you can then go and tell your provider that it is NOT your VPS that is using all the IO bandwidth because of bi/bo is low.

    But on VZ hosts, provider can easily find out the offending processes using things like iosta, which will be more difficult on Xen I guess.

  14. #14
    This has been a very informative thread thus far! I have learned a lot about what really impacts a VPS, and better ways of finding and reporting it.

    Just to be sure I understand, a single node (VE) on a VPS cannot really impact the CPU on some other VE on the same host, except through disk IO (forcing the CPU into a wait state).

    I am not clear which tools report system wide performance, and which report performance just on my VE. It seems to me that vmstat and uptime report system wide, while top reports just my VE (with the exception of load average). Other tools, like iostat and sar, do not work on my VPS so I have no idea there.

    Top has me a little confused where in the Cpu(s) header 1.5% CPU will be used, and at the same time the %CPU column will report 10% use. Why is there a difference?

    If anyone could comment on the above I would be most appreciative.


    Thanks for all the input!

    --Ron

  15. #15
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    645
    When in top, press '1' to see all the CPU's listed separately.
    VPSVille.com
    Toronto, London, Dallas, Los Angeles
    Quality VPS hosting on Premium bandwidth

  16. #16
    Quote Originally Posted by rfulkerson View Post
    This has been a very informative thread thus far! I have learned a lot about what really impacts a VPS, and better ways of finding and reporting it.

    Just to be sure I understand, a single node (VE) on a VPS cannot really impact the CPU on some other VE on the same host, except through disk IO (forcing the CPU into a wait state).

    I am not clear which tools report system wide performance, and which report performance just on my VE. It seems to me that vmstat and uptime report system wide, while top reports just my VE (with the exception of load average). Other tools, like iostat and sar, do not work on my VPS so I have no idea there.

    Top has me a little confused where in the Cpu(s) header 1.5% CPU will be used, and at the same time the %CPU column will report 10% use. Why is there a difference?

    If anyone could comment on the above I would be most appreciative.


    Thanks for all the input!

    --Ron
    Unfortunately in VPS environments it's hard or even impossible to get system wide information about what the hardware node and other VEs are doing from your VE (That is the purpose of isolation between VE and the host hardware)

    It is however possible for your provider to access this information in order to troubleshoot loaded servers (At least in Xen, which is what I use)

    Regards,
    Jorge Luis

  17. #17
    Join Date
    Feb 2004
    Location
    Sacramento CA
    Posts
    3,342
    I for one would want a host that would be a bit more pro-active in finding out what's going on. If it is a node spike then it will be affecting all of their customers on that node so it should be something they would want to get to the bottom of. At the very least clearly demonstrate that it's just your VPS.

  18. #18
    Join Date
    Nov 2006
    Posts
    50
    According to the information you have posted so far, I think it is clear the problem is not of your vps.
    If it was me, I would insist with support to fix the problem. You are completely right about your fustration, you are not beeing petty at all.
    "The load is normal now" would be an unacceptable answer for me with a recurring issue like that.

    Rui

  19. #19
    i have the same load problem on 4 VPS hosted there. 3 of them are on the same node. Load was fine until January. Fom the middle of january i have high load first on a VPS (lets say Node A) then magically it has going over on to another node where i have 3 VPS hosted. (lets say Node B) What i can say is that there support was very good for repsonse etc. (they upgraded anything on those VPS enable disable services etc. etc.) Then they say the high load comes from mailserver that use a lot of resource and suggest a ram upgrade. I am not sure if this will fix that problems....but will let you know.


    BTW: I also have suspended All accounts on VPS (that stays on Node A) But load was still high....

  20. #20
    I have invited SLHost to join this thread! Here is my most recent email to them, lets hope to see a response here!


    The load on my VPS is high once again. I have included information from uptime, top, and vmstat to give you a snapshot of this ongoing problem. You will notice the VPS has become unusable as it is blocked on I/O. As usual, a full uptime log is available on /var/log/load_avg.

    Also, a thread is discussing this persistent issue on Web Hosting Talk. I have let others know of my troubles, and the typical 'its fine now' response. I invite / urge you to join this thread with your input. I think you will want to fairly represent yourself, give a good defense, and (my hope is) this thread may help you to finally resolve this issue.

    Thanks,
    Ron

    [--- Domain information was here ---]


    UPTIME:
    11:04:02 up 10 days, 22:04, 1 user, load average: 2.74, 1.77, 0.77

    TOP:
    top - 11:04:36 up 10 days, 22:05, 1 user, load average: 2.10, 1.71, 0.78
    Tasks: 46 total, 1 running, 45 sleeping, 0 stopped, 0 zombie
    Cpu(s): 0.0% us, 0.0% sy, 0.0% ni, 77.3% id, 22.7% wa, 0.0% hi, 0.0% si
    Mem: 8298836k total, 8214516k used, 84320k free, 21640k buffers
    Swap: 6144852k total, 1625464k used, 4519388k free, 1007368k cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    1 root 15 0 1868 624 528 S 0 0.0 0:08.52 init
    32118 daemon 22 0 1604 308 236 S 0 0.0 0:00.00 portmap
    32340 root 16 0 1556 548 444 S 0 0.0 0:18.79 syslogd
    32360 root 18 0 1500 352 284 S 0 0.0 0:00.00 klogd
    32482 postgres 15 0 17224 2152 1776 S 0 0.0 0:00.47 postmaster
    32493 postgres 16 0 8024 1244 476 S 0 0.0 0:00.01 postmaster
    32495 postgres 16 0 7032 1008 568 S 0 0.0 0:00.02 postmaster
    4057 root 16 0 13872 1092 780 S 0 0.0 0:21.82 nscd
    5171 root 16 0 1672 572 484 S 0 0.0 0:00.00 inetd
    5414 root 18 0 2536 732 620 S 0 0.0 0:00.00 xinetd
    5819 bind 18 0 37248 2952 1684 S 0 0.0 0:08.18 named

    VMSTAT:
    procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
    r b swpd free buff cache si so bi bo in cs us sy id wa
    0 1 1625180 36848 26676 1058512 0 0 0 0 0 1758 0 0 75 25
    0 1 1625116 36088 27840 1050248 0 0 0 0 0 2119 0 0 75 25
    0 1 1624996 50456 29080 1044316 0 0 0 0 0 2031 0 0 76 24
    0 1 1624312 32056 30116 1069196 0 0 0 0 0 1907 0 0 64 36
    0 1 1624312 51568 30868 1057672 0 0 0 0 0 2027 0 0 75 25
    0 1 1624312 40864 31736 1065080 0 0 0 0 0 2354 0 0 74 26
    0 1 1624308 69816 32892 1051672 0 0 0 0 0 2755 0 0 72 28
    0 1 1624308 85208 33648 1030568 0 0 0 0 0 2418 0 0 72 28
    0 2 1624276 153000 34920 958280 0 0 0 0 0 2585 0 0 75 25
    0 1 1624248 149032 36284 968828 0 0 0 0 0 2302 0 0 72 28
    0 1 1624248 247528 37688 872672 0 0 0 0 0 2663 0 0 79 21
    0 0 1624244 14376 10796 1153752 0 0 0 0 0 2203 0 0 78 22

  21. #21
    Join Date
    Mar 2007
    Location
    UK
    Posts
    852
    The Load Values that are shown in any program inside your VPS are your Load Values and not the Host Nodes, the reason you are seing high Load Averages on your VPS is because their is a high I/O wait caused by another VPS on the system, meaning your VPS processes are having to wait for I/O time to execute their write/read from the harddrive, therefore causing your systems Load Averages to increase.

    Alot of people think that Load Averages are only affected by CPU, however I/O and many other parts of the system can affect the Load Average, in your example your system is near enough Idle on the CPU, however the load Average is high, due to high system wide I/O. One thing VZ 3.x has a problem with.

    Hope that helps, and makes a few things clearer.
    ZXPlay
    Premium Virtual Private Servers | Dedicated Media Streaming Servers
    Dedicated Resources | EU Based
    www.zxplay.co.uk

  22. #22
    Join Date
    Nov 2006
    Posts
    50
    And those readouts of cpu from top and vmstat are mean values for all cpu cores, and if his VPS is using 4 cores, a 25% mean value in i/o wait probably means 100% in one of the cores, which means all processes using that core are completely blocked while the core is waiting for i/o.

    Rui
    Last edited by RMSSF; 03-20-2008 at 03:41 PM.

  23. #23
    Ashley & Rui, thanks for the replies.

    If I understand correctly, the load I am seeing is only coming from my VPS. This would be a measure of my just my processes. This surprises me because my VPS is VERY idle. I get about 50 unique visits a day, with 500 pages if I am lucky. This VPS is just for a little hobby, nothing serious. (But, given that I am paying $25/mo. for a nearly idle hobby VPS, it is frustrating when I cannot use it!)

    I gather that if I had any regular traffic at all I would see high loads throughout the day! Is this right?

    SLHost monitored my VPS for a few hours after the last time I posted. Here is their reply and my response back.

    Ron,

    We have monitored your sever and the load never seen as high. I made a cron to upload the load results in every five minute to the file /root/load.txt and you can verify the same to check the load status on your server. Let us know how do we help you further.


    --------------
    Regards,
    James
    Hi James,

    I agree that the load has not shot back up for the rest of the day. I am wondering though, as expressed in the thread (http://www.webhostingtalk.com/showthread.php?t=677656) what can be done to prevent this from being a daily routine? Is this something that can be fixed, or is this just what I get and there is not much to do about it?

    Thanks,
    Ron

  24. #24
    Join Date
    Nov 2006
    Posts
    50
    The cpu load value expresses how many processes at a given time are waiting for cpu time slot, loadavg gives that mean value for 1 min, 5 min and 15 min respectively.
    Any process blocked because of cpu waiting for i/o will increase the load by 1.00, so if you see a load of 2.00 because of i/o blocking, it means there are 2 processes blocked.
    So it is very easy for the load to go high when there are these kind of issues.
    One time I saw the load in my VPS going as high as 60 and more because there was an issue with a failed disk causing very high disk i/o wait times and very low server performance and stability.

    Rui

  25. #25
    i have update memory on one VPS a few days ago but this didn't fix the problem. It is still high as it was befor.. so this is no memory problem...
    "rfulkerson " can you PM me on wich Node you are?

  26. #26
    load is incredible high on my 3 VPS. THisa is what i seen in TOP on on of my VPS:

    Code:
    top - 08:49:21 up  1:39,  1 user,  load average: 18.55, 19.52, 18.52
    Tasks: 124 total,   5 running, 119 sleeping,   0 stopped,   0 zombie
    Cpu(s): 12.8% us,  0.9% sy,  0.0% ni, 41.2% id, 45.1% wa,  0.0% hi,  0.0% si
    Mem:   8298896k total,  8281680k used,    17216k free,   102844k buffers
    Swap:  8385920k total,  2033576k used,  6352344k free,  2458396k cached
      PID USER      PR  NI %CPU    TIME+  %MEM  VIRT  RES  SHR S COMMAND
    20060 nobody    16   0   47   0:45.49  0.8  144m  63m  15m S /usr/local/apache/bin/httpd -DSSL
    30220 mysql     15   0    2   1:21.79  0.3  173m  26m 3336 S /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/server.an-dns6.com.pid --skip-external-locking --sock
    20098 nobody    16   0    1   0:42.48  0.8  144m  61m  13m S /usr/local/apache/bin/httpd -DSSL
     1662 username  15   0    0   0:04.19  0.4 33140  30m 2040 D spamd child
     7205 root      16   0    0   0:02.36  0.0  2024 1084  788 S top -c
     5775 mailnull  16   0    0   0:00.03  0.0  9168 4032 2696 S /usr/sbin/exim -bd -q60m
        1 root      15   0    0   0:00.11  0.0  1628  604  524 S init [3]
    24199 root      15   0    0   0:00.28  0.0  1532  528  440 S syslogd -m 0
    24420 named     19   0    0   0:17.98  0.1 77248  11m 1912 S /usr/sbin/named -u named
    29866 root      16   0    0   0:00.00  0.0  1456  376  320 S /usr/sbin/courierlogger -pid=/var/spool/authdaemon/pid -facility=mail -start /usr/libexec/courier-authlib/authdaemond
    29867 root      15   0    0   0:00.00  0.0  1804  592  484 S /usr/libexec/courier-authlib/authdaemond
    29894 root      15   0    0   0:00.01  0.0  5764 1784 1360 S cupsd
    29939 root      15   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29942 root      15   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29944 root      16   0    0   0:00.00  0.0  1804  356  236 S /usr/libexec/courier-authlib/authdaemond
    29945 root      16   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29946 root      16   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29947 root      15   0    0   0:00.00  0.0  1804  356  236 S /usr/libexec/courier-authlib/authdaemond
    29949 root      16   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29950 root      15   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29951 root      15   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29952 root      15   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    30091 root      15   0    0   0:00.00  0.0  4024 1032  740 S /usr/sbin/sshd
    30138 root      18   0    0   0:00.00  0.0  2084  780  652 S xinetd -stayalive -pidfile /var/run/xinetd.pid
    30161 root      18   0    0   0:00.00  0.0  2152 1120  956 S /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/server.an-dns6.com.pid
    30588 root      15   0    0   0:00.10  0.0  5672 4092 1216 S chkservd
    30618 root      16   0    0   0:00.00  0.0  1460  380  320 S /usr/sbin/courierlogger -pid=/var/run/imapd.pid -start -name=imapd /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -maxperip=50
    30619 root      16   0    0   0:00.00  0.0  1568  516  440 S /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -maxperip=50 -nodnslookup -noidentlookup 143 /usr/lib/courier-imap/sbin/imaplog
    30642 root      20   0    0   0:00.00  0.0  1460  312  260 S /usr/sbin/courierlogger -pid=/var/run/imapd-ssl.pid -start -name=imapd-ssl /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -max
    30643 root      18   0    0   0:00.00  0.0  1568  488  412 S /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -maxperip=50 -nodnslookup -noidentlookup 993 /usr/lib/courier-imap/bin/couriert
    30649 root      15   0    0   0:00.03  0.0  1460  380  320 S /usr/sbin/courierlogger -pid=/var/run/pop3d.pid -start -name=pop3d /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=50 -maxperip=50
    30650 root      16   0    0   0:00.04  0.0  1568  516  440 S /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=50 -maxperip=50 -nodnslookup -noidentlookup 110 /usr/lib/courier-imap/sbin/pop3logi
    30661 root      18   0    0   0:00.00  0.0  1460  312  260 S /usr/sbin/courierlogger -pid=/var/run/pop3d-ssl.pid -start -name=pop3d-ssl /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=50 -maxp
    30663 root      18   0    0   0:00.00  0.0  1568  488  412 S /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=50 -maxperip=50 -nodnslookup -noidentlookup 995 /usr/lib/courier-imap/bin/couriertl
    32707 root      16   0    0   0:00.27  0.1  6408 4920 2644 S /etc/authlib/authProg
     1334 root      17   0    0   0:00.21  0.1  6408 4908 2636 S /etc/authlib/authProg
     1390 root      16   0    0   0:00.26  0.1  6408 4920 2644 S /etc/authlib/authProg
     1391 root      17   0    0   0:00.33  0.1  6408 4848 2572 S /etc/authlib/authProg
     1392 root      16   0    0   0:00.17  0.1  6408 4908 2636 S /etc/authlib/authProg
     1393 root      17   0    0   0:00.17  0.1  6408 4908 2636 S /etc/authlib/authProg
     1394 root      16   0    0   0:00.14  0.1  6408 4908 2636 S /etc/authlib/authProg
     1396 root      16   0    0   0:00.24  0.1  6408 4844 2572 S /etc/authlib/authProg
     5279 root      17   0    0   0:00.02  0.0  5888 1348 1048 S pure-ftpd (SERVER)
     5283 root      18   0    0   0:00.00  0.0  3580  924  728 S /usr/sbin/pure-authd -s /var/run/ftpd.sock -r /usr/sbin/pureauth
     5326 root      16   0    0   0:02.34  0.1  7848 5996  904 S lfd - sleeping
     5458 root      18   0    0   0:00.00  0.0  3580  920  724 S /usr/sbin/pure-authd -s /var/run/ftpd.sock -r /usr/sbin/pureauth
     5477 root      17   0    0   0:00.03  0.0  2484  916  524 S crond
     5871 xfs       16   0    0   0:00.00  0.0  3036 1332  756 S xfs -droppriv -daemon
     7858 root      16   0    0   0:01.27  0.1  100m  11m 4676 S /usr/local/apache/bin/httpd -DSSL
     9277 root      18   0    0   0:00.00  0.1 13660 7884  360 S cpdavd - accepting connections on 2077 and 2078
     9546 root      15   0    0   0:00.50  0.0  6024 3496 1340 S cpbandwd
     9547 root      34  19    0   0:01.41  0.1  9824 5348 1792 S cpanellogd - sleeping for logs
     9698 root      18   0    0   0:00.00  0.0  4060  752  568 S /usr/sbin/saslauthd -m /var/run/saslauthd -a pam -n 1
     9857 dbus      16   0    0   0:00.00  0.0  2400  876  784 S dbus-daemon-1 --system
     9956 root      16   0    0   0:00.22  0.1 18584 9060 1004 S cpsrvd - waiting for connections
    10008 root      18   0    0   0:00.00  0.0  1488  392  320 S /usr/sbin/portsentry -tcp
    10074 root      18   0    0   0:00.00  0.0  3580  728  724 S /usr/sbin/pure-authd -s /var/run/ftpd.sock -r /usr/sbin/pureauth

  27. #27
    this is what i see on another VPS:

    Code:
    top - 08:54:31 up  1:44,  1 user,  load average: 8.61, 11.09, 13.53
    Tasks: 101 total,   5 running,  94 sleeping,   0 stopped,   2 zombie
    Cpu(s):  1.1% us,  0.6% sy,  0.0% ni, 45.3% id, 53.0% wa,  0.0% hi,  0.0% si
    Mem:   8298896k total,  8187672k used,   111224k free,   108460k buffers
    Swap:  8385920k total,  2032644k used,  6353276k free,  2437592k cached
      PID USER      PR  NI %CPU    TIME+  %MEM  VIRT  RES  SHR S COMMAND
    29986 root      15   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29987 root      15   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29989 root      15   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29990 root      16   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    29991 root      15   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    30110 root      16   0    0   0:00.00  0.0  4024 1032  740 S /usr/sbin/sshd
    30150 root      18   0    0   0:00.00  0.0  2084  780  652 S xinetd -stayalive -pidfile /var/run/xinetd.pid
    30191 root      20   0    0   0:00.00  0.0  2152 1120  956 S /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/server.otherserver.com.pid
    30229 mysql     16   0    0   0:00.78  0.3  180m  23m 3396 S /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/server.an-dns5.com.pid --skip-external-locking --port
    30537 root      15   0    0   0:00.13  0.0  5672 4116 1216 S chkservd
    30550 root      16   0    0   0:00.00  0.0  1460  380  320 S /usr/sbin/courierlogger -pid=/var/run/imapd.pid -start -name=imapd /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -maxperip=50
    30551 root      16   0    0   0:00.01  0.0  1568  516  440 S /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -maxperip=50 -nodnslookup -noidentlookup 143 /usr/lib/courier-imap/sbin/imaplog
    30564 root      16   0    0   0:00.00  0.0  1460  380  320 S /usr/sbin/courierlogger -pid=/var/run/imapd-ssl.pid -start -name=imapd-ssl /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -max
    30565 root      16   0    0   0:00.00  0.0  1568  516  440 S /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -maxperip=50 -nodnslookup -noidentlookup 993 /usr/lib/courier-imap/bin/couriert
    30571 root      16   0    0   0:00.05  0.0  1460  380  320 S /usr/sbin/courierlogger -pid=/var/run/pop3d.pid -start -name=pop3d /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -maxperip=50
    30572 root      16   0    0   0:00.06  0.0  1568  516  440 S /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -maxperip=50 -nodnslookup -noidentlookup 110 /usr/lib/courier-imap/sbin/pop3log
    30577 root      15   0    0   0:00.00  0.0  1460  380  320 S /usr/sbin/courierlogger -pid=/var/run/pop3d-ssl.pid -start -name=pop3d-ssl /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -max
    30578 root      17   0    0   0:00.00  0.0  1568  516  440 S /usr/lib/courier-imap/libexec/couriertcpd -address=0 -maxprocs=100 -maxperip=50 -nodnslookup -noidentlookup 995 /usr/lib/courier-imap/bin/couriert
    32497 root      15   0    0   0:25.33  0.9  113m  69m  924 S /usr/sbin/clamd
    32510 mailnull  16   0    0   0:01.46  0.0  7480 1192  784 S /usr/sbin/exim -bd -q60m
    32526 mailnull  20   0    0   0:00.00  0.0  7684 1132  728 S /usr/sbin/exim -tls-on-connect -bd -oX 465
    32571 root      15   0    0   0:00.73  0.0  3784 1752  640 S antirelayd
     1421 root      16   0    0   0:00.39  0.1  6408 4920 2636 S /etc/authlib/authProg
     1422 root      16   0    0   0:00.27  0.1  6408 4908 2628 S /etc/authlib/authProg
     1538 root      15   0    0   0:00.31  0.1  6408 4848 2564 S /etc/authlib/authProg
     3955 root      16   0    0   0:00.22  0.1  6408 4912 2628 S /etc/authlib/authProg
     5138 root      15   0    0   0:00.01  0.0  5888 1348 1048 S pure-ftpd (SERVER)
     5143 root      17   0    0   0:00.00  0.0  3580  916  720 S /usr/sbin/pure-authd -s /var/run/ftpd.sock -r /usr/sbin/pureauth
     5322 root      15   0    0   0:00.80  0.3 27544  24m 1936 S /usr/bin/spamd -d --allowed-ips=127.0.0.1 --pidfile=/var/run/spamd.pid --max-children=5
     5406 root      15   0    0   0:01.90  0.1  7980 6084  904 S lfd - sleeping
     5797 username  15   0    0   0:20.91  0.4 32032  28m 2044 S spamd child
     7376 root      15   0    0   0:00.98  0.2 88080  12m 4916 S /usr/local/apache/bin/httpd -DSSL
     7417 root      18   0    0   0:00.00  0.0  3580  912  716 S /usr/sbin/pure-authd -s /var/run/ftpd.sock -r /usr/sbin/pureauth
     7446 root      15   0    0   0:00.04  0.0  2484  920  524 S crond
     7906 xfs       16   0    0   0:00.00  0.0  3036 1332  756 S xfs -droppriv -daemon
    10121 root      18   0    0   0:00.00  0.1 13660 6092  360 S cpdavd - accepting connections on 2077 and 2078
    10206 root      16   0    0   0:00.35  0.1 18584 9060 1004 S cpsrvd - waiting for connections
    11383 root      15   0    0   0:00.67  0.1  6024 4344 1340 S cpbandwd
    Last edited by reamark; 03-21-2008 at 05:36 AM.

  28. #28
    and this is the 3 VPS:
    Code:
    top - 08:55:54 up  1:46,  1 user,  load average: 8.11, 10.91, 13.48
    Tasks:  87 total,   1 running,  86 sleeping,   0 stopped,   0 zombie
    Cpu(s):  1.7% us,  0.8% sy,  0.0% ni, 31.5% id, 66.1% wa,  0.0% hi,  0.0% si
    Mem:   8298896k total,  8234664k used,    64232k free,   128220k buffers
    Swap:  8385920k total,  2032640k used,  6353280k free,  2507816k cached
      PID USER      PR  NI %CPU    TIME+  %MEM  VIRT  RES  SHR S COMMAND
    28166 mysql     15   0    1   6:23.70  0.3  116m  20m 3560 S /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/server.myserver.com.pid --skip-external-locking --port
     5564 nobody    16   0    1   0:22.57  0.3  110m  22m 9904 S /usr/local/apache/bin/httpd -DSSL
    25806 mailnull  15   0    1   0:00.03  0.0 10112 4008 2684 S /usr/sbin/exim -bd -q60m
    25820 mailnull  16   0    1   0:00.02  0.0 10112 3972 2652 D /usr/sbin/exim -bd -q60m
    25822 mailnull  16   0    1   0:00.02  0.0 10112 3984 2664 D /usr/sbin/exim -bd -q60m
    25880 root      18   0    1   0:00.02  0.0  9420 4148 2844 S /usr/sbin/exim -Mc 1Jcc6m-0006gx-OV
    25616 named     19   0    0   0:18.15  0.1 78016  12m 1944 S /usr/sbin/named -u named
     3158 root      16   0    0   0:00.63  0.0  7068 2308 1840 S sshd: [email protected]/0
     7256 root      15   0    0   0:00.92  0.0  2024 1072  788 R top
    22263 root      15   0    0   0:00.09  0.0  1896 1016  788 S top -c
        1 root      16   0    0   0:00.07  0.0  1628  604  524 S init [3]
    24528 root      15   0    0   0:00.40  0.0  1532  528  440 S syslogd -m 0
    28065 root      15   0    0   0:00.00  0.0  1456  376  320 S /usr/sbin/courierlogger -pid=/var/spool/authdaemon/pid -facility=mail -start /usr/libexec/courier-authlib/authdaemond
    28066 root      16   0    0   0:00.00  0.0  1804  592  484 S /usr/libexec/courier-authlib/authdaemond
    28075 root      16   0    0   0:00.02  0.0  5764 1784 1360 S cupsd
    28080 root      16   0    0   0:00.01  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    28081 root      15   0    0   0:00.01  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    28082 root      16   0    0   0:00.01  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    28083 root      16   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    28084 root      15   0    0   0:00.01  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    28085 root      16   0    0   0:00.01  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    28086 root      16   0    0   0:00.01  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    28088 root      15   0    0   0:00.01  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    28089 root      16   0    0   0:00.01  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    28090 root      15   0    0   0:00.00  0.0  1804  360  240 S /usr/libexec/courier-authlib/authdaemond
    28115 root      17   0    0   0:00.14  0.0  4028 1136  840 S /usr/sbin/sshd
    28126 root      17   0    0   0:00.00  0.0  2084  784  652 S xinetd -stayalive -pidfile /var/run/xinetd.pid
    28135 root      17   0    0   0:00.00  0.0  2152 1120  956 S /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/server..com.pid
    28225 root      15   0    0   0:00.08  0.0  5672 4112 1216 S chkservd
    29827 mailnull  16   0    0   0:00.00  0.0  8552 1168  776 S /usr/sbin/exim -bd -oX 26
    29833 mailnull  16   0    0   0:02.22  0.0  9028 1200  792 S /usr/sbin/exim -bd -q60m
    29837 mailnull  22   0    0   0:00.00  0.0  8308 1144  752 S /usr/sbin/exim -tls-on-connect -bd -oX 465
    29845 root      15   0    0   0:01.76  0.0  3784 1764  640 S antirelayd
    29856 root      15   0    0   0:00.59  0.1  6408 4956 2636 S /etc/authlib/authProg
    29906 root      16   0    0   0:00.62  0.1  6408 4960 2636 S /etc/authlib/authProg
    29958 root      16   0    0   0:00.47  0.1  6408 4960 2636 S /etc/authlib/authProg
     1349 root      16   0    0   0:00.37  0.1  6408 4960 2636 S /etc/authlib/authProg
     1705 root      17   0    0   0:00.01  0.0  5888 1348 1048 S pure-ftpd (SERVER)
     1719 root      18   0    0   0:00.00  0.0  3580  924  728 S /usr/sbin/pure-authd -s /var/run/ftpd.sock -r /usr/sbin/pureauth
     1788 root      15   0    0   0:01.17  0.3 27524  24m 1936 S /usr/bin/spamd -d --allowed-ips=127.0.0.1 --pidfile=/var/run/spamd.pid --max-children=5
     1932 root      15   0    0   0:00.85  0.1  6452 5060 2724 S /etc/authlib/authProg
     1960 root      18   0    0   0:00.00  0.0  3580  920  724 S /usr/sbin/pure-authd -s /var/run/ftpd.sock -r /usr/sbin/pureauth
     1989 root      16   0    0   0:00.03  0.0  2484  916  524 S crond
     3419 xfs       15   0    0   0:00.00  0.0  3036 1332  756 S xfs -droppriv -daemon
     5269 root      15   0    0   0:01.70  0.1  102m  11m 4808 S /usr/local/apache/bin/httpd -DSSL
     5365 root      18   0    0   0:00.00  0.1 13660 7900  360 S cpdavd - accepting connections on 2077 and 2078
     5562 nobody    15   0    0   0:22.37  0.3  105m  21m  11m S /usr/local/apache/bin/httpd -DSSL
     5565 nobody    15   0    0   0:17.80  0.3  108m  22m  11m S /usr/local/apache/bin/httpd -DSSL
     5566 nobody    16   0    0   0:14.23  0.3  106m  24m  13m S /usr/local/apache/bin/httpd -DSSL
     5568 nobody    15   0    0   0:26.86  0.2  107m  17m 8200 S /usr/local/apache/bin/httpd -DSSL
     5773 nobody    15   0    0   0:25.60  0.3  110m  27m  14m S /usr/local/apache/bin/httpd -DSSL
     5801 root      15   0    0   0:01.83  0.1  6028 4416 1340 S cpbandwd
     5802 root      34  19    0   0:01.76  0.1  9756 6912 1688 S cpanellogd - sleeping for logs
     5861 root      18   0    0   0:00.00  0.0  4060  796  568 S /usr/sbin/saslauthd -m /var/run/saslauthd -a pam -n 1
     5976 root      16   0    0   0:00.14  0.1 18584 9060 1004 S cpsrvd - waiting for connections

  29. #29
    Join Date
    Dec 2003
    Location
    Hamilton, NJ, USA
    Posts
    1
    This may be caused by someone running a backup of their node from the VPS Power Panel. I've had support kill my backup jobs because they were affecting other users on the node. (The backup runs at the host level, not the VPS level). I only run that backup once a month or so now, and I run it in the middle of the night.

    The problem is really with Virtuozzo (and VPSs in general)...They do a good job of separating the individual nodes, but if something is running on the layer above (the host machine), it can affect all of the nodes,

  30. #30
    Hello Ron,

    I wonder if your problem was resolved at all. I'm on slhost too for about 8 month. In general it is an excellent hosting, but currently I have exactly the same high-load VPS problem, it happens each day, near 9:00 GMT.

    Regards,
    Mikhail

  31. #31
    Join Date
    Mar 2007
    Location
    United Kingdom
    Posts
    181
    Quote Originally Posted by rfulkerson View Post
    Is this what I can expect from all VPS plans? Do I just have live with it, or would another host (possibly Xen based) be better?
    No, VPS plans aren't like this in general - it's a symptom of an overloaded node. An experienced VZ provider can identify the VPS's causing high load and re-balance their nodes so that the disk I/O problem disappears (i.e. your VPS is moved to another node, or the problem VPS(s) are moved elsewhere onto a node which has less I/O usage and/or higher I/O capacity).

    The technology used isn't to blame, and I would be careful about assuming VZ or Xen (etc.) would do a better job or otherwise as you really need to understand the technology in detail to make that level of judgement. There are advantages and disadvantages of each virtualisation technology but any will potentially work ok for you with a provider that handles it properly.

    Quote Originally Posted by devonblzx View Post
    The differences between Xen and VZ would not be noticed in this situation. This could happen anywhere I suppose, but if it is a persistent problem caused by the main node then KnownHost should be able to track down the usage and find which VPS is causing the problem.
    Exactly. It's very easy for the provider to evaluate this situation and IMO it's not appropriate to expect the customer to do all of the detective work (even if it's an unmanaged VPS) - if the load is coming from the node (i.e. due to I/O problems) then it's for the provider to identify and resolve as it's not a problem within the VPS.

    In this case, I'm surprised they haven't moved your VPS onto a different node as a "let's see what happens" kind of idea. At least that way they would probably have resolved your problems - even if they didn't understand why

  32. #32
    Join Date
    Jul 2005
    Location
    Australia
    Posts
    104
    I am having the exact problem as rfulkerson is having...also Slhost has shifted me onto another node, but I still have high loads on the server starting at 4.00 pm {Aussie Time} approx...and sometimes going on for an hour or so, I have been with them for over 2 years..and never have had these problems before...but the last few months have been shocking

    Every time they check the server, they report back everything is fine, they also stated that backs up on the node can cause these problems, well then they should be doing something about it, my sites are very low resources, so they would not be causing any problem with load.

  33. #33
    Join Date
    Jan 2006
    Posts
    1,915
    Quote Originally Posted by devonblzx View Post
    The differences between Xen and VZ would not be noticed in this situation. This could happen anywhere I suppose, but if it is a persistent problem caused by the main node then KnownHost should be able to track down the usage and find which VPS is causing the problem.

    The only reason the VPS load average would go up because of the node is because it is waiting for disk, that is why I said to open up top and see where the usage is. If their is a lot of CPU under the wait (wa) category then the problem is being caused by the main node's disks. If not, then their could also be a problem within your VPS.

    Is this a managed VPS? If so, they should track it down for you, if not, you may want to look into a managed solution if it does not resolve.
    This thread is a bit old but I noticed KnownHost mentioned. I think this thread was about SLhost not KnownHost unless I am missing something. We always move a customer to another node if it seems to be the best option at that time.

    -Jay
    KnownHost Managed VPS Specialists
    Toll Free: (866)-332-9894
    Fully Managed VPS, Hybrid, and Dedicated Servers

    RocketVPS.com - Premium Unmanaged VPS Hosting

  34. #34
    Join Date
    Jul 2005
    Location
    Australia
    Posts
    104
    You are correct Knownhost...It is about Slhost, I say it is a typo error regarding your company...in which I have heard good reports about

  35. #35
    Join Date
    Jan 2006
    Posts
    1,915
    Quote Originally Posted by Unix-Aussie.Host View Post
    You are correct Knownhost...It is about Slhost, I say it is a typo error regarding your company...in which I have heard good reports about
    Thank you. We do try. I figured it was a typo but wanted to make sure.

    -Jay
    KnownHost Managed VPS Specialists
    Toll Free: (866)-332-9894
    Fully Managed VPS, Hybrid, and Dedicated Servers

    RocketVPS.com - Premium Unmanaged VPS Hosting

  36. #36
    as mentioned elswhere i also had this high load on some VPS i have with slhost since February (sometimes it goes up to 30. ) Some VPS has be transfered to other nodes and it's a bit better now. I think they growing and just hosted to many VPS on the same node.

  37. #37
    Join Date
    Jun 2008
    Location
    India
    Posts
    261
    you may use sar command with opetions

  38. #38
    Quote Originally Posted by rankris View Post
    you may use sar command with opetions
    can you elaborate please?

    thanks

  39. #39
    Join Date
    Feb 2006
    Location
    Portland, Oregon
    Posts
    3
    I'm about 5 months into my 3rd year with slhost.

    Things were good for the first two years. But since the first of THIS year, I've had nothing but problems with cpus running way high and, of course, pages not loading till next week.

    I've sent countless support tickets to SL host. And they DO reply back fairly quickly... but never resolve the problem once and for all. Initially, support tried to pass it off as MY vps issue. But not a thing has changed with sites on my vps since before the first of the year. Sites are low traffic, with no scripts or anything fancy running in the background... no cron jobs... nuttin.

    Then, slightly over a month ago they migrated my vps to another datacenter - without giving me any notice. I found out when I arrived at my computer one morning to find ALL SITES dead, and couldn't log into any cpanels or WHM. Support replied with my NEW IP. But NOT the new login/password. Sheesh... Finally got that ironed out. But...

    Since that migration, I've been having to restart Apache 3-4 or MORE times a day just to get cpus down low enough for pages to finally load.

    I submitted a ticket to sales last week saying that I canNOT continue to spend an hour or more per day with SLHost support and restarting apache, and that I'm going to be moving out unless they do something. They replied back four days ago saying they were
    1. Unaware of this problem and
    2. They are moving my vps to a new server and that will fix the problem.

    Well, it's day 4, and I've not been notified that they've moved my vps to a less crowded server. And, I get to my computer this morning to find NO sites loading and cpus over 16.75

    Sent another support ticket, and I get this reply...

    ~~~~~~~~~~~~~~~~
    Service apache was causing heavy load on your server and I have turned it for you. The load has been brought down to normal levels and your domains are loading fine atm. Please have a check and update us if there are still problems.

    Update us incase you face the same issue again in future and we will have it investigated for you.
    ~~~~~~~~~~~~~~~~~~~~~~~~

    Good grief! What has happened to SL Host? You'd think with over a dozen support tickets lodged for this SAME issue - And now I've gotten SALES department in on this... That they'd quit with the 'canned, stupid' replies. And DO SOMETHING.

    Worst of it all is I PAY once yearly. And I JUST paid for my
    3rd year in full the end of March. And they tell me they do NOT offer refunds after 30 days. You'd think SL Host would treat a long-time, yearly paying customer better than this!

    ARGH!! I'm giving them till Monday evening. Then my only logical and smart choice is to move 'outa there. Losing the pre-paid year's hosting fee is getting to be a moot point, considering the revenue I've lost just in the last 4 weeks with slow to no page loads.

    I've got a VPS at KnownHost - slightly more expense but always stellar performance. I'll either get a 2nd account at KH and migrate over there, or I'm also considering Servint or WiredTree.

    Deb

  40. #40
    Join Date
    Jan 2006
    Posts
    1,915
    Quote Originally Posted by oppgroup View Post
    I'm about 5 months into my 3rd year with slhost.

    Things were good for the first two years. But since the first of THIS year, I've had nothing but problems with cpus running way high and, of course, pages not loading till next week.

    I've sent countless support tickets to SL host. And they DO reply back fairly quickly... but never resolve the problem once and for all. Initially, support tried to pass it off as MY vps issue. But not a thing has changed with sites on my vps since before the first of the year. Sites are low traffic, with no scripts or anything fancy running in the background... no cron jobs... nuttin.

    Then, slightly over a month ago they migrated my vps to another datacenter - without giving me any notice. I found out when I arrived at my computer one morning to find ALL SITES dead, and couldn't log into any cpanels or WHM. Support replied with my NEW IP. But NOT the new login/password. Sheesh... Finally got that ironed out. But...

    Since that migration, I've been having to restart Apache 3-4 or MORE times a day just to get cpus down low enough for pages to finally load.

    I submitted a ticket to sales last week saying that I canNOT continue to spend an hour or more per day with SLHost support and restarting apache, and that I'm going to be moving out unless they do something. They replied back four days ago saying they were
    1. Unaware of this problem and
    2. They are moving my vps to a new server and that will fix the problem.

    Well, it's day 4, and I've not been notified that they've moved my vps to a less crowded server. And, I get to my computer this morning to find NO sites loading and cpus over 16.75

    Sent another support ticket, and I get this reply...

    ~~~~~~~~~~~~~~~~
    Service apache was causing heavy load on your server and I have turned it for you. The load has been brought down to normal levels and your domains are loading fine atm. Please have a check and update us if there are still problems.

    Update us incase you face the same issue again in future and we will have it investigated for you.
    ~~~~~~~~~~~~~~~~~~~~~~~~

    Good grief! What has happened to SL Host? You'd think with over a dozen support tickets lodged for this SAME issue - And now I've gotten SALES department in on this... That they'd quit with the 'canned, stupid' replies. And DO SOMETHING.

    Worst of it all is I PAY once yearly. And I JUST paid for my
    3rd year in full the end of March. And they tell me they do NOT offer refunds after 30 days. You'd think SL Host would treat a long-time, yearly paying customer better than this!

    ARGH!! I'm giving them till Monday evening. Then my only logical and smart choice is to move 'outa there. Losing the pre-paid year's hosting fee is getting to be a moot point, considering the revenue I've lost just in the last 4 weeks with slow to no page loads.

    I've got a VPS at KnownHost - slightly more expense but always stellar performance. I'll either get a 2nd account at KH and migrate over there, or I'm also considering Servint or WiredTree.

    Deb
    SLHost sold their company from what I heard. I think there was a thread in the outages forum about it recently. Also, it's great to hear your happy with us.

    -Jay
    KnownHost Managed VPS Specialists
    Toll Free: (866)-332-9894
    Fully Managed VPS, Hybrid, and Dedicated Servers

    RocketVPS.com - Premium Unmanaged VPS Hosting

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •