Many admins will do what we did: make a few obvious squid.conf changes after the initial install, then let Squid run for awhile and observe what happens. Among our initial tuning changes:

Before disabling logs, we started a Polygraph workload and monitored the access.log. But with an active workload, these logs grew large and quickly consumed all available space in their default location /usr/local/squid/logs. We then set cache_access_log none, but this only created a file called none! In fact, you can't stop Squid from recording client access, but you can avoid writing the log to disk by sending output to /dev/null. You can also better manage disk space by placing your log files in another partition, invoking squid -k rotate periodically in a cron job and transferring old files elsewhere.

Once we brought disk usage under control by tweaking cache_disk and log settings, our next challenge was memory. The config option cache_mem affects how much RAM is used by in-transit, hot and negatively cached objects, but if Squid needs more memory for in-transit objects, it will use it despite any limit you set here.

And there is no config option to limit Squid process size: cache_mem is only one way Squid consumes RAM; others uses include disk and network I/O buffers, IP and FQDN cache, per-request state information (including request and reply headers) and statistics. You can monitor Squid memory usage with Cache Manager. Our general stats showed 55 KB in use when we'd configured cache_mem 32 KB. Squid developers have been working to eliminate memory leaks; check the FAQ for hints on how to reduce usage and avoid leaks.

Next: Tuning Squid Efficiency »