Re: RAM and conntrack performance: first draft of the document is online

[Patrick McHardy <kaber@trash.net>]

Harald Welte wrote:

>>Don't you think it would be good to shrink the lists immediately?
>>Waiting til the number has dropped below the limit can take days...
>>    
>>
>
>well, it might be a good idea.  but I somehow doubt this is a valid
>scenario.  And if we would shrink the list:  how do we select which
>entries to evict?  I'd rather wait for ctnetlink to appear in mainstream
>kernels and then leave that to a userspace process.
>  
>

PF uses "adaptive timeouts" to scale down timeouts if the table gets full.
IIRC until some threshold is reached, all entries have 100% of their normal
timeouts, from then on its scaled down until 0% for a completly full table.
I've been thinking about adding this to ip_conntrack for some time because
I often have problems with my roommates edonkey and overflowing conntrack
table. I decided to experiment with it when the timeout handling of conntrack
is changed from beeing handled by a per-conntrack timer to a global cleanup
timer. I recall someone wanted to make a patch for this some time ago to
prevent timer storms, do you have any information if anyone is currently
working on this ? Otherwise I might just do both ..

Best regards,
Patrick