Making sense of CPU exceeded errors

[frodojrr]

I'm trying to locate the cause of a CPU-exceeded error that occurred today. Trouble is, there is no corresponding mysql_slow_queries log to correspond with a huge CPU-exceeded log entry I found.

Here's the CPU-exceeded entry:

CPU Exceeded Log For Mon Aug 25 11:48:29 2008


Mon Aug 25 11:48:15 2008: used 259.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:47:07 2008: used 139.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:46:42 2008: used 11.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:46:21 2008: used 6.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:46:19 2008: used 3.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:46:06 2008: used 4.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:45:45 2008: used 42.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:45:26 2008: used 4.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:45:14 2008: used 1.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:44:53 2008: used 1.03 seconds of cpu time for HTTP Request: www.enewspf.com : GET /index.php?option=com_content&task=view&id=4525&Itemid=1&ed=98 HTTP/1.1
Mon Aug 25 11:44:41 2008: used 0.10 seconds of cpu time for HTTP Request: www.pfrpc.com : GET /gallery/thumbs/P1010014.jpg.LCK HTTP/1.1
Mon Aug 25 11:44:39 2008: used 0.03 seconds of cpu time for HTTP Request: www.pfrpc.com : GET /gallery/thumbs/P1010026.jpg.LCK HTTP/1.1
Mon Aug 25 11:44:38 2008: used 0.01 seconds of cpu time for HTTP Request: www.pfrpc.com : GET /gallery/thumbs/P1010033.jpg.LCK HTTP/1.1
Mon Aug 25 11:44:37 2008: used 0.43 seconds of cpu time for HTTP Request: www.pfrpc.com : GET /gallery/thumbs/P1010035.jpg.LCK HTTP/1.1
Mon Aug 25 11:44:36 2008: used 0.09 seconds of cpu time for HTTP Request: www.pfrpc.com : GET /gallery/images/P1010006.jpg HTTP/1.1
Mon Aug 25 11:44:34 2008: used 0.85 seconds of cpu time for HTTP Request: www.enewspf.com : GET /modules/js_flashrotator/img/stub-hub-get-theater-tickets.jpg HTTP/1.1

This is completely unacceptable. But there is no corresponding mysql_slow_queries secton that corresponds. How can I locate the bad section, especially for these sections?


Mon Aug 25 11:48:15 2008: used 259.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:47:07 2008: used 139.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:46:42 2008: used 11.00 seconds of cpu time for [[mysql query]]

[Eriksrocks]

Have you looked at this helpdesk entry? :)
http://helpdesk.bluehost.com/kb/index.php?x=&mod_id=2&id=498

[frodojrr]

Have you looked at this helpdesk entry? :)
http://helpdesk.bluehost.com/kb/index.php?x=&mod_id=2&id=498

I did. I've read that before.

But my dilemma remains that these lines, for example, tell me next to nothing:


Mon Aug 25 11:48:15 2008: used 259.00 seconds of cpu time for [[mysql query]]
Mon Aug 25 11:47:07 2008: used 139.00 seconds of cpu time for [[mysql query]]

The lines in the Helpdesk FAQ you reference are more descriptive, pointing to specific processes or scripts that were running.

I'll keep exploring.

[buggy]

But my dilemma remains that these lines, for example, tell me next to nothing:


I have this exact problem (but I have a HostMonster account). My account is being suspended for exceeding the cpu quota due to [[mysql query]].

I've contacted HM support and they say they have nothing other than what would appear in the mysql_slow_queries logs and of course there is no corresponding query that remotely takes as long as what is reported in the cpu_exceeded_logs.

Have you had any luck in narrowing down your problem?

[frodojrr]

I have this exact problem (but I have a HostMonster account). My account is being suspended for exceeding the cpu quota due to [[mysql query]].

I've contacted HM support and they say they have nothing other than what would appear in the mysql_slow_queries logs and of course there is no corresponding query that remotely takes as long as what is reported in the cpu_exceeded_logs.

Have you had any luck in narrowing down your problem?

Not really. I had a friend who knows more MYSQL than I do look over the logs, and there was no real way to track anything down. He says my scripts are pretty good. The threshold at BH must be very low -- I don't know.

I have a ton of content. I ended up archiving half of it, and this seems to have helped the situation. We'll see.

