MariaDB - pomalá replikace (F21 vs. F22)

Ahoj,

provozujete někdo replikaci pod MySQL, potažmo tedy Maruškou? Mám tři servery, master (není v mých pazourech, jsou na něm tuším Widle a též MariaDB ve verzi 10.0.22) je na nějaké 40Mbps lince, 2 slave na páteři na 1Gbps (každý v jiném serverhouse). Na F21 vše šlapalo jedna báseň. Ledva jsem upgradoval na F22 (kde je IMHO úplně stejná MariaDB ve verzi 10.0.21), začala replikace podivně zpomalovat. Když si vytrasuju síťové spojení, po spuštění slave-a to chvíli jede “full céres”, ale brzy to spadne na rychlosti kolem 1Mbps, takže se slave začně proti masteru zřetelně opožďovat (parametr Seconds_Behind_Master postupně narůstá).

Hlava mi to nebere, neboť v my.cnf ani žádných slave nastaveních se vůbec nic neměnilo, žádné firewallové hrátky na obou stranách také neproběhly (pokud si mezi oběma servery pustím ssh či FTP seanci, jede to plnou rychlostí zcela bez problémů), takže nějaký network driver related problem v F22 jádrech to nejspíš nebude. Ale věru netuším, kde / po čem mám pátrat.

Zajímavé je, že v F23 je ve stable repositories stále verze MariaDB 10.0.20-3, tedy o verzi nižší, byť zřejmě čerstvěji patchovaná (nežli 10.0.21-1 v F22). Ale proč tomu tak je, to jsem nikde nevyhrabal. Nu, asi vyzkouším jeden slave server zupgradovat na F23, jestli se něco změní. Couvat na F21 (za chvíli končí support) se mi věru už nechce…

Za jakýkoliv tip, postřeh či nakopnutí správným pátracím směrem předem díky…

Diky za report, zkusime nejak pomoct. Koukam, ze mariadb-10.0.21-1 uz by mela byt ve vsech verzich Fedory ve stablu, ale nemyslim, ze by upgrade na posledni bugfix verzi pomohl, protoze z changelogu se mi nezda, ze by se fixovalo neco ohledne performance replikace: https://mariadb.com/kb/en/mariadb/mariadb-10021-changelog/

Za spatnou performance obcas muze i nejaka zmena v kernelu, takze pokud je to mozne, doporucil bych zkusit vymenit kernel za verzi z F21, jestli to nepomuze. To same jde samorzrejme zkusit i se samotnym balikem mariadb-server, abysme vyloucili, ze je chyba tam. Posledni balik, ktery me napada, je libaio, ale ten se mezi F21 a F22 prakticky nezmenil, takze tam bych chybu taky necekal.

Pokud by se podarilo vydolovat reproducer, tak na to muzem mrknout bliz, bez neho asi lip pomoct nedokazu.

[nic, jen zapinam sledovani]

hhorak napsal(a):

Diky za report, zkusime nejak pomoct. Koukam, ze
mariadb-10.0.21-1 uz by mela byt ve vsech verzich
Fedory ve stablu, ale nemyslim, ze by upgrade na
posledni bugfix verzi pomohl, protoze z changelogu
se mi nezda, ze by se fixovalo neco ohledne
performance replikace:
https://mariadb.com/kb/en/mariadb/mariadb-10021-ch
angelog/

Za spatnou performance obcas muze i nejaka zmena v
kernelu, takze pokud je to mozne, doporucil bych
zkusit vymenit kernel za verzi z F21, jestli to
nepomuze. To same jde samorzrejme zkusit i se
samotnym balikem mariadb-server, abysme vyloucili,
ze je chyba tam. Posledni balik, ktery me napada,
je libaio, ale ten se mezi F21 a F22 prakticky
nezmenil, takze tam bych chybu taky necekal.

Pokud by se podarilo vydolovat reproducer, tak na
to muzem mrknout bliz, bez neho asi lip pomoct
nedokazu.

Já děkuju za postrčení správným směrem. Pořád jsem přemýšlel, jaké všechny balíky povyměňuju a přitom evidentně stačilo přebootovat ;-). Na f21 jádru se situace valně zlepšila, slave dohání zpoždění z nastřádaných 80000 sekund, aktuálně je na cca 11000 a stále se to snižuje.

Takže result je evidentní - Maruška je v tom nevinně, může za to jádro. Abych byl konkrétnější, v F22 jsem běžel nejnovější stable kernel 4.2.5-201.fc22 (ale zlobilo to i na předchozím 4.2.3-200), reboot proběhl na poslední “jednadvacítkové” jádro, tedy 4.1.10-100.fc21. Otázka tedy zní, co je v 4.2 kernelovské řadě “rozbité” ? Nějaký předělaný MM nebo scheduler? Nebo jakási regrese? Dlužno ale říci, že jiné performance degradace u jiných procesů jsem si nevšiml … jen u té SQL replikace …

To jsou dobre zpravy, urcite by bylo dobre to nareportovat, kernel vyvojari snad pomuzou zjistit zbytek chybejicich informaci a opravit toho sotka: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=kernel

hhorak napsal(a):

To jsou dobre zpravy, urcite by bylo dobre to
nareportovat, kernel vyvojari snad pomuzou zjistit
zbytek chybejicich informaci a opravit toho sotka:
Log in to Red Hat Bugzilla
Fedora&component=kernel

Ok, nareportoval jsem :

https://bugzilla.redhat.com/show_bug.cgi?id=1281994

