the issue of suspending sites, cpu usage,etc

[Urano]

Since yesterday I have a site suspended. In the first response (12 hour later, ticket HSV-573172) HostGator say:


"That site doens't ping to our server. It looks like they need to update the dns since it's not currently hosted on our servers."


I have to show them that the site is in their server, and then I received the second response (21 hours after the first ticket):

"That site was suspended for causing load issues on the server. You should have received a notice about that."

But I don't have any message, and I don't have information about the suspending. How many time it will suspended? For a day, a month, for ever? The site must to found a new hosting?

Something like this take almost a day (21 hours) only for to know the cause of the suspending. I hope that before other day I can know about the cause of the problem, and the solution suggested by Hostgator....


I am waiting....

The suggestion is to make al info available to the customer, including the time and date, the % of usage, and the script/url. The info about the time of suspending is important, too.

[Serra]

Originally Posted by Urano

I am waiting....

The suggestion is to make al info available to the customer, including the time and date, the % of usage, and the script/url. The info about the time of suspending is important, too.

Have you checked the ticketing system to see if a ticket was created? Also, you can ask for the ticket number of the suspention.

[GaryW]

Originally Posted by tobyhede

I can now confirm that the problem was not in our script at all, but through the use of GET triggered through CRON.

Caveat Emptor: You're account can be suspended at any time even though you may not be doing anything wrong.

I've just had a similar problem with a cron/GET combination when generating a Google SiteMap ... (HG suspended permission for the .php script to run - don't have a problem with this .... ) ... but whilst the guys have answered my emails on the matter extremely timely and politely ... they have not been able to give me a definative solution ... when in fact I appear to have the same problem as you had ..

What did you end up using to run your .php script within a cron job??

did you use PHP instead of GET/WGET???

Regards,

GaryW

[Serra]

GET/WGET is used in a lot of expoits, so PHP would be a better way to do it. However, those site map scripts can really eat up the processor power. I wonder if it was suspended because it was running or because it was running too long or taking to much CPU?

[GaryW]

Thanks Serra ... Yes ... not being a total "techy" I'm not sure what is going on .... the emails I got from HG did have a tendancy to say (and I para-phrase) "It's your problem ..." .

Having said that I do not want to appear as a disgruntled user ... to-date I have had nothing but great service from the HG guys/gals etc ...

I'm still happy they stopped the script from continuing to be executed (the cron job was set up to run each night) so that the load was not affecting other users on the shared server ... but still need to find a solution ....


As I said not being a techy the following they sent me does not really help me ...

Hello,
Your site on gator36 was causing very high load which caused the server to spike to a load of 12. It looks like the resources were from the "generator" directory. Instead of suspending your account, we have disabled the script from running. Please reply back to this E-Mail as soon as possible.

---
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13130 nobody 29 10 120m 68m 4340 S 95.1 1.7 23:05.04 /usr/local/apache/bin/httpd -DSSL
3800 nobody 29 10 121m 68m 4316 R 84.3 1.7 26:08.30 /usr/local/apache/bin/httpd -DSSL
31279 nobody 35 10 119m 75m 3744 S 83.3 1.9 855:47.39 /usr/local/apache/bin/httpd -DSSL
31372 nobody 35 10 118m 75m 4416 S 83.3 1.9 915:29.17 /usr/local/apache/bin/httpd -DSSL
24177 nobody 26 10 98.6m 45m 3088 S 13.7 1.1 0:00.69 /usr/local/apache/bin/httpd -DSSL
24227 nobody 26 10 98040 42m 3080 S 12.7 1.1 0:24.66 /usr/local/apache/bin/httpd -DSSL


root@gator36 [/home/xxxxuser/public_html/xxxx/generator]# ls -la /proc/31279
total 0
dr-xr-xr-x 5 nobody nobody 0 Jul 6 19:30 ./
dr-xr-xr-x 253 root root 0 Jun 28 23:44 ../
dr-xr-xr-x 2 root root 0 Jul 7 19:57 attr/
-r-------- 1 root root 0 Jul 7 19:57 auxv
-r--r--r-- 1 root root 0 Jul 7 19:10 cmdline
lrwxrwxrwx 1 root root 0 Jul 7 19:57 cwd -> /home/xxxuser/public_html/xxx/generator/
-r-------- 1 root root 0 Jul 7 19:57 environ
lrwxrwxrwx 1 root root 0 Jul 7 19:15 exe -> /usr/local/apache/bin/httpd*
---

Thank you.

[Serra]

To tell you the truth, I can tell you exactly what that says. And it does prove your script is a problem. The last part, ls -al /proc/31279 is the proof that it is your script.

The part that says:

31279 nobody    35  10  119m  75m 3744 S 83.3  1.9 855:47.39

Says that your script is a HOG... specifically, the number 855:47:39, which basically means your script is eating CPU.

The bad news is that there is nothing you can do to get this to run. The script takes too much CPU to be allowed run. The fact that you are running it every night is even worse. What type of site do you have that changes so much that it would need a new site map every night? Google only scans about once ever two weeks, so your wasting a ton of CPU running it so often. Even if you add 200 pages a night, running it once a week would have been nicer to the other users on the box and still mean that google would never get a site map older than 6 days.

I've run into the same problem myself. I have yet to find a site map program that doesn't bring my server to its knees on larger sites. Even when the map is run on my PC for a website on the server, the server still screams.

The only suggestion I can make is that you don't run it so often and try to find a more CPU friendly version. That version would run longer, but use less CPU. You can keep support in the loop on what you are doing. If the site mapper didn't take so much CPU, take so much CPU in such a short time, it would likely be ok to run. The TOS doesn't say you can't run long running cron jobs, just that you can't hog the CPU.