[buggy]

I am now questioning how BlueHost / HostMonster determines that a mysql querying coming from a particular user is taking that much CPU time (and without being able to provide us with the query in suspect).

If I did a 'ps ux' during the same time that the supposed cpu intensive query is executing I wouldn't expect to see anything out of the ordinary for the cpu usage of the processes owned by me since the 'mysqld' daemon that is owned by the user 'mysql' would be the actual process whose cpu usage would go up.

[frodojrr]

I am now questioning how BlueHost / HostMonster determines that a mysql querying coming from a particular user is taking that much CPU time (and without being able to provide us with the query in suspect).

If I did a 'ps ux' during the same time that the supposed cpu intensive query is executing I wouldn't expect to see anything out of the ordinary for the cpu usage of the processes owned by me since the 'mysqld' daemon that is owned by the user 'mysql' would be the actual process whose cpu usage would go up.

Yes, the five minute slap on the hand doesn't help if you can't go back and fix what's wrong.

[mhJr_]

Not really. I had a friend who knows more MYSQL than I do look over the logs, and there was no real way to track anything down. He says my scripts are pretty good. The threshold at BH must be very low -- I don't know.

I have a ton of content. I ended up archiving half of it, and this seems to have helped the situation. We'll see.

http://www.avxf.com/img18.jpg

IF your friend can single out the problem, please due post it up as I've had friends with this reoccurring issue on cpu exceeding.

I will have them check their logs also. =]

[friky19]

Welcome to the club. I get the same error, specially when trying to backup the databases I have. So its not my sites scripting, its something at Bluehost/Hostmonster.

This is my case:

http://www.bluehostforum.com/showpost.php?p=59966&postcount=31

[buggy]

I'm starting to think more and more that the issue is really on Bluehost's / Hostmonster's end.

I've contacted support and no one can answer how they are determining that an individual mysql query that I issue is taking up that much cpu time since it is the mysqld daemon that processes everyones' queries and it is that process whose cpu time would go up.

Determining the cpu usage in this case is not as simple as tracking the cpu time for a process that is owned by my user account. They would have to determine that a mysql query I issue is causing the mysqld process to take up X amount of cpu time more than if it wasn't processing my query,

This combined with the fact that no corresponding slow query appears in the mysql_slow_queries logs makes me question how accurate their CPU quota determination is.

Simply providing the actual query instead of [[mysql query]] would go a long way in helping users avoid getting suspended and removing doubt that the CPU exceeded errors are our fault and not theirs.

[felgall]

I believe Matt mentioned something on his blog a long time ago about how they rewrote that part of mySQL in order to incorporate the ability to track which account launched what processing.

[buggy]

I believe Matt mentioned something on his blog a long time ago about how they rewrote that part of mySQL in order to incorporate the ability to track which account launched what processing.

You'd think they'd also track which query is suspect instead of the ambiguous [[mysql query]].

[charlesp]

I have a folder in the root directory called tmp. Inside that folder is a file called mysql_slow_queries. The files tell you what query took so long and how long the query took. Right above that file is a file called cpu_exceeded_logs.

[friky19]

Thing is why are these queries getting these errors and causing high cpu load, when at godaddy, this same database never had such errors.

The only thing that i can think of is that godaddy hosts the databases in another server completely different from were they store your webpages. So they probably let higher cpu load on these database servers.

Maybe Bluehost should do that as well

[al7or]

i have the same problem
it was only with bluehost
i didn't get any solution for it up to now

[frodojrr]

i have the same problem
it was only with bluehost
i didn't get any solution for it up to now

BlueHost is taking quite a spanking on several web design Yahoo groups over this -- and none of those contributions are from me. Apparently this issue is endemic to BlueHost, and many have taken notice.

[al7or]

BlueHost is taking quite a spanking on several web design Yahoo groups over this -- and none of those contributions are from me. Apparently this issue is endemic to BlueHost, and many have taken notice.

do u believe that everyday i have exceeded erorrs ? i checked all the plugin products they are fine

when i ask bluehost support
they tell me check this
i will get crazy now coz everything is fine but why the exceed erorrs happen

http://helpdesk.bluehost.com/kb/index.php?x=&mod_id=2&id=498

[felgall]

