On Fri, Feb 15, 2013 at 4:21 PM, Chris Burroughs <[email protected]> wrote: > http://comments.gmane.org/gmane.comp.web.haproxy/8307 > > So my understanding is that is is generally not helpful to increase > nbproc and instead pinning NIC IRQs and haproxy on two adjacent cores is > recommended for handling a high connection rate. In the case of using > multiple NICs, more NIC/haproxy pairs can be pinned. > > How does this recommendation change when two NICs are available and > tproxy is being used? Should the backend requests all use one NIC, and > outgoing client the other? If there are no bandwidth requirements to > use both NICs, should one one be used to reduce interrupts? >
If you can use one NIC this is what I'd do just to keep the setup as simple as possible. Even if you use two, I would just leave the IRQs alone and set haproxy to run on CPU 1 in your startup scripts (IRQs default to 0, which you can leave as-is). You probably don't have to do this unless you have a LOT of traffic. To give you an example from our environement, right now we're processing 2500 req/s and about 900Mbps through our one haproxy server. The server is a quad core Xeon 2.4Ghz with seven NICs set up in two bond interfaces, one with 4 interfaces and one with 3 interfaces. One bond is external (frontend) and one is internal (backend). haproxy uses about 56% of CPU 1, and software interrupt processing is taking about 30-50% of CPU 0. Our average CPU utilization over the past month is only about 17% for the entire box. We've been running perfectly stable this way for months. Brendon
