Large blogs fatal error in cache.php: extreme memory consumption on object reference removal

[astereo]

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.

[tacker]

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

[torbens]

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

[foolswisdom]

Setting milestone as future until the issue is further understood.

[torbens]

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?

[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?

[torbens]

I would rather see this one in for 2.3 since it is rather critical and knocks out the entire blog.

[markjaquith]

I'd love a better solution to this... any suggestions?

[Mrasnika]

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 ?

[Mrasnika]

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.

[DD32]

see #3141 which increases the Memory limit to 32M for trunk(2.4/2.5)

[ryan]

cache.php no longer serializes and unserializes.