Stressz teszt idő intervallum

 ( mauser1 | 2016. január 14., csütörtök - 20:06 )

Sziasztok!

Kérdesem a következő telepitettem egy debian alapú xen szervert.
stress-ng programot használnék.
Mennyi az ideális idő, meddig fusson fullon?
10s , 1h vagy akár futthat károsodás nélkül a gép egy napig is 100%-on?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem gondolom, hogy 15,2 s vagy hasonló konkrét válasz adható a kérdésedre.

A tesztelés hossza annak céljától függ általában.

Teljesítmény teszt esetén a cél a maximális hibátlan válasz / időintervallum megtalása a cél, hogy tudd méretezni a terheléselosztást, egyebet.

Ha egy kicsit több erőforrást szánunk tesztre, szokás SOAK tesztet végezni (https://en.wikipedia.org/wiki/Soak_testing). Nem tudom, mi a magyar neve. Ennek lényege, hogy az éles üzemi körülményeket szimulálja napokon, heteken keresztül. Így olyan problémák jöhetnek elő, amelyek rövid tesztelésnél nem.

Ha stressz tesztelni akarod, akkor a meghibásodásokat, nem jellemző működés esetén felmerülő lehetőségeket próbálod ki. Ennek időtartama az előidézett állapottól függ.

Általánosságban elmondható:
- Egy mérés nem mérés
- Ha a 100%-on használt rendszer ettől meghibásodik, akkor örülj, hogy a tesztelés során előjött a probléma.

Remélem tudtam segíteni

Igen tudtál köszi,
"a meghibásodásokat, nem jellemző működés esetén felmerülő lehetőségeket próbálod ki."
erre van szükségem.

Ha 100%-on teker a CPu az nagyon, jo mert azt jelenti szamol. De ez vajon user vagy sys vagy io? Mit szeretnel merni?
Ha a memoriat terheled folyamatojan 100%-ra az mit jelent? Mit mersz? Active memoriat, vagy a chache hasznalatat? Mire vagy kivancsi?

Es igy tovabb. Meg minek a stress teszt? Lehet hogy teszteled mittom 1000TPS-el, de a valosagban csak 5 TPS lesz (akarmit is jelentsen ez nalad), vagy 5000 (ebben az esetben az 1000 TPS-es teszteddel ki is lehet ugye torolni).

Es igy tovabb. De mar az elottem szolo is ezt kapargatta.

http://www.cyberciti.biz/faq/stress-test-linux-unix-server-with-stress-ng/
ből indulok ki , ebből ugy tünik a fontosabb rendszer elemeket leteszteli
stress-ng --all 10 -timeout 30m

Ok: "örökölt gép" -> vmi miatt leállt, nem indult -> elinditottam eddig jó, de szeretném látni nagyobb teljesítmény alatt is, hátha akkor kiugrik az előző hiba oka. (diagnosztikai programok mindent rendben találtak)

Valmi miatt leallt. Megnezted a logokat, hogy miert es ugy gondoltad, hogy nincs eleg kraft benne? Mert azert nem nagyon szoktak leallni a gepek. Meg nem nagyon szoktam nem elindulni.
Es mit fogsz leszurni a sress-testbol, hogy azt birja? Es addig fogod probalni mig ki nem akasztod ugy, hogy megalljon? Es akkor azt mondod majd hogy hat ilyen terheles mellett fog megallni?

Meg mindig nem ertem mi ertelme ebben az esetben a stress-testnek. De tenyleg.

Első körben egy kövér memtest-et neki. Ha valamilyen brandebb gép, akkor lesz neki vmi management felülete is. Ha ilyened nincs, akkor tippmixes picit a dolog.

Ha a memtesten jó, akkor több VM-ben vmi cpu tekerő cucc (pl. boinc) és másik VM-ekben meg bonnie, hogy a diskio-t is hajtsad. Egyébként ha hw probléma, akkor elsőre a táp körül nézelődnék.

En elsore a logokat neznem meg, de a tobbiben geyetértunk.

Azon azért már illik túl lenni, ha a hw-re gyanakszol. :)

Szerk: egy hozzászólásból kiderült, hogy egyszercsak leállt/újraindult és olyankor nem túl sok log szokott keletkezni.

Azert ez nem szokott csak ugy bekovetkezni. Ha ilyesmi elofordul, akkor a logokbol az alabbiak szoktak latszani:
- valami futott es dobalta is magarol, hogy mingya megpurnyad
- jo kis segfaultok mindenfele
- semmi kulonos, valami kozepen megallt a log, a kovetkezo uzenet az ujrainditasrol szol

Az elso esetben ki kellene deriteni miert olte meg az alkalmazas a gepet, mi az hogy megallt, mi van ha csak 3000-es load volt rajta?
A masodik esetben gyanakodnek valamilyen hw elem bajara, vagy hibas driverre
A harmadik esetben eros a gyanum egy tuskere a betapban

Es akkor most csak a harom legnyilvanvalobb dolgot mondtam, ami eszembe jutott. Aztan ott van meg ezer masik dolog az oom-killertol kezdve, barmi.

Azt sem specifikaltuk itt, hogy mit jelent az hogy megallt. A gep maga? A szolgaltatas? Nem volt elerheto?

De ott a sar is, amit meg lehet nezni, stb, stb. Iszonyat sok minden kiderulhet a logokbol vagy csak abbol, hogy milyen a karakterisztikaja a logoknak. Lasd fenti harmadik esetet.

En biztos ott kezdenem a keresest, de persze neki lehet esni stresstestelgetni, csak minek, ha mondjuk a Xen halt meg, akkor a Xen belet kellene kihajtani, mert valoszinuleg a Linux maga nagyon jol fogja kezelni a CPU tekerest es a memoria cseszegetest is. De hat azt csinal a tulajdonos amit akar a gepevel. :D

+1 boinc. Egyrészt hasznos, másrészt ha futás közben nem is történik észrevehető hiba, az eredmény érvényesítésénél kibukik a probléma.

Kösz Mem teszt természetesen megvolt, a blade diagnosztikája is mindent rendben talált, ahogy már fentebb is emlitettem, és igen első dolgom az volt Live ről bootoltam , és at nézegettem a logokat benn -> legutolsó bejegyzés egy syscrtd SIGNAL 15 volt (ha jól emlékszem a számra).
bonnie++ ,jónak, és egyszerünek tünik.
bonic-ről igy első megtekintére ezt nem mondanám, de megpróbálom a legtöbbet kihozni belőlük.