Jump to content


information

Serverbuddy Memory Limit Check: Pay Attention To Local Value

serverbuddy php memory limit

This topic has been archived. This means that you cannot reply to this topic.
4 replies to this topic

#1 Guest_OldGrumpy_*

Guest_OldGrumpy_*
  • Guests

Posted 21 April 2012 - 10:19 PM

Hi there,

I only recently learnt about BackupBuddy and was curious about its memory requirements (as with many shared hosters, memory is often the main problem). So I came to install ServerBuddy and noticed one thing it its output that needs some polishing: The display of the php memory limit setting.

I am maintaining a set of WordPress installs at a shared hoster that configures everything quite tightly: While the master value for the php memory limit is set to 256M, the local value is set to 50M. And that is where ServerBuddy isn't as clear as it should be: It only honors the master value (256M), but the actual limit enforced by the local php.ini setting is 50M. I guess it would be a good idea to pay attention to both settings.

Best regards,
OldGrumpy

#2 Ronald

Ronald

    Forum Admin

  • Administrators
  • Others: All Plugins, All Themes, Moderators, Webdesign
  • 30,145 posts

Posted 22 April 2012 - 01:20 PM

Thanks for your post, I will forward this to the dev crew, and if necessary, they will fix this,

Ronald

Join the iThemes Builder Community on Google+.



To ensure that we can process your support request efficiently, ALWAYS include a link to your site, and/or the page your request is related to. Please also read the forum guidelines.



When asking your question/posting your request on the forum, please be as concise and specific as possible. The shorter your request, the more to the point, the more specific, the easier it will be for us to try and help out.


#3 Jeremy Trask

Jeremy Trask

    Moderator

  • Moderators
  • Others: All Plugins, Builder, Members, Toolkit
  • 12,381 posts

Posted 22 April 2012 - 05:00 PM

Hi

I think what you may be seeing here is the effect of WordPress itself "upping" the memory limit value.

The value shown in ServerBuddy is taken from the value provided by the PHP ini_get() function for the configurable parameter memory_limit which represents the _current_ value of the memory_limit configurable parameter at the time the function is called.

If you click on the button below the information panel for calling up the phpinfo() information it will refresh the page with the output of that function call and if you look for the "Core" value section you will see the memory_limit values from the configuration file and from the current value of the parameter - so you will likely see the 50M that you expect and the 256M that WordPress has "upped" the value to "locally". So ServerBuddy is correctly showing what WordPress is reporting as the memory limit that it has set for itself through using the ini_set() function for memory_limit. Of course this is just a limit and doesn't mean that that amount of memory is allocated or will even be used (and in many cases the server may ignore that limit anyway and stick to some predefined limit that it knows about).

Actual setting of the "memory_limit" is controlled by a number of things within WordPress itself and then plugins or themes can override as well.

WordPress itself has a setting for the WP_MEMORY_LIMIT that is defined as follows:

// set memory limits
if ( !defined('WP_MEMORY_LIMIT') ) {
if( is_multisite() ) {
define('WP_MEMORY_LIMIT', '64M');
} else {
define('WP_MEMORY_LIMIT', '32M');
}
}

and this is subsequently used

// set memory limits.
if ( function_exists('memory_get_usage') && ( (int) @ini_get('memory_limit') < abs(intval(WP_MEMORY_LIMIT)) ) )
@ini_set('memory_limit', WP_MEMORY_LIMIT);

so you can see that WordPress says it needs a minimum of 32M for a standalone site and if your memory_limit as set in a php.ini were lower than this then it would try and set memory_limit to be 32M. Of course in your case you mention it is 50M so this particular statement will not change the memory_limit value as it is already > 32M

Now this is the bit that causes the behaviour that you are seeing from WordPress on your site:

if ( ! defined( 'WP_MAX_MEMORY_LIMIT' ) ) {
define( 'WP_MAX_MEMORY_LIMIT', '256M' );
}

so WordPress is saying that if there isn't a definition for WP_MAX_MEMORY_LIMIT already set then it is going to set it to 256M. Then in the admin access bootstrap section you will find the statement:

if ( current_user_can( 'manage_options' ) )
@ini_set( 'memory_limit', apply_filters( 'admin_memory_limit', WP_MAX_MEMORY_LIMIT ) );

