# increase the default memory limit in 5.2.0+

- Thread: https://externals.io/message/25369
- Original archive: https://news-web.php.net/php.internals/25369
- Started by Pierre on 2006-08-16T10:30:06+00:00
- Messages: 16
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #25369 — Pierre — 2006-08-16T10:30:06+00:00

URL: https://externals.io/message/25369#25369

Hello,

After having tested 5.2 and the new memory manager for a couple of
weeks, I notice a significant increase of the reported memory usage. As
a side effect, many applications reach the 8M memory limit. It can be
a problem.

A good example is to compare the usage of a pear/pecl command between
5.1 and 5.2.

I would suggest to increase the default 8M to 12M. I discussed this
issue with Dmitry and he agrees on the principle. Any other opinions?
Or is it fine to increase it?

-- Pierre

---

## #25370 — bertrand Gugger — 2006-08-16T11:13:12+00:00

URL: https://externals.io/message/25369#25370 · In reply to: #25369

Bonjour,
Pierre wrote:
> Hello,
> 
> After having tested 5.2 and the new memory manager for a couple of
> weeks, I notice a significant increase of the reported memory usage. As
> a side effect, many applications reach the 8M memory limit. It can be
> a problem.
> 
> A good example is to compare the usage of a pear/pecl command between
> 5.1 and 5.2.
> 
> I would suggest to increase the default 8M to 12M. I discussed this
> issue with Dmitry and he agrees on the principle. Any other opinions?
> Or is it fine to increase it?

I know a few cms they would be pleased with 12M.
That looks quite fair to me.

But , why the hell is this not a configurable limit by build ?
Why do we need to --enable-memory-limit to be able to get a custom value 
but then at run time only ?

In clear, I would like to be able to generate php with a limit given in 
./configure.
This limit may be different from an install to another , depending on 
the applications.

I hope my poor english is understandable.

Regards.

---

## #25371 — Derick Rethans — 2006-08-16T11:14:04+00:00

URL: https://externals.io/message/25369#25371 · In reply to: #25369

> I would suggest to increase the default 8M to 12M. I discussed this
> issue with Dmitry and he agrees on the principle. Any other opinions?
> Or is it fine to increase it?

I actually thought we increased it to 16M already... but apparently not. 

regards,
Derick

---

## #25372 — Antony Dovgal — 2006-08-16T11:14:50+00:00

URL: https://externals.io/message/25369#25372 · In reply to: #25370

> Bonjour,
> Pierre wrote:
> > […]
> 
> I know a few cms they would be pleased with 12M.
> That looks quite fair to me.
> 
> But , why the hell is this not a configurable limit by build ?

JFYI: Its value is configurable in php.ini, configure option just enables or disables the limit itself.

-- 
Wbr, 
Antony Dovgal

---

## #25373 — bertrand Gugger — 2006-08-16T11:29:23+00:00

URL: https://externals.io/message/25369#25373 · In reply to: #25372

Antony Dovgal wrote:
> 
> 
> > […]
> 
> 
> JFYI: Its value is configurable in php.ini, configure option just 
> enables or disables the limit itself.
> 
Exactly my question , why is it configurable *only* at run time ?

I want to generate a php with a custom *fixed* limit , but not enable 
memory limit setting at run time.

Sorry if my english is bad , but please , try to understand my question.

Regards

---

## #25375 — Pierre — 2006-08-16T11:34:38+00:00

URL: https://externals.io/message/25369#25375 · In reply to: #25373

Hello,


> Antony Dovgal wrote:
> > […]
> Exactly my question , why is it configurable *only* at run time ?
>
> I want to generate a php with a custom *fixed* limit , but not enable
> memory limit setting at run time.

It is not at runtime, it is a php.ini definition, which is parsed
before the execution. But this is not the subject of this discussion.

--Pierre

---

## #25376 — Pierre — 2006-08-16T11:36:36+00:00

URL: https://externals.io/message/25369#25376 · In reply to: #25371

Hello,


> 
>
> > […]
>
> I actually thought we increased it to 16M already... but apparently not.

I was trying to find a minimum value to reduce the troubles., but 16M
would be perfect :)

--Pierre

---

## #25374 — Marco — 2006-08-16T11:46:47+00:00

URL: https://externals.io/message/25369#25374 · In reply to: #25369

>
>
> I would suggest to increase the default 8M to 12M. I discussed this
> issue with Dmitry and he agrees on the principle. Any other opinions?
> Or is it fine to increase it?


Could we not increase it to 16MB? Almost every server I have used has
changes the php.ini from 8MB to 16MB anyway.