BlueHost is taking quite a spanking on several web design Yahoo groups over this -- and none of those contributions are from me. Apparently this issue is endemic to BlueHost, and many have taken notice.

BlueHost look after their target user base by ensuring that no one can hog all of the CPU. This keeps over 99% of their users happy at the expense of those who shouldn't be using shared hosting in the first place.

There are two possible causes for exceeding the CPU limit.

1. There is something wrong with the scripts that you are running so that they use far more CPU than they should - the solution is to rewrite the script to fix it to run properly.
2. The scripts run efficiently but are being run very frequently due to the number of visitors you are getting - the solution is that you have outgrown shared hosting and should be looking for either a virtual server or dedicated hosting account.

Some scripts by the nature of what they do might exceed the CPU limit even with just a handful of visitors but then such scripts are not designed for use on shared hosting in the first place.

You need to use scripts that work efficiently and select an appropriate level of hosting for your site's requirements. Those who complain about CPU exceeded have failed to do this. That is their fault so trying to pass the blame just means that they don't understand the requirements of what they are trying to do.

[friky19]

BlueHost look after their target user base by ensuring that no one can hog all of the CPU. This keeps over 99% of their users happy at the expense of those who shouldn't be using shared hosting in the first place.

There are two possible causes for exceeding the CPU limit.

1. There is something wrong with the scripts that you are running so that they use far more CPU than they should - the solution is to rewrite the script to fix it to run properly.
2. The scripts run efficiently but are being run very frequently due to the number of visitors you are getting - the solution is that you have outgrown shared hosting and should be looking for either a virtual server or dedicated hosting account.

Some scripts by the nature of what they do might exceed the CPU limit even with just a handful of visitors but then such scripts are not designed for use on shared hosting in the first place.

You need to use scripts that work efficiently and select an appropriate level of hosting for your site's requirements. Those who complain about CPU exceeded have failed to do this. That is their fault so trying to pass the blame just means that they don't understand the requirements of what they are trying to do.

Ok then can you answer me why when trying to backup the database using the backup tool thru cpanel, the forum or thru phpmyadmin, the system gets the cpu exceeded errors even when all the sites are down to try and do this backup and no visitors are on the site ?

In other words your saying that these applications/scripts that work perfectly well in other hosting places used by thousands in different configurations that dont get this cpu exceeded error when trying to back up a simple small database (200mb) is the root of the problem that only happens to bluehost ?

[al7or]

Ok then can you answer me why when trying to backup the database using the backup tool thru cpanel, the forum or thru phpmyadmin, the system gets the cpu exceeded errors even when all the sites are down to try and do this backup and no visitors are on the site ?

In other words your saying that these applications/scripts that work perfectly well in other hosting places used by thousands in different configurations that dont get this cpu exceeded error when trying to back up a simple small database (200mb) is the root of the problem that only happens to bluehost ?

i totally agree with you
Bluehos should give us real solution?

[felgall]

BlueHost are the only shared hosting that has actually implemented CPU limiting that properly identifies the account to which all CPU usage actually belongs. Other shared hosts allow individual accounts to hog the CPU and adversely affect other accounts on the same server because they don't identify the correct ownership of some CPU hungry processing.

If you don't want to share the CPU fairly with the others on your shared server then go somewhere that doesn't force you to keep within your fair share of the available CPU. The 99.5% of people on your server who don't have CPU issues do not want your stopping their sites from working by stealing all their share of the CPU.

[dkinzer]

BlueHost are the only shared hosting that has actually implemented CPU limiting that properly identifies the account to which all CPU usage actually belongs.I am suspicious that their algorithm is faulty. I've seen CPU exceeded messages for situations that executed timely in many other cases.

I'm also suspicious of their method of identifying slow MySQL queries. Here is a sanitized excerpt from one of my mysql_slow_queries logs:

# Query_time: 22 Lock_time: 0 Rows_sent: 0 Rows_examined: 0
use myaccount_mydb;
SELECT * FROM mytable

You might look at this and say, "Wow! 22 seconds to select all columns and all rows from a table. That must be a *huge* table." Not so. This is a table with two fields, both VARCHAR(255), and the table only has 35 records. On what planet does that query take 22 seconds? I just did the same query in phpMyAdmin and it reported this:
Showing rows 0 - 29 (35 total, Query took 0.0090 sec)
So, something else was going on that caused the query to take 2200 times as long as "normal". Whatever it was, it is something over which I have no control whatsoever and it shouldn't show up in my slow query logs.

