Hi David & Alexey, (note: new problem report below, may be related, or not) On Sun, Aug 27, 2000 at 09:10:59PM -0700, David S. Miller wrote: > From: kuznet@ms2.inr.ac.ru > > No, I think I know about this bug for veeery long time. Only > permanently forgot to peer to the situation more carefully, just > because nobody reported the problem. > > Please, try this. Try carefully. If it will help, please, relay the > patch to Dave. I probably will be off line for some time. > > Patch need not be relayed, I have applied it because it is an obvious > fix in my eyes regardless of whether it solves this specific reported > problem or not. It did solve the problem I reported. Great! I started with 121 inuse socks in /proc/slabinfo, growing to 183 / 245 under load (400000 connections), and settling at 183 when a test run is done (all TIME_WAIT sockets vanished). At the beginning of the next run, it falls down to 121 once, and again oscillates between 183 and 245, settling again at 183 after the test. Still looks strange, but stable. (starting another test, with double the number of concurrent connections, now at 256) Oops. Wish I had a console in front of me. During the last run, I did netstat -an | grep ESTAB | wc -l and both that command, and a while loop grepping /proc/slabinfo, dropped dead. ping to the box runs at 60% packet loss and varying roundtrip. I stopped the test, and got back the two shells (slow because of the loss, which remains). My two test server processes (poll loop based) still run, show 50% CPU each (according to ps), and are unkillable (even with -9)! I looked at the open fd's of one of them - there are some 15 sockets still ESTABLISHED, but not doing much. I see no traffic at all on the interface through which they should run. No errors, also. I'll reboot the box now. Any ideas on what THAT could have been? best regards Patrick - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
