Gavin McCullagh ha scritto:
Hi,
On Mon, 16 Mar 2009, Marcello Romani wrote:
From my little experience I would suggest that you give squid cache_mem
a value of just some hundreds of MBs, and let the other GBs of ram to
squid for indexes and the OS for disk caching. I guess after some time
this will take you near a ramdisk-only setup.
Really? I would have thought the linux kernel's disk caching would be far
less optimised for this than using a large squid cache_mem (whatever about
a ramdisk).
As others have pointed out, squid's cache_mem is not used to serve
on-disk cache objects, while os's disk cache will hold those objects in
RAM after squid requests them for the first time.
So if you leave most of RAM to OS for disk cache you'll end up having
many on-disk object loaded from RAM, i.e. very quickly.
Also, squid needs memory besides cache_mem, for its own internal
structures and for managing the on-disk repository. If its address space
is already almost filled up by cache_mem alone, it might have problems
allocating its own memory structures.
OS's disk cache, on the other hand, is not allcated from squid's process
memory space and has also a variable size, automatically adjusted by the
OS when app memory needs grow or shrink.
This is how I understand the whole story so far, others might correct me
of course :-)
Also, this would move the problem of accessing a very large ram address
space from squid (which being only 32-bit can lead to problems) to the
OS, which IMHO is better suited for this task.
It's starting to look that way alright.
Also, I don't understand why spending so much on memory instead of
buying some more spindles to have a more balanced server in the end
(maybe space constraints ?)
The cost of 8GB of ram was about €100, so it was relatively cheap. As you
guessed, the machine itself is 1U and doesn't have space for any more hard
drives.
Gavin
--
Marcello Romani
