Bekijk Volledige Versie : 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:
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.
#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?
CharlieRoot
01/03/15, 11:02
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)
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.
CharlieRoot
01/03/15, 12:39
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.
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.
CharlieRoot
01/03/15, 14:01
Waarom gebruik je check source ?
De config is nu al iets gewijzigd. Dit is de current. Nog steeds zonder resultaat helaas:
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...:
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
CharlieRoot
01/03/15, 17:39
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.
systemdeveloper
02/03/15, 00:12
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 (http://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=1) en gaan ze via netwerk #2 (http://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=2) weer terug naar netwerk #1 (http://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=1) . Als backup heb je dan nog netwerk #3 (http://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=3) . Ga je direct verbinden blijf je in netwerk #1 (http://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=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
HI guys,
De afgelopen week al jullie tips geprobeerd; ben nog eens via PB / Skype geholpen door geweldige collega's. Helaas mocht 't allemaal niet baten. Het is gewoon qua performance niet haalbaar om mysql via haproxy over verschillende netwerken te verdelen.
Het e.e.a. is nu omgezet zodat de mysql server intern wordt benaderd door de webservers. Dit geeft natuurlijk wel het gewenste resultaat qua performance.
Bedankt voor jullie reacties, tips en het meedenken!