[friky19]

BlueHost are the only shared hosting that has actually implemented CPU limiting that properly identifies the account to which all CPU usage actually belongs. Other shared hosts allow individual accounts to hog the CPU and adversely affect other accounts on the same server because they don't identify the correct ownership of some CPU hungry processing.

If you don't want to share the CPU fairly with the others on your shared server then go somewhere that doesn't force you to keep within your fair share of the available CPU. The 99.5% of people on your server who don't have CPU issues do not want your stopping their sites from working by stealing all their share of the CPU.


Believe me, I want to leave as soon as possible, If I could only backup the Databases !

[dkinzer]

I'm also suspicious of their method of identifying slow MySQL queries.On further research, I just found this slow query entry:

# Query_time: 13 Lock_time: 0 Rows_sent: 78 Rows_examined: 78
SELECT *,
`TABLE_SCHEMA` AS `Db`,
`TABLE_NAME` AS `Name`,
`ENGINE` AS `Engine`,
`ENGINE` AS `Type`,
`VERSION` AS `Version`,
`ROW_FORMAT` AS `Row_format`,
`TABLE_ROWS` AS `Rows`,
`AVG_ROW_LENGTH` AS `Avg_row_length`,
`DATA_LENGTH` AS `Data_length`,
`MAX_DATA_LENGTH` AS `Max_data_length`,
`INDEX_LENGTH` AS `Index_length`,
`DATA_FREE` AS `Data_free`,
`AUTO_INCREMENT` AS `Auto_increment`,
`CREATE_TIME` AS `Create_time`,
`UPDATE_TIME` AS `Update_time`,
`CHECK_TIME` AS `Check_time`,
`TABLE_COLLATION` AS `Collation`,
`CHECKSUM` AS `Checksum`,
`CREATE_OPTIONS` AS `Create_options`,
`TABLE_COMMENT` AS `Comment`
FROM `information_schema`.`TABLES`
WHERE BINARY `TABLE_SCHEMA` IN ('myacct_mydb')
LIMIT 250 OFFSET 0
The date/time correspond exactly to when I ran phpMyAdmin and the query looks like one that phpMyAdmin would use to show the tables in a database.

There is clearly something that's not right with the query time computation. I'm beginning to suspect that it is elapsed clock time from beginning to end rather than actual CPU time spent doing the query.

[Bohrme]

BlueHost are the only shared hosting that has actually implemented CPU limiting that properly identifies the account to which all CPU usage actually belongs. Other shared hosts allow individual accounts to hog the CPU and adversely affect other accounts on the same server because they don't identify the correct ownership of some CPU hungry processing.

If you don't want to share the CPU fairly with the others on your shared server then go somewhere that doesn't force you to keep within your fair share of the available CPU. The 99.5% of people on your server who don't have CPU issues do not want your stopping their sites from working by stealing all their share of the CPU.

Wow. Just wow.

[al7or]

for today

--------------------------------------------------------------------------------
CPU Exceeded Log For Sat Sep 27 03:31:34 2008

Sat Sep 27 03:31:34 2008: used 8.50 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:33 2008: used 8.50 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:32 2008: used 8.50 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:31 2008: used 8.50 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:30 2008: used 8.50 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:29 2008: used 8.50 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:28 2008: used 8.50 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:27 2008: used 8.50 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:26 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:26 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:25 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:25 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:24 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:24 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:23 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:23 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:22 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:22 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:21 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:21 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:20 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:20 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:19 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:19 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:18 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:18 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:17 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:17 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:16 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:16 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:15 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:15 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:14 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:14 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /homeuser/public_html/vb/showthread.php
Sat Sep 27 03:31:13 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:13 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:12 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:12 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Sat Sep 27 03:31:11 2008: used 6.62 seconds of cpu time for [[mysql query]]
Sat Sep 27 03:31:11 2008: used 0.00 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php

[al7or]

