adatbázis szerver, context switch, mit tegyek?

Linux-haladó

Sziasztok,

Van nekünk egy eléggé túlterhelt adatbázisszerverünk (Firebird), ami nagy terhelésnél (100-150 kliens) eléggé belassul.
A terhelés viszonylag gyakori egyszerű select/insert/update kis (tízezer, max. százezer rekord) táblákon, insert néhány nagy böszme (log) táblába, és ritkán bonyolultabb, subquery-s, join-os select-ek a kicsi és a nagy táblákon (statisztika).
Nyilván lehetne a query-ket, indexeken reszelni, de most a Linux konfigolásáról kérdeznék.

A vas: HP szerver, 2x dualcore xeon (core), 4G RAM, 8x36g 10k RPM sas, RAID10, Etch, firebird
Munin fut rajta, és összehasonlítottam 2 másik szerverünkkel. Ami igazán durva volt (szerintem) az két dolog:
process fork rate: max. 10/sec, a többi szerveren ez 2
context switch: átlag 20k, peak 100k az adatbázison, a többi szerveren peak 5k-7k, átlag 500-1k
interrupts: átlag 1000/s, peak 3k. Nap közben inkább a peak közelében van. Itt láttam, hogy egy interrupt-on van a raid vezérlő, az eth0, illetve két nem használt usb. A többi szerveren külön vannak, és nincs is ekkora terhelés átlagosan (a peak az megvan).

A többi látszólag rendben van, max 1.6-os load, cpu-ból 70% system és 100% user, 2% iowait (peak, a munin a 4 core-t 400%-nak méri), nem swap-el, memória nagyja cache, átlag max 100 process.

A CPU ütemező a szerverekhez ajánlott 100/sec-re van állítva, viszont mi Firebird-ből a Classic server-t használjuk, ami minden connection-höz csinál egy külön processzt.
Az jutott eszembe, hogy segítene-e szerintetek, ha ezt 500-ra vagy 1000-re állítanánk, ami ugyan desktop-ra javasolt, viszont szerintem jobban passzolna ehhez a terheléshez.
Másik: segíthetne-e, ha külön interrupt-ra raknánk a leginkább terhelt raid vezérlőt és hálókártyát?

Szeretném a véleményeteket, segítségeteket kérni ezekben a konkrét témákban, illetve általánosan Linux adatbázis szerver tuningolás témájában is.

kösz előre is,
x

  • 1893 megtekintés

( zwei | 2007. 11. 15., cs – 14:42 )

Másik: segíthetne-e, ha külön interrupt-ra raknánk a leginkább terhelt raid vezérlőt és hálókártyát?

Érdemes megpróbálni.

context switch: átlag 20k, peak 100k
Ez nagyon sok.
A context switch az voluntary, vagy involuntary?
Ha voluntary, akkor nézd meg a mutexek számát, mert lehet, hogy lockolási probléma van.

Nem ismerem a kérdéses adatbázist, de akár az is lehet, hogy túl sok thread-ot akar használni a 4 processzorhoz képest. (2xdualcore az oprendszer szempontjából 4CPU)

Az jutott eszembe, hogy segítene-e szerintetek, ha ezt 500-ra vagy 1000-re állítanánk
Ezzel valószínűleg csak nőni fog a context switch szám. (Főleg, ha involuntary context switchek vannak túlsúlyban)

Az a 70%-os system time is soknak tűnik nekem, bár ez lehet a magas context-switch miatt is...

( uid_1062 | 2007. 11. 15., cs – 14:36 )

IRQ oldalarol a halozati vezerlon sokat tud segiteni a NAPI bekapcsolasa, mar ha a driver/kartya tud ilyet.

( zwei | 2007. 11. 15., cs – 15:10 )

A CPU ütemező a szerverekhez ajánlott 100/sec-re van állítva .....Az jutott eszembe, hogy segítene-e szerintetek, ha ezt 500-ra vagy 1000-re állítanánk, ami ugyan desktop-ra javasolt, viszont szerintem jobban passzolna ehhez a terheléshez.

No akkor egy kis elmélet:

Ha egy processz futás alatt az ütemező ciklusidején belül lemond a processzorhasználatról (pl. elmegy aludni - sleep) azt hívják voluntary context switch-nek.

Ha kitölti a teljes ciklusidőt és az ütemező megszakítja a futását, (vagy bármi egyéb miatt erőszakkal lekerül a processzorról) az az involuntary context switch.

A 100/sec es felbontás jóval nagyobb (pontosan ötször), mint az 500/sec.
Vagyis első esetben 1/100 másodperc egy ciklus az ütemezőben, a második esetben 1/500.
Ha magas az involuntary context switchek száma, és 500/sec -re állítod a felbontást, vagyis kisebb lesz az ütemező ciklusideje, akkor még kevesebb időszelet jut egyszerre egy processznek, vagyis gyakrabban le fogja venni az ütemező a processzorról.

Magas context switch számot egyébként a magas interrupt-szám is okoz. (Az interrupt kiszolgálása az adott processzoron context-switchet generál.) A fenti esetben egyébként nekem nem tűnik túl soknak az interrupt szám, és nem is indokol akkora nagyságú context-switchet.

Mennyi a a system-call szám, illetve a mutexek száma?

Kizárásos alapon a nagyja voluntary (kösz a leírást, mert nem értettem), mivel a 20k-ból 3k az interrupt, 4 mag és 100 váltás /mag az 400, ebből gondolom.

Nem feltétlenül, sőt ..
Inv. context switchet nem kizárólag csak interruptok okoznak, sőt általában azok okozzák a legkevesebbet. (Ráadásul az interruptoknak is van több fajtája.)
Őszintén szólva nem tudom linux alatt hogy lehet megnézni a syscall és mutex számot, Solaris-on erre az mpstat parancs való, de a linuxos mpstat parancs ezeket nem mutatja.
(mutexek helyett van más lockolási módszer is, igazából nem nagyon tudom hogy a linux mit használ...)