Re: [squid-users] performance deterioration.

From: Squid Support (Henrik Nordstrom) <[email protected]>
Date: Tue, 9 Apr 2002 04:40:32 +0200

cachemgr provides a quite detailed view on what the memory is (or is
not) being used for.

Start by reading the "General Runtime Information" page. If the
memory utilization there reports that there is a lot of "Free" memory
and yet Squid is growing in size then you need switch to another
malloc. The dlmalloc package (shipped with Squid. --enable-dlmalloc
option) usually works well, and Solaris malloc packages is known for
not working too well... but there is worse ones)

If the general runtime information shows a view resembling the ps
output with only a small amount of "Free memory", then go to the
"Memory Utilization" page and see if you can figure out what is tying
up all that memory.

Regards
Henrik

On Tuesday 09 April 2002 03:53, orko wrote:
> Hey
>
> Just a quick query. It seems that squid (slowly) consumes more and
> more swap, to the point where it needs to be restarted to get the
> memory back. I'm not sure exactly what the time frame of this is,
> but roughly a fortnight or less. At the moment, which is approx.
> 10hrs after a restart, it looks like:
>
> PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
> 250 squid 100 30 0 652M 648M cpu/0 285:26 38.51%
> squid
>
> which seems OK, but before the restart, it looked like:
>
> PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
> 18615 squid 100 60 0 2453M 1174M sleep 162.4H 20.00% squid
>
> The machine is an Ultra 250 running squid2.4s4 under Solaris 8.
> 2GB memory, A1000 disk array.
> cache_mem is 60MB, and has 6 cache_dir's configured as:
> cache_dir aufs /cache/00 10000 16 256
> It's currently handling ~50 client req/s.
>
> (need more info?)
>
> could it just be the spool is too large for the available ram?
>
> gracias

-- 
MARA Systems AB, Giving you basic free Squid support
Your source of advanced web reverse proxying solutions
http://www.marasystems.com/producs/
Received on Mon Apr 08 2002 - 20:43:19 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:07:29 MST