[27-Sep-2008 00:05:21] PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting ']' in /home/user/public_html/vb/includes/functions_digest.php(226) : eval()'d code on line 7
[27-Sep-2008 00:05:21] PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting ']' in /home/user/public_html/vb/includes/functions_digest.php(226) : eval()'d code on line 7
[27-Sep-2008 00:05:21] PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting ']' in /home/user/public_html/vb/includes/functions_digest.php(226) : eval()'d code on line 7
[27-Sep-2008 00:05:21] PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting ']' in /home/user/public_html/vb/includes/functions_digest.php(226) : eval()'d code on line 7
[27-Sep-2008 00:05:21] PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting ']' in /home/user/public_html/vb/includes/functions_digest.php(226) : eval()'d code on line 7

[al7or]

[29-Sep-2008 00:03:02] PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting ']' in /home/user/public_html/vb/includes/functions_digest.php(226) : eval()'d code on line 7
[29-Sep-2008 00:03:02] PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting ']' in /home/user/public_html/vb/includes/functions_digest.php(226) : eval()'d code on line 7
[29-Sep-2008 00:03:02] PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting ']' in /home/user/public_html/vb/includes/functions_digest.php(226) : eval()'d code on line 7
[29-Sep-2008 00:03:02] PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting ']' in /home/user/public_html/vb/includes/functions_digest.php(226) : eval()'d code on line 7
[29-Sep-2008 00:03:02] PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting ']' in /home/user/public_html/vb/includes/functions_digest.php(226) : eval()'d code on line 7

[al7or]

Mon Sep 29 07:01:23 2008: used 0.19 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Mon Sep 29 07:01:20 2008: used 0.10 seconds of cpu time for HTTP Request: www.domain.com : GET /vb/member.php?u=7264 HTTP/1.1
Mon Sep 29 07:01:19 2008: used 0.26 seconds of cpu time for HTTP Request: www.domain.com : GET /vb/images/statusicon/post_new.gif HTTP/1.1
Mon Sep 29 07:01:17 2008: used 1.00 seconds of cpu time for [[mysql query]]
Mon Sep 29 07:01:17 2008: used 0.18 seconds of cpu time for HTTP Request: www.domain.com : GET /vb/images/icons/exll.gif HTTP/1.1
Mon Sep 29 07:01:15 2008: used 1.00 seconds of cpu time for [[mysql query]]
Mon Sep 29 07:01:14 2008: used 1.00 seconds of cpu time for [[mysql query]]
Mon Sep 29 07:01:00 2008: used 0.17 seconds of cpu time for /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php
Mon Sep 29 07:00:59 2008: used 2.00 seconds of cpu time for [[mysql query]]
Mon Sep 29 07:00:56 2008: used 0.17 seconds of cpu time for HTTP Request: www.domain.com : GET /vb/cron.php?rand=1222693232 HTTP/1.1
Mon Sep 29 07:00:49 2008: used 5.00 seconds of cpu time for [[mysql query]]
Mon Sep 29 07:00:42 2008: used 0.04 seconds of cpu time for PROCESS : /ramdisk/bin/php5 /home/user/public_html/vb/showthread.php

[charlesp]

What's your point? :confused:

[felgall]

He has made his point - either he has poorly written scripts that chew up too much CPU that he hasn't fixed OR he has too many visitors for shared hosting.

He either has to fix his scripts or find alternate hosting with higher CPU limits.

[giorno]

@felgall
What we have to do to backup our databases without get a CPU exceeded errors? thank you

[Jason_85]

I'll probably get banned for this but here goes. Bluehost is obviously modifying their database access records to make it look like queries and php processes take longer than they actually do.

This is not only misleading, it's illegal. If you feel like you've been mislead, why not stop it from happening to others? If everyone who is unhappy with this misleading advertisement files a complaint with their local office of fair trading than they'll finally stop doing it.

[felgall]

I'll probably get banned for this but here goes. Bluehost is obviously modifying their database access records to make it look like queries and php processes take longer than they actually do.

You have no proof that they are doing that and there is no reason whatsoever why they would do that and so it is just about as certain as anything can be that they are not.

They set what the CPU limits on the hosting are and so if they need to manipulate how much CPU people can use then all they would need to do is lower the CPU limit - not manipulate the CPU calculation. The last change that was made to the CPU limit was earlier this year when they effectively doubled it so that now everyone gets about twice as much CPU as they did at the beginning of the year.

[felgall]

@felgall
What we have to do to backup our databases without get a CPU exceeded errors? thank you


