Thanks for the answer. Le lun. 30 sept. 2019 à 05:51, Willy Tarreau <[email protected]> a écrit :
> Hi, > > On Sat, Sep 28, 2019 at 07:07:02PM +0200, Emmanuel BILLOT wrote: > > Hi, > > > > We use HAProxy as a LB for many usage, including LB for Squid and user > > acces on Internet. > > Users frequently grumble about "Internet speed" (classical...) and we > want > > to be sure that it is not a LB issue (msconfig, or system bottleneck ?). > > > > How could we find is haproxy is "undersized" in config or if the hosting > > system (CentOS) is not correctly configured (file desc ? memory ?) > > Well, this sounds more like a sysadmin training than an haproxy-specific > question, but a few things you should have a look at : > - is your system swapping ? (it must never) > - do you see in your system logs "conntrack table full" ? If so you're > hitting some misconfigured conntrack limits > - do you see in your system logs "TCP: sending SYN cookies" ? If so > you're likely running haproxy with too low a maxconn setting, resulting > in connections not being accepted > - do you see in your haproxy logs flags "sC" or "SC" while you know > your servers are working fine ? If so that could indicate a failure to > allocate a source port or a file descriptor for an outgoing connection > - do you see your CPU steadily running above, say, 50% ? If so you cannot > exclude frequent 100% peaks possibly causing some sub-second delays not > reported by the system tools. > - and if you're running in a VM, you can redo all this above inside the > hypervisor, and in the guest you should also look at the "st" field in > vmstat to make sure your CPU is not stolen by other VMs (or goodbye low > latency), and you can also run "ping" to your VM from an external host > on the same LAN and make sure the latency never jumps above 1 > millisecond > on a mostly idle network or 2-3 ms on a loaded network or it can > indicate that you're have performance issues caused by noisy neighbors > on your machine. > - connection setup timers exhibiting multiple of 3s in haproxy logs > usually indicate packet drops between haproxy and the servers > - client timeout errors during request like "cR" often indicate drops or > MTU issues between the client and haproxy (sometimes caused by bogus > virtualized network drivers). > > Hoping this helps, > Willy >
