Onderwerp: MySQL via HAProxy (traag)

Hi,

Sinds kort heb ik MySQL in een master-master opstelling. Tussen de webservers en de mysql servers heb ik HAProxy draaien.

HAProxy draait op twee virtuele servers: lb1 en lb2 en handelt dus http-verkeer en tcp-only verkeer (MySQL) af.

Tijdens het testen kwam dit probleem niet zozeer naar boven, maar nu twee servers gebruik maken van MySQL via de HAProxy merk ik dat de latency bij het laden van semi-grote websites of wordpress sites erg hoog is. Het is Klik - wachten - wachten - klaar met laden.

Als ik dan de DB-host verander naar één van de mysql servers (dus direct praten met mysql1 bijv.) dan is het klik - klaar met laden. Bijna instant dus.

Hierbij een overzicht

- webserver (sites, localhost gaat d.m.v. socat naar mysql.[domain].[ext])
- mysql 1
- mysql2
- lb1 (haproxy)
- lb2 (haproxy)

De loadbalancers draaien op een virtuele server met 1x2.6 Ghz processor.

mysql.[domain] is gebind op het virtuele ip-adres tussen de HAProxy servers. De specifieke config voor deze binding is als volgt:

Code:

global
        log 127.0.0.1   local0
        log 127.0.0.1   local1 notice
        #log loghost    local0 info
        maxconn 40000
#       debug
#       quiet
        user haproxy
        group haproxy
        daemon

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        option redispatch
        maxconn 40000
        timeout client  60000ms
        timeout server  60000ms

frontend ao-mysql-frontend
        bind *:3306
        default_backend ao-mysql-backend
	mode    tcp
	option  tcpka
	option tcp-smart-accept
	option tcplog
	balance roundrobin


backend ao-mysql-backend
	mode    tcp
	option  tcpka
	option tcp-smart-connect
#	no option tcp-smart-accept
	balance roundrobin
	option mysql-check user haproxy_check
        server mysql1 [ip-mysql1]:3306 check source [ip lb1]:1025-65000
        server mysql2 [ip-mysql2]:3306 check source [ip lb1]:1025-65000 backup

Ik heb ook enkele aanpassingen gedaan in /etc/sysctl.conf op de loadbalancers - en gedeeltelijk ook op de webserver.

Code:

#HAProxy
net.ipv4.ip_nonlocal_bind=1
net.ipv4.ip_forward=1

net.ipv4.ip_local_port_range = 1025 65000
net.ipv4.tcp_tw_reuse=1

net.ipv4.tcp_max_syn_backlog = 40000
net.ipv4.tcp_max_tw_buckets = 400000
net.ipv4.tcp_max_orphans = 60000
net.ipv4.tcp_synack_retries = 3
net.core.somaxconn = 40000

Het probleem met het lange laden blijft echter. Heeft iemand dezelfde ervaring en heeft het op de een of andere manier kunnen oplossen? Of heeft iemand de verlossende tip?

Je gebruikt heel veel opties waarvan ik het nut niet in zie. Misschien dat het daar ergens zit. Mijn MySQL config is super simpel (en werkt perfect)

Code:

listen mysql-cluster14
    bind 10.127.14.100:3306
    mode tcp
    option mysql-check user haproxy_chk
    balance roundrobin
    server node-1 10.0.14.10:3306 check
    server node-2 10.0.14.11:3306 check

Thanks voor je reply!

Die opties heb ik er juist bijgezet omdat het zo traag is. Ik zal het eens versimpelen om te kijken of het dan wellicht beter gaat. Het kan zomaar zijn dat het niet eens aan HAProxy zelf ligt.

Mag ik vragen wat de specificaties van je HAProxy machine zijn?

