On Tue, 2012-03-20 at 12:35 +0100, Henrik Nordström wrote: > tis 2012-03-20 klockan 13:09 +0400 skrev Alexander Komyagin: > > Sorry for disinformation, BIND requests are present in both RSBAC logs. > > IOCTL's were removed by adding --disable-eui to Squid configuration > > command, but that did not give any performance increase. > > ok > > > On Tue, 2012-03-20 at 12:37 +0400, Alexander Komyagin wrote: > > > > > >> Also according to logs, that clients timeouts are caused by some of > > > > >> new > > > > >> connections not being spotted and accepted as well (not gone through > > > > >> doAccept() routine from TcpAcceptor.cc). > > Do you have sockets hanging in SYN_SENT state? > > Or are they ESTABLISHED but not picked up for procssing by Squid?
Yep, looks like I have them in SYN_SENT for 5 secs and then they are discarded (timeout for httperf is set for 5 secs). > > > > > Alex, I have performed some more tests (including oprofile profiling, > > > no-daemon mode, 1 worker, 2 workers, etc.). For now, it seems that the > > > problem is highly related to RSBAC Networking which is enabled in our > > > kernel. When I disabled it, the performance issue _has gone_. According > > > to RSBAC logs, no single operation is denied. > > This RSBAC? http://www.rsbac.org/ > > If so, which kernel version? This one. 2.6.35.10 SMP x86_64. > > > > By comparing oprofile results for 3.2 with and w/o RSBAC-Net, I can > > > assume that RSBAC-Net subsystem performs some internal operations on > > > list structures, which are indeed protected by locks - and this, in my > > > point of view, may block simultaneous squid socket operations and affect > > > performance. > > Possible. We would not know. >From RSBAC logs squid 3.2 produces much more operations on NETLINK RAW ROUTE sockets than 3.1. Maybe performance differs due to some changes in the Squid interception mechanism in 3.2? > > Regards > Henrik > -- Best wishes, Alexander Komyagin
