Nagyon magas load fájlműveletek esetén + IPv6 bridge

Linux-haladó

Sziasztok!

Olyan problémám van, hogy van a hetznernél egy szerverem, szoftveres RAID 1 van rajta. Ha valamilyen komolyabb fájlműveletet végzek (pl. a mai nap lefoglaltam 50 giga helyet a VPS-nek, vagy letöröltem egy 28 gigás fájlt vagy kicsomagolok valami nagyobb fájlt), nagyon felszökken a load (12-13 körüli értékre). Ez vajon mitől lehet? Sokszor használhatatlan a szerver ez esetben

A másik kérdésem pedig, hogy interfaces fájlom ezt tartalmazza és egyszerűen nem működik az IPv6, mit hogyan kellene csinálnom, hogy működjön és pár címet tudjak adni a VPS-nek?

Előre is köszönöm a segítségeteket!

  • 1707 megtekintés

( wyx v | 2011. 11. 01., k – 06:57 )

a filemuvelet megeszi a hostot..attol fuggoen...milyen stotqge van mogotte...

( meroksz | 2011. 11. 01., k – 08:19 )

Szia

A magas load jogos lehet. Megeszi a diszk alrendszeredet az hogy kiirja a 50 gigát. Amig az 50G-t irod a diszkre addig más folyamatok elöl elzabálja a I/O-t így többi folyamat vár arra hogy neki is jusson esetleg I/O művelet.

Magas load esetén a top-al nézd meg hogy mi is az ami felzabálja a erőforrásokat, szerintem a "wa" lesz a magas
Igy fest a laposom most :
Cpu(s): 12.4%us, 2.3%sy, 0.0%ni, 85.0%id, 0.2%wa, 0.0%hi, 0.1%si, 0.0%st.

Megoldás az lehet hogy
1) adott folyamat prioritását átállítod hogy a kiszolgálás ne akadjon meg, a kernel majd csak akkor foglalkozik a folyamattal, ha más nem várakozik.
2) költséges de a virtuális gépek storage pool-ját tedd külön raid-re (azért is jó mert ha a VM megörülne és elkezdene nagyon swap-olni vagy bármi ami az I/O-t eszi, akkor a kiszolgáló környezet szintén nem fog meghalni, mert másik diszk rendszeren van, azon meg nem lesz I/O wait)

Virtuális gépnél esetleg ne prallokálj le mindent, bár ezt az utat csak teszt gépek esetében használom én is.

Fontos dolgot kifelejtettem

load : az éppen most végrehajtótt, és végrehjtásra várakozó folyamatok száma. 1 folyamat megfogja a diszket, akkor a többi csak áll és vár,vár,vár hogy neki is jusson diszk művelet, így szépen szaporodik a váró folyamat, amivel nő is a load

Amit észrevettem, hogyha törlök akkor a wa felmegy 15%-ra, de előbb tesztből kicsomagoltam egy 20 gigás fájlt és felment 50-60%-ra a wa + még azt is csinálta, hogy "akadozottan" csomagolta ki pedig hasonló méretű fájlok voltak benne. Amikor kicsomagolta, akkor minden okés volt, de volt olyan, hogy megállt a kicsomagolás várt egy picit és folytatta.

Ez a meg meg "akadás" tipikusan olyan eset hogy a RAM-ból a cache-t üríti.

Ugye a file műveletek úgy gyorsítja az oprendszer hogy a file elöször egy cache-be kerül amit a RAM-ba tárol. De mivel a RAM-od nem végtelen nagy, ezért a cache betelik, és azt ki kell írni a diszkre, ekkor megakadást vehet észre az ember. Akkor ez egy ilyen működés, ha kissebb állományokról van szó néhány 10 mega RAM tól függöen néhány 100 meg akkor nagyon jó. Kiadsz egy műveletet,tök gyorsan kész, dolgozol tovább, a háttérben meg közben a lassabb diszk-re megy a láthatatlan kiirás.

free -m parancsal megában láthatod a RAM-od állapotát cache meg buffe kijelzéssel
sync parancsal pedig ki erőszakolhatod a folyamatban lévő műveletek befelyezését.

Neked a gondot a karcsú diszk alrendszer okozza. Ha combos a proci, és sok ram-od van attól a szervered lehet nagyon ramaty, ha lassú a diszk alrendszer. RAID-nél is meg kell gondolni hogy milyet építesz, RAID1-et mellőzném a helyedbe, ha corei7-re össze tudtad szedni akkor szerezz be még 6db 300G-s diszket, építs belölle RAID6-ot. Rejtett hibát is elvisel, sebességet is produkál,ill szeparálja a rendszertől a nagy disk I/O-t (Ez persze még mindig nem a tuti megoldás, de azzal kel főzni ami van)

( xclusiv v | 2011. 11. 02., sze – 19:20 )

Az IO lesz a szűk keresztmetszet, de a filesystem is érdekes dolog. Ext3 pl. baromi lassan töröl, ext4 sokkal gyorsabb ebben (is), viszont nem annyira mature. FS tuninggal is el lehet játszani, relatime, noatime, ilyenek.

Illetve a FS/raid/hdd sector size se árt, ha szinkronban van.

Illetve a disk scheduler (elevator) is érdekes lehet, a deadline jobb throughput-ban, viszont (úgy tudom, hogy csak) cfq-val működik az ionice, szóval a low prio dolgokat (50g helyfoglalás, 28g törlés) el tudod indítani ionice-al idle-ben, és akkor (elvileg) akkor fog ezzel pöcsölni, ha másnak nem kell az io. Én böhöm tömörítést úgy indítok, hogy sudo nice -n 19 ionice -c 3 tar..., így egészen reszponzív marad a rendszer.

( vl v | 2011. 11. 02., sze – 20:18 )

/usr/src/linux/Documentation/block/switching-sched.txt

cat /sys/block/[hs]d?/queue/scheduler

noop [deadline] cfq
noop [deadline] cfq

ha nálad nem a deadline a kiválasztott, akkor állítsd át deadline-ra.

a) megoldás: kernel fordításkor:

CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_IOSCHED="deadline"

b) megoldás: kernel paraméterként (pl. grub.conf-ban):

elevator=deadline

c) megoldás: minden bootolás után:

echo deadline > /sys/block/[hs]d?/queue/scheduler

Persze ehhez az kell, hogy a kernelbe bele legyen fordítva a deadline scheduler.

A tapasztalataim szerint mind a cfq, de különösen az anticipatory schedulerhez képest látványosan barátságosabb lesz a deadline scheduler.