where you can see that if the user logging in has sufficient privileges then WordPress will attempt to set the local value of the memory_limit parameter to WP_MAX_MEMORY_LIMIT (which by default is 256M) after running it through a filter which may change the value. If there is no such filter defined (which by default I do not believe there is) then the apply_filter() function will simply return the value (256M in this case) and so memory_limit gets set to 256M. Of course as mentioned before this doesn't mean that memory is being allocated by default or will even be used and the server may override it anyway.

Note that this only applies in access to admin and only for users with the appropriate privilege as shown.

If you want to restrict this to be a lower value then you can put a statement in your wp-config.php such as:

define('WP_MAX_MEMORY_LIMIT', '50M');

and then this value would be used whenever that statement above is executed.

Of course if anything on your site does define an admin_memory_limit filter then that may have an influence as well.

I hope this information can help in enabling you to understand how WordPress manages the memory_limit configurable parameter and how you can adjust your site configuration to better represent the behaviour that you want, thanks.

Regards...jeremy

"Everything will be all right in the end. If it isn't all right yet then it isn't the end."


#4 Guest_OldGrumpy_*

Guest_OldGrumpy_*
  • Guests

Posted 24 April 2012 - 09:57 AM

Hi Jeremy,

thanks for shedding some light on this. Actually, I was talking about the output of the phpinfo() statement. It displays two columns, one labeled "local value" and one labeled "master value". For the memory limit, phpinfo() shows this:
memory_limit 256M 50M

Where the first value is the "local value" and the second one is the "master value". The WordPress plugin "WP Overview (lite)" shows the 50M as the relevant memory limit (and I receive the expected error when WordPress tries to allocate more than those 50M, so it is indeed the relevant limit here). That is why I think it would be great if ServerBuddy doesn't just display the first value because it makes the user think "oh I have 256M, that is plenty" while he actually only has 50M and, later on, potentially problems during memory-intensive tasks due to that. What do you think? Consider less tech-savvy clients, not me ;)

It's not so much about me wanting a certain behaviour for a particular site, it's more about getting reliable (and relevant!) information :) I'm looking forward to read about your opinion on this.

Best regards,
OldGrumpy

#5 Jeremy Trask

Jeremy Trask

    Moderator

  • Moderators
  • Others: All Plugins, Builder, Members, Toolkit
  • 12,381 posts

Posted 24 April 2012 - 12:23 PM

Hi OldGrumpy

Well I suppose it can be argued either way - ServerBuddy is showing the information that PHP gives it which is based on the value that the WordPress application sets, so it is showing the operational environment that the WordPress application has (reportedly) established. Showing the general initialization file value  just shows the generic value that isn't necessarily specific to WordPress. For example, if the general value were 128M but a plugin or theme unilaterally constrained the value lower then you wouldn't be seeing the operational environment for the WordPress application but general value for any PHP application (unless there is a discrimination to show the single lowest value). ServerBuddy allows both to be viewed through the provision of the phpinfo() function call to show additional detail so it covers both bases.

Whether or not PHP might be returning a value that will not be honoured is a different matter and I suppose would be better addressed to the PHP authors. Similarly, if the WordPress application is setting a value that it doesn't verify as being valid then again probably an issue for the WordPress authors. I guess that is why they provide the WP_MAX_MEMORY_LIMIT parameter that can be set and/or the filter that can be defined to manage the memory limit value setting.

I believe that in some server environments the memory limit value that may be set in an initialization file applies to the sum of all simultaneous application usages for the specific hosting account - in that case you wouldn't necessarily be wanting to show the configuration file value but instead a value that is constrained by a setting of WP_MAX_MEMORY_LIMIT or a filter implementation as it might be preferable to constrain the memory that an individual site from a collection of sites could possible try and allocate from the available pie.

So the definition of what may be reliable and/or relevant is really open to discussion and I'm sure there would be different opinions on this ;-) Having multiple sources of information - whether it be from within the same tool (such as ServerBuddy) or using multiple tools (such as a plugin like you mention and other tools) - is of course helpful in this respect.

Regards...jeremy

"Everything will be all right in the end. If it isn't all right yet then it isn't the end."