Dotaz: Problemy s tcp pripojenim pri nekolika tisicich spojeni [mysql server]

[Skřivy]

Ahoj,

uz cca pul roku resime problemy s pripojenim k databazi.

Situace:

• 2 mysql servery (replikace master->slave) [predimenzovany hw, load kolem 4, nezatizene disky, dostatek pameti]
• 8 web serveru
• 30 dalsich serveru, ktere se k databazi pripojuji
• aplikace napsana v php

Problem:

• ve spicce i mimo spicku (ne vsak v noci) se stava, ze se nepodari pripojit k mysql serveru a php vrati chybu.
• pri debugovani jsme zjistili, ze pakety projdou pres iptables, ale jiz se nedostanou z kernelu do aplikace (nedostanou se do funkce accept) jakoby se ztratily nekde v kernelu
• chova se to dost ruznorode - jeden den vse funguje v poradku i presto, ze je mnohem vyssi zatez nez dalsi den, kdy nastava tento problem
• lagy: v cyklu jsme se zkouseli porad pripojovat k databazi (cca s pul vterinovym odstupem) v nekolika vlaknech a vzdy v neurcitych intervalech na cca 5 vterin se sekly vsechny vlakna a spojeni se nepodarilo vytvorit.

Dalsi poznamky:

• persistentni spojeni: nepouzitelne - spojenich je tam pak desitky tisic a cele to jde dolu jeste rychleji
• mysql proxy: ten samy problem
• otestovane kernely: 2.6.30-bpo.2-amd64, 2.6.32-bpo.2-amd64, 2.6.26-2-amd64
• neupravene parametry v sysctl
• system: Debian 5.0.6
• problem se nam povedlo nasimulovat i s jinymi aplikacemi nez mysql serverem

Samozrejme uspesneho resitele ceka odmena.

Jarda

---

---

Odpovědi

[oho]

pisete ze pouzivate iptables, takze tam nejspis mate nejaka stavova pravidla, nemate teda nahodou plnou conntrack tabulku?

viz. http://www.taxze.com/ip_conntrack-ct-0-table-full-dropping-packet.htm

[Skřivy]

Do logu jsme se divali, bohuzel ani skytnuti o tom, ze by neco melo byt spatne. :\

Jinak ano - firewall tam byl, prozatim jsem jej vypnul (cili vyprazdnil, ale iptables v kernelu ponechal).

[petr_p]

Malý TCP back-log?

Jak se klient dozví, že spojení do databáze nefunguje? Dostane TCP reset, chybu ICMP, prostě vytimeoutuje?

[Skřivy]

Rekl bych, ze vytimeoutuje. Tcpdump ukazuje, ze pakety na server prijdou (kdyz jsem zapnul logovani na iptables, tak se spravne zalogovaly). Nicmene na funkci accept (zjistovani stracem) se jiz nedostanou, cili ze serveru ani neodejde zadna odpoved.

[petr_p]

Nehádejte a podívejte se, co ze serveru odchází. Chybový packet odesílá jádro, ne naslouchající proces.

[Skřivy]

Na klienta jiz zadna odpoved neprijde (zjisteno tcpdumpem).

[Ivan]

OT: v takovyhle situacich se vyplati duplikovat na switchi porty(serveru i klienta) a tcpdump spoustet na jinych pocitacich pripojenych k tem duplikovanym portum.

[iwk]

Zeby nofile limit v /etc/security/limits.conf ?

[Skřivy]

Prázdné.

ulimit je unlimeted.

[rADOn]

Co na to netstat? Nemas nahodou hromady portu zadrenych ve stavu TIME_WAIT?

[Skřivy]

Ano, to souhlasi. Zkusili jsme i snizit dobu, po kterou tam budou hnit, nicmene to vyresilo problem pouze castecne.

[Skřivy]

Viz unix-socket-faq. Snizeni tcp_fin_timeout pomuze jen do urcite miry a za urcitou cenu. Pokud to nestaci, budete muset aplikaci naucit pouzivat persistentni spojeni.

[HoGo]

Co mysql parametry ?

set-variable = wait_timeout=20

set-variable = interactive_timeout=20

[Skřivy]

Tohle uz tam mame dlouho.

[Skřivy]

Persistentni spojeni problem neresily.

Jinak:http://www.mysqlperformanceblog.com/2006/11/12/are-php-persistent-connections-evil/

[Skřivy]

Tohle nam dost pomohlo, cili to oznacuji jako reseni. Vsem dekuji za napady.

[Grunt]

pri debugovani jsme zjistili, ze pakety projdou pres iptables, ale jiz se nedostanou z kernelu do aplikace (nedostanou se do funkce accept) jakoby se ztratily nekde v kernelu

Sice ne přímo řešení, ale částečná indicie by to mohla být.