Je wilt eigenlijk nooit round-robin active-active doen in setups als dit. De kans op split brain scenario's is daarmee groter, zeker bij standaard log shipping replicatie van MySQL, en je winst met round-robin is voor writes 0. Voor reads helpt het wel, maar ook niet altijd. Je caching wordt bijvoorbeeld niet gerepliceerd. Het zijn uitzonderlijke situaties waar in je reads wilt load balancen en een twee node cluster vind ik voor HA en performance sowieso niet de beste keuze. In dit geval had ik het simpeler gehouden en active-passive gaan draaien. Op node-2 de optie backup mee geven en je bent klaar.

Misschien dat dit zelfs je problemen op lost, maar dat blijft lastig inschatten op afstand.

Oorspronkelijk geplaatst door Ahmed

Thanks voor je reply!

Die opties heb ik er juist bijgezet omdat het zo traag is. Ik zal het eens versimpelen om te kijken of het dan wellicht beter gaat. Het kan zomaar zijn dat het niet eens aan HAProxy zelf ligt.

Mag ik vragen wat de specificaties van je HAProxy machine zijn?

1 Vcpu, 512MB ram. Haproxy vereist amper resources


Verzonden vanaf mijn iPhone

Hi getUP:

In principe gebeurt er hetgeen jij beschrijft. Alle reads en writes gaan altijd naar 1 mysql server (mysql1). Alleen indien die niet bereikbaar is gaan ze door naar mysql2. De round-robin balance is inderdaad overbodig -en heb ik er nu uitgehaald. De tweede server stond al als 'backup'. Helaas nog steeds dezelfde performance.

Code:

server mysql1 [ip-mysql1]:3306 check source [ip lb1]:1025-65000
server mysql2 [ip-mysql2]:3306 check source [ip lb1]:1025-65000 backup

CharlieRoot : thanks - heb ongeveer hetzelfde

Ah, ik zie nu pas dat je kunt scrollen in je eerste code blocks. Had dat stukje dus gemist. Heb je iets in je firewall staan op de load balancer wat stiekem nog rate limiting doet? Of op de MySQL servers zelf?

Anders misschien debug logging aanzetten in HaProxy. Misschien dat daar iets boven komt drijven. Het komt mij zo niet bekend voor.

Waarom gebruik je check source ?

De config is nu al iets gewijzigd. Dit is de current. Nog steeds zonder resultaat helaas:

Code:

frontend ao-mysql-frontend
        bind 164.138.24.101:3306
        default_backend ao-mysql-backend
	mode    tcp

backend ao-mysql-backend
	mode    tcp
	option mysql-check user haproxy_check
        server mysql1 91.238.177.210:3306 check
        server mysql2 5.101.100.238:3306 check backup

Ik heb op elke server (web, mysql en LB) alle firewalls eens uitgeschakeld. Dat deed de trick helaas ook niet.

Qua logs zie ik ook niet veel abnormaals...:

Code:

Mar  1 16:14:51 localhost haproxy[22887]: 91.238.177.195:47133 [01/Mar/2015:16:14:51.271] ao-mysql-frontend ao-mysql-backend/mysql1 1/4/34 104 -- 2/2/2/2/0 0/0
Mar  1 16:14:51 localhost haproxy[22887]: 91.238.177.195:47132 [01/Mar/2015:16:14:50.757] ao-mysql-frontend ao-mysql-backend/mysql1 1/4/898 24790 -- 1/1/1/1/0 0/0
Mar  1 16:14:53 localhost haproxy[22887]: 149.210.199.118:39178 [01/Mar/2015:16:14:49.759] ao-mysql-frontend ao-mysql-backend/mysql1 1/4/3575 3608 -- 0/0/0/0/0 0/0
Mar  1 16:14:56 localhost haproxy[22887]: 91.238.177.195:47136 [01/Mar/2015:16:14:55.646] ao-mysql-frontend ao-mysql-backend/mysql1 1/4/369 38705 -- 0/0/0/0/0 0/0
Mar  1 16:14:56 localhost haproxy[22887]: 91.238.177.195:47138 [01/Mar/2015:16:14:56.321] ao-mysql-frontend ao-mysql-backend/mysql1 1/4/50 768 -- 0/0/0/0/0 0/0
Mar  1 16:14:58 localhost haproxy[22887]: 91.238.177.195:47141 [01/Mar/2015:16:14:58.245] ao-mysql-frontend ao-mysql-backend/mysql1 1/4/100 3646 -- 0/0/0/0/0 0/0
Mar  1 16:14:59 localhost haproxy[22887]: 91.238.177.195:47144 [01/Mar/2015:16:14:59.328] ao-mysql-frontend ao-mysql-backend/mysql1 1/4/45 104 -- 0/0/0/0/0 0/0

