> Your posts are very hard to follow - perhaps Kmail is a little broken?
> I've re-edited this post accordingly - though it still incorrectly shows
> comment precedence.
> Perhaps you are not simply selecting a response from the list and
> choosing "reply to" as an option??
My sincere apologies for this inconvenience. The problem is, I write
from work and can't subscribe to the list there. My only way is to
read the list in a browser and to try to fake all needed reply info
(in which I'm apparently not good).
>On 04/10/14 23:53, Grigor Kolev wrote:
>>>>>> Hi all, I need to set the PHP memory limit to more than 512
>>>>>> MB and found that I can't. Is this caused by the Suhosin
>>>>>> patch (my guess), and how to get around it?
>------------8<------------>8----------------------
>>>>> Did you try edit /etc/php5/conf.d/suhosin.ini from:-
>>>>> ;suhosin.memory_limit = 0 suhosin.memory_limit = 1G (NOTE the
>>>>> suffix used above) Don't forget to check php.ini and ensure a
>>>>> similar settings for max_post and memory_limit
>>
>>>> No file /etc/php5/conf.d/suhosin.ini exists on a standard Sid
>>>> php5-common
>>
>------------8<------------>8----------------------
>>> /var/lib/dpkg/info/php5-suhosin.md5sums
>>
>>> /var/lib/dpkg/info/php5-suhosin.postinst
>>
>------------8<------------>8----------------------
>>
>>>> <?php ini_set ( 'suhosin.memory_limit', '1G' ); ini_set (
>>>> 'memory_limit', '1G' ); ini_get ( 'memory_limit' ); // returns
>>>> '1G' - so far, so good
>>
>
> Did you restart the webserver after doing this? (any changes won't take
> effect until after restarting the webserver)
>
> e.g. # service apache2 restart
The software is a MediaWiki bot (http://apibot.zavinagi.org), entirely
command-line driven and thus not dependent on the webserver. (I guess
that this is the reason for separating the config paths /etc/php5/apache2
and /etc/php5/cli. In addition, I tried restarting the server, just for
the case - no desired result.)
>>
>>> Unfortunately it will report that even if that amount of memory is
>>> not available.
>>
>>>> file_put_contents ( $about_520M );
>>>>
>>>> // PHP Fatal error: Allowed memory size of 536870912 bytes
>>>> exhausted...
>
> I'm not sure how file_put_contents would be affected by memory_limit
> (and visa versa). max_input_time and max_execution_time might.
>
>
> http://php.net/manual/en/function.file-put-contents.php I haven't examined the PHP interpreter sources yet, but my guess is
that file_put_contents() passes parameters by value, not by reference.
Thus, it creates an additional copy of the parameter in the memory.
Give it a huge file body, and it becomes the point where most memory
is consumed - thus, the place where you will likely see the
'memory exhaused' message.
>>
>>> What do you get from (as the user running the php process):- php
>>> -i | grep memory_limit
>>
>------------8<------------>8----------------------
>>
>>>>>> Debian Sid, amd64, php5-common 5.6.0+dfsg-1+b1. If you need
>>>>>> more info,
>>
>------------8<------------>8---------------------- >
>> 5.6.0+dfsg-1+b1 is the current php-common version for Sid.
>>
>>
>>>
>> I haven't applied any patch to it. What I discuss as a possible
>> problem origin is the Suhosin patch applied by the package
>> maintainers. (Applying a patch of mine would solve the problem, but
>> that would be washed away by the package flow in Sid. Also, it won't
>> solve the problem at potential software users: I need a solution to
>> describe for these.) Squeeze and Wheezy PHP5 experience might not
>> translate directly into Sid one, as the package maintainers have
>> made meanwhile some changes (useful and needed ones, I think). Part
>> of these changes is that /etc/php5/conf.d doesn't exist anymore -
>> there are already separate /etc/php5/apache2/conf.d and
>> /etc/php5/cli/conf.d. (Using a suhosin.ini there doesn't work, as
>> well as posting the suhosin settings in the code or in any php.ini
>> file.)
>
>
> Makes sense.
>
>
>
>> Maybe I need some counsel on what Suhosin patches the package
>> maintainers apply, and is there another way to configure it besides
>> fixing directly the code and recompiling it.
>>
>>
>> From what I have heard, php5-common carries a Suhosin patch that
>> does few things (limiting RAM is one of them), but might not be
>> configurable. The full patch, which is configurable, is said to be
>> in php5-suhosin, but that breaks most other PHP packages, which I
>> can't afford. Is there anyone around who would know something about
>> this?
>
>
> php.net ??
> I included the link to the memory_limit documentation in a previous post.
I guess no. In Debian, all packages are compiled from source and package
maintainers often apply patches that are outside the original source.
If my info about the Suhosin patches in php5-common and php5-suhosin is
correct, that would be the case. Consequently, the folks at php.net
will be unable to be of use.
>> The 'server' is my home PC. 16G RAM, over 12 of them free and
>> available to the process.
>
> Thanks
My pleasure. :-)
>> php -i | grep memory_limit returns "memory_limit => -1 => -1".
>
> Which means you have *no* memory limits set in php.ini
> Try restarting the webserver - if that doesn't fix the problem then the
> limit is being set by an application. .htaccess is the first place I'd
> look, 2nd would be any application's config.php.
>
> So, any limit is being set somewhere in your application, here's some
> examples where that happened with a slightly earlier version of suhosin
> patched php:-
> http://serverfault.com/questions/526987/how-comes-php-throws-a-memory-limit-exhausted-when-memory-limit-is-set-to-1 > http://ubuntuforums.org/showthread.php?t=1634625 > Slightly different:-
> http://stackoverflow.com/questions/26098618/php-not-recognizing-memory-limit-changes I googled and checked these before asking on the list. Unhappily, none helped.
Still, thank you for the time and effort to seek them!
> HTH
>
> Kind regards
Thank you again.
|