Out of Memory Errors: /wp-includes/query.php

[Resellr]

VPS SOFTWARE:

PHP 5.3.x
MySQL 5.1.x
Apache 2.2.x
xCache 1.3.x
Suhosin & SuPHP

VPS SPECIFICATIONS:

3.2GHz Dedicated CPU
2GB Dedicated RAM
CentOS 5.x

xCache is given 48MB of RAM as Dedicated. PHP max. memory has been raised from 32MB to 64MB (we've tested it both ways).

That said, we've commented out the standard Apache Configuration limits on CPU & RAM prior to submitting this ticket (we saw this in a previous ticket, so http.conf has already been modified).

The issue here is that we're experiencing timeouts when trying to save any large amount of Text, PHP or CSS through the WordPress Admin Interface.

If we exceed the size of the box (non-modifed, non-extended), it times out and the following error is logged:

PHP Fatal error: Out of memory (allocated 6291456) (tried to allocate 491520 bytes) in /home/username/public_html/wp-includes/query.php on line 1906

Line 1906 is:

		if ( !empty($q['category__not_in']) ) {
			$cat_string = "'" . implode("', '", $q['category__not_in']) . "'";
			$whichcat .= " AND $wpdb->posts.ID NOT IN ( SELECT tr.object_id FROM $wpdb->term_relationships AS tr INNER JOIN $wpdb->term_taxonomy AS tt ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy = 'category' AND tt.term_id IN ($cat_string) )";
		}

That doesn't really make the most sense to me, seeing as how it relates to categories, not the saving of a file.

[nacin]

6291456 bytes is 6 MB. WordPress hums along, without any plugins or a localization loaded, at anywhere from 12-17 MB, and attempts to assign itself a limit of 32 MB (which arguably should be 48 MB) during startup. Most likely, that action is blocked, and your server isn't configured properly, giving the script much less than it requires.

[dd32]

Suhosin can limit memory as well, check the settings on that.

That being said, Given the script is only allocated 6MB at that point in this, This is a invalid ticket as WordPres ssimply required more memory than that.

[Resellr]

I appreciate the suggestion, however, if it were an issue with SuPHP and the limits imposed, then certainly it would work when switching to FCGI or DSO without SuPHP enabled. It doesn't.

PHP's memory_limit is set to 64MB, which is more than enough even for most shared hosting servers (which this one is not, it's a new VPS for testing). That said, the VPS has 2GB of RAM which should be more than capable of being used when and as needed as nothing on the VPS is even coming close to using any of it.

[Resellr]

I've reconfigured Apache & PHP. The configuration is now set to utilize FCGI & xCache wtih Suhosin by without SuPHP. That said, the same problem persists.

[nacin]

Replying to Resellr:

I've reconfigured Apache & PHP. The configuration is now set to utilize FCGI & xCache wtih Suhosin by without SuPHP. That said, the same problem persists.

The error message reveals that the script is only being allotted 6 MB, or 6291456 bytes. It's not a WordPress problem why the script is only getting 6 MB, it's a server configuration issue.

[Resellr]

Replying to nacin:

Replying to Resellr:

I've reconfigured Apache & PHP. The configuration is now set to utilize FCGI & xCache wtih Suhosin by without SuPHP. That said, the same problem persists.

The error message reveals that the script is only being allotted 6 MB, or 6291456 bytes. It's not a WordPress problem why the script is only getting 6 MB, it's a server configuration issue.

If that is the case, I can't seem to locate where the issue would reside considering the memory of the VPS, the memory_limit set for PHP and the memory allowed by Apache.

I understand the error, it makes perfect sense, what I am not getting is why it persists under such provisions.

[dd32]

Disable Suhosin and try it without it. If the error message makes so much sense, You'll understand why you'll get no help here for reconfiguring the server.

Trac is not for Support issues, Please consult a Apache/PHP support avenue for support related to server configurations. Trac is for reporting bugs in the software, WordPress cannot do anything about your installation/setup having a low memory limit for whatever reason.

I'm closing this as invalid, Please do not re-open the ticket unless you can show that its a WordPress issue and not a server configuration issue. You may continue to reply here without re-opening the ticket however.

[Resellr]

Hello,

I am not asking for help reconfiguring the server, nor would I. I am saying, however, that while the error makes sense, it's not physically possible for the server to be out of RAM.

This is the only website on the server, it receives no traffic at all and I am the only one accessing the website or the WordPress Administrative Panel.

Seeing as how this is an issue relating to the saving of a file being modified within the admin panel of WordPress 3.0, I find it to be a valid request for support. When saving larger files, it simply forces the error. When saving small, non-lengthy data, it has no issue. It appears it has trouble writing larger amounts of data whether to file or to the database.

I can adjust the RAM all day/night long, as I've been doing, yet that doesn't change things. It should function perfectly under such conditions, the point is, it doesn't.

Again, I'm not asking for help configuring the server, I am asking why it seems to have so much trouble writing a file or to the database on a server that is fully and beyond capable of running the software.

[hakre]

WordPress runs out of memory from time to time, especially with database and variable operations. That can even happen in simple setups, but it must not. So as long you are able to reproduce the problem on your end, you're able to fix this problem for yourself.

What's the maximum number of bytes of RAM you can give your blog? Please give your Blog at least 256MB of RAM for the admin. That is the what WordPress is asking for and that _is_ the propper configuration. So for your setup, please raise the PHP Memory Limit from 64M to 256M.

Related: #13847

Please report here if with 256M the problem still is reproduceable.