Make WordPress Core

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: astereo's profile astereo 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 @tacker
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

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

#2 follow-up: @torbens
17 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 @foolswisdom
17 years ago

  • Milestone changed from 2.2.2 to 2.4 (future)

Setting milestone as future until the issue is further understood.

#4 @torbens
17 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: @Otto42
17 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 @torbens
17 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.

#7 @markjaquith
17 years ago

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

#8 @ryan
17 years ago

  • Milestone changed from 2.3 to 2.4 (next)

#9 in reply to: ↑ 5 @Mrasnika
17 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 @Mrasnika
17 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.

#11 @DD32
16 years ago

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

#12 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

cache.php no longer serializes and unserializes.

Note: See TracTickets for help on using tickets.