On 17/01/18 02:37, Vieri wrote:
Hi,
Just a quick follow-up on this.
I dropped squidclamav so I could test c-icap-modules's clamd service instead.
The only difference between the two is that squidclamav was using unix sockets
while c-icap-modules is using clamd.
At first, the results were good. The open fd numbers were fluctuating, but
within the 1k-2k limit during the first days. However, today I'm getting 4k,
and it's only day 5. I suspect I'll be getting 10k+ numbers within another week
or two. That's when I'll have to restart squid if I don't want the system to
come to a network crawl.
I'm posting info and filedescriptors here:
https://drive.google.com/file/d/1V7Horvvak62U-HjSh5pVEBvVnZhu-iQY/view?usp=sharing
https://drive.google.com/file/d/1P1DAX-dOfW0fzt1sAeyT35brQyoPVodX/view?usp=sharing
Sorry I have a bit of a distraction going on ATM so have not got to that
detailed check yet. Good to hear you found a slightly better situation
though.
By the way, what does "Largest file desc currently in use" mean exactly? Should
this value also drop (eventually) under sane conditions?
The OS assigns FD numbers and prefers to assign with a strong bias
towards the lowest values. So that can be seen as a fluctuating "water
level" of approximately how many FD are currently in use. If there are a
few very long-lived connections and many short ones it may be variably
incorrect - but is good enough for a rough guide of FD usage.
In normal network conditions it should rise and fall with your peak vs
off-peak traffic times. I expect with your particular trouble it will
mostly just go upwards.
Amos
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