Ik zie als MySQL servers twee externe IP's? Je bedoelt dat je - over internet - verbinding maakt met twee MySQL servers? Tussen jou en die servers zitten vast ook componenten die invloed hebben op de connecties..

edit-
Alle IP's komen bij andere netwerken uit. Je hebt zo wel heel erg veel potentiële bottle-necks. Lijkt me geen handige opzet dit.. Ik zou beginnen met wat MTR resultaten te bekijken en vanaf de loadbalancer een test laten draaien om te kijken of je vanaf de LB wel op de juiste manier (en juiste snelheid) kunt verbinden.

Hi Wieger,

Dat klopt inderdaad. Het 'rare' is dat wanneer ik gewoon vanaf de webserver verbind met het mysql ip-adres. Alle connecties en dergelijk supersnel gaan. Alleen wanneer ik 't via HAProxy laat lopen lijkt het net of er een latency van een 6-10 seconden bij komt. Dus vandaar mijn vermoeden dat het iets met HAProxy te maken heeft.

Ik heb niet veel ervaring met haproxy en ga meestal voor de kiss setups met zo min mogelijk regels, maar wat me even opvalt:

Bij de defaults heb je 'mode http' staan wat op layer 7 gebruikt wordt en bij de sql services heb je 'mode tcp' staan wat weer op layer 4 gebruikt wordt.
Daarnaast heb je roundrobin gekozen, terwijl dat 'normaal' beter geschikt is voor http (korte) connecties. Misschien kun je daar beter 'leastconn' kiezen dat beter geschikt voor sql 'zou zijn'.

Of die publieke ip's iets uitmaakt kan ik niet zeggen. Als het echt naar buiten gaat dan kan dat wel de nodige lag veroorzaken omdat je met de replicatie van de sqlservers te maken hebt. Zou geen 6-10 seconden moeten zijn natuurlijk. Blijft het allemaal aan de binnenkant dan zal het niet veel uitmaken. Al zou ik, in geval van 2 servers onder 1 switch gewoon even een lokaal net maken en die op de switch in een eigen vlan duwen.

Een iets hogere latency kan bij verkeerde code al snel zorgen voor een hoge vertraging. Als ik je logs goed zie komen de verbindingen van netwerk #1 en gaan ze via netwerk #2 weer terug naar netwerk #1 . Als backup heb je dan nog netwerk #3 . Ga je direct verbinden blijf je in netwerk #1 .

Dan is het niet zo gek dat je performance daar beter is. Wil je hoge performance dan gaat dit niet je oplossing worden. Als beschikbaarheid belangrijk is zul je dit op een andere manier op moeten lossen en dan is je enkele HA proxy server ook niet ideaal.

Misschien heeft het iets met je MySQL config te maken eerder dan met je HAProxy config. Doen je MySQL server DNS resolving op inkomende connecties? If so, mogelijk hebben je loadbalancers dan geen geldige rDNS en komt die latency van je MySQL server die aan het wachten is op die DNS queries. Als je DNS resolving niet nodig hebt (normaal enkel nodig als je users hebt die je gedefinieerd hebt als user@hostname ip user@ip), kan je dit uitschakelen door skip-name-resolve toe te voegen aan je my.cnf.

Jongens, bedankt voor de reacties. Heb geen meldingen van WHT gehad. Dus ik zie ze nu pas. Ga ze op kantoor zometeen direct doornemen!


Sent from my iPhone using webhostingtalk