Have you tried backing up one table at a time?

[dkinzer]

What we have to do to backup our databases without get a CPU exceeded errors?I have several large databases that I back up nightly via a cron job using Wolf's dbbackup script (http://restkultur.ch/personal/wolf/scripts/db_backup). So far, I've never had a "CPU exceeded" condition. In contrast, if I attempt to backup the databases using cPanel, I almost always get an abort before it finishes.

[friky19]

Have you tried backing up one table at a time?

I have, the "largest" table that is 27mb wont do it. Tried backing up the whole DB thru the shell and it apparently does so, but the size isnt the same, it should be 102mb in total, but its backup is 68mb.

When I open up the backup done thru the shell, the table "posts" which is the large one on the database, isnt complete.

Im going to try Wolf's Script now and see what happens.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------



#### Update 1 #####

tried Wolf's Script and I got this:

----------------------------------------------------------------------
21:49:26: Starting backup of table XXXXXX.ngpost ...
21:49:36: Creating backup file days/ngpost.2008-09-30.sql ...

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 27811567 bytes) in /home/XXXXXXXX/public_html/XXXXXXX/db_backup/db_backup.php on line 454

#### Update 2 ####

Removed FastCGI, changed memory limit in php.ini and was able to backup that table... now its stuck on this one:

22:17:20: Starting backup of table XXXXXX.postindex ...

Fatal error: Out of memory (allocated 8388608) (tried to allocate 6291424 bytes) in /home/XXXXXXXX/public_html/XXXXXXXX/db_backup/functions.php on line 327

[DocO]

Add me to the list of "offenders". Tech support just instructs me to repair tables with overhead. I do this daily. Any insert, update, or delete seems to automatically create overhead again, and it seems to build up quickly. My site is small with maybe a 12 to 24 users logging in daily. The same queries are executed over and over again, yet only once in a while will the execution time spike and cause the CPU exceeded problem. Properly running databases with indexed tables and queries that use those indexes do not have a tendency to change their execution time so wildly. There is a problem, and I'm fairly certain it's not my site.


EDIT - Just curious.. those having this problem.. what box are you on?

I'm on 403.

[dkinzer]

# Query_time: 22 Lock_time: 0 Rows_sent: 0 Rows_examined: 0
use myaccount_mydb;
SELECT * FROM mytable
I opened a trouble ticket and asked how this query could possibly take 22 seconds. The reply from a "Level 2 Scripting Specialist" was:

It is possible the server was under a really high load when it tried to run the query. I do not see anything else that would slow it down.
If server load can affect query time that significantly, that suggests that the query time is not actual CPU time spent on the query but some other measure; perhaps actual clock time. If that is true, then the reported query time is not very useful.

[dkinzer]

If server load can affect query time that significantly, that suggests that the query time is not actual CPU time spent on the query but some other measure; perhaps actual clock time.I received a response today from BlueHost confirming that the 2 seconds threshold for slow mySQL queries is, in fact, real time not CPU time.

This is unfortunate because when you are looking at the slow mySQL query reports, you have no idea what the system load was at the time. Obviously, it is only worthwhile looking into improving queries that take too long under "normal" load conditions. Under heavy system load nothing you do with query optimization or indexing is going to help much, if at all.

I asked if they could implement a change to include the recent system load in the slow query report. That would be a significant improvement, I think.

[Esmart]

I had the same problem about 6 months ago. I couldn't find anything that was running incorrectly or malfunctioning. In the end I had to dump every php application I had running - pretty drastic but it was the only way I could prevent getting kicked off the server.

My sites are all php includes - so I always have slow scripts which tends to support your claim. These are only tiny includes to compose sections of the page but I will often get a slow loading page and a lot of page loading errors reported in AWstats. The total page size is well within the standard range so this shouldnt be happening.

Just about all of the slow script entries now refer to Wordpress access to SQL for every day post saving etc - but fortunately no more CPU_Exceeds. These are pretty small scripts and very standard so I would expect to be able to run these without causing any slow-query errors at all.
Hence - again, I agree with you that I think the issue is on the Bluehost side, and have had this conversation with them.

Doesnt help solve your problem - but I would push on with the tech team at Bluehost to help resolve the issue - I did find them very helpful [even if your logs are not]

[ABCDiamond]

