[MEGOLDVA] Hálózati MariaDB teljesítmény és Packet Loss

Linux-haladó

Az egész történet több fizikai gépen elhelyezett XenServerekből (6.2) áll, amelyeken több időszakosan nagy mértékű adatátvitelre van szüksége.

Maga a szolgáltatás UDP alapú, kicsi, de sok csomaggal dolgozik. Példának okáért használjon ez a szolgáltatás 30 000 csomagot, másodpercenként. Ha megemelkedik az igénye az adatbázis használatra akkor a statisztikában a csomagok száma felemelkedhet 70 000 vagy akár jóval több fölé is (ebben az adatbázis forgalma is benne van, ettől emelkedik!), majd hirtelen visszazuhan mondjuk 3-4000-re. Sajnos ez a csomag veszteség a szolgáltatás ideiglenesen instabilitását okozza, amely a nagy mértékű lekérdezéseket követően helyreáll.

Tények:
- A fizikai szerverek adatközpontban vannak gigabites switchen
- A fizikai szerverek gigabites hálózati interfésszel rendelkeznek
- A virtuális gépek paravirtualizált Debian Wheezyk és szintén gigabites interfészt használnak
- Utóbbiakon TSO és egyéb offloading ki lett kapcsolva
- A XenServerek dmesg-jében a következő hibák sorozata látható ilyen packet loss idején: "openvswitch_mod: xenbr0: dropped over-mtu packet: 3074 > 1500", ilyenkor a 3074 változik, de mindig nagyobb természetesen 1500-nál
- Az adatbázis teljesítményével probléma nincsen, helyi lekérdezéssel minden tökéletes.
- Az adatbázis szerverként az egyik XenServeren elhelyezkedő VM szolgál, amely a vele közös fizikai gépen valamint további másik fizikai gépeken lévőkkel való kommunikáció során is produkálja a hibát
- Hálózati interfészként a fizikai hálókártyát használják a VM-ek kizárólag.

Van-e bármi ötlet, illetve javaslat. Írjak-e még részletet?

Várom a válaszokat, köszönöm!

---

UPDATE: Maga a szolgáltatás volt a hibás, ami az adatbázist használta. 100x-os terhelést nyomott rá, a korábbiakhoz képest (minden lekérdezés majdnem ennyiszer ment el...) A packet loss is emiatt volt, mivel a hálózat bírta, mint kiderült (nem érintett más szolgáltatást) csak az adott szolgáltatás laggolt.

Köszönöm a tippeket! Legalább teljes körű körülnézés és optimalizálás volt :)

  • 2318 megtekintés

( andrej_ v | 2014. 11. 30., v – 21:08 )

Ez nekem MTU probléma gyanús. Az konzisztensen be van mindenhol megfelelőre állítva?

( blackluck v | 2014. 11. 30., v – 21:13 )

Azert a 70k+ packet/sec mar sokszor konnyen magas lehet egy gigas halokartyanak, amire meg rajohet a virtualizacio is.
Milyen kartya van benne?
Paravirtualizalt guestekrol van szo?
Host gepen nem latszik esetleg sok system interrupt (pl top-ban egyik magot terheli jelentosen)?

( Szenti v | 2014. 12. 01., h – 16:57 )

Van egy tippem, ami gyakorlati tapasztalatból adódik. Van egy micro instance-on (ez szintén paravirtualizált) futó Ubuntum az Amazonban, amin futtattam egy minimál játék szervert (Jedi Knight 2, ha valakit érdekel :) ). Amikor az egyik bugos játék MOD elkezdte tekerni az egyetlen vCPU-t (értsd: jk2ded processz 99-100% között), akkor játékosként azt tapasztaltam, hogy a ping (játéko belül is, és az ICMP echo is) az egekbe szökkent. A jelenséget sikerült reprodukálni másik CPU zabáló processzel is.

Ebből arra következtettem, hogy paravirtualizált VM esetén el tudja lopni a user módú processz a CPU-t a hálózatkezeléstől(fixme): ha nem jut elég CPU a hálózatkezelésre, akkor a latency is emelkedik. A megoldást valószínűleg HVM guest jelentené, de még nem próbáltam meg.

( Mico v | 2014. 12. 01., h – 21:47 )

Reassembly problémának tűnik, így átugornám azt a részt, hogy a forgalom alapján ez egy komoly dolognak tűnik, ami komoly hardvert és szoftvert érdemelne, nézzük inkább, mi történhet:
Az over-mtu annak az eredménye lesz, hogy nem egymáshoz való UDP csomagok kerültek összeragasztásra és ez nem lett máshol eldroppolva. Azt nem látom, ebben a stackben minek hol kellene történnie, de alapból ez egy 16 bites ID alapján történik, ami ekkora packet rate-nél nudli. Emellett szerintem 10000x annyi packetod eldroppolódik, mint ami így megjelenik, aminek lehet több oka: reassembly buffer tele van, különböző receive bufferek tele vannak, timeout a reassembly bufferben, és ezek okozhatják egymást is: pl. a reassembly buffer azért telik meg, mert wrong assemblyk kezdenek történni, eredeti hozzátartozó csomagoknak így nem lesz "párja" és beragadnak a reassembly bufferben. Vagy (és itt jön be a hardver), eleve azért kezdődnek a wrong reassembly-k, mert a hardver droppol, beleülnek a reassembly bufferbe a csomagok, de soha nem érkezik meg a párjuk, csak másodpercekkel később jön egy azonos ID-vel, de máshova tartozó packet. Ennek a nagy részét hagyományos (netstat, stb) módszerekkel fel lehet deríteni.

Lásd még: RFC 4963 - IPv4 Reassembly Errors at High Data Rates