Woodward, Andrew wrote:
Hello,
I've got a couple of questions that I'm hoping that some of you more experienced can enlighten me with.
1)We're recently set up several squid servers to act as a reverse proxy accelerator for some of our web-content servers. When we first set them up they were mostly set with default configs, we have since changed the configs to be more tuned for performance and have noticed some oddities.
Initialy we deployed two boxes with the default cache settings:
cache_mem 8 MB
maximum_object_size_in_memory 8 KB
cache_dir ufs /usr/local/squid/cache 1024 16 256
maximum_object_size 4096 KB
We then changed them to:
cache_mem 1536 MB
maximum_object_size_in_memory 120 KB
cache_dir ufs /usr/local/squid/cache 10240 16 256
maximum_object_size 100 MB
Both servers are kept with identical configs, specs, and OS/component versions. Both service the same load balanced pool and in turn receive requests through the load balancer. Conceptually they see identical traffic and should behave the same.
The first server was hard bounced and was un-able to save its cache objects in memory, the second was gracefully told to reload the config with squid -k parse. We then spun up a third server and used the second cache config (listed above) on server since it's startup. We have been running all three servers for a couple of days (the third one day less) and have noted the stats below and are confused with the deviation. Most interesting is that when monitoring the access log for server A and B I frequently see the same objects requested but they are not being moved back into memory. Would I be wrong to assume that squid has an idea of the time it takes to return the object and can therefore identify if the request was serviced by the linux buffer/cache and not actually read from disk and that; because of this process, it doesn't bother to move it into its own memory?
Squid's cache_mem is only used for objects fetched from the wire.
2)In relation to one I've tired to change memory_replacment_policy from lru to heap LFUDA however when I load the config with "memory_replacment_policy heap LFUDA" it errors telling me It doesn't know what policy "heap" is. I've tried with various quotes and just "LFUDA" with no success. Is there a step I'm missing here?
The heap replacement algorithm needs to be added as a compile time
option. Check "squid -v" for "--enable-heap-replacement". If you have
to recompile squid, I'd advise adding "--enable-storeio=ufs,aufs" and
using aufs for the cache_dir type. That will allow asynchronous disk
accesses.
3) in order to further extort performance from pinning the cache in memory, I've been toying with the idea of creating a tempfs and using it to store the 'disk' cache, and periodically (about every 15 min) syncing the cache back to a physical disk. If the system restarts I'll just remount the tempfs and copy the cache back into the tempfs before starting squid again. Does anyone have any experience or comments on the procedure, and if it is better / worse than letting Linux buffers handle pinning the objects in memory. My indications say that this would be favorable over the possibility of the buffer's being wiped by a service process (assuming that squid is the only dedicated service on the server) grabbing the buffers for other files
http://www.squid-cache.org/mail-archive/squid-users/200806/0392.html
Testing would be the only way to be sure. In any case, it appears you
are only using an average of 60MB of cache_mem across all three servers
(Storage Mem size). Perhaps you would benefit from upping your
maximum_object_size_in_memory.
Thanks,
Andrew Woodward
Chris
