On Tuesday 10 June 2003 12.20, atit_ldce wrote: > This is the frequest memory leak I am sending u log file telling > memory leak info generated via XMALLOC_xxx options in squid. This > is log file after squid has served only 2 requests. > > Actually i am facing vary serious problem of memory leak in squid.
Then try to find the cause of this rather than spending a lot of time on small and often false leaks which are not increasing over time. To find increasing memory leaks monitoring of memory usage while Squid is running is your best friend. Monitor both overall memory usage and memory pool usage. In memory pools, pay attention to the pools with a low high use time. By using the XMALLOC_xxx tools you will have to spend a huge amount of time to find the leak you are looking for and sort if out from all the false reports which are not truely leaks but just initializations which never get freed. This is usually not worth the effort on the majority of the memory leaks as there is much better tools available. memprof is also somewhat useful in this, but lacks a "diff" feature to show changes between two points in time. because of this memprof mainly becomes useful once you have narrowed down a little in which area the leak may be. > Squid is serving about 1200 request/minute on redhat linux box with > kernel 2.4 and memory 1GB RAM Memory utilized by Squid is going to > increase with time. > So we need to restart squid once daily. Then something is seriously wrong somewhere. This is not normal for a Squid. The cbdata "memory leak" you have found is not a serious one. This is memory allocated once per cbdata type on startup and never freed on shutdown. This leak is not very easy to fix without making all memory pool labels dynamically allocated and does not have any impact on Squid functionality what so ever. Regards Henrik
