[squid-users] squid workers question

[Amos Jeffries]

On 10/03/2017 3:21 a.m., Matus UHLAR - fantomas wrote:
> Hello,
> 
> I have installed squid 3.4.8 on linux 3.16/64bit (debian 8 / jessie
> version)
> 
> (I know it's old, but I prefer using distribution-provided SW unless it has
> real problem distribution isn't able to fix)
> 
> - does this version have known memory leaks?
> http://www.squid-cache.org/Versions/v3/3.5/ChangeLog.txt
> shows some leaks fixed but they all seem to be related to something we
> don't
> use (certificated, Surrogate capability), unless the:
> 
> "Fix memory leak of HttpRequest objects" that is fixed in 3.5.16 applies
> to 3.4 too.
> 

IIRC that does, and there were some issues with CONNECT exceeding
configured limits.

The Bug 3553 issue
<http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13903.patch>
can also cause nasty issues on busy proxy as the cache disk overflows
from too-slow purging.


> 
> I configured rock store (for smaller files) and (later) standard aufs
> for others:
> 
> cache_dir rock /var/spool/squid3/rock 1024 max-size=32768
> #cache_dir aufs /var/spool/squid3 8192 16 256 min-size=32769
> 
> are those correct values? (bug 3411 says something about 256B metadata)
> 

Those 256 Byte will matter for Squid-3.4. It may be worthwhile adjusting
for anyway.

> 
> logs said this:
> 
> 2017/03/02 18:32:15 kid1| /var/spool/squid3 exists
> ...
> 2017/03/02 18:32:18 kid3| Swap maxSize 0 + 262144 KB, estimated 20164
> objects
> 2017/03/02 18:32:18 kid2| Swap maxSize 1048576 + 262144 KB, estimated
> 100824 objects
> 
> - do I get it right that kid1 is the Master, kid2 is the disker for rock
>   store and kid3 is the single worker process?
> 

Alex may corect me here but AFAIK; Master (the daemon manager) should
not have a number, the workers should be kid1 thru kid(N), the Disker
should be kid (N+1) thru kid (N+D), and the Coordinator should be kid(N+D+).

I suspect the coordinator changes its kid number during config parse as
things like workers and diskers are discovered if that matters. After
config the numbers are reliable.

There is also a bug that the FATAL messages do not indicate their
timestamp or what kid is applicable. So one has to guess somewhat based
on surrounding log info.

> 
> After first start I noticed crash:
> 
> 2017/03/02 18:32:18 kid3| Max Mem  size: 262144 KB [shared]
> 2017/03/02 18:32:18 kid2| Max Mem  size: 262144 KB [shared]
> 2017/03/02 18:32:18 kid3| Max Swap size: 0 KB
> 2017/03/02 18:32:18 kid1| WARNING: disk-cache maximum object size is too
> large for mem-cache: 16384.00 KB > 32.00 KB
> 2017/03/02 18:32:18 kid2| Max Swap size: 1048576 KB
> 2017/03/02 18:32:18 kid3| Using Least Load store dir selection
> 2017/03/02 18:32:18 kid3| Set Current Directory to /var/spool/squid3
> FATAL: Ipc::Mem::Segment::open failed to shm_open(/squid-cache_mem.shm):
> (2) No such file or directory
> 
> Squid Cache (Version 3.4.8): Terminated abnormally.
> FATAL: Ipc::Mem::Segment::open failed to
> shm_open(/squid-var.spool.squid3.rock.shm): (2) No such file or directory
> 
> Squid Cache (Version 3.4.8): Terminated abnormally.
> 
> 
> ... this happened in http://bugs.squid-cache.org/show_bug.cgi?id=3411
> however that
> - restart with "workers 1" worked, but isn't that the default?

Maybe. There is SMP and no SMP at all - both have 1 worker. It is
unclear to me which is the default and whether "workers 1" switches to
the other or not.


>   or was the creash caused by something else?
> (will try to replicate)

In my experience that "No such X" messages on the SHM usually means
/dev/shm is not mounted.

(For completeness it could also mean the device name/path is too long on
MacOS.)

Amos