Re: Problems with memory allocation / renicing unlinkd

From: David Rees <[email protected]>
Date: Wed, 24 May 2000 09:30:00 -0700

On Wed, May 24, 2000 at 11:46:03AM +0200, Patrik Schindler wrote:
> Hello,
>
> we're using squid in a medium-traffic environment. We've got the problem that squid eats all memory after running for a while:
>
> squid 15015 0.5 79.1 544972 409568 ? S May19 44:54 (squid)
> squid 15016 0.0 0.0 1112 84 ? S May19 0:34 (unlinkd)
>
> As mentioned in the config file, squid may eat up to twice of cache_mem. 532MB is nearly *seventeen* times of my set cache_mem (which is set to 32MB).
>
> We're using Version 2.3stable2 on a dual-PIII 550 machine with 512MB RAM and U2W SCSI under Linux-2.2.14, glibc 2.1.2, compiled with egcs-2.91.66. The ChangeLog states nothing about memory allocation changes for 2.3stable3.
>
> The perhaps most memory-relevant lines from squid.conf:
>
> cache_mem 32 MB
> maximum_object_size 40960 KB
> cache_dir ufs /usr/local/squid/cache 512 128 128
>
> I searched the list archive but found only references that memory allocation over time is normal. But *this* much?
>
> Does anybody know if this is a possible memory leak or how I could restrict this behaviour in some way?
>
> Periodically, unlinkd starts to work and eats lots of memory, too. There is *lots* of disk activity then (squid has got a 4GB U2W disk for himself) which slows down the entire system way too much. Is there a way to renice unlinkd in any way so it's a bit friendlier to the rest of the system?
>
> Must we use a dedicated squid machine to get rid of these issues or did I miss something?

How long does it take for squid to start using that much memory? Here are
the steps I would take:

1. Try upgrading to 2.3stable3, there are other bug fixes that you should
be running anyway.

2. Restart squid as often as necessary to keep it under control. Put
this into cron so it runs automatically. It will do so, and you will
forget that squid has this memory issue. :-)

Good luck,

-Dave
Received on Wed May 24 2000 - 10:34:48 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:53:33 MST