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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
