Support » Plugin: UpdraftPlus WordPress Backup Plugin » Updraft Plus appears to be causing PHP Fatal error: Out of memory (allocated 26

  • Resolved paulzee


    Hi David,

    Your plugin has been great to use up to this point, so thanks first for you hard work: much appreciated.

    I’ve read several of the recent support tickets and I believe the memory issues that we are all experiencing are very likely related to Updraft Plus. Update: I’m on Version 1.7.18 of UpdraftPlus

    I can’t confirm exactly when I upgraded the UpdraftPlus plugin on my site, but it occurred sometime earlier this week, around the same time that I upgraded to WP v3.6.1.

    When I look at my site resource usage since then, I appear to see a massive spike in memory use around the time that Updraft plus kicks in for its nightly backup, however this memory allocation is never released. The following day the pattern repeats again, and the memory use doubles again.

    In my case, I am currently running at a constant 962,936KB of an available 1,048,576 KB. And additional use of the site periodically tips that over the allocation limit, killing site access with out-of-memory errors.

    Note that prior to the WP v3.6.1/ UpdraftPlus updates, my constant memory use ran extremely low: average was close to zero, and peaks comfortably under 256MB. The first backup took this to a constant average of over 512MB; the second to over 768MB, meaning that any reasonable use of the site now causes memory errors.

    I’ve finally managed to get back into WP Admin between out-of-memory occurrences, and have disabled UpdraftPlus, however the memory hasn’t been released as I believe it’s locked up in the cron jobs that apfotos reported here:

    David, I believe that – all things being equal – it is very likely UpdraftPlus causing the problem, possibly in combination with WordPress v3.6.1. I strongly recommend/ advise investigating this.

    Sincere Regards,

    Paul Zee

Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Author David Anderson


    Hi Paul,

    If you look at the top of a UD log file, then UD requests PHP to tell it information about memory usage there – so, take a look at that.

    > I am currently running at a constant 962,936KB of an available 1,048,576 KB

    Note that the support forum thread you link to was from a guy who had a maximum of 64Mb of memory available to PHP. I back up some sites on installs with a maximum of 32Mb available to PHP.

    You can test memory usage with various plugins that will print out memory usage in the footer of your admin dashboard… you can disable UD and see the difference it makes.

    Also, try updating to the development version: – that has some tricks to prevent WordPress from kicking off multiple backup jobs on a loaded server (unfortunately, on loaded servers, WP’s scheduled task system is prone to kick off jobs multiple times). See if that makes a difference.


    Plugin Author David Anderson


    > however this memory allocation is never released

    Since UD is a WordPress plugin that runs only for up to a few minutes, it’s not possible for it to ‘never release’ memory (since once it’s not running, by definition it’s using zero memory)… what you’re seeing there is likely to be Apache/mod_php’s way of handling memory. Are you on a VPS running Apache? You should check out your various settings for Apache’s process handling, to get it to terminate children and thus hand back their resources more aggressively.

    Thanks for the feedback David.

    Here’s what I did.

    I had the hosting company restart the httpd server, and the memory was instantly released, and returned to its normal flat profile (pretty much zero regular use with intermittent spikes).

    I noticed that you’d released another update, so I upgraded to UD 1.7.20 and re-enabled the plugin. As I’d have expected, no problem at all with memory at that point.

    Unfortunately, when I ran a UD backup manually at 3am this morning my time, the memory use by the end of that process had jumped by ~500MB constant use. To compound that problem, I unfortunately forgot to check the next backup time, so UD backup ran again at 5:30am, again leaving memory in use increased by another ~500MB used. Memory is now at a constant average of ~950MB.

    Here’s a graph showing resource usage over the last few days:

    You can clearly see the spikes in Virtual Memory occurring in the early morning hours, when the UD run is really the only activity on the site. You can also see this correlating to VM faults.

    David, it’s important to restate that this system-resource profile wasn’t present with UD prior to the past couple of updates, so regardless of whether technically your code is or isn’t at fault, it is – as clearly as I can reproduce – the trigger that causes the problem to occur.

    The difficulty with you suggesting that server parameters need to be tuned is that in shared, managed environments, we aren’t often in direct control of these parameters. For example, I’m not apparently able to restart my services/ processes myself, so I now have to wait until a helpdesk staff member responds to my call in regular hours.

    The hosting provider isn’t happy that my site is impacting the shared virtual environment, with numerous other sites and customers. These guys are a well-respected local provider with top-class service. And I think they find it strange that this one WP plugin out of however many hundreds are on their platform is the catalyst for such a big impact.

    Changing default Apache install settings across an extensive infrastructure for one customer isn’t something they’ll do lightly. I suspect that for now they will ban UD from use until this problem is proven to be resolved, but more importantly, I’m in a critical time where I can’t afford the site to be at risk.

    I’d love to give you more diagnosis help, but not sure that I can afford the time or risk. I’m disappointed that I’ll need to disable UD for now. UD is a great basic design and I like it a lot. Keep us posted: I hope you get a workable solution sorted soon.

    PS – David, I should have the last log available still, so if that would help you at all, let me know and I can send that to you.

    Plugin Author David Anderson


    Hi Paul,

    That’s the classic profile of a memory leak – PHP has automatic garbage collection (i.e. the language engine, not the code, is responsible for dealing with memory management), so that indicates a fault in mod_php in the Apache install.

    Challenge your web hosting provider with a simple test: write a PHP program, *any* PHP program, by deliberate design, which causes the above behaviour (i.e. memory which remains allocated, *even after the program terminates*). It can’t be done; it’s not conceptually possible, *unless you manage to trigger a defect in the installed version of the PHP engine*. When they find that defect (which, of course, can only be done by testing the defective environment – you can’t find it by testing non-defective environments), there’s then only one solution; to fix the defective environment. Your web hosting company must be having a really bad day (we all have them!) – I find it hard to understand that they can’t recognise the profile of a memory leak when it’s quite so obvious as in those graphs.

    > And I think they find it strange that this one WP plugin out of however many hundreds are on their platform is the catalyst for such a big impact.

    A strong suspect for the memory leak would be in PHP’s zip module (ZipArchive/, since UD makes heavy use of that in creating the backups (i.e. churns a lot of memory), which other plugins are unlikely to be doing. Based on that, you could also apply a band-aid for your site, by forcing use of a different zip engine: put this in your wp-config.php:


    Personally, though, if the hosting company doesn’t want to find/fix the leak, the I’d think about moving my site – because it’s just a matter of time before another site on the shared server runs code that hits it too, and brings your site down with it.

    Best wishes,

    That’s helpful feedback David – thanks.

    I believe the php install in this environment has been stable for a while, but I’ll double check. Given that this memory leak has been identified based on changes in the last couple of UD updates, can you think of any additional insights around specific changes you have made that might have caused this to be found? Would looking at my UD log tell you anything? Might be useful info when submitting a bug report on Apache/ php.

    The hosting provider aren’t bluffing about anything. They’re managing a business that provides a shared environment, and quite reasonably/ appropriately concerned that one site in that environment is exhibiting behaviours that are having an impact on that sites stability (generating errors and support calls) and the environment in general.

    But these are very reasonable folks: so if they have time/ bandwidth to investigate this, I’m sure they’d be open to helping. I’ll also look at making the change you suggest to the ZIP engine. However, I can’t afford to spend too much more time on this, and can’t afford to risk more memory faults occurring.

    Note that – based on my fallible arms-length assessment – this does not appear to be a problem specific to my hosting providers environment. The support logs for UD over the past number of days indicate this is a common problem that others are also experiencing.

    So yes, it seems most likely as you suspect that Apache/ PHP or some other combination of underlying base environment fault is the root cause. But perhaps – given the significant impact this has, and appears to be having for a number of folks – you might consider rolling back the recent change you have made to UD that is triggering this until such time as a Apache/ PHP fix can be found? Alternatively, perhaps you could find something in my log file that might indicate a potential trigger condition? Or perhaps – if you have some time – you could find a way in parallel to replicate the problem?

    I’ll keep you posted on any developments.

    Thanks again David, hope we can get this sorted!

    Plugin Author David Anderson


    > The support logs for UD over the past number of days indicate this is a common problem that others are also experiencing.

    No, that is not so… you are the only person with whom we have had an issue like this reported.

    I worked with apfotos, from the link that you gave; she had a completely different problem (an overloaded server was resulting in WP kicking off the backup multiple times – but there was no issue of memory being leaked by Apache when those backups finished. We released a fix for that scenario in UpdraftPlus 1.7.20).

    Where you see this one (‘Fatal error: Allowed memory size of …’) – – that’s a fatal error thrown by PHP as part of its tracking of internally allocated *per-script* memory – i.e. the memory it requests on behalf of the script and hands back; whereas you’re having an external problem with *operating system* memory (memory is handed back to Apache, but never released by Apache). (And note that in any case, a WordPress forum mod posted on that thread saying “This is usually a hosting issue – not a plugin specific one”; which is what I’m saying to you about your issue!).

    Those are the only *two* support threads opened since UpdraftPlus 1.7.18 was released that mention memory (and note zero in our paid support forum: It’s not accurate to say that this is not a “common problem” – on the data so far, it’s a unique problem! Because the word ‘memory’ crops up in those two, they may look potentially related to inexpert eyes – but trust me (or find a systems programmer!), they’re not related – yours is a classic memory leak issue in your webserver.


    Thanks David,

    My reading of apfotos problem, plus these two:

    is that these are similar issues to what I have been experiencing (a massive increase in memory use) and that the latest UD update has triggered multiple issues with memory management: as you suggest, these are probably underlying base environment faults.

    It appears that in most cases, more memory/ resource is being requested than had otherwise been configured for. In my case, I happen to have a good default limit, so the visible symptoms are more dramatic.

    Of course, as you suggest, these may all be unrelated incidents with completely unrelated root causes.

    Hi guys,

    I’m having a very similar problem as David. I’m managing the server for my client, who installed this plugin, but I’m going to have it removed because its processes don’t stop running until I kill them manually. Here are the two error messages for your information:

    lfd on Excessive resource usage: user(32282 (Parent PID:32272))
    Time:         Thu Nov  7 19:08:53 2013 -0500
    Account:      user
    Resource:     Process Time
    Exceeded:     16260 > 1800 (seconds)
    Executable:   /usr/bin/zip
    Command Line: /usr/bin/zip -v -@ /home/user/public_html/wp-content/updraft/
    PID:          32282 (Parent PID:32272)
    Killed:       No
    lfd on Excessive resource usage: user (32436 (Parent PID:17729))
    Time:         Thu Nov  7 19:08:53 2013 -0500
    Account:      user
    Resource:     Process Time
    Exceeded:     19861 > 1800 (seconds)
    Executable:   /usr/bin/php
    Command Line: /usr/bin/php /home/user/public_html/wp-cron.php
    PID:          32436 (Parent PID:17729)
    Killed:       No

    It apparently has a bug.

    Plugin Author David Anderson


    Hi intelligentDesign,

    Please update to the development version, and I think you’ll find your issue is gone:

    As per the forum guidelines, do please post issues in your own thread:

    Best wishes,

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Updraft Plus appears to be causing PHP Fatal error: Out of memory (allocated 26’ is closed to new replies.