PHP Fatal errors Max exec. time of 90 seconds on multiple files WordPress
I have been getting these errors for some time on WP's error log;
[02-Aug-2011 14:31:43] PHP Fatal error: Maximum execution time of 90 seconds exceeded in /home/apcc/public_html/wp-includes/functions.php on line 1007
[02-Aug-2011 14:37:13] PHP Fatal error: Maximum execution time of 90 seconds exceeded in /home/apcc/public_html/wp-includes/wp-db.php on line 900
[02-Aug-2011 14:38:42] PHP Fatal error: Maximum execution time of 90 seconds exceeded in /home/apcc/public_html/wp-includes/cron.php on line 60
As you can see, it occurs with different files.
I know I can go in and increase the max execution time, however I don't see any reason for these scripts to be running for that amount of time.
These errors are appearing in the log 90 seconds after any page is browsed. We're not doing uploads or anything that should be load intensive.
Having the processes clocking for 90 seconds eats up resources on the server.
Any suggestions as to why these scripts are trying to run, and how I can stop this from happening?
Answers (8)
Maor Barazany answers:
Hi,
You may try to debug and see it might be you have a page in the site or a plugin / theme's function that makes a lot of database queries and takes a lot of time.
You can try the following:
1. Add this in your theme's footer php for debug -
<?php echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds
This will show you how many queries have been running in the current viewed page. Then - try to deactivate plugins one by one and recheck, is there a plugin that caused a lot of queries?
If it is production site and you do not want that it will be seen bu users, you can have the code as this -
<?php
if (current_user_can('administrator')) {
echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds
<?php } ?>
Then be logged in as admin to the site, and you will see this, while regular user's won't.
2. Add this to your wp-config.php file -
define('SAVEQUERIES', true);
<strong>Notice</strong> that this increase load time of pages, so you should remove this line as soon as you finish testing.
Then, when SAVEQUERIES is on, you may add to the bottom of your theme's footer.php file this code for debug -
<?php
if (current_user_can('administrator')) {
global $wpdb;
echo "<pre>";
print_r($wpdb->queries);
echo "</pre>";
}
?>
This will dumo to screen for each page the actual queries that are being sent to database.
If there are a lot of them, you may find by examining the queries who might be responsible for that.
Once I founc in that may a plugin that makde about 900(!) queries to page, after deactivating that plugin, num of queries has been reduced to 40 and page load time became ok.
Michael I. comments:
Just added the query script, great info, so far.
Home page 250 queries. 6.874 seconds
Child page: 26 queries. 7.520 seconds
I'll follow your instructions to keep on digging and figure out what those might be.
Maor Barazany comments:
6.874 seconds and 7.520 seconds are very long time loads! You must have there some non-efficient code that makes all this.
Try again deactivating plugins, maybe even go back to default WP theme and see if time gets lower.
It may also be that your server is very loaded (is this on a shared hosting or a VPS?)
Michael I. comments:
Dedicated server but this account seems to be using the most resources and that's why I'm digging into it.
I think the query results show a few things that are dragging it down;
Array
(
[0] => Array
(
[0] => SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
[1] => 0.0440220832825
[2] => require, require_once, require_once, require_once, wp_not_installed, is_blog_installed, wp_load_alloptions
)
[1] => Array
(
[0] => show tables
[1] => 0.000472784042358
[2] => require, require_once, require_once, require_once, include_once, check_calendar
)
[2] => Array
(
[0] => SELECT config_value FROM wp_calendar_config WHERE config_item='calendar_version'
[1] => 5.81741333008E-5
[2] => require, require_once, require_once, require_once, include_once, check_calendar
)
[3] => Array
(
[0] => SELECT option_value FROM wp_options WHERE option_name = 'jlao_cat_post_thumb_sizes' LIMIT 1
[1] => 0.000387907028198
[2] => require, require_once, require_once, require_once, include_once, get_option
)
[4] => Array
(
[0] => UPDATE `wp_options` SET `option_value` = '1312315587' WHERE `option_name` = '_transient_doing_cron'
[1] => 0.000401020050049
[2] => require, require_once, require_once, require_once, do_action, call_user_func_array, wp_cron, spawn_cron, set_transient, update_option
)
[5] => Array
(
[0] => SELECT * FROM wp_users WHERE user_login = 'admin'
[1] => 0.000133037567139
[2] => require, require_once, require_once, require_once, WP->init, wp_get_current_user, get_currentuserinfo, wp_validate_auth_cookie, get_userdatabylogin, get_user_by
)
[6] => Array
(
[0] => SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE user_id IN (1)
[1] => 5.79357147217E-5
[2] => require, require_once, require_once, require_once, WP->init, wp_get_current_user, get_currentuserinfo, wp_validate_auth_cookie, get_userdatabylogin, get_user_by, _fill_user, get_user_metavalues
)
[7] => Array
(
[0] => SELECT ID, post_name, post_parent FROM wp_posts WHERE post_name = 'churches' AND (post_type = 'page' OR post_type = 'attachment')
[1] => 9.70363616943E-5
[2] => require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->parse_query, get_page_by_path
)
[8] => Array
(
[0] => SELECT ID, post_name, post_parent FROM wp_posts WHERE ID = 16 and post_type = 'page'
[1] => 4.29153442383E-5
[2] => require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->parse_query, get_page_by_path
)
[9] => Array
(
[0] => SELECT * FROM wp_posts WHERE ID = 195 LIMIT 1
[1] => 7.70092010498E-5
[2] => require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->parse_query, get_page_by_path, get_page, get_post
)
[10] => Array
(
[0] => SELECT `post_parent` FROM wp_posts WHERE ID = 16 LIMIT 1
[1] => 4.29153442383E-5
[2] => require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->parse_query, get_page_by_path, get_page, get_post, _get_post_ancestors
)
[11] => Array
(
[0] => SELECT wp_posts.* FROM wp_posts WHERE 1=1 AND (wp_posts.ID = '195') AND wp_posts.post_type = 'page' ORDER BY wp_posts.post_date DESC
[1] => 7.29560852051E-5
[2] => require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts
)
[12] => Array
(
[0] => SELECT `post_parent` FROM wp_posts WHERE ID = 16 LIMIT 1
[1] => 4.10079956055E-5
[2] => require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts, get_post_status, get_post, _get_post_ancestors
)
[13] => Array
(
[0] => SELECT t.*, tt.*, tr.object_id FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON tt.term_id = t.term_id INNER JOIN wp_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN ('category', 'post_tag') AND tr.object_id IN (195) ORDER BY t.name ASC
[1] => 6.103515625E-5
[2] => require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts, update_post_caches, update_object_term_cache, wp_get_object_terms
)
[14] => Array
(
[0] => SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (195)
[1] => 4.38690185547E-5
[2] => require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts, update_post_caches, update_postmeta_cache, update_meta_cache
)
[15] => Array
(
[0] => SELECT * FROM wp_posts WHERE ID = 16 LIMIT 1
[1] => 0.000137090682983
[2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, feed_links_extra, get_post_comments_feed_link, get_permalink, get_page_link, _get_page_link, get_page_uri, get_page, get_post
)
[16] => Array
(
[0] => SELECT p.* FROM wp_posts AS p WHERE p.post_date < '2010-11-03 19:02:08' AND p.post_type = 'page' AND p.post_status = 'publish' ORDER BY p.post_date DESC LIMIT 1
[1] => 0.000102043151855
[2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, adjacent_posts_rel_link_wp_head, adjacent_posts_rel_link, get_adjacent_post_rel_link, get_adjacent_post
)
[17] => Array
(
[0] => SELECT `post_parent` FROM wp_posts WHERE ID = 10 LIMIT 1
[1] => 4.50611114502E-5
[2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, adjacent_posts_rel_link_wp_head, adjacent_posts_rel_link, get_adjacent_post_rel_link, get_permalink, get_post, _get_post_ancestors
)
[18] => Array
(
[0] => SELECT * FROM wp_posts WHERE ID = 10 LIMIT 1
[1] => 6.19888305664E-5
[2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, adjacent_posts_rel_link_wp_head, adjacent_posts_rel_link, get_adjacent_post_rel_link, get_permalink, get_page_link, _get_page_link, get_page_uri, get_page, get_post
)
[19] => Array
(
[0] => SELECT p.* FROM wp_posts AS p WHERE p.post_date > '2010-11-03 19:02:08' AND p.post_type = 'page' AND p.post_status = 'publish' ORDER BY p.post_date ASC LIMIT 1
[1] => 6.60419464111E-5
[2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, adjacent_posts_rel_link_wp_head, adjacent_posts_rel_link, get_adjacent_post_rel_link, get_adjacent_post
)
[20] => Array
(
[0] => SELECT `post_parent` FROM wp_posts WHERE ID = 16 LIMIT 1
[1] => 4.41074371338E-5
[2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, adjacent_posts_rel_link_wp_head, adjacent_posts_rel_link, get_adjacent_post_rel_link, get_permalink, get_post, _get_post_ancestors
)
[21] => Array
(
[0] => SELECT config_value FROM wp_calendar_config WHERE config_item='calendar_style'
[1] => 4.79221343994E-5
[2] => require, require_once, include, get_header, locate_template, load_template, require_once, wp_head, do_action, call_user_func_array, calendar_wp_head
)
[22] => Array
(
[0] => SELECT * FROM wp_comments WHERE comment_post_ID = 195 AND (comment_approved = '1' OR ( user_id = 1 AND comment_approved = '0' ) ) ORDER BY comment_date_gmt
[1] => 0.000110864639282
[2] => require, require_once, include, comments_template
)
[23] => Array
(
[0] => SELECT COUNT(*) FROM wp_ngg_pictures WHERE exclude != 1
[1] => 6.60419464111E-5
[2] => require, require_once, include, get_sidebar, locate_template, load_template, require_once, dynamic_sidebar, call_user_func_array, WP_Widget->display_callback, nggWidget->widget
)
[24] => Array
(
[0] => SELECT t.*, tt.* FROM wp_ngg_gallery AS t INNER JOIN wp_ngg_pictures AS tt ON t.gid = tt.galleryid WHERE tt.exclude != 1 ORDER by rand() limit 9
[1] => 0.00133299827576
[2] => require, require_once, include, get_sidebar, locate_template, load_template, require_once, dynamic_sidebar, call_user_func_array, WP_Widget->display_callback, nggWidget->widget
)
)
Michael I. comments:
I disabled the calendar and it dropped it 18 queries 4.93 seconds.
Michael I. comments:
Hmm, even with calendar disabled, queries are way down, but loadtime is still high.
I don't get the earlier errors in the log, instead I get;
[02-Aug-2011 20:38:06] PHP Fatal error: Allowed memory size of 838860800 bytes exhausted (tried to allocate 20717145 bytes) in /home/apcc/public_html/wp-includes/wp-db.php on line 785
Maor Barazany comments:
Try to disable NextGen and see. I had once lots loading time issues with that plugin, I never use it..
Michael I. comments:
Doesn't seem to make much of a difference without NexGen,
18 queries. 6.713 seconds
Maor Barazany comments:
Have you tried to optimize tables of your database? Maybe big overheads might causing mysql to take a lot of time to respond.
Also, check the mysql process (run top in your server's shell ) and see how much memory and cpu it takes, it may be that something is wrong there. Also see if you by accident have a lot of apache processes that loads the server.
Michael I. comments:
Tables are not too big. There was minimal overhead (27kb). I just optimized the 3 tables that had overhead;
apcc_wp.wp_commentmeta optimize status OK
apcc_wp.wp_comments optimize status OK
apcc_wp.wp_options optimize status OK
I've been watching top all day. That's how I knew that apcc php processes were eating up cpu and memory.
Michael I. comments:
example of a process from this account;
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3175 apcc 25 0 432m 370m 6268 S 72.5 9.4 0:40.33 php
Maor Barazany comments:
Have you tried to switch to default WP theme and disable plugins and see what the difference about response time and server load? It might be that some non-efficient code is in one of the plugins that in use, or in the theme's functions.
Michael I. comments:
I had a lengthy response typed out, but I got logged out.
To recap..
I didn't change the themes, because this is a live server.
Instead I copied the site to an older VPS I have and it ran perfect there. All page loads were under a second and there were no errors in the error log.
The account i copied was the same, but PHP,MySQL, and Apache were all older versions and there was no load on the server.
I'm afraid this is telling me that I'm back to square one, which is figuring out why the server is slow!
Teri Westerby answers:
I ran into this problem myself. Are you hosting with godaddy? we had to get them to switch our servers as I believe it was on a windows server and it was timing out.
Michael I. comments:
No, this is on our dedicated server running linux.
Jarret Minkler answers:
Most likely, this is due to a poorly coded plugin trying to access the database in some way.
To try and get to the bottom of this, first open up your wp-includes/functions.php file and go to line 1007 and see what it is trying to do there, most likely it will become apparent (user function - maybe too many users or user operations and DB calls)
Next, you can go into your MySQL and turn the slow query log on.
http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html
This may also give you more indication.
You may also want to see exactly which part of code is calling these functions.
You can insert code into the functions to dump out the backtrace (trace of what code is calling what)
$trace = debug_backtrace();
foreach ($trace as &$t) {
unset($t['args']);
}
error_log(print_r ( $trace,true), 3, '/tmp/debugbacktrace.log');
Leave this in the code for a bit and hit the pages a bit, and the cron.php and see what ends up in the log (or post some of it here)
Jarret Minkler comments:
Home page 250 queries
This seems to be way too many queries
You are probably running into problems where mysql doesn't have enough resources, things are getting locked, and timing out ..
Why So many queries? What Gallery plugin is this (usually bad gallery plugins are the usual suspects)
Michael I. comments:
Gallery is NextGEN Gallery.
Michael I. comments:
FYI, looking at your earlier post, this is what is around that line in functions.php, with line 1007 bolded.
/**
* Serialize data, if needed.
*
* @since 2.0.5
*
* @param mixed $data Data that might be serialized.
* @return mixed A scalar data
*/
function maybe_serialize( $data ) {
if ( is_array( $data ) || is_object( $data ) )
<strong>return serialize( $data );</strong>
if ( is_serialized( $data ) )
return serialize( $data );
return $data;
}
Michael I. comments:
Oops, can't bold withing code, but this is line 1007
return serialize( $data );
Michael I. comments:
I appreciate the slow sql process suggestion, not sure I can do that though, I have MySQL version 5.0.92
Jarret Minkler comments:
This this the 5.0 MySql slow query page
http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html
Seems like the serialize line is trying to serialize some large object, might be useful to place the backtrace there and figure out what is calling it.
Jarret Minkler comments:
What do you have on this line?
838860800 bytes exhausted (tried to allocate 20717145 bytes) in /home/apcc/public_html/wp-includes/wp-db.php on line 785
I have comments on that line ..
which is my next question, which version on WP are you running?
Michael I. comments:
Line 785 on wp-db.php is;
return mysql_real_escape_string( $string, $this->dbh );
We are running WP 3.0 on this site.
Jarret Minkler comments:
Thats really quite odd that its timing out there, unless for some reason, its trying to work with VERY large objects.
Only way your going to figure out why is with a backtrace or xdebug to see what is getting send to that function and from what code.
Romel Apuya answers:
Hi,
I think the main reason should be optimizing the code, not the tables.
It should be that queries are made when its necessary and queries should be reseted
if not in use. SO the main problem is on poor code optimization.
AdamGold answers:
If you have and can edit php.ini, find and alter
max_execution_time = 90
and increase the value to
max_execution_time = 300
If editing .htacess instead, add the line:
php_value max_execution_time 300
Credit goes to Brian Richards and:
[[LINK href="http://www.lancelhoff.com/maximum-execution-time-of-30-seconds-exceeded/"]]http://www.lancelhoff.com/maximum-execution-time-of-30-seconds-exceeded/[[/LINK]]
ej_emman answers:
Yes I Agree with Adam.
try to edit you php.ini:
max_execution_time = 300
then,
restart your APACHE server or any server you have...
tell me if it helps...
Michael I. comments:
I still firmly disagree with this approach UNLESSS there is something that COULD take a long time to run. File uploads, crons, etc. I did increase to 150 and it didn't help, but there is no reason for a process to be running for that long. That's not going to fix the root of the problem.
ej_emman comments:
Okay, try this if it helps;
1.) check wp_reset_query() every end of your code.
2.) restart your mysql database, then optimize table called by your query.
optimize table yourtable
3.) try to check your server:
top
try to see the CPU usage and Memory
It helps me, when I encounter this kind of problem...
Ozh RICHARD answers:
From what I can read here, there are 2 parts in this problem. First, your home page fires an *insane* number of SQL queries (250???). Second, even on pages with a reasonable number of queries, page generation time is way too high. The problem is not just on the SQL part, and can be somewhere else: other internals of WP, or other internals of the server itself.
Overall, your goals should be:
- find why things are slow on a regular page with only 25 queries (key problem)
- find a way to reduce the number of queries on the home page (secondary problem, especially if you're running on a dedicated server)
<em>Things I *don't* suggest you do:</em>
- increase max exec time and RAM available as some have suggested. Just because your bus explodes if you drive below 30 MPH doesn't mean you've fixed things if you just keep driving faster.
<em>Things I'd suggest you do and investigate</em>
<strong>- is the blog running that slow with all plugins deactivated?</strong>
You should deactivate *all* plugins, benchmark things a bit (home page, sub page) and see if things are fast enough. Then, one by one, activate 1 plugin and benchmark again. Hopefully you'll find a sudden drop in performance after you've activated one plugin (deactivate and test again, then continue activating other plugins one by one). This can be a poorly written plugin, or a perfectly valid plugin that's getting harm from another poorly written plugin, so don't judge too fast.
<strong>- What is the number of pages (not posts) your blog has ?
- How is your permalink structure ?</strong>
WordPress doesn't perform too well with a large number of pages because of the way rewrite rules are generated. Similarly, WP can perform poorly depending on the permalink structure, especially with /%category%/ beginning the permalinks.
These two first questions are the first obvious things to investigate. If you cannot find your answer there, more for you.
Deactivate all plugins, and install [[LINK href="http://wordpress.org/extend/plugins/core-control/"]]Core Control[[/LINK]]. This plugin can help diagnose what's running and how it's running. For instance, maybe your setup tries to contact api.wordpress.org to check the latest version of WP and, due to poor network config of the server, takes ages to do so.
Again, within Core Control, disable core components (HTTP API, Cron jobs...) one by one and check if you see any improvements.
If that's still not enough, try deactivating Apache or PHP level components: opcode cache modules, security modules, etc... and see if you see an increase in performance.