Tak uvidíme, jestli se toho někdo ujme a nedopadne to jak s mým reportem o mrznoucí remmině, který ani po 2 měsících nikoho nezajímá :-). Ale pokud je to opravdu nějaká regrese v kernelu, pravděpodobně to někdo řešit bude, spíš se divím, že to ještě nikdo nezaregistroval / nereportoval přede mnou.
Snad se objeví i relativně brzký fix, ono trčet věčně na fc21 jádrech (notabene v mixu s novějším OS kolem) není úplně výherní…

Hmm, tak se zdá, že to nakonec nebude kernel 4.2.X regrese – po párdenním pozorování jsem zjistil, že vliv nemá reboot na starší jádro, ale prostě reboot. Zřejmě se vyčistí nějaké (v paměti rezervované?) oblasti a chvíli trvá, než se to zaplní (jen spekuluju, nějak vůbec netuším, na co bych se měl při traceování zaměřit). Konkrétně mám oba dva slave-y na Dell serverech (takže HW/vendor specific to taky nebude), přičemž ten jeden jede po rebootu už asi 4. den bez zpožďování, tomu druhému to vždycky vydrží tak den, den a půl, a pak začne opět zpožďovat.

Když to tedy není 4.2 kernel specific, musí to být něco fc22 specific, neboť - jak jsem již byl uváděl - v naprosto stejné konfiguraci před upgradem F21->F22 to jelo dlouhé měsíce zcela bez problémů.

Že s tím ještě tak “otravuju” - bohužel problém stále trvá, dokonce je čím dál horší … jestliže jsem ten problém poprve registroval v 4.2 jádrech, přijde mi, že ve 4.3 je to ještě výraznější – replikace laguje jako blázen, forky se množí, obecně na mne působí F23 jako podstatně méně svižná / více zadýchávající se při zátěži – on ten problém skutečně zjevně nebude v MariaDB jako takové ani v replikaci, ale v tom, že ten systém z nějakých důvodů nestíhá.

Možná to ani nebude F23 related problém, ale spíše kernel 4.2/4.3 a/nebo systemd related. Jenže systemd je pro mne pořád tak trochu černá magie, takže netuším, kde/jak/co smysluplně debugovat. Narazil jsem na podobně vypadající problémy na fóru archlinuxu, třeba zde :

https://bugs.archlinux.org/task/47662

Ten problém v mých Fedorách vypadá podobně, ale nasimulovat ten “Resource temporarily available” efekt puštěním tisíc sleep-ů v cyklu se mi nepovedlo reprodukovat. Netuším tedy, zda je ta chyba v systemd (nízký výchozí počet procesů per uživatel) přítomna i ve Fedoře, ergo zda to se vším výše uvedeným souvisí. Samozřejmě jsem vyplnil i bugzillu, ale nevypadá to, že by se tím někdo nějak prudce zaobíral, dost možná i proto, že nejsem schopen vygenerovat relevantnější debug report (protože zkrátka moc netuším, co a kde začít debugovat) :

https://bugzilla.redhat.com/show_bug.cgi?id=1281994

Závěrem ještě podotýkám, že to určitě není HW error nebo HW related záležitost. Naprosto shodné problémy (tedy lagující SQL replikaci a obecně nestandardně přetížený server) pozoruji na několika mašinách – něco je na fyzickém železe s AMD (radeon.ko), něco na nVidia (nouveau.ko), něco na Intelu (vše nicméně běží v multi-user targetu aneb initlevelu 3, takže grafika s tím zřejmě mnoho společného mít nebude), něco v jedné virtuální mašině pod VirtualBoxem … chová se to všude stejně, tedy stejně neradostně.

Nemá čirou náhodou někdo podobnou zkušenost - nemyslím přímo tu lagující replikaci (jak jsem byl výše pravil, to je zřejmě důsledek něčeho jiného, nikoliv příčina jako taková), ale obecně lagující / přetížené F23 instance pod třebas jen průměrnou zátěží na serveru? Chápu samozřejmě, že většina lidí bude mít Fidorku spíš na desktopu a na serverech spíše “rock-solid” RHEL/CentOS … taky to tak mám a na většině firewallů urputně držím RHEL/CentOS 6.X, abych se tam co nejdéle vyhnul systemd, dokud to není nezbytně nutné. Zjevně by asi bylo řešení na ony replikující servery fláknout právě CentOS 6.x, jenže to je zas v kontradikci s požadavkem mít tam co nejnovější Marušku, PHP, a podobně… RHEL má standardně tyhle “piece of SW” v konzervativních starších řadách, což má samozřejmě mnoho logických a dobrých důvodů. Ale…

…únikový workaround je asi udělat RHEL instanci a nějak tam přeportovat či zkompilovat novější balíky, případně pustit souběžnou virtuální instanci s RHEL 6.X jen kvůli té replikaci. To má ale jednak taky svá “ale”, a krom toho bych samozřejmě mnohem raději tu “F23 / kernel 4.3” záhadu úspěšně vyřešil, nejen kvůli replikaci, ale obecně. Není přece rozumný důvod, aby server, který na F21 a 4.1 kernelu běžel jak víno, šel náhle (v téže aplikační konfiguraci a téže zátěži) do kolen. No jo, no, evoluce, já vím :slight_smile:

Problém vyřešen, na vině byl jbd2 journálovací proces a tedy zjevně nějaké změny v driverech (journálu a/nebo ext4) v kernelech 4.2/4.3. Více viz můj comment na bugzille:

https://bugzilla.redhat.com/show_bug.cgi?id=1281994

Muzes zkusit porovnav configy jader, treba neco najdes.