• Resolved Gμ?rD???

    (@guardian74)


    I took a look at @jame’s pinned post and saw a reference to “sql” issues at the bottom and they were helpful overall but it still didn’t address my particular issue so I wanted to find out what is going on and how I can resolve it.

    First off, the error:

    Fatal error: Out of memory (allocated 134062080) (tried to allocate 274432 bytes) in /wp-includes/wp-db.php on line 1811

    Second a look at that line:

    $this->result = mysqli_query( $this->dbh, $query );

    This led to me believe it has something to do with the rest of the mysqli issues that @james referred to but I am not sure exactly how this is applying to me given the error is about memory allocation.

    The general thinking would be its not getting enough memory, but here is the problem, I have 2 GB dedicated RAM on this installation, there is NOTHING in the world that can overflow that limit in MY setup. Secondly, the amount of memory showing as allocated and what little its failing on, makes no sense to me. Especially that simply F5 or reloading the page moves on.

    The issue occurs on the backend, on the front end, and especially on post editing/publishing. Before I read about the removal of the “hiding” suggesting that the problems were there before just not visible, ok, I can get behind that because I tested (before reading that) by cloning the site, db and all and simply rolling back the version to one before 4.5.3 because that’s when it started happening. But since its completely killing the render, my guess is its more than just a hiding issue, thoughts?

    So anyone know what’s going on here? My site is up to date, my plugins, themes and everything are up to date, my db is pruned, regularly and optimized, so its not that. The server is fast, so is the MySQL db server. No other app connects to that DB. I am at my wits end, as I can’t narrow it down to what the problem is, any assist would be greatly appreciated, especially if someone has gone down the path outlined by @james and has discovered a solution.

    TIA.

