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