I have to agree with support, the current version you are running, combined with the amount of CPU it is using and the frequency that you are running it is a good reason to suspend your account. You were luck they only suspended the cron job, they could have suspended your whole account.

To make it worse, there is no way for you to know you were doing anything wrong, unless your script reports CPU usage or run time. Those report are only available on the server level. So when you find/test a new version, let support know so they can cancel it if it gets out of hand. That will prevent them from suspending you.

[GaryW]

Thanks again Serra .. At least you have confirmed what I really could not decipher myself ... and yes as you say ... at least if the script had given me some insight into what it was doing cpu wise I might have detected it myself ...

Anyhow ... it will be back to looking for an alternative sitemap generator ...

Most of the active increase in pages is due to new posts of information being added to a forum ... usially in the order of about 70 - 80 new web pages per day ... but as you say ... maybe I should only get a map generated every week or so ..

Again ... thanks for the info ... and as I said ... I certainly are not complaining about the way HG has handled it ... since all they did was prevent the script from running ... rest of the site has been up all the time ...

[Serra]

Post if you find a sitemap generator that doesn't kill the machine. I have several ecommerce clients that really could use a good sitemap generator, but all of the ones that I've tested have either sucked or been really hard on the box. Running one sitemap, I could put my box into the red!

For now, I'm running them offline with Gsitecrawler, which doesn't kill the CPU tototally, but isn't totally friendly either. However it can't be automated, it is something that I run locally.

I've been getting around sitemaps by using search engine friendly URLs, which seems to be a far better solution. Map out the main site with a site map and let google find everything else with friendly URLs.]

Originally Posted by GaryW

Again ... thanks for the info ... and as I said ... I certainly are not complaining about the way HG has handled it ... since all they did was prevent the script from running ... rest of the site has been up all the time ...

I agree, they did exactly what they should have done and you were totally good about it. Keeping in mind that you had no idea that your scripts were doing anything wrong and no way to know they were a problem. The first time I ran a sitemap, I checked the CPU usage and was shocked. Without that ability, its hard to judge if something is working or not.

[GaryW]

For now, I'm running them offline with Gsitecrawler, which doesn't kill the CPU tototally, but isn't totally friendly either. However it can't be automated, it is something that I run locally.

Will do ... Believe it or not I was using Gsitecrawler before I found the xml-sitemap generator script .. As you say, it does the job ... but was not as friendly to set up as the .php script ... so it will be back to it for a while anyway ...

catch you later

GaryW

[Barcelona Barry]

My shared account has been suspended and the recommendation been made that I go on to a dedicated server. However, nothing more "high usuage" is quoted by hostgator. Yet the analytics shows no such high traffic, no unusual activity in fact no issues at all.

We have gone back to Hostgator to try to find the source of the problem but all we get is "high usuage".

Unfortunately this lack of accurate info - which we cannot investigate ourselves because the account is blocked - simply leads one to the view that someone is trying it on looking for increased revenue. It is probably very unfair to say that, but the lack of information does give that perception. A shame!

[eLIANT]

Is there a question?

(...other than: who are you? why add onto a 5-year-old thread? what is your URL? etc.)

As I have been impacted by "system upgrades" and unacceptable downtime, I read these threads and it is evident that I am not the Lone-Ranger. I would entertain helping Host Gator in any way that I can. The growth must be accompanied with Support Training, and each call must be identified systematically by customer account number or domain. This is the first issue that must be resolved, customer call-in logs. Seems, each time I call in, if a "Ticket" wasn't created then each Agent knows nothing about the issue. Also, it is pretty commen experience to not have a ticket created, and customer service seems very reluctant to create a ticket. Unexpected downtime, improper call logging, and inconsistant customer support are HUGE issues with Host Gator. Although, I do very much enjoy the functionality, I believe these offerings are "overgrowth" that currently can not be supported with such company infrastructure.

[denisedb]

Hi all. i dont know why i cant create a new post but i have a situation here:
i have been experiencing a slow sites and its cause is cpu over usage. although i have 19 site addon in my account i don't get much traffic. i summed up the average user visit in google analytics per website and get only a total of 200 users!! thats very small so i was thinking i am not the cause of over using the cpu. but is this a reliable test? and I was wondering if inode usage can cause cpu overloading. (but i dont believe it will). i am currently still moving some sites to our new server purchased from host gator to bring down inode usage. I'm just scared our account will get shut down because we are over using cpu. Please help!

[avalanch]

Why did you bump a 6 year old thread?

Originally Posted by Barcelona Barry

My shared account has been suspended and the recommendation been made that I go on to a dedicated server. However, nothing more "high usuage" is quoted by hostgator. Yet the analytics shows no such high traffic, no unusual activity in fact no issues at all.

We have gone back to Hostgator to try to find the source of the problem but all we get is "high usuage".

Unfortunately this lack of accurate info - which we cannot investigate ourselves because the account is blocked - simply leads one to the view that someone is trying it on looking for increased revenue. It is probably very unfair to say that, but the lack of information does give that perception. A shame!

[thunderstruck]

The whole advertising issue is that HostGator does not charge you according to how much bandwidth you use in "unlimited bandwidth" plans. There are no guarantees that you will ever approach unlimited bandwidth without violating TOS for cpu usage.

Pretty clear in the Terms of Service. HostGator stands out from the competition by the fact it does not consider your bandwidth or number of domains hosted towards determining the costs of certain hosting plans, I am amazed by how many people try to twist that marketing strategy into something it is clearly not.