Dotaz: snmp zveda load

[snmp]

Ahoj, mel bych dotaz pouzivame nagios plugin check_snmp_int.pl, pri jeho nasazeni nam vzrostl na serveru load a jeho hodnota je kolem 7 pri 4 cpu.

Vsechny CPU jsou z cca 50% idle, diky se taky flakaji. Predpokladam ze bottlecneck bude sit. Muzete prosim poradit jak udelat troubleshooting? Pripadne jakym nastrojem a jakou podezrelou hodnotu hledat?

Diky

---

---

Odpovědi

[X]

Load ceho?

[snmp]

serveru na kterem ten plugin spoustime

[NN]

Jasne, ale load ceho? Site, pameti, disku, nebo CPU?

[snmp]

Mluvim o load average - prvni radek v topu uplne v pravo.

- Vsechny CPU jsou vice mene stejne idle okolo 50%.
- Available RAM je dost - odswapovano je 0.
- iostat ukazeje u disku %util mezi 0.2% - 0.38%. Vidim sice nejakou hodnotu ve await a w_await, ale je to okolo 0.5, takze myslim ze disky nejsou problem.

Takze co zbyva? Sit? Co vsechno se da zkontrolovat? Jestli kernel droppuje packety? Muze navazat dostatek tcp spojeni? Propustnost? Ta sit je trosku komplexnejsi tema.

[Peter Golis]

A v tomm TOPe sa zobrazuje čo pod tou bielou čiarou?

Tam by mohol byť schovaný proces ktorý vyťažuje zbernicu tak, že z polovice čaká na dáta z nejakej prispatej periférie.

[snmp]

Ahoj, stridaji se tam v podstate tyto processy.

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 7799 icinga    20   0 1837828 175216   7140 S  16.6  4.5  87:31.03 icinga2
 1257 icinga    20   0  483240   2796    936 S   4.3  0.1  28:21.61 icinga2
 4298 icinga    25   5  149484  11964   2368 S   3.0  0.3   0:00.09 check_snmp_int.
 4305 icinga    25   5  149352  11964   2368 S   3.0  0.3   0:00.09 check_snmp_int.
 1044 root      20   0   27292   1188    848 S   2.6  0.0  20:26.93 xinetd

Myslim, ze to dela prave ten check_snmp_int.pl, protoze kdyz jsme v icinge vypnuli tento check, tak load sel dolu. Navic na jinem satelitu tento check nemame a load je v pohode.

Vytizeni sbernice. Jak se to da prosim zkontrolovat?

[tttttt]

Tohle vypadá, že icinga2 vytíží jedno jádro procesoru. Problém bude spíš na příjmu, než v tom skriptu, který to odesílá.

Nedávno jsem odstraňoval několik miliónu souborů pojmenovaných "perfdata*" z jednoho adresáře, které icinga vygenerovala. Můžeš se podívat, jestli tam nemáš něco podobného.

[snmp]

Diky za tip, kouknu se.

Ja sleduji jak prumernou hodnotu vyuziti CPU, tak pak jeste kazde CPU zvlast, prave pro pripad jedno threadovych aplikaci. Vsechny jsou vicemene z poloviny idle.

Myslim ze je to ten script, protoze jsme na masteru vypnuli check, ktery jej pouziva a vsechny ostatni nechali zapnute a load hezky spadnul dolu.

[ttttttttt]

To pořád může znamenat, že skript je v pořádku a icinga má problém se zpracováním výstupu toho skriptu. Ty skripty, které posílají data do nagiosu (icingy), se často dají ladit ručně. Bude to nějaká verze podobná http://nagios.manubulon.com/check_snmp_int.pl, můžeš tam případně přidat výpisy a koukat, co dělá.

[snmp]

Ja teda souhlasim, ze ten script bude asi svym zpusobem ok - co jsem koukal na ruzna fora, tak to vypada, ze jej pouzivaji mraky lidi.

icinga má problém se zpracováním výstupu toho skriptu Ok, ale jak je toto mozne debugovat?

Ja mam porad podezreni, ze to drhne na strane site, ale nejsem schopny to nejak rozumne prokazat... Koukal jsem na pocet droppnutych packetu a nema narustajici tendenci. Koukal jsem jestli nemam nejak velky pocet TCP spojeni ve stavu SYN_RECV, ale je to v prumeru stejne cislo, jako na druhem satelitu, ktery nemam zvyseny load.

[ET]

mno a nechces to teda spustit z radky, jak pise predrecnik (s parametrama, s kteryma to vola icingaa idealne s time) a postnout vystup?

[snmp]

Jasne, tady to je.

[root@satelite plugins]# time /usr/lib64/nagios/plugins/check_snmp_int.pl -2 -B -C public -H 10.11.11.11 -S -Y -c 51200,51200 -d 90 -e -f -k -n ether1 -t 5 -w 40960,40960
ether1:UP (426.1Kbps/170.7Kbps):1 UP: OK | 'ether1_in_bps'=426052;40960000;51200000;0;1000000000 'ether1_out_bps'=170652;40960000;51200000;0;1000000000 'ether1_in_error'=0c 'ether1_in_discard'=0c 'ether1_out_error'=0c 'ether1_out_discard'=0c 'ether1_speed_bps'=1000000000

real    0m0.172s
user    0m0.062s
sys     0m0.012s

Vtipne je, ze load pred vikendem spadnul do nejakeho normalu a drzi se tam do ted.

Takze ze by nakonec problem se siti? Ze by treba ten check bezel delsi dobu, protoze sit mela nejake problemy?

[snmp]

Moc nerozumim, proc byl dotaz oznacen za vyreseny :)

[j]

To je easy, prijde mamlas, vylosuje libovolnej post, a prohlasi o nem ze resi problem, ackoli to v 99% pripadu tady neni pravda.

Jinak krome dalsich veci zkus redukovat frekvenci odesilani udaju, ztratis tim sice podrobnosti ale tvuj problem by to melo taky omezit. Ony tyhle sledovace jsou totiz schopny ten server velmi rychle vysat do mrte, staci na to doslova par stroju u kterych sledujes vic ukazatelu, a server prestava stihat hodnoty zapisovat. Problem se jeste nasobi tim, pokud s tema hodnotama rovnou provadis nejakej vypocet.

Nekdy je vyhodny si napsat i vlastni scripty, protoze ty defaulni veci pak fungujou jako ten kanon, ty chces 1-2 hodnoty, ale ono to ve skutecnosti zpracovava 100.

---

Dete s tim guuglem dopice!

[snmp]

Jasne, vice mene souhlasim.

Ony tyhle sledovace jsou totiz schopny ten server velmi rychle vysat do mrte, staci na to doslova par stroju u kterych sledujes vic ukazatelu, a server prestava stihat hodnoty zapisovat. Nechci slovickarit. Myslel jsi zapisovani na disk? To se podle me nedeje, taky bych videl narust hodnoty wait v iostat.

Ale mozna drhne nejak komunikace mezi procesy? Pokud ano, je to mozne nekde vycist?