On Thu, Jun 05, 2014 at 04:25:49PM +0200, Pablo Neira Ayuso wrote: > I tried two different tests: > > 1) Normal conntrackd sync configuration, with reliable events. My > testbed is composed of three machines, the client, the firewall and > the server. I generated lots of small HTTP connections from the client > to the server through the firewall. Things were working quite fine, I > could see ~8% of CPU consumption in the workqueue thread, probably due > to retransmission. The dying list remained also empty. > > 2) Stress scenario. I have set a very small receive buffer size via > NetlinkBufferSize and NetlinkBufferSizeMaxGrowth (I set it to 1024, > which results in slightly more). The idea is that just very little > events can be delivered at once and we don't leak events/entries. > > For this test, I generated something like ~60000 conntrack entries > (with wget --spider) during very short time, and then I run 'conntrack -F' > so all the entries try to get out from at the same time. > > In one test, I noticed around ~75 entries stuck in the dying list. In > another test, I noticed conntrackd -i | wc -l showed one entry that > got stuck in the cache, which was not in the dying list. I suspect > some problem in the retransmission logic. Another interesting information. If I generate new entries that get stuck in the dying list because of undelivered events, the worker seems to give another chance to deliver, and the entries that were stuck are not there anymore. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
