Hi
> Summary: After a few days of operation squid suddently dies.
> Box: Dell 2300 Poweredge, 512Mb RAM, 512Mb Swap (partitions), 6x9Gb
> of which 5 x 9Gb are for cache_dirs.
> Version: Squid 2.2PRE1
There are newer versions out... not sure if that is the problem.
> 1999/03/18 17:01:36| Validated 482307 Entries
> 1999/03/18 17:01:36| store_swap_size = 4956842k
> 1999/03/18 17:01:37| storeLateRelease: released 7 objects
It seems like there is quite a long time space here: there may be no
relationship between this message and the failure.
> FATAL: Received Segment Violation...dying.
Hmm. We need some more information before we can tell what it is. Do
you have a core file that we you could run 'gdb' on?
> In the squid.conf:
>
> cache_mem 400 MB
> It may be the cache_mem which is wrong, however:
It is. You should not set cache_mem to more than a few percent of your
available ram. If you have a look at the comment in the newer
squid.conf files, you will see why. This value is the amount of ram
that will use ABOVE AND BEYOND the memory it uses by default (which is
probably a good few 100Mb on your machine).
> a) does anyone know why squid bombs out so badly,
Perhaps it's:
1) max memory size per process. ulimit -a
2) some bug in the code. Would not be the first time ;)
Try the latest version: the pre-release stuff is not
really made to be ultimately stable.
> b) what would a recommended cache_mem be for this particular box?
cache_mem is used for 'fast object store' - it keeps commonly
requested objects in ram so that it doesn't have to touch disk. In
many cases your OS can use this ram more efficiently (say, for buffer
cache). I wouldn't set this to more than 10Mb on your machine. If your
average object size is 13kb, you are keeping the 700 or so
most-requested objects in ram. Any ram not used by squid for internal
tables/info can thus be kept available for buffer cache and OS use.
Oskar
Received on Thu Mar 18 1999 - 13:18:24 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:45:20 MST