WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 4 days ago

#29341 new enhancement

Raise default value for WP_MEMORY_LIMIT in wp-includes/default-constants.php

Reported by: DavidAnderson Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.0
Component: Bootstrap/Load Keywords: has-patch dev-feedback
Focuses: Cc:
PR Number:

Description

wp-includes/default-constants.php currently has a default value for WP_MEMORY_LIMIT of 40Mb (or 64Mb for multisite).

The effect of this constant is that if the current value of ini_get( 'memory_limit' ) is less, then ini_set() is used to raise it to at least WP_MEMORY_LIMIT.

This default is fine, if your site has few plugins. When the constant was brought in (looks like 3.0, from the comment in the code), sites tended to have fewer plugins, and need less memory.

It is not clear exactly what the rationale behind the default choice for WP_MEMORY_LIMIT is, and what data it is based upon. Nevertheless, I get to read a lot of log files through support for one of my plugins, and it is not uncommon for me to see sites where PHP memory use has exceeded 40Mb. It is not uncommon for me to have to advise someone on how to raise their PHP memory limit, because they are trying to clone their site into something like MAMP, which apparently has a lower limit than this (can't verify: I have no Mac), and the WP default is too low to then load their site successfully.

Based on my (admittedly anecdotal) experiences, I would recommend 64Mb or 80Mb as a much more suitable default in 2014 (and a corresponding increase for multisite), if the aim is for users to not be surprised by a lack of memory. I don't think that hosting companies will have a problem with this. I have extensive data on default settings of the PHP memory limit, and 99.8% of web hosting companies in that data have 64Mb or more. 99.5% have 96Mb or more.

Attachments (1)

29341.diff (436 bytes) - added by voldemortensen 5 years ago.
Patch raising limit to 80M on Multisite and 64M single site.

Download all attachments as: .zip

Change History (16)

#1 @DavidAnderson
5 years ago

  • Summary changed from Rause default value for WP_MEMORY_LIMIT in wp-includes/default-constants.php to Raise default value for WP_MEMORY_LIMIT in wp-includes/default-constants.php

#2 @ocean90
5 years ago

We raised it from 32MB to 40MB in 3.5, see #21646.

#3 @DavidAnderson
5 years ago

A lot of the discussion in #21646 - is relevant. The limit was apparently 32Mb in 3.0 (June 2010), and 40Mb in 3.5 (December 2012). An increase of 8Mb in over 4 years surely isn't keeping pace with real-world WP plugin usage. I came back to comment on this ticket because I just received another support request caused by this, this morning - "Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 98304 bytes) in D:\Hosting\4662999\html\wp\wp-admin\includes\post.php on line 281)".

I just Googled the exact phrase "Fatal error: Allowed memory size of 41943040 bytes exhausted" - 46,100 results. And presumably that's the tip of the iceberg (since presumably most people made do with one of those results instead of adding a new one!).

The default memory_limit setting in PHP 5.4 is 128Mb, according to #21646. I think WP is being hyper-conservative by edging the setting up to 40Mb if it finds something lower. Anything less than 128Mb is very conservative, based on the PHP defaults. But 40Mb in 2014 is approaching useless.

Last edited 5 years ago by DavidAnderson (previous) (diff)

@voldemortensen
5 years ago

Patch raising limit to 80M on Multisite and 64M single site.

#4 @voldemortensen
5 years ago

  • Keywords has-patch added

#5 follow-up: @nacin
5 years ago

"I have extensive data on default settings of the PHP memory limit, and 99.8% of web hosting companies in that data have 64Mb or more. 99.5% have 96Mb or more. "

We don't lower the memory limit that is already set, so whoever is seeing this problem is on a web host that is <= 40 MB by default.

#6 in reply to: ↑ 5 @DavidAnderson
5 years ago

Replying to nacin:

We don't lower the memory limit that is already set, so whoever is seeing this problem is on a web host that is <= 40 MB by default.

Yes, I was aware... the reason for my stats was to indicate what hosts appear to think of as reasonable defaults these days. i.e. If we raise the "absolute minimum" from 40Mb, then we're not going to see web hosting companies complaining that we've gone too high, except for web hosting companies who are crazy + trying to shave their margins far beyond all reasonable limits.

I've not got data on why people still hit this 40Mb limit. From some support requests, I've got the impression that some people are DIY hobbyists and running a version of MAMP or WAMP that has an issue somewhere. But it could be that they've been copying php.ini settings suggested in web pages they Googled and came across and didn't realise that they were way out of date.

#7 @nacin
5 years ago

I don't want to take a guess here on what memory limit we actually need, so let's get some numbers. For us to change this, I'd prefer to see the following tests run. All tests should be performed on 4.0 stable.

  • Some basic memory_get_peak_usage() numbers for single and multisite, dashboard and admin (so, 4 numbers), on a few different shared hosts (say, GoDaddy, BlueHost, Dreamhost, and any others someone has access to). (For these tests only, also repeat them on the Russian version of 4.0: http://ru.wordpress.org/wordpress-4.0-ru_RU.zip or using the language chooser.)
  • English, single site: Peak usage numbers when crunching the image on #22869 (it's huge, just 4.9MB but 12600 x 9450 pixels) when specifically forcing GD. add_filter( 'wp_image_editors', function() { return array( 'WP_Image_Editor_GD' ); });
  • English, single site: Peak usage numbers when doing a core update that specifically avoids using a partial build. For consistency, how about an update from 3.9.2 to 4.0.
  • The default memory_limit values of said hosts and the version of PHP tested.
Last edited 5 years ago by nacin (previous) (diff)

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


5 years ago

#9 @nacin
5 years ago

I'm working on a more complete test. Also, the sunset photo from #22869 isn't a good candidate as it blows GD up.

Last edited 5 years ago by nacin (previous) (diff)

#10 @nacin
5 years ago

I think this photo is good for testing, and I came up with this for logging purposes:

<?php
add_filter( 'wp_image_editors', function() { return array('WP_Image_Editor_GD'); });
function log_mem( $preamble = 'visit' ) {
        $log = array( $preamble );
    $log[] = is_admin() ? 'admin' : 'front';
    $log[] = is_multisite() ? 'single' : 'multi';
    $log[] = get_locale() . "\t";
    $log[] = $mem = memory_get_peak_usage();
    $log[] = size_format( $mem );
    $log[] = ini_get( 'memory_limit' );
    $log[] = phpversion();
    error_log( implode( "\t", $log ) );
}
add_action( 'wp_footer', 'log_mem', 10000, 0 );
add_action( 'admin_footer', 'log_mem', 10000, 0 );
add_action( 'load-async-upload.php', function() {
        add_action( 'shutdown', function() {
                log_mem( 'upload' );
        });
});
add_action( 'load-update-core.php', function() {
        if ( 'POST' !== $_SERVER['REQUEST_METHOD'] ) {
                return;
        }
        add_action( 'shutdown', function() {
                log_mem( 'upgrade' );
        });
});

#11 @chriscct7
4 years ago

  • Keywords dev-feedback added

This ticket was mentioned in Slack in #hosting-community by aaroncampbell. View the logs.


3 years ago

This ticket was mentioned in Slack in #hosting-community by boogah. View the logs.


3 years ago

This ticket was mentioned in Slack in #hosting-community by tomsommer. View the logs.


5 days ago

#15 @tomsommer
4 days ago

Due to larger and more complex plugins, there are now a great number of online articles that instruct users how to set WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT to big values. This should not be a thing users have to deal with.

The better option in 2019 would be leave memory-management up to the Sysadmin, PHP and the memory_limit setting from php.ini.
Currently there is no way for a server/sysadmin to impact WP_MEMORY_LIMIT above 40M and that should not be the case - WordPress-core itself does not know best what memory_limit to use.

I propose always setting WP_MEMORY_LIMIT to $current_limit by default, unless WP_MEMORY_LIMIT is already defined.

Last edited 4 days ago by tomsommer (previous) (diff)
Note: See TracTickets for help on using tickets.