Opened 17 years ago
Closed 16 years ago
#4045 closed defect (bug) (fixed)
Large blogs fatal error in cache.php: extreme memory consumption on object reference removal
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 2.5 | Priority: | high |
Severity: | critical | Version: | 2.2 |
Component: | General | Keywords: | 5.2 memory_limit |
Focuses: | Cc: |
Description
When using PHP 5.2, large blogs may experience issues such as the following:
Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 3003232 bytes) in /home/dlounge/public_html/wp-includes/cache.php on line 48
This fatal error may show up as in a plugin, but after disabling the faulted plugin, it defaults to cache.php. Even disabling the cache in wp-config.php, the error continues. This cropped up with the upgrade to PHP 5.2.
Change History (12)
#1
@
17 years ago
- Component changed from Administration to General
- Keywords memory_limit added; php php erros fatal removed
- Milestone 2.2 deleted
- Priority changed from high to normal
- Resolution set to worksforme
- Status changed from new to closed
#2
follow-up:
↓ 10
@
16 years ago
- Cc torbens added
- Milestone set to 2.2.2
- Resolution worksforme deleted
- Severity changed from normal to critical
- Status changed from closed to reopened
- Version changed from 2.1.2 to 2.2
I'm not sure if this is related to a low memory quota for PHP only. My hoster allows for 32M and I'm experiencing the same problem.
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 316105 bytes) in wp-includes/cache.php on line 48
I wasn't even able to get the blog running again so far. As mentioned above, disabling the cache in wp-config.php doesn't have an effect at all:
define('ENABLE_CACHE', false);
Please also see the thread at: http://wordpress.org/support/topic/87413
#3
@
16 years ago
- Milestone changed from 2.2.2 to 2.4 (future)
Setting milestone as future until the issue is further understood.
#4
@
16 years ago
By simply commenting out the vicious line 48 of cache.php, I got my blog working again:
$data = unserialize(serialize($data));
This line does look pretty weird to me anyway. Anybody an idea what it's supposed to do except for a lot of allocs?
#5
follow-up:
↓ 9
@
16 years ago
The unserialize/serialize was introduced by [4856] and [4857] to fix #3726. The purpose is to remove references inside objects. I can see why it's being done, however this method does eat a ton of memory for large objects.
Perhaps these calls need to be moved closer to the actual problem area and out of the general cache functions entirely?
#6
@
16 years ago
- Milestone changed from 2.4 (future) to 2.3 (trunk)
- Priority changed from normal to high
- Summary changed from PHP 5.2 / Large Blogs Error to Large blogs fatal error in cache.php: extreme memory consumption on object reference removal
I would rather see this one in for 2.3 since it is rather critical and knocks out the entire blog.
#9
in reply to:
↑ 5
@
16 years ago
Replying to Otto42:
The unserialize/serialize was introduced by [4856] and [4857] to fix #3726. The purpose is to remove references inside objects. I can see why it's being done, however this method does eat a ton of memory for large objects.
Perhaps these calls need to be moved closer to the actual problem area and out of the general cache functions entirely?
Exactly, this is how I solved it for my blog. Indeed it is the serialize|unserialize routine that eats the memory. I decided the turn off the cache by setting DISABLE_CACHE . However, the wp_cache_set() function is not aware of it! This is the functions that's on line 48, and that's the function that's triggering the fatal error. So, in order to make the function aware that the cache has been disabled, I simply copied the checks to the function, like this (did the same for wp_cache_replace since it also has serialize|unserialize):
function wp_cache_set($key, $data, $flag = '', $expire = 0) { if (defined('DISABLE_CACHE')) return; if ( ! defined('ENABLE_CACHE') ) return; global $wp_object_cache; $data = unserialize(serialize($data)); return $wp_object_cache->set($key, $data, $flag, $expire); }
In this way, whoever has issues with exhausting the memory, he/she can turn the caching off for real, and never execute the serialize|unserialize routine.
What do you think ?
#10
in reply to:
↑ 2
@
16 years ago
Replying to torbens:
I wasn't even able to get the blog running again so far. As mentioned above, disabling the cache in wp-config.php doesn't have an effect at all:
define('ENABLE_CACHE', false);
This is because wp_cache_replace() and wp_cache_set() are not aware that the cache is disabled. See my comment above to see how I fixed it - just by copied the is-the-cache-disabled
check to beginning of those two functions.
This is not a WP error.
You have to increase the memory limit in your php.ini.
memory_limit = 16M ; Maximum amount of memory a script may consume (16MB)
Try 32M