[squid-users] TCP out of memory

[Amos Jeffries]

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