Viewing 15 replies - 1 through 15 (of 21 total)
  • Moderator James Huff

    (@macmanx)

    Just because the server has 2 GB of RAM, doesn’t necessarily mean that enough has been allocated to PHP.

    If you’re seeing this error either suddenly (no specific task was done to cause the error) or frequently, try deactivating all plugins to rule-out a plugin-specific issue and try switching themes to rule-out a theme-specific issue.

    Otherwise, here are three ways to increase PHP’s memory allocation:

    1. If you can edit or override the system php.ini file, increase the memory limit. For example, memory_limit = 128M

    2. If you cannot edit or override the system php.ini file, add php_value memory_limit 128M to your .htaccess file.

    3. If neither of these work, it’s time to ask your hosting provider to temporarily increase PHP’s memory allocation on your account. Keep in mind that most decent hosting providers allocate 64 MB to PHP under each account, and most decent hosting providers allow users to temporarily increase the memory allocation. If your hosting provider won’t accommodate you, perhaps it’s time to find a new hosting provider.

    (in the above examples, the limit is set to 128MB)

    Thread Starter Gμ?rD???

    (@guardian74)

    @james, thank you, yes I am aware of that, I should have been clear that the 2 GB dedicated is on the server that runs it and its isolated, meaning nothing else is running. The PHP memory is actually at 256 MB, which is more than you suggested, so not sure why that’s not enough.

    The PHP Details

    PHP Version : 7.0.9
    PHP Memory Usage: 39.47 MB
    PHP Memory Limit : 256M
    PHP Max Upload Size : 64M
    PHP Max Post Size : 64M
    PHP Allow URL fopen : On
    PHP Allow URL Include : Off
    PHP Display Errors : On
    PHP Max Script Execution Time : 50000 Seconds

    So given that the memory is not an issue, I guess time to check each of the plugins one by one then, but given that it doesn’t happen predicatively, I have to run with a very badly sparse and disabled system until I can be sure that the plugin is fine and enabling the next one, that is going to be majorly disruptive. Its a very inefficient way to debug this problem that only began showing up after the last update, wish there was a better way.

    Moderator James Huff

    (@macmanx)

    Yes, I’d say it’s time to rule-out the plugins.

    Just for fun though, since nothing else needs major needs all 2 GB, any luck if you bump it up to 512M?

    Thread Starter Gμ?rD???

    (@guardian74)

    SIGH ?? not looking forward to that AT ALL.
    DEEP BREATH, will start on it tomorrow ??

    Yeah the FTP and SSH weight is minimal, as is the MySQL server, so yeah I don’t see why we can’t allocate more to PHP.

    You think I should do a “passive” if you will method of increasing it using the php.ini and see if it fixes it first or the .htaccess method, whichever, or should I just make the change at the top and just make it global?

    Just wondering thoughts on that.

    Moderator James Huff

    (@macmanx)

    Yeah, just go full out for 512M first to see if that fixes it, might as well make use of that 2 GB lying around.

    You might even be able to get away with 1024M, but you could be getting close to using what all of the not-WordPress things require.

    Thread Starter Gμ?rD???

    (@guardian74)

    Sounds like a plan, thanks for the suggestion.

    Step one, let’s go with 512 and see. So far since the change, it has happened only once when I loaded Adminer, which is odd, this plugin beyond some 500 errors in the past has been always pretty behaved, so I know its not the fault of it, but still happened.

    So far hasn’t happened on loading the site, which I suspect is due to me being logged into the site and its loading the dashboard atop the page, because on non-logged in browsers or sessions, it doesn’t occur on simply rendering, so that tells me whatever it is, probably (although that could be inductive reasoning) limited to possibly activity on the backend?

    I’ll watch it through the rest of the week and see how it behaves.

    Moderator James Huff

    (@macmanx)

    Maybe keep an eye on everything else’s resources too. If WordPress is the majority of what’s on the server, you may even be able to get away with 768M or even 1024M.

    (I’m kind of a fan of not letting any resources go to waste, you never know what problems you might avoid down the line.)

    Thread Starter Gμ?rD???

    (@guardian74)

    Agreed, I am not a big fan of wasting resources either. I am in full on watch mode at the moment, will report back findings as soon as I gather enough useful tidbits to share.

    Thread Starter Gμ?rD???

    (@guardian74)

    @james, apologies to everyone for the delay in reporting back, its been hectic (not all related to this issue – personal life issues).

    The last time we spoke, it coincided with a background upgrade operation we had planned to deprecate all MySQL 5.1 databases and move them to 5.5 which was completed and while doesn’t directly affect this install, it does gently brush up against it ?? but luckily confirmed, no issues whatsoever, so that’s nice.

    At the same time, it coincided with the release of version 4.6 which made observing changes a bit more difficult not knowing how the changes introduced will affect the observation. So far the one thing I have noticed is that the site will simply show a blank page, the source is <html></html> that’s it, and reloading continues, which is what used to happen before except with the “out of memory” error displaying in raw PHP.

    And of course, not to go unmentioned, the change we made to the “available” allocated memory to the system. So as you can imagine things have required me to watch with a more discerning eye, and so it has taken longer.

    On a positive sign, although in itself its a horrible situation, but might shed some light here, not sure, but for that you can refer to this topic: Excessive and Unsolicited Backups – iThemes Security which leads to me to believe the culprit might be this extension tying up the entire system, db, and everything exhausting system resources or at the very least mishandling them in such a way that affects everything else.

    I have disabled the extension outright until they resolve it, since nothing it does is special or unique to them and can be accomplished with far more stable extensions, so I have opted to shut it down for now until a resolution is presented and as luck would have it, so far, so good, no more problems since this extension was disabled, so that’s something awful.

    Moderator James Huff

    (@macmanx)

    Hm, excessive backups like that could certainly be using most of the resources, that’s why most decent backup programs either only backup the changes or run full-site backups on traditionally low-traffic hours.

    Was there an improvement overall after deactivating the plugin?

    Thread Starter Gμ?rD???

    (@guardian74)

    +1 on that, agree completely.

    Before all this that brought me to ask about what’s going on, to which you have been privy, my site’s load time was less than a second, the site rendered almost instantly. On its worst day, it was loading at just a tick above 1 second.

    Then suddenly the site would take up to 30 seconds to load, on a good day or lucky moment even 3 seconds, can you imagine that? Half way to a minute for god sake. Or it would just not load, and of course the prevalent issue of the out of memory error, which brings us full circle.

    Now with the plugin disabled, the site is near instant again, although for some bizarre reason, I think the “very slight” lag that I am seeing might actually be due to the increased memory. I know that sounds absolutely insane and seems dumb, but I swear it, anecdotal evidence suggests that its actually a hair trigger slower with more memory allocation. Which strictly from logical standpoint makes absolutely no sense whatsoever. I know that. But my eyes and gut challenge that, could just be reading into it, who knows.

    Moderator James Huff

    (@macmanx)

    I think the “very slight” lag that I am seeing might actually be due to the increased memory. I know that sounds absolutely insane and seems dumb

    It’s not crazy, server memory is a touchy thing. If you’ve increase PHP’s allocated memory, but the site is a bit slower, that usually means that you’re taking just a bit too much memory away from other server processes, so try decreasing PHP’s allocated memory by either 64M or 32M increments.

    Thread Starter Gμ?rD???

    (@guardian74)

    @james, I am so glad that I am not losing my mind, thanks.

    Ok, right now I have it settled on 512 (that was our first increase remember, so I hadn’t gotten to raising it again since I needed to see if it was necessary or not) and the default that my WP installation asks for by default is 256 which I always thought and experienced to be enough until recently. Beginning to think that it might still be ok were this plugin not an issue, what do you think?

    Thread Starter Gμ?rD???

    (@guardian74)

    Holly crap on a cracker, sorry just surprised.

    I decided to just “comment out” the line I had added to give it more memory and let the site kick back to its default of 256 and boy howdy it is zipping like a demon.

    Gonna let it ride like this for a bit and see if any hiccups come or still keeps playing nice.

    Moderator James Huff

    (@macmanx)

    Awesome, that’s great! ??

Viewing 15 replies - 1 through 15 (of 21 total)
  • The topic ‘Fatal error: Out of memory’ is closed to new replies.