I have recently been changing my site from htm to php.

And now my account is suspended, due to one or more of these reasons:

Your account has used more than its share of the cpu in the past 60 second sliding window.
Your account has too many concurrent processes running simultanously.
Your account has consumed too much memory.
Your site was recently very busy trying to run inefficient scripts.


I have just put in a support ticket, but am unable to access my cpanel to do anything.

From what I have just read, it appears that I may need to drop php, but I don't want to lose all the data that has recently been created on the php side of things.

[bdon123]

The answers (some of them) we are getting here from the people who supposedly know what they are talking about are bogus. (I don't know if they are support people, or forum support people, or who they are)

Our site ran great (pretty much, except for the occasional glitch) for the last several months and now SUDDENLY it is running slow (about a week), sometimes unusably slow, and NOTHING of even minor significance has changed. (by us/me -- and I run a pretty tight ship)

I finally got someone in support to understand that there is an actual problem with very strange behaviors. That took about three days. It has been bumped up to "Level 2 Support". We'll see what that does.

Other people on our shared server do not have the same problem. (although I know the sites they showed me as examples were NOT PHP/MySQL sites) Our traffic has not changed to any significant degree for the last three months.

We show the same thing, that MySQL queries are taking up to 2 to 3 seconds, and some of them 30 to 200 seconds. I was told that that is CPU time, which I understand from above is incorrect. (which was my suspicion) We finally got the dreaded "site is shut down due to CPU exceeded errors" tonight. (that I saw, I suppose it could have happened before then)

I got the usual suggestions about repairing the database, make sure you use indexing, etc., etc., etc. The difference is, I am a programmer, and the site designer, and I know what I'm doing, so I was able to answer every question they threw out and show that that is not the problem. (logical analysis is hard to refute, especially when you obviously know what you're talking about)

For some reason, the MySQL server is screwed up. (as far as I can tell) Which is why it is taking so long to do stuff, and the reason why the site is so slow, IN PART, is because the MySQL database queries are "taking so long to execute". Which is occurring NOT because the databases are so large, or the tables have so many records in them, or the databases need repair, or the indexes are not correct, etc., etc., etc.... (The one example I showed was a table that has about 5,000 records that are medium-sized with a primary key and about as simple as you can get SQL statement: SELECT * from table where id=255 and column1<>'test1' and column2<>'test2' -- There is ABSOLUTELY NO REASON WHY this should not be executed almost "immediately", even if you did have a high server load)

There is something wrong somewhere. And it is NOT with our website PHP scripts or MySQL databases or anything like that. If I knew more about system stuff, especially as it applies to *nix, I could probably tell them what is actually wrong, or point them in the right direction.

One weird thing is that our FTP access is also very slow. Supposedly, that is separate from web access. Also, although this could be a by-product of the slow site in general, even if you load a straight HTML page, or even an image, those are equally slow, when there is NO PHP involved. That means something. That is a clue.

One support person said the problem might be because we are using so much disk space. That is nonsensical and they should train their support people better than that. They can't pull those crap answers on me, because I know what I'm talking about.

Having been a support person before more than once in several different scenarios, I tend to cut them some slack, especially if the problem is difficult to analyze and solve, which I can usually tell if it is, or not, better than some. But I do not appreciate being ignored, dismissed, in more than one instance lied to, and that sort of thing. That is uncalled for. When I did support, I knew what I was doing, and I had no problem admitting that I didn't know an answer, because no one knows everything, but I always did my best to try to find out the answer, one way or another, and get a decent resolution. That is how support should always be done. (even if we are only paying $10 a month) There should be a base principle of pride that overrides anything else.

[bluidkiti]

I spoke with a blue host tech today inquiring about whether if I convert my forum pages from php to html would that help. He told me no. Well in reading what's written here:
http://helpdesk.bluehost.com/kb/index.php?x=&mod_id=2&id=498


CPU Quota/Suspension Error

http://www.etrainingteam.com/fastdomain/fdcpuexceeded.JPG
What are CPU Quota/Suspension Errors?
CPU Quota/Suspensions Errors are used as a maintenance tool to help avoid server lockups by preventing customers from running inefficient scripts that monopolize unnecessary CPU time and slow your server down.
Why do I get CPU Quota/Suspension Errors?
CPU Quota/Suspension Errors are currently triggered by a single process taking more than 30 CPU seconds to run or if your total processes take more than 40 CPU seconds in any 60 second window. They are set up like this to avoid server lockups. Your site will generally come back up after 5-10 minutes of suspension. In some cases the following issues may trigger CPU Quota/Suspension Errors:

