Blank screen due to memory allocation failure
-
Hi
Now and then my reporting tool > http://wordpress.org/plugins/strictly-system-check/ will report that the site is down with a 500 status error.
The main info is
The server load is currently 0.08
The current database load is 4%
Total Reads: 2866093 (88%) – Total Writes 379600 (12%)
No DB tables need REPAIRING – the whole report is at the bottom of the page.So I go and check the screen and get a white page on the homepage or when I try and login to wp-admin.
Also when I try and access another site on the same Virtual Server (Rackspace) the site is running fast and with no problem. Both servers have EXACTLY the same plugins installed.
I turn on the WP_DEBUG constant and the error is about memory allocation e.g tried to allocate X bytes but memory was X so it couldn’t be allowed this is on the WP-Admin homepage / login screen.
I don’t know if it’s some kind of plugin or some process going on behind the scenes but when I run a TOP command the amount of memory used is not as much as the site says. Disk swapping is not low. I do have a 2 GB RAM Server so the hard disk space for swapping is 4 GB ( I’ve been told) so I am not sure what is going on or how to narrow down the problem.
Sometimes when I run TOP I DO see an APACHE process taking up 99% CPU but I have no idea how I can narrow this down to find the PHP script or file being loaded CAUSING this.
Also when I check the standard error logs in VMIN I don’t get any errors apart from Client Denied due to IP Configuration (Network Firewall and DebyHOST etc) for the time the error was shown.
Is there anyway of narrowing down OR logging at the time of the error (as it doesn’t seem to get logged in the error_log) what plugins were running or processes that required the memory and made it unavailable?
Or is there some kind of log file that stores all processes that use over X bytes of memory with a timestamp – OR if you give me the logic I would need I could write one in PHP/PERL. If there was a core file loaded in before every other file like settings.php I could log the current memory usage, time and URL (and if I had the code the process chain as you see in some errors e.g
[Sun Jul 13 00:44:12 2014] [error] [client 141.101.98.153] WordPress database error Table ‘mysite.wp_wpr_subscribers_2’ doesn’t exist for query select * from wp_wpr_subscribers_2 where id=720; made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), call_user_func_array, wpresponder_init_method, include(‘/plugins/wp-responder-email-autoresponder-and-newsletter-plugin/confirm.php’), sendConfirmedEmail, wpr_place_tags
But with [memory] 1234434MB used at the end or something.
I am thinking of adding the memory usage to my reporting plugin but a better logging system IS required.
Ideas?
This is the full report I got before investigating – notice the VERY low server usage.
System Report: 2014-07-13 09:07:44
Initiating System Report…
Using Strictly System Check Version: 1.0.6
Initiating an HTTP request to http://www.mysite.com
The HTTP request to http://www.mysite.com took 1 second(s) to respond and returned a status code of 500
The specified search text read more could not be located within the HTTP response
The server load is currently 0.08
The server load is very quiet
MySQL has been running for: 9 days 6 hours 9 mins 41 secs
Total Connections: 327217 – Aborted: 0 – Connections Per Hour 1472
Total Queries: 18098706 – Queries / Per Hour 81466
Joins without indexes: 0 – Joins without indexes Per Hour 0
Total Reads: 2866093 (88%) – Total Writes 379600 (12%)
Initiating a check for corrupt tables and indexes
Table: wp_ak_twitter does not need repairing
Table: wp_bad_behavior does not need repairing
Table: wp_category_subdomains does not need repairing
Table: wp_commentmeta does not need repairing
Table: wp_comments does not need repairing
Table: wp_links does not need repairing
Table: wp_options does not need repairing
Table: wp_postmeta does not need repairing
Table: wp_posts does not need repairing
Table: wp_seoqueries_data does not need repairing
Table: wp_seoqueries_terms does not need repairing
Table: wp_seoqueries_terms_stats does not need repairing
Table: wp_term_relationships does not need repairing
Table: wp_term_taxonomy does not need repairing
Table: wp_terms does not need repairing
Table: wp_usermeta does not need repairing
Table: wp_users does not need repairing
Table: wp_wbz404_logs does not need repairing
Table: wp_wbz404_redirects does not need repairing
Table: wp_wpo_campaign does not need repairing
Table: wp_wpo_campaign_category does not need repairing
Table: wp_wpo_campaign_feed does not need repairing
Table: wp_wpo_campaign_post does not need repairing
Table: wp_wpo_campaign_word does not need repairing
Table: wp_wpo_log does not need repairing
Table: wp_wpr_autoresponder_messages does not need repairing
Table: wp_wpr_autoresponders does not need repairing
Table: wp_wpr_blog_series does not need repairing
Table: wp_wpr_blog_subscription does not need repairing
Table: wp_wpr_custom_fields does not need repairing
Table: wp_wpr_custom_fields_values does not need repairing
Table: wp_wpr_delivery_record does not need repairing
Table: wp_wpr_followup_subscriptions does not need repairing
Table: wp_wpr_newsletter_mailouts does not need repairing
Table: wp_wpr_newsletters does not need repairing
Table: wp_wpr_queue does not need repairing
Table: wp_wpr_subscriber_transfer does not need repairing
Table: wp_wpr_subscribers does not need repairing
Table: wp_wpr_subscription_form does not need repairing
Table: wp_yarpp_keyword_cache does not need repairing
Table: wp_yarpp_related_cache does not need repairing
No repairing of tables was required
Completed check for corrupt tables and indexes
The system is currently configured to accept a maximum of 25 database connections
At the time of reporting the database was running 1 query
The current database load is 4%
The database load is okay
The system is not set up to OPTIMIZE the tables or the server load of 0.08 was below the threshold for an OPTIMIZE of 15.
The system report concludes that the site is having problems and requires some immediate attention.
- The topic ‘Blank screen due to memory allocation failure’ is closed to new replies.