Jak zatizit server - dlouhodobe testovani stability

Jan Kasprzak kas na fi.muni.cz
Úterý Leden 16 13:51:48 CET 2007


David Kredba wrote:
: Zdravim Vas.
: 
: Jaky software na zatizeni serveru se Vam osvedcil?
: 
: Mam tu  server, ktery je bez zateze stabilni a pri zatezi se mu obcas po
: vypnuti a zapnuti degraduje pole a radic pole zrebuilduje.
: 
: Deska je Intel, chipset 7230, posledni BIOS, radic Adaptec AAR-2420,
: posledni firmware, tri disky od ruznych vyrobcu, write caching na discich
: vypnuty, na radici zapnuty, zalohovano UPS a baterii na radici.
: 
: Chtel bych ty rebuildy provokovat co nejcasteji, abych mohl zkouset najit
: souvislost.
: V jadre mam prelozeny ovladac od Adaptecu, ne distribucni, protoze s
: distribucnim byl server jeste mene stabilni.
: Server bezi na CentOS 4.4, posledni jadro z aktualizaci.

	Hmm, nejde tam treba nastavit nejake postupne zapinani disku?

	Ja jinak mam svuj software - jednak paralelni kompilace jadra
(treba 3-5 kopii zdrojaku, v kazdem v cyklu make clean && make -j 4 bzImage
- podle poctu procesoru a pameti), ten software se diva jestli nektera
kompilace neskoncila s chybou nebo jestli se neodmlcela na prilis dlouho.

	Pak (jako v tvem pripade) kdyz mam spis podezreni na chybu disku,
tak mam software, ktery zkopiruje velky strom adresaru (treba /usr) nekam
jinam, a pak bere original a kopii a dela cmp a vypisuje chyby.

	No a jeste mam neco jako memtest86, ale v user-space. Naalokuju
velke pole a delam s nim ruzne kousky - plneni nulama, jednickama, plneni
daty na preskacku, atd., a pak kontroluju, jestli tam jsou data, ktera tam
cekam.

	Nejvic chyb odhalila kompilace jadra, sem tam neco z toho kopirovani
souboru, ale ten memtest neodhalil nic (vetsinou rychleji spadla kompilace
jadra nebo tak neco).

-Y.

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
> I will never go to meetings again because I think  face to face meetings <
> are the biggest waste of time you can ever have.        --Linus Torvalds <


Další informace o konferenci Linux