OK, try this one:
#define TWENTY_GIG (1024*1024*20)
main()
{
   void *x = malloc(TWENTY_GIG);  /* 20 Gig */
   memset(x, 0, TWENTY_GIG-1);
   free(x);
   sleep(100);
}

FYI - Threads are part of the process image.  
Their memory is part of the whole process.  Just because
a thread exits doesn't mean the memory it allocated
goes away.

It clearly sounds to me that the page you run every five minutes
is the cause of your memory leak.  If it is the only thing running,
then you have you culprit.

--
Tom Jordahl
MacroMedia Server Development


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 25, 2001 12:35 PM
To: CF-Linux
Subject: Re: Memory Usage growing.


Hi Tom.


> main()
> {
>    void *x = malloc(1024*1024*20);  /* 20 Gig */
>    free(x);
>    sleep(100);
> }

This programm will not use much memory until you really start using it.

With Linux memory will only really be allocated if you are actually
using it. So you can allocate 1 GB on a 100 MB + 100 MB swap space system.
As long as you don't really use it, it will work !!.

The compiled example above uses 52 KB and frees them if it stops !!
Of course, as long as it runs it doesn't free anything, the programm could
at a later date call malloc once again and then the memory is reused.
(Very effcient!!)


So CF is organized in threads. They start, they hand out data to the
requesting application and they die.
Right ?

They shouldn't have to keep memory until the main process dies.


> 
> If you look at this program, it grows to 20 Gig and stays
> there. 

No it doesn't. See above.

> This is universally true across all *default* Unix 
> malloc implementations.
> 

Can be, but NOT Linux.

> What this means for 4.5.1 users:
> If you run a template, and it uses a large amount of memory,
> or the template calls Verity, or you make a Query which causes
> the DB driver to use memory, this memory is correctly freed
> (i.e. no leak) but the cfserver process will not shrink from
> its high water mark.  What will happen is that the memory
> will get reused for later requests.  Under load however, things
> might not work so well.
> 
> Consider:  Template A causes a 10MB file to be loaded in to
> memory (CFFILE).  It completes and frees the 10MB.  Template
> B now runs and allocates 50K and it still running.  Template A
> runs again, needs 10MB, but the space it used before is not
> available (it has to be contiguous).  So cfserver grows another
> 10MB in order to run Template A.
> 
> To determine if a template is causing CF to grow without bounds,
> start the server fresh, run the template, and check the memory.
> Repeat.  If CF gets bigger each run, you should take a look at
> what is happening in the template and start eliminating things.
> If you get a reproducible test case, its time to call support.
> 
> 
> The GOOD NEWS - CF 5.0 uses SmartHeap from MicroQuill software.
> 
> What this means for 5.0 users:
> SmartHeap is tuned for maximum performance and scalability. 
> It has a feature called 'footprint reduction'.  This means
> that ColdFusion WILL give back large amounts of memory, if
> this memory is not longer being used.
> 
> It also gives CF a HUGE performance boost in load situations.
> Why? Because SmartHeap reduces (or eliminates) the locking
> needed in for multi-threaded memory allocation.
> 
> Be aware that we have tuned the SmartHeap defaults for high load 
> performance, which means the 'reserve' pool of free memory is large
> (10MB).  You will have to exceed these limits in order to see CF
> shrink its memory usage.
> 

Thank you for your detailed answer. We have yet only one CF 5.0 running.

It doesn't grow as fast as 4.5.x does.
It still grows, but not as fast as with 4.5.x.

And it still grows if on a saturday or sunday there's nothing happening
except for our regular check whether there's something to do.

It's quite difficult to pinpoint what's actually the template or file
that causes this situation.
I think it's just the number of requests and simultaneous actions that have
to be done.


Bye
-- 
Christoph Gr�ver, [EMAIL PROTECTED]

Sitepark
Gesellschaft f�r Informationsmanagement mbH
Rothenburg 14-16
D-48143 M�nster

Telefon (0251) 482 65 -50
Telefax (0251) 482 65 -39

http://www.sitepark.de

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-linux%40houseoffusion.com/
To Unsubscribe visit 
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_linux or send a 
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.

Reply via email to