LVM overhead

Linux-kezdő

Sziasztok!

Szeretnem valtozatos kornyezetben hasznalni az LVM-et, a problemam a kovetkezo:
Szuksegem lenne olyan informaciora, hogy processzorido szegeny kornyezetben hogyan teljesit az LVM. Gondolom sokan kozuletek hasznalnak bizonyos disztribuciokban vagy akar tesztre LVM alapu particiokat.
Erdekelne, hogy mikor egy CPU van a gepben, illetve osztott csatornas (IDE-ATA) vagy barmi mas lokalis taroloegysegen hasznaljatok, akkor mekkora lassulast lehet elkonyvelni az LVM-nek?
Regi szamitogepeken(p3) hasznalva nekem ez a plusz teljesitmeny igeny nagynak tunt(~20%-40%). Viszont mas kornyezetben (iSCSI, FC) illetve erossebb processzorok eseten teljesen eltunik az overhead(<1%). (nem talaltam ra ertelmes magyarazatot az lvm forras nezegetes utan sem)
Direkt alapbeallitott read-ahead beallitasokkal probalkoztam minden esetben.
Ha esetleg valaki hasznal otthon ilyet, es hajlando megosztani tapasztalatait azt szivesen varom.

  • 1196 megtekintés

( turul16 v | 2008. 09. 15., h – 09:39 )

Hogyan merted 20-40% -ot ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( XMI | 2008. 09. 15., h – 11:59 )

Direkt alapbeallitott read-ahead beallitasokkal probalkoztam minden esetben.
Pedig de! Az lvm lassú teljesítményének pont a túl kicsi readahead szokott a fő oka lenni. A másik amit érdemes megnézni, hogy a fizikai eszközöd milyen i/o ütemezőt használ, néhány kivételtől eltekintve a deadline szokott a legjobb lenni.

Szvsz ami te tapasztaltál annak az lehet az oka, hogy az iSCSI vagy FC eszköz eleve többet pufferel, illetve működőképes tagged command queueing megvalósítással bír ezért nincs szükség nagy readaheadre. PATA eszközöknél a TCQ/NCQ alapból le van tiltva, mert a rossz designból adódoan adatvesztést okozhat. A nagy CPU terhelés jelentős része pedig szerintem iowait, tehát nem függ különösebben a CPU teljesítményétől.

Egyébként nem hülyeség lokálisan dd-vel vagy a bonnie++ csomagból a zcav toollal vizsgálni, mert így el tudod különíteni, hogy a hálózati rész vagy a lokális eszközkezelés-e a szűk keresztmetszetet.
---
Linux is bad juju.

En ertem, de nem a problemamra keresem a megoldast, hanem tapasztalatok erdekelnenek. Az, hogy azt hogyan valtoztassuk idealissa az a kovetkezo lepes.
A legtobb disztro lvm setup install lehetoseggel jon. Ezert gondoltam vannak tapasztalatok.
Abbol a szempontbol nincs ertelme, hogy nem hasznos felhasznallas es nativ kornyezetben benchmark es hibakereses kivetelevel nincs ra szukseg, abban remenykedtem, hogy jon rengeteg cafolo, illetve megerosito post.
Igy viszont, hogy problemamegoldo postok jonnek gondolom ritka ilyen kornyezetben az lvm.

Akkor tapasztalat:

- RAID-5, 4 x SATA 500GB, Intel 965P chipset, core2 duo 1.8GHz
- RAID-1, 2 x SATA 80GB, ugyanebben a gépben

A RAID-5-ös tömbön az LVM kb 100MB/s-et tudott lokálisan, míg a tömb natúran ~240MB/s-et. Közben a vinyók hallhatóan keményen seekeltek, pedig szekvenciális transzfernél ilyet nem illene nekik. Megemeltem a logikai kötet readahead értékét 256-ról 2048-ra (mérések alapján ez jött ki legjobbnak), így már az logikai kötet is 240MB/s-et tudott.

A RAID-1-es tömb esetén viszont semmit nem kellett csinálni, ott teljesen jó volt a default 256-os érték is.

Az ok talán az lehet, hogy a raid-1 párhuzamosítani tudja az olvasás műveleteket a két tükör között, így ezzel meg lehet úszni a felesleges seekelést.

A CPU nem volt korlátozó tényező egyik esetben sem, szekvenciális transzfernél alig mutat valami terhelést (~10% az egyik magon), random hozzáférésnél az iowait érték magas (60-70%, de ez gyakorlatilag üresjárat a processzornak). iSCSI target fut a gépen pár példányban, gigabit ethernettel kb 80-90MB/s-re hajtható ki (Persze ehhez azért kellett kicsit kézzel tuningolni az ietd.conf-ot is, főleg a threadek számával érdemes játszani. Nagy thread számnál jön különösen elő az lvm readahead beállítás hatása.)

Ezen kívül többnyire virtuális gépekben használtam lvm-et, mert így szükség esetén egyszerűbb növelni a virtuális diszk méretet, ott viszont a teljesítmény eleve nem annyira kritikus, hogy méregessem, illetve komoly energiát fektessek az optimalizálásba.

---
Linux is bad juju.

( turul16 v | 2008. 09. 16., k – 10:43 )

latencytop -ot nezted ?
(oprifile is jol johet)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.