> The reason is that httpd memory usage patterns significantly differ from
> your simple example. E.g., there might be some memory block allocated at
> the end of the heap, which is not freed at the end of the request - and it
> will prevent all the rest of memory from being returned to the system
FS>> And here is the basic difference between 'mall' and 'httpd'
FS>> processes: the last are on the top ALL THE TIME.
The reason is that httpd memory usage patterns significantly differ from
your simple example. E.g., there might be some memory block allocated at
the end of the heap, which is no
The answer is really not so easy.
I have RedHat Linux 6.2 (with standard kernel, I suppose 2.1).
I tried such program in c++:
//File mall.cc
#include
#include
#include
#include
int main() {
void* v[1000];
for (int i=0;i<1000;i++) {
v[i]=malloc(10);
/
SV>> How does Zend allocate memory then? I guess I could try to
SV>> figure it out myself, but it's a bit complex. Are there many
SV>> small chunks? Seems like emalloc() is called a lot creating
SV>> small chunks, but each emalloc() doesn't result in a
SV>> corresponding malloc() perhaps? I guess
On Wed, Jan 10, 2001 at 09:23:43PM +0200, Stanislav Malyshev wrote:
> SS>> Thanks for the correction! I have never seen that in action
> SS>> though. Usually, the C library will keep freed memory in
> SS>> free lists and does not decrease the size of the data
> SS>> segment using
SS>> Thanks for the correction! I have never seen that in action
SS>> though. Usually, the C library will keep freed memory in
SS>> free lists and does not decrease the size of the data
SS>> segment using sbrk.
Actually, from glibc source there's a hook that is supposed to do th
BS>> the number of bytes contained in the Increment parameter and
BS>> changes the amount of available space accordingly. The Increment
BS>> parameter can be a negative number, in which case the amount of
BS>> available space is decreased."
Theoretically, you are right. Practically, you need firs
> >From AIX docco...
> "The sbrk subroutine adds to the break value the number of bytes contained in
> the Increment parameter and changes the amount of available space accordingly.
> The Increment parameter can be a negative number, in which case the amount of
> available space is decreased."
On Wed, Jan 10, 2001 at 02:04:43PM -0500, Bill Stoddard wrote:
>
> Really?
>
> >From AIX docco...
> "The sbrk subroutine adds to the break value the number of bytes contained in
> the Increment parameter and changes the amount of available space accordingly.
> The Increment parameter can be a ne
> > Any ideas ?
>
> Welcome to Unix. You can only increase the heap size using
> sbrk(), you cannot shrink it. So, if you have allocated n
> bytes, you can only reuse those bytes, but never give it back
> to the system (without terminating the process).
>
> - Sascha
>
Really
> Any ideas ?
Welcome to Unix. You can only increase the heap size using
sbrk(), you cannot shrink it. So, if you have allocated n
bytes, you can only reuse those bytes, but never give it back
to the system (without terminating the process).
- Sascha
--
PHP Development M
Hi !
Look at such example:
The apache server configuration:
Timeout 100
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 3
MaxSpareServers 40
StartServers 3
MaxClients 40 <-- This is important !
MaxRequestsPerChild 40 <-- This is important !
Let us assume,
12 matches
Mail list logo
