[LUGOS] promise raid sx6000

Metod Kozelj metod.kozelj at lugos.si
Tue Jul 15 11:44:41 CEST 2003


Howdy!

>po celovecernem matranju se strinjam, da bom poskusil pospravljati buffer 
>bolj pogosto. Zanima me, zakaj bi laufal update daemon, ce ze laufa nek 
>[kupdated] in [kbsflush]. A se njima da nastaviti kaksen parameter? 
>

Tale imena so rahlo nedeskriptivna in iz njih clovek ne more direktno 
sklepati na funkcionalnost. Bi pa rekel, da je tudi tale 'userland' 
daemon kar uporabna stvar, ce ima pid 5. Bi rekel, da je to v bistvu 
kernel thread in ne samostojen proces. Cisto mozno je, da je vsebina 
tiste man strani malo stara in da je to v bistvu samo program, ki ta 
kernel thread obudi v zivljenje in mu opcijsko poda se kaksen parameter.

>ps. a te lahko prosim, za tvoje nastavitve update v inittabu?
>

Kompletna vrstica je takale:

# Things to run in every runlevel.
ud::once:/sbin/update

Torej brez kaksnih parametrov.

Ti bi lahko update poganjal recimo s parametrom '-f 1' ali pa celo '-s 
2'. V tem primeru (predvsem v zadnjem) bi bila 'zamrzovanja' pogostejsa 
(vsako sekundo ali 2), vendar pa takrat bistveno krajsa (in s tem manj 
moteca).


Ce pa se vrnemo nazaj k osnovnemu problemu: nekaj o pasteh igranja s 
parametri za diske ti je zapisal ze Uros. Res ni, da bi clovek pri 
nastavitvah pretiraval. V najslabsem primeru ti bo sla vsebina diskov 
rakom zvizgat.
Druga tezava je 'write performance' tvojih diskov. Sem pozabil, ali jih 
imas v kaksnem raidu ali ne. So pa moje izkusnje z raznimi 'resnimi' 
RAIDi (iz SCSI diskov) taksne, da je performans celotnega raida nekoliko 
slabsi, kot performance posameznih diskov (overhead procesiranja). No, 
to je seveda odvisno od tipa RAIDa (mislim si, da bi RAID-1 - mirroring 
- znal pri branju v celoti gledano biti celo malenkost hitrejsi od 
svojih komponent).

In tretja tezava je kolicina podatkov, ki jih trpas na diske. Od tod 
sledi neodzivnost. V normalnem delovanju je obicajno kolicina podatkov 
za pisanje nekajkrat manjsa od podatkov za branje in te neodzivnosti ne 
opazis (prepogosto). Edini 'nenormalni' primer, kjer tudi pri normalni 
rabi tvoja tezava nastopa stalno, je kaksen zajem videa. Ampak tiste 
primere je bolje resevati s hardverom malo visjega razreda (IDE ali SCSI 
diski, ki so namenjeni za streaming, kontrolerji, ki to ime tudi 
zasluzijo, ...).
Ce pa imas tele probleme na serverju in je normalno, da tocis velike 
kolicine nanj (in jih potem tudi brises; pri 10MB/s napolnis spodobno 
velike diske (=250GB) prej kot v enem 8-urnem sihtu), pa je resitev 
uporaba SCSI diskov.

-- 
Peace!
  Mkx

---- perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'





More information about the lugos-list mailing list