Regards

Marco

---

## #25378 — Stefan Esser — 2006-08-16T12:39:55+00:00

URL: https://externals.io/message/25369#25378 · In reply to: #25369

Hello,
> After having tested 5.2 and the new memory manager for a couple of
> weeks, I notice a significant increase of the reported memory usage. As
> a side effect, many applications reach the 8M memory limit. It can be
> a problem.
>
> A good example is to compare the usage of a pear/pecl command between
> 5.1 and 5.2.
>   
The question is why do we want a new memory manager that seems to
allocate 1.5 times more memory than the old one.
I haven't looked into it yet, but for me this looks like a waste of
ressources. What are the advantages of it. I really doubt,
that a significant speed increase can be measured, and I wonder if it
worth the waste of memory.

Yours,
Stefan Esser

---

## #25379 — Ilia Alshanetsky — 2006-08-16T13:47:44+00:00

URL: https://externals.io/message/25369#25379 · In reply to: #25369

> Hello,
>
> After having tested 5.2 and the new memory manager for a couple of
> weeks, I notice a significant increase of the reported memory  
> usage. As
> a side effect, many applications reach the 8M memory limit. It can be
> a problem.
>

Is this caused by the increased memory usage during input processing  
caused by the filter extension? I would be very interested in hearing  
what has caused PHP memory utilization to go up, since that will  
likely result in reduced performance as well.

Ilia Alshanetsky

---

## #25380 — Pierre — 2006-08-16T14:06:40+00:00

URL: https://externals.io/message/25369#25380 · In reply to: #25379

Hello,


> 
>
> > […]
>
> Is this caused by the increased memory usage during input processing
> caused by the filter extension? I would be very interested in hearing
> what has caused PHP memory utilization to go up, since that will
> likely result in reduced performance as well.

No, it is not filter extension. As I said, a good example is to use
the pear command (list-all, package or install).

Also I do not think (neither said) that there is a 1.5x increase
factor. I was talking about reported memory usage. My point is that
the new system seems more accurate.

In general, with or without the new memory manager, I do think we
should increase this limit. Many common applications/usages reach it
already.

--Pierre

---

## #25381 — Matt W — 2006-08-16T14:08:44+00:00

URL: https://externals.io/message/25369#25381 · In reply to: #25378

----- Original Message -----
From: "Stefan Esser"
Sent: Wednesday, August 16, 2006


> Hello,
> > […]
> The question is why do we want a new memory manager that seems to
> allocate 1.5 times more memory than the old one.
> I haven't looked into it yet, but for me this looks like a waste of
> ressources. What are the advantages of it. I really doubt,
> that a significant speed increase can be measured, and I wonder if it
> worth the waste of memory.

I found there was about a 10% difference overall (Windows) before/after when
running the Zend/bench.php script -- some parts are ever-so-slightly slower,
but things like string concatenation (erealloc()...) are massively faster.
And I know Andi has said it's supposed to perform better under load and over
time.

About the memory usage amount, I had mentioned the following in a previous
discussion, but I guess I'm wrong, so I don't want to be annoying. :-)  I
found that emalloc()'ing big chunks anyway (many MB+) on Windows (assume
others are the same), *doesn't actually* take "real" memory from the system
(only VM) unless or until it's actually filled with something ("used"),
which makes sense.  So I was wondering why the overhead (where the "higher"
usage comes from) even needed to be counted with the new manager...?  But,
maybe that's only with larger chunks that it's not "really" taken, or it
changes over time with fragmentation or something...

Actually, after typing that, it probably is wrong for the way I think the
Memory Manager handles its small blocks!  (efree()'d space isn't returned?
But dunno when/if the blocks are truely free()'d.)

> Yours,
> Stefan Esser

Matt

---

## #25401 — Peter Brodersen — 2006-08-22T02:56:00+00:00

URL: https://externals.io/message/25369#25401 · In reply to: #25369

On Wed, 16 Aug 2006 12:30:06 +0200, pierre.php@gmail.com (Pierre)
wrote:

>I would suggest to increase the default 8M to 12M. I discussed this
>issue with Dmitry and he agrees on the principle. Any other opinions?
>Or is it fine to increase it?

Just out of curiousity regarding default values and slightly
off-memory_limit-topic:

session.gc_maxlifetime has a default value of 1440 (as of revision 1.2
of php.ini-dist where it was introduced). Obviously some value has to
be the default value, but 1440 seconds seem as a peculiar value. 24
minutes is not a rounded value such as 1 day (86400 secounds) would
be.

I'm only guessing, but is it possible that this default value was
added with the idea that the value was specified in minutes, not
seconds (as 1440 minutes equals 1 day)? The current php.ini-dist
mentions correctly that it equals 24 minutes (per 1.162).


I would like this default value to be globally changed from 1440 to
86400. I think that the 24 minute "timeout" limit would and does
confuse developers and users with spurious "suddently my session
disappeared, but I didn't close my browser" issues.

I believe that it is more easy and nice for a web developer to discard
a session in a system with a high gc_maxlifetime than to keep a
session alive (e.g. having the page access a php resource every couple
of minutes using javascript).

-- 
- Peter Brodersen

---

## #25402 — Robert Cummings — 2006-08-22T03:26:18+00:00

URL: https://externals.io/message/25369#25402 · In reply to: #25401

> On Wed, 16 Aug 2006 12:30:06 +0200, pierre.php@gmail.com (Pierre)
> wrote:
> 
> > […]
> 
> Just out of curiousity regarding default values and slightly
> off-memory_limit-topic:
> 
> session.gc_maxlifetime has a default value of 1440 (as of revision 1.2
> of php.ini-dist where it was introduced). Obviously some value has to
> be the default value, but 1440 seconds seem as a peculiar value. 24
> minutes is not a rounded value such as 1 day (86400 secounds) would
> be.
> 
> I'm only guessing, but is it possible that this default value was
> added with the idea that the value was specified in minutes, not
> seconds (as 1440 minutes equals 1 day)? The current php.ini-dist
> mentions correctly that it equals 24 minutes (per 1.162).
> 
> 
> I would like this default value to be globally changed from 1440 to
> 86400. I think that the 24 minute "timeout" limit would and does
> confuse developers and users with spurious "suddently my session
> disappeared, but I didn't close my browser" issues.
> 
> I believe that it is more easy and nice for a web developer to discard
> a session in a system with a high gc_maxlifetime than to keep a
> session alive (e.g. having the page access a php resource every couple
> of minutes using javascript).

The short duration is to help ensure better privacy. It means that if
you leave a computer and forget to close down the browser then snoopy
people only have 24 minutes to access anything you left behind.

24 minutes is probably some value that lies between irritatingly quick
session expiry and overly long session lifespans -- at least for a
default value.

Cheers,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

---

## #25452 — Peter Brodersen — 2006-08-31T01:21:55+00:00

URL: https://externals.io/message/25369#25452 · In reply to: #25402

Hi,

On Mon, 21 Aug 2006 23:26:18 -0400, in php.internals
robert@interjinn.com (Robert Cummings) wrote:

> > […]
>
>The short duration is to help ensure better privacy. It means that if
>you leave a computer and forget to close down the browser then snoopy
>people only have 24 minutes to access anything you left behind.

That value still seem pretty arbitrary. As mentioned, it would be much
more easy for a developer to discard specific session variables after
a shorter period of time than by extending this period.

Far from all session data is private data and don't have to be nuked
after 24 minutes. The developer could also distinguish between
sensitive- and non-sensitive-data and discard a few session variables
instead of nuking every data in the current session.

The method of extending the timeout is also pretty cumbersome and
pretty much a hack. One would have the pages to perform background
requests as a form of keepalive requests.

>24 minutes is probably some value that lies between irritatingly quick
>session expiry and overly long session lifespans -- at least for a
>default value.

I would disagree. I don't think that the default value of 1440 seconds
was set because of this - I simply think it was meant to be one day in
the first place. I believe that a value of half a day or a day is more
sensible. At least I have experienced a couple of incidents, where I
or some of my users have used more than 24 minutes between pages.

As well as other parts of PHP the application should handle security,
including reasonable timeout values for different tasks. The garbage
collection is a safety valve (as with any other garbage collection).

Summarized:
A higher default gc_maxlifetime would benefit:
+ Fewer strange session expiration incidents (with non-private data)
+ Easier for the administrator to maintain his own timeout value
(above 24 minutes) without resolving to keepalive-hacks
! Security handling should, where possible, be performed by the code.

-- 
- Peter Brodersen

---

## #25453 — Robert Cummings — 2006-08-31T01:27:20+00:00

URL: https://externals.io/message/25369#25453 · In reply to: #25452

> Hi,
> 
> On Mon, 21 Aug 2006 23:26:18 -0400, in php.internals
> robert@interjinn.com (Robert Cummings) wrote:
>
> [-SNIP-]
>
> ! Security handling should, where possible, be performed by the code.

Yes, security should be handled by the code, but erring on the side of
caution is a good practice when setting defaults.

Cheers,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'