On Jul 3, 2014 7:19 PM, "Sasha Pachev" <[email protected]> wrote: > > Some ideas: > > - what happens if you up the size of the request ?
We increased the request to more than 2500 bytes and it has an effect on the soft interrupt CPU for the cpu 0 (the one where we pinned the IRQ, not the one where we pinned haproxy). This makes sens since we don't use jumbo frames and we probably double or tripled the number of RX packets. However we arrive in the stunning situation where both cpu 0 and cpu 1 have around 25 to 30% of soft interrupt (at least according to top). This does not affect at all the session rate, stuck to ~16k/s. This makes me thing that the cpu 1 soft interrupt time is really abnormal and that the cpu 0 si time is normal (normal = coming from a hard interrupt on eth0) right? > - what results do you get with haproxy 1.4 ? Very similar result, same blocker around ~16k session/s with haproxy at 100% CPU (same pattern with user, sys and si). It all looks like a kernel or hardware or stupid config issue somewhere. > - have you tried gdb -p $(pidof haproxy) --batch --ex "set pagination > 0" --ex "thread apply all bt" ? Sometimes a few random stacktrace > samples help you stumble upon an idea of where your bottleneck is. > I ran a couple of them but without much success since i'm not very fluent in this stuff :) from all the stacktraces i got nothing stood out and the code didn't seem blocked somewhere special. Additional note: we get around 300k TIME_WAIT connections but use tw_reuse so it shouldn't be an issue i think
