[squid-users] squid 3.5.27 does not respect cache_dir-size but uses 100% of partition and fails

Alex Rousskov rousskov at measurement-factory.com
Thu Jul 12 16:16:48 UTC 2018


On 07/12/2018 05:53 AM, pete dawgg wrote:


> I have set workers 8 just recently; but the disk full error had
> definitely been occuring before.

AUFS cache_dirs are not compatible with SMP Squid. Removing workers was
the right thing to do even if that incompatibility was not causing disk
overflows.


> FATAL: Ipc::Mem::Segment::open failed to shm_open(/squid-cf__metadata.shm): (2) No such file or directory

> This error seems to occur when the disk is really full and squid is restarted.

Ah, then it could be a side effect of poor PID management (and
associated shared resource locking) in Squid v3. You can probably ignore
this error until you fix the restarts. FWIW, Squid v4 addressed those
shortcomings.


> When there is no traffic squid seems to cleaning up well enough: over
> night (no traffic) disk usage went down to 30GB (now it's at 50GB
> again)

This may be a sign that your Squid cannot keep up with the load. IIRC,
AUFS uses lazy garbage collection so it is possible for the stream of
new objects to outpace the stream of object deletion events, resulting
in a gradually increasing cache size. Using even more aggressive
cache_swap_high might help, but there is no good configuration solution
to this UFS problem AFAIK.


> There was another error i just fixed:
>> FATAL: Failed to open swap log /mnt/cache/squid/swap.state.new
> Not a permissions or diskspace problem, caused by workers 8.
> I have deactivated workers 8 and this error went away.

Yes, that error is one of the signs that AUFS cache_dirs are not SMP-aware.

Alex.


More information about the squid-users mailing list