Web Hosting Talk : Web Hosting Main Forums : Reseller Hosting : What is a good server load for a reseller?

[ozzie123]

Hello,

One of my account is currently hosted with Site5. Lately, however, I've experienced a very slow response time from my server and when I checked the server load, it's around 4 up until 7.

I'm hosted under dual xeon 2.8 GHz with 2GB RAM. My question is, is that server load normal? Site5 technical support always told me that the normal load of such server is between 3-4

[dollar]

Between 3 and 4 would be the max load I'd want that server running at, but I would be happy if it never got any higher than that.

Your response time may not be related to server load, do you have a trace route to the server?

[ozzie123]

The trace route might be somewhat slow, probably because of the geographical difference. Here's my tracert:

1 26 ms 29 ms 29 ms fe5-1-1-gw6-bdg.melsa.net.id [202.138.238.1]
2 30 ms 28 ms 28 ms fe0-3-gw-bdg.melsa.net.id [202.138.225.81]
3 65 ms 99 ms 69 ms 202.152.43.165
4 70 ms 89 ms 79 ms 202.152.0.163
5 78 ms 80 ms 89 ms 202.152.0.161
6 446 ms 549 ms 449 ms 202.93.40.141
7 617 ms 648 ms * 12.118.124.89
8 798 ms 669 ms 769 ms gbr5-p40.sffca.ip.att.net [12.122.2.254]
9 837 ms 659 ms 649 ms tbr2-p013501.sffca.ip.att.net [12.122.11.89]
10 747 ms 739 ms 789 ms tbr1-cl2.sl9mo.ip.att.net [12.122.10.41]
11 656 ms 639 ms 659 ms 12.122.12.185
12 661 ms 629 ms 599 ms gar3-p300.dtrmi.ip.att.net [12.123.139.54]
13 628 ms 688 ms 719 ms 12.118.112.34
14 648 ms 768 ms 709 ms lw-core1-ge4.rtr.liquidweb.com [209.59.157.22]
15 778 ms 830 ms 648 ms 209.59.157.50
16 700 ms 619 ms 639 ms 209.59.177.86

The actual problem is today I can't update my blog nor any other site that's connected to MySQL database under that account. The server always return with request time out (60) and by then I assume that this is caused by a high server load.

[layer0]

Hi,

http://blog.permagnus.com/ -- that site from your profile loads fine here.

[ozzie123]

http://blog.permagnus.com/ is actually redirected to http://permagnus.com/portal/ and when you tried to visit the second address I gave you, it will return request time out.

Another thing is when you tried to leave a comment (say for example http://permagnus.com/portal/2005/10/...toks/#comments), it will only take you to a blank white page.

So I'm sure that there's something wrong with the server and my first guess is the server load. But after a while, the server load is decreasing but the problem still exist...

I wonder why Site5 tech support team hasn't answered my ticket yet.

[Website Rob]

Although I would agree that the Server load is too high, there does seem to be a problem with http://permagnus.com/portal/ in general.

I get a blank page no matter what I try in that directory.

Can you confirm the URL works at anytime?

[ozzie123]

I'm sure of it. And that's one of the problem. However, the server load is not so high currently but still you can't have a page fully opened. There must be a part that can't be loaded.

Does their tech support not available on sunday? I haven't got any reply since.

[starfinder]

Perhaps they were experiencing a temporary problem. If the server load has backed off and continues to do so, you should be ok. Ideally a single processor server should never be above 2.

How long has this problem been happening?

[zerodamage]

haha. Funny. Bluewho told me that a server load of around 4-6 is normal yet this happens to be a single cpu server.

[dollar]

Originally posted by zerodamage
haha. Funny. Bluewho told me that a server load of around 4-6 is normal yet this happens to be a single cpu server.

The server in question in this thread is a dual xeon machine with 2GB of ram. A load of 4ish is nothing to cry over. This means that there is a total of 4 "jobs" waiting to be taken care of by the system. Using a SMP kernel which I'm sure they are there should be 2 jobs waiting for each CPU.

Even at a load of 20 the OP should not be seeing timeouts when trying to access a page.

[Website Rob]

Let us clear up a common mis-conception.

Linux displays the Load average as the average number of runnable or running processes (R state), and the number of processes in un-interruptible sleep (D state) over the specified interval.

As most of us know, Load average is a 3 decimal number but some people refer to it as one and it is also presumed, unless specified, the referred load average is for one minute. Even though, 1 - 5 - 15 minute intervals are available in top, most people go by what their Control Panel shows them which is the 1 minute interval.

Therefore, a load average of 4 is probably a minute load average of 4.00 which means, 400+ jobs are waiting in the queue.

We run dual Xeons, ranging from 2 - 4 GB of RAM, and I can tell you this, if any one of them got to 4+ and stayed there for minutes or hours, something would be done 'pretty quick' to bring that down.

[dollar]

Originally posted by Website Rob
Let us clear up a common mis-conception.

Linux displays the Load average as the average number of runnable or running processes (R state), and the number of processes in un-interruptible sleep (D state) over the specified interval.

As most of us know, Load average is a 3 decimal number but some people refer to it as one and it is also presumed, unless specified, the referred load average is for one minute. Even though, 1 - 5 - 15 minute intervals are available in top, most people go by what their Control Panel shows them which is the 1 minute interval.

Therefore, a load average of 4 is probably a minute load average of 4.00 which means, 400+ jobs are waiting in the queue.

We run dual Xeons, ranging from 2 - 4 GB of RAM, and I can tell you this, if any one of them got to 4+ and stayed there for minutes or hours, something would be done 'pretty quick' to bring that down.

I am curious where you have found that a load average of 4.00 means 400 jobs are waiting in the queue, I have never read this personally (I could easily be wrong on the subject, just curious where you foudn it).

Also I commend you for keeping your load on dual CPU systems below the 4.00 mark, but even O'Reilly says that under 3 on a single CPU system is generally acceptable.

Perfection would be to have your load at or below 1 on course (and 2 if you have a dual CPU system).

[Website Rob]

Got the info from RedHat -- they have an excellent Newsletter.


Also, I was just able to connect with http://www.permagnus.com/portal/, and, if no script related problems, would have to agree the problem with intermittency is due to the Server. Either load too high or too many concurrent mySQL connections for the setup.

[ozzie123]

The site is back to normal for a day (or is it 2?) and it goes all wrong again. When you point your browser to http://permagnus.com/portal/ all you can see is just a blank page as we speaking.

I mean... (almost) 2 days in a row and without a decent support response (they always told me to do a trace route, yaddi yadda and when I did, they said that it's a latency problem when it's clear that people from the other side of the world is experiencing the very same problem) is not a good web hosting performance

[Website Rob]

Latency or connection problems would not be the case for this problem.

http://nwtools.com/default.asp?prog=...=permagnus.com

An excellent 3rd party site I recommend to many people and in this case, shows there is no connection problem yet I too, only see a blank page.

When this problem crops up, ozzie, do you normally check the Server load? Definitely seems like a problem, but the question is where?

Why does http://blog.permagnus.com/ load when http://permagnus.com/portal/ does not?
And yet, they are supposed to be the same page?

If the 'blog' URL is supposed to redirect to the 'portal' URL, then why does it not do that every time?

That is why I asked before about the coding for the two URLs. The 'portal' page gives me this error msg. when I check further, which might shed a clue:

Warning:
fopen(http://www.hostip.info/api/get.XML?ip=my_ip): failed to open stream: HTTP request failed! �j� in /home/yourID/public_html/includes/php/kb_visitor.php on line 18

'my_ip' and 'yourID' have been changed from the original, for security.