Over sized and unnecessary database queries can lead to performance issues. Optimize your applications to use less CPU by adding appropriate indeces (index) to your MySQL tables. Click here to learn more about Optimizing MySQL: Queries and Indexes (http://helpdesk.bluehost.com/kb/index.php?x=&mod_id=2&id=499)
Poorly coded .php scripts may lead to extended processing times. Try using static .html documents instead of .php scripts; doing so will practically eliminate CPU Quota Suspension/Errors


it says different. Who is right? Blue Host or Blue Host? :confused:

[areidmtm]

I spoke with a blue host tech today inquiring about whether if I convert my forum pages from php to html would that help. He told me no. Well in reading what's written here:
http://helpdesk.bluehost.com/kb/index.php?x=&mod_id=2&id=498
[/list]
[/indent]it says different. Who is right? Blue Host or Blue Host? :confused:

This is a user to user forum. None of us work for bluehost nor does what said here represent them in anyway.

Your CPU errors should go away with static HTML pages.

[bluidkiti]

Thank you so very much areidmtm for replying. I mean that sincerely. I have been searching and looking and trying to find an answer. Now just to find the best way to convert those php pages to html. Have a great 24! :-)

[bluidkiti]

Also just thought I would mention this same tech told me I should go to a Dedicated IP and that would cost me $19.95 a month but I see here http://helpdesk.bluehost.com/kb/index.php?x=&mod_id=2&id=484 that a Dedicated IP would cost me $2.50 a month or $30 dollars a year. hmmmmmmmmm

[Early Out]

Some miscommunication there. A dedicated IP is $30 a year, but that won't do anything at all to avoid CPU quota problems. It's not a dedicated server - it's just a dedicated IP address. Everything else remains the same - you're still on shared hosting, with all the customary limitations.

There is a high-CPU plan available, though BH doesn't publicize it, and I believe that does, indeed, cost $20 a month. But if you're hitting CPU quota problems, the high-CPU plan won't get rid of it - it'll just push the problem slightly further away. Ultimately, the solution is still to optimize scripts and index databases.

[bluidkiti]

Ultimately, the solution is still to optimize scripts and index databases.

How do you do that?

[Early Out]

The first in a series of articles that might help (links to the others at the bottom):

http://helpdesk.bluehost.com/kb/index.php?x=&mod_id=2&id=499

[borderline]

The first in a series of articles that might help (links to the others at the bottom):

http://helpdesk.bluehost.com/kb/index.php?x=&mod_id=2&id=499

does that applies to coppermine? even if it did, I wouldn't have a clue how to do it

[Early Out]

I don't know much of anything about Coppermine, but with gallery software, one of the cardinal rules is to create the thumbnails on your own PC, and upload them. Having the server-side software do it is almost guaranteed to get you suspended - resizing images is a very CPU-intensive activity, apparently.

[borderline]

I don't know much of anything about Coppermine, but with gallery software, one of the cardinal rules is to create the thumbnails on your own PC, and upload them. Having the server-side software do it is almost guaranteed to get you suspended - resizing images is a very CPU-intensive activity, apparently.

yes, I heard that too but I never got a suspension when uploading pictures, even if never created any thumbnails on my computer.
The CPUs suspensions I get must be when certain amount of people are visiting my gallery:(

[felgall]

yes, I heard that too but I never got a suspension when uploading pictures, even if never created any thumbnails on my computer.
The CPUs suspensions I get must be when certain amount of people are visiting my gallery:(

Perhaps you are letting the script dynamically generate the thumbnails as they are requested and that is using too much CPU.

[borderline]

Perhaps you are letting the script dynamically generate the thumbnails as they are requested and that is using too much CPU.

could you elaborate a little more on that? how can I know if that's the case?:confused:

[felgall]

could you elaborate a little more on that? how can I know if that's the case?:confused:

If you are not creating and uploading the thumbnails yourself then you must be using some other method to create them and that method probably uses lots of cpu since image manipulation is a cpu intensive task best done on your computer.