Lapozás és lemezműveletek használhatatlanná teszik a gépet

Linux-haladó

Üdv!

Egy nagyon negatív linuxos tapasztalatomról szeretnék beszámolni nektek. Igazából nem vagyok biztos abban, hogy ez kifejezetten linuxos, ritkán jutok más operációs rendszer elé, de az emlékezetem szerint windows alatt annó nem volt *ennyire* rossz a helyzet.

Picit nem összeszedett post ez, mert sietek, és mert elment egy csomó munkaidőm az imént, és ideges vagyok

Ha valami komolyabb lemezműveletet csinál a gépem, például nekiáll lapozni, mert betelt a memória, vagy csomagokat telepít, akkor kb használhatatlanná válik a gép.

Az imént picit túl sok mindent sikerült elindítanom, és kb 15-20 percig szó szerint semmit nem tudtam csinálni a gépemmel. A vinyó pörgött, a gui nem reagált semmire, még az egérkurzor is szaggatott. SSH-val próbáltam belenyúlni a gépbe, és kilőni a memóriaigényes folyamatokat, de 10 perc nem volt elég, hogy egy parancssort kapjak. Nem vagyok egy átlag felhasználó, épp a harmadik virtuális gépemet próbáltam elindítani (3 különböző IE-n tesztelek, három "tiszta" környezetben), de a három összesen nem eszik 2.5 giga ramot (4 van összesen), ráadásul nem nagyon csináltak semmit, nem kellene akadályozniuk a rendszerem működését.

Eközben zenét hallgattam volna, de az előbb szaggatni kezdett, majd percekre leállt. Hogy tud valami olyan agresszíven erőforrást lopni, hogy egy jelentéktelen zenelejátszás is megakad? Hogy lehet, hogy a merevlemezműveletek (amikor a vinyó teker, de a gépnek nem nagyon kell gondolkodni, pl másolás) a procit terhelik? Főleg: hogy lehet, hogy ennyire terhelik?

Nagyon régi problémám ez, korábban a lassú gépemnek tudtam be ezt a fajta működést, de most az új gépemmel nem lehet ez a kifogás (intel i5 mittoménmennyi otthon, i3 munkahelyen).

Tudom, hogy itt a schedulerekkel van valami nyűg, de ez nem annyira az én témám, örülnék valami felvilágosításnak, vagy tippnek, hogy lehet optimalizálni a gépemet, hogy még nagy terhelés mellett is használhatóak (persze lassabbak) legyenek a kis alkalmazások.

( kaltsi | 2011. 03. 21., h – 12:10 )

Logokat nézted?
Egy free kimenetet dobhatnál, vagy top pár sorát.
Egy df -h sem lenne rossz kezdetnek.

Így okozhatja bármi.

Az a baj, hogy ez nem egyedi és nem gépfüggő eset. Volt két laptopom, most van egy izmosabb gépem, és egy nem annyira izmos, de elég erős munkahelyi gépem, ami mind produkálja ezt a viselkedést.

Kimeneteket most nem nagyon tudok nyomni, mert azóta már indítottam újra a gépet. df-re: 130 giga szabad helyem van 500-ból, szóval az nem lehet gond, hogy túl tele van a vinyó.

Nem igazán keresem az okozóját a dolognak, mert tudom mi okozza. Mindig az amit épp csinálok. Ha tömörítek akkor az, ha virtualboxban telepít a gép akkor az, ha elfogyásközelbe kerül a memóriám, akkor az intenzív lapozás.

( xclusiv v | 2011. 03. 21., h – 12:20 )

1. Ha elfogy a memória, akkor swap-pelni fog -> RAM helyett disk-et használ, ami több nagyságrenddel lassabb -> vegyél még ram-ot
2. Ha sok minden öli egyszerre a disk-et, akkor szerencsétlen ideje nagy részében seek-el, ezen _valamennyit_ segít az elevator (i/o scheduler) csere (cfq -> deadline), de még többet az, ha ssd-t használsz -> vegyél ssd-t, vagy tegyél alá rendesebb raid tömböt (raid5 vagy raid10)
3. Három virtuális környezetnek baromi sok a 2,5 giga, nálam virtualbox-ban xp 384 megával elketyegett, azon elfut az ie6-7-8
4. Ez nem procifüggő, beleteheted a legdurvább i7-et is, akkor is baromi lassú lesz, ha elfogy a memória és baromi sok az iowait (vagyis a proci által futtatott process _vár_ a disk io-ra)
5. ja, és mindez OS független, tehát a windows is beledöglik, csak nem úgyanígy

1) 2) tudom, és sejtem hogy ez a hiba, de miért van így? egy usernek szánt oprendszeren két tömörítés mellett miért szaggat be az mp3 lejátszás? egy virtualboxban települő windows miért nem lassabban telepít, mintsem használhatatlanná szaggatja a gépem? Ez sokkal inkább filozófiai kérdés, mintsem hibaelhárítás :)

3) kell a photoshopnak a ram, azt is használok rajta (most épp pont nem)
4) na igen, az ilyenekkel nem vagyok még annyira tisztában, akkor most a laikus válaszol: ne legyen io wait. vagy csináljanak vele valamit. Lapozzon picit lassabban, legyenek a programok lassabbak, de ne használhatatlanok. Nyilván ez az elevator dolog amit írtál megoldja ezt, de akkor miért nem az a default egy ubuntuban, amit a hülyeembereknek csinálnak?

Két dolog okozhat intenzív swappelést:
1. Nincs elég szabad RAM. Ha folyamatosan több ram kell, mint amennyi van, akkor "page thrashing" lesz a vége, azaz az alkalmazások egymást lökik ki a ramból, egymást gáncsolják el. Ilyenkor kilökik az ablakkezelőd, Xorg-od, GNOME paneled is a swapra, így szaggatni fog az UI is. Erről írtál az eredeti post-ban, erre azt lehet mondani: vegyé bőven ramot! Ez egy olyan hiba, amivel az oprendszer nem nagyon tud mit kezdeni, nem is nagyon lehet elvárni tőle.
2. High order allocation: van szabad ram, de túl töredezett, nincs annyi egybefüggő szabad lap, amennyi épp kell az alkalmazásnak/kernelnek.

Ez utóbbi egy aljas dög. Azt látod, hogy a free szerint mondjuk a ram 40%-a szabad, mégis szétswappolja magát a gép 1-2 percre és amikor magához tér, azt látod, hogy szabaddá tette mondjuk a ram 60%-át. Sajnos ezt a felszabadítást agresszív kifelé swapeléssel éri el, ami közben a gép totál megmakkan.

Ez nálam is probléma.

Hát ez jó kérdés. :)

Pl a SLAB-ok is nagyobb lapokba szeretnek szerveződni mint amennyire feltétlenül szükség van (pl egy 257 bájtos igényhez már 2db 4KB-os egybefüggő lapot allokál és 16 allokációt elégít ki belőle), még nem néztem utána hogy miért. Biztos valami teljesítményok lesz a háttérben, pl hogy kisebb legyen a TLB, vagy ilyesmi.

Ami hirtelen eszembejut, az pl a PCIe busz felé még nincs virtuális memória, ezért érdemes eleve egybefüggő lapokon tárolni, ami ilyen eszközök felé fog kimenni (bár van scatter/gather).

Mel Gorman HUP-ot olvas! :)

A memory compaction leváltotta a lumpy reclaim algoritmust 2.6.38-ban, így a "high order allocation" többé nem jelent brutális swapout-ot, amibe beleáll a desktop 1-2 percre. Ennek már nagyon ideje volt.

ang után én is azt javaslom, próbáld ki a 2.6.38-at, ez tényleg egy powerboost release lett.

De most komolyan, PS-t használsz, annak kell a RAM. Remek, egy PS többszázezer Ft, ilyet munkára vesz az ember, akkor a munkaeszközként használt gépbe is rakjon még néhány giga ramot párezerért, aztán elmúlik a jelenség.

Létezik nice és ionice parancs, ezekkel lehet a processzek cpu és io prioritását állítani.

Nincs olyan, hogy ne legyen iowait, iowait azért van, mert a disk io több nagyságrenddel lassabb, mint a memória. Vegyél 4 SLC SSD-t, vágd be stripe softraid-be, aztán nem fogod észrevenni, de akkor is lesz.

Ez nem filozófiai kérdés, alkalmatlan gépet agyon ölsz, aztán csodálkozol. A probléma oka, hogy nincs elég ram-od, ennek maximum csökkenteni lehet a hatásait, megoldani nem lehet semmilyen varázslással, ram-ot kell venni bele, az az egyetlen megoldás.

Eddig 1 giga ram volt a gépemben, és kevés volt (pedig annyival adják a netbookokat). most négy van és kevés. Sok gépet 2 giga rammal adnak. És most ne nézd azt, hogy virtualbox, meg ps mert amikor nem használom ezeket akkor is van hogy beüt a dolog. Nehogy már én használjak kevés ramot. Nehogy már négy (2, 1) giga kevés legyen desktopnak...

nem az a panasza, ha jól értettem, hogy amelyik program miatt swappel, az a program lassú.
hanem az a panasza, hogyha sok az io, akkor megdöglik az egész tokkal-vonóval.
pl. fut egy mpg123, betöltötte már az egész számot, de egy dpkg miatt tolja a vinyókat, akkor megdöglik az mp3-a is.

azt saccolom, túl magas prioritást kap a kernelben az io kiszolgálása és ezzel megöli a többi processzt is. én is láttam már ilyet, nagyjából sejtem, mire gondol.

szerintem swap-pel, és az visszafog mindent baromira.
ne swap-peljen semmi, annál egészségesebb nincs. Van vagy ötezer egy 1 gigás RAM, belevág még 2 gigát 10-ért, aztán ez tuti segíteni fog.

Szerintem nem az IO kiszolgálás prioritása lassítja be, legalábbis nem hiszem, h ubuntu-n ez előfordulna, mert akkor minden ezzel lenne tele, hogy másolásnál beszaggat az mp3.
Szerintem minden a disk-re várt, amit tekert 3 virtuális gép +a host +a swap-pelés +ment még 1-2 tömörítés +tele volt a memória, cache-elni se tudta a vinyót +gondolom elevator az cfq, szóval a vinyó szétseek-elte magát, plusz ha még a vinyó lassú is, akkor garantált a halál.

( blueghost | 2011. 03. 21., h – 12:44 )

Ha a lemezművelet nagymértékben terheli a cpu-t, akkor szerintem nincs DMA. Én első körben megnézném a BIOS beállításokat.

( bambano | 2011. 03. 21., h – 12:37 )

ez hardverfüggő, van, amelyik vason jobban gyilkolja a linux a hardvert, van, ahol nem annyira.
ha ez neked nem tetszik, tegyél fel freebsd-t, ebben a kérdésben igen látványos a különbség.
hdparm-mal megnézhetnéd a vinyó beállításait.

( saxus | 2011. 03. 21., h – 12:45 )

DMA-val minden rendben?

----------------
Lvl86 Troll

nemtom, ehhez (nem|sem) értek, de 4 gépben, amiből hármat nem én raktam össze (laptop + munkahelyi gép) csak nem rossz mind.

itt egy hdparm kimenet
bár ez szerintem sokmindent nem mond
egyébként sata vinyó

/dev/sda:
multcount = 0 (off)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 60801/255/63, sectors = 976773168, start = 0

( vl v | 2011. 03. 21., h – 13:12 )

Nagyon régi problémám ez, korábban a lassú gépemnek tudtam be ezt a fajta működést, de most az új gépemmel nem lehet ez a kifogás (intel i5 mittoménmennyi otthon, i3 munkahelyen).

izmos gép?
ha a diszked a kurva lassú, akkor azon mit segít a gyors cpu?

a probléma ott van, hogy _minden_ diszket használ. és amikor odaér a program, hogy olvasson, akkor meg kell várja a többieket.
a problémán lehet reszelni, hogy egyik program kevésbé várjon a másik hülyesége miatt, de az alapvető problémát nem tudod kiiktatni. mellesleg, winfos alatt is ugyanúgy megdöglik minden, ha a diszket megterheled. annyira, hogy az ikonokat se bírja a desktopon kirajzolni, mert persze azokat is egyesével olvasgatja diszkről...

épp a harmadik virtuális gépemet próbáltam elindítani (3 különböző IE-n tesztelek, három "tiszta" környezetben), de a három összesen nem eszik 2.5 giga ramot (4 van összesen), ráadásul nem nagyon csináltak semmit, nem kellene akadályozniuk a rendszerem működését.

segítek: a windows, amikor nem csinál semmit, folyamatosan tekeri a vinyót (defragmentál az isten barma).
ebből a roppant hasznos "funkcióból" te most éppen hármat indítottál be ugyanarra a diszkre, ebből egyébként egy is túlterhelné a vinyó...
ez az orvosság ellene:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OptimalLayout]
"EnableAutoLayout"=dword:00000000

Tapasztaltam hasonlót, xwindow és egyéb virtuális terhelések nélkül is. Nekem is sikerült már olyan progit írnom ami a select tájékán duplanelsonba fogta a gépet.
Nem lehet a schedulon állítani? Még nem jutottam el odáig hogy megnézzem mit lehet egy előreforgatott kernelen (mondjuk kernel paraméterrel) állítani a schedulon. Az biztos hogy a Linux maximálisan kihasználja a rendelkezésre álló erőforrásokat, és ha valami beállítás, inkompatibilitás is beleszól akkor az nagyon nagy "dúlást" tud okozni.

* Én egy indián vagyok. Minden indián hazudik.

( Kiskübi v | 2011. 03. 21., h – 13:41 )

Azért 4G RAM-mal 3 virtuális gépnek jól kellene szaladnia.

Nálam is van ilyen jelenség, amikor kifutok RAM-ból. Ezért találták ki az OOM-killert, bár én azt hiszem, nem ez az igazi megoldás a problémára.

Tűzoltás: nekem az segít, hogy Ctrl+Alt+F1, bejelentkezek root-ként, és 

killall az_a_bináris,_ami_sokat_zabál

. Vagy 

killall -9 bináris

, ha a TERM jelzésre nem adja meg magát. A konzolra elég hamar, fél percen belül át szokott váltani :) még az ócskavasam is. login + killall parancs hasonló nagyságrendű időben megy.

Másik:

man malloc azt mondja, hogy a Linux kernelnek nem feltétlenül szokása NULL-lal visszatérni akkor sem, ha elfogyott a memória. Bízik abban, hogy az alkalmazások csak ideiglenesen kérnek sok memóriát, arra meg szerez valahonnan (pl. addig kilapoz valamit?... nemtom). Erről az optimizmusról ugyan le lehet beszélni az 

# echo 2 > /proc/sys/vm/overcommit_memory

paranccsal, de úgy veszem észre, többen rászoktak, hogy rövid időre lehet nagyon sok memóriát lopni, és ha ez nem megy, a programjaik nem jól működnek.

( Kiskübi v | 2011. 03. 21., h – 14:03 )

Amúgy mekkora a swap-területed? Nem kicsi?

azt hiszem tartottam a memória dupláját elvet

Ez a baj. Irtsd ki az összes swap-et, vagy tedd mindet SSD-re. Emellett állítsd be az alábbi két sysctl-t: 


vm.overcommit_memory = 2
vm.overcommit_ratio = 99

(Az utóbbi lehet 100 is.) A sysctl-ek azért kellenek, hogy ha a swap híján kifutnál a memóriából, akkor az a program dögöljön meg, amelyik zabál / pazarol. Így esetleg képes leszel kifejezetten azt hangolni.

Nincs továbbra sem SSD-m (és pénzem se rá), munkahelyi gépbe meg nem igazán nyúlhatok.

Az a baj, hogy ha kiirtom a swapet, akkor szépen megy minden egészen addig amíg el nem fogy a memória valamiért. Ha nekem elkezdi a rendszer megölni azt a virtualboxot amiben épp dolgozom, és elszáll vele egy óra munka, akkor sikítófrászt is kaphatok alkalmanként hajtépéssel. Otthon tudna működni ez az elv.

Igazából azt sajnálom, hogy nem lehet (legalábbis erre még senki nem írt utalást, hogy lehetne) úgy hangolni a rendszert, hogy az io műveletek ami miatt az egész probléma van ne tudják blokkolni ennyire (semennyire) a rendszert.

Nézd meg, a virtuális gépeid használat közben mennyi memóriát használnak. Adj nekik annál 20-30 %-kal kevesebbet. XP pl. jól elvan 512 rammal, meg ugyanúgy swapel 1 gigával is. (Ha lehet, rakd a virtuális gépek lemezfájljait külön fizikai lemezekre.)
Figyeld a memóriahasználatod. Gnome-ban ki tudsz rakni a tálcára rendszermonitor appot, ami mutatja, hogy állsz ram meg swap ügyileg.Esetleg a swappiness értékkel próbálj meg játszani, swapoljon minél hamarabb, ne várja meg, amíg már nincs ram.

Ha a gép halála nem azonnal következik be a bekapcsolás után, hanem mondjuk 1-2 óra használat múlva, úgy, hogy végig ugyanazok a programok futnak, akkor jó eséllyel valahol szivárog a memóriád. És szánj rá 2 percet, és Synapticban dúrd le a Compizt teljes eltávolítással. :)

Ez az egész, amit írtam, bőven megvan egy óra alatt.

Az a baj, hogy ha kiirtom a swapet, akkor szépen megy minden egészen addig amíg el nem fogy a memória valamiért.

Elsősorban ezt kellene megoldanod. Ha a memória elfolyik, akkor majdnem mindegy (interaktív munkánál), hogy valami azonnal elpukkan-e, vagy elkezd diszkre/diszkről lapozni a gép, használhatatlanná válik, és újraindítod erővel.

Ha nekem elkezdi a rendszer megölni azt a virtualboxot amiben épp dolgozom

Nem ismerem a virtualboxot, de feltételezem, hogy az nem eszik egyre többet és többet. A fenti sysctl-eket beállítva, miután a virtualbox induláskor sikeresen lefoglal egy jókora szelet memóriát, az OOM killer már nem fogja lezúzni. Azért, mert nem lesz OOM killer. Amelyik alkalmazás dinamikusan (= kezdeti setup után is rendszeresen) allokál, az fog a malloc()-ban vagy az anonim mmap()-ban hibát kapni.

az io műveletek ami miatt az egész probléma van

Nem az IO műveletek (normál fs aktivitás) miatt van, hanem a diszkre/diszkről lapozás miatt. A diszkre/diszkről lapozás, erősen valószínűsítem, a page fault handler-ben fut, amikor is a CPU egy kilapozott lapra eső címet próbál meg elérni. Amíg a kérdéses lap nem érkezik be, addig jó eséllyel minden áll. A helyzetet súlyosbítja, hogy ha igazi memórianyomás van, akkor több processz verseng a memóriáért, nincs lokalitás, nagy a globális working set, tehát iszonyatos fejrángatás lesz.

Azt javaslom, hogy a virtualbox-on belüli OS-ben állíts be swap-et, de a virtualbox-nak ne adj nagyon sok RAM-ot. A swap file-nak vagy partíciónak vagy kötetnek el kellene férnie a vdi-ben, az pedig a host OS-en már szimpla file IO-nak számít (legrosszabb esetben is O_DIRECT vagy valami ilyesmi.) Ha a guest-ben valami elkezd swappelni, az a host-on így "csak" file-terhelésként jelentkezik, ami más file-műveleteket lelassíthat ugyan, de mondjuk az mp3 lejátszódat nem fagyaszthatja meg. Kiváltképp, ha megadsz neki mondjuk egy fél perces pre-buffer-t.

munkahelyi gépbe meg nem igazán nyúlhatok

Annyit bizonyára megtehetsz, hogy egy USB diszket (nem pendrive-ot, hanem rendes, tengelyes diszket) rádugsz a gépre. Aztán vagy az mp3-aidat, vagy a vdi file-t kiteszed erre. Így ha a guest irdatlan O_DIRECT file-zúzásba kezd -- mert valamelyik alkalmazása miatt swappel --, akkor is egy elkülönített "diszkfejhalmazra" van korlátozva.

> Amelyik alkalmazás dinamikusan (= kezdeti setup után is rendszeresen) allokál, az fog a malloc()-ban vagy az anonim mmap()-ban hibát kapni.

Szerintem a malloc() sikertelensége jóformán ugyanazt eredményezi, mint az OOM-killer: a processz kilép, nem nagyon tud mást tenni. Oké, még lezárja a függő erőforrásokat előtte, jobb esetben.

Kis swap mellett (kb. RAM negyede, történeti okokból :) ) az overcommit=2-vel próbálkoztam egy időben, de nem ajánlom. Határozottan kevesebb program tudott elindulni. (Ki lehet próbálni, akinek van ideje.)

(szerk: azt is gondnak tartom, hogy szerintem a T. alkalmazásfejlesztők hozzászoktak az overcommithoz, és ész nélkül foglalják a memóriát... én fejlesztőknek-tesztelőknek javasolnám a kikapcsolt (2-es) overcommit-ot.)

Ellenben kíváncsi vagyok, hogy nagy swap-pal hogy muzsikál.

Dap kolléga hozzászólása is a nagyobb swap mellett szól szerintem.

( Foltos | 2011. 03. 21., h – 14:11 )

He-he! Most tervezgetem, hogy Linuxra váltok a winx xp és a win7 ugyanilyen működése miatt.

Véleményem szerint a baj az, hogy a procik fejlődése jóval túlhaladta az egyéb komponensekét. Ha egyszerre sok minden akar sok mindent csinálni, a PC mint olyan halott. Talán mar a buszok (PCI, PCI Expressz) illetve chipset sem bírják az ilyen terhelést rendesen, de a merevlemez biztosan halott ügy. Hiába tud 30-40 MiB/sec -t szekvenciális elérésre, ha a random elérés csak 5-10 MiB/sec. A mai multitaszkos világban max másoláskor van szekvenciális terhelés.

Megoldás?
Szerver chipset -es alaplap, SSD (vagy RAID tömb), hogy jobb legyen a "merevlemez" random teljesítménye, illetve terhelés csökkentés. Próbálok megszabadulni a víruskeresőtől, meg az egyéb háttérben futó, vackoktól. Ha mindezt ingyé akarom, akkor marad a teljesítmény csökkentés, azaz irány a Linux.

Az alapján amit írsz nem néz ki annyira rózsásan a dolog mint gondoltam.

mondjuk annyiból érdekelne a téma, hogy több hete nyomulok gépcsere ügyében, és még én sem tudtam eldönteni, hogy inkább annyi ramot vegyek, amiben minden elfér vagy vegyek ssd-t.

a többi itt olvasható topic alapján a ramról gondolom most, hogy jó lenne. de ezt meg kellene agyalni még rendesen:)

Nézz utána ennek : OCZ Revodrive. Az 50 gigás kisker ára mikor utoljára néztem {szerk.- kb. 50k árgépen jelenleg}

Beteg cucc, azért van pci-e 4x-ben, mert eléri a sata i/o limitet.

http://www.ocztechnology.com/ocz-revodrive-pci-express-ssd.html

"superior speeds up to 540MB/s reads and random 4k writes up to 75,000 IOPS"

még én sem tudtam eldönteni, hogy inkább annyi ramot vegyek, amiben minden elfér vagy vegyek ssd-t

RAM-ot vegyél. Az SSD lehet önmagában gyors, de messze van, és keskeny az út.

http://static.duartes.org/img/blogPosts/latencyAndThroughputFull.png

http://duartes.org/gustavo/blog/post/what-your-computer-does-while-you-…

( tbs v | 2011. 03. 21., h – 16:17 )

SSD + sok RAM = ideális kombi. :D

(Bocs, Bambano-nek.)

De mit segít nekem a compiz eltávolítása? Látom én, hogy fut a háttérben ha kell, ha nem, de egyrészt ránézésre nem eszik szinte semmi memóriát, másrészt ha nem lenne valami oknál fogva nagyon lassú a videokártyám, akkor használnám

Ez elég sajnálatos.
És ez örökérvényű, vagy valamelyik compiz / ubuntu verzióra vonatkozik? Nem hiszem hogy egy memóriaszivárgást nem javítanak meg, ha tudomásuk van róla.

És hol derül ki, ha szivárog?
(most nézem, munkahelyi gépemen egyáltalán nem fut compiz háttérben sem)

1,
Ez csak egy javaslat, nem csak Ubuntu verziótól függhet ez, hanem VGA drivertől meg minden mástól is. Én ezzel sokat szívtam 2 különböző verziónál is. Mivel a művelet 2 percet vesz igénybe, mialatt ellenkezni kezdtél, megcsinálhattad volna, főleg, hogy nem is használod.
2, nem írtad le, milyen verziót használsz
3, már gyakorlatilag minden tanácsot megkaptál, amit ezzel kapcsolatban adni lehet, csak össze kell szedned őket
4, ha a vasad nem alkalmas arra, amire szeretnéd, akkor nem alkalmas. Rakj fel Windowst, várjuk a tapasztalataidat.

Ugyan :) Dehogy rinyálok, kicsi félreértés van. Én egy általános tűnő (és mint kiderült tényleg általános) dologról számoltam be nektek, ami kiakaszt. Általános, mert ugyanezt tapasztaltam különböző ubuntu verziókkal (7.04-napjainkig), különböző DE-kkel (xfce, gnome, kde), különböző gépeken (netbook, alsókategóriás laptop, 5 éve jónak tűnő asztali gép, most közepesnek számító desktop), különböző videokártyákkal (intel, nvidia), különböző szoftverhasználat mellett (pl böngészőből ff, chrome), különböző memóriamennyiséggel. stb... Nincs mit megoldani, csak kíváncsi voltam mennyire jellemző, és ha van valami hack ami elviselhetőbbé teszi annak örülök :)

Nagyjából arra jöttem rá a hozzászólásaitok alapján amit eddig is sejtettem, hogy ez egy tervezési hiba, vagy általánosan a gépeké, vagy az operációs rendszeré.

Ne gondoljátok, hogy nekem van "egy" problémám amit szeretnék megoldatni veletek, és csak rinyálok ahelyett, hogy kiszolgálnálak titeket mindenféle adatokkal. Megtehetném, de az nem fogja megoldani azt a problémát, hogy k hangosan csipog a papagáj. Az is design hiba, és zavar.

Ősszefoglalom röviden: Nagyjából általános használat mellett is tud a gép olyan szinten beszaggatni, hogy semmit sem tudok vele kezdeni, mert az egérkurzor is szaggat, a konzol pedig percekig csinál egy logint. Ezt már leírtam. Amit talán nem nyomatékkosítottam, hogy az én problémám az, hogy ilyen van. Nem az, hogy "éppen" van, hanem az, hogy egyáltalán.

Ez nem egy konfigurációból, vagy használati módból adódó probléma, hanem tervezési hiba. És van rá logikus, programozói szemmel érthető magyarázat (még úgy is értem, hogy nem igazán vagyok a rendszerközeli dolgokkal tisztában), de ez nem teszi szebbé a napomat amikor figyelmetlenül sokmindent indítok el, és elszáll a munkám (ha kilövi a kernel, és nincs swap) vagy hosszú percekre használhatatlanná válik a gépem.

Ilyet nem szabadna produkálnia. Ideális esetben a desktop operációs rendszeremnek szólnia kellene, hogy elfogyott a memóriája, és megkérdeznie, hogy mire nem vagyok már kíváncsi. Vagy akár tekerjen a vinyó, de ezt csinálja kultúráltan, úgy, hogy az élményem nem romlik. Történjenek lassabban a dolgok, csak ne akadályozzák a többi történést. Nemtom. Tudom, hogy így működik, evvan, csak azért mégis. Jobb lenne, ha jobb lenne. Apple-ék az iphone-t annyira hekkelgetik, hogy még csak véletlenül se vesszen el a "smooth" élmény, miért nem cél ez itt? Tudom, hogy más a célja a linuxnak, de nézzünk egy webszerver helyzetet: az adatbázis percekig nem ad választ egy kétsoros query-re, csak mert backup fut a háttérben?

Őszintén szólva 4 giga rammal "általános használat mellett is" nem tudom, hogy a francba fogyhat el a memóriád. Ha azért fogy el, mert valami verziókon átívelően megzabálja (nem a compiz, hanem bármi :) ), akkor ezt kellene megkeresned. De ha neked az az általános használat, ahogy annyi progid van nyitva, hogy 4 giga ram elfogy (ezt nem igazán tudom elképzelni), akkor az nem tervezési hiba, hanem rendszerkorlát. Mielőtt eljutottunk oda, hogy az egyébként nagyságrendekkel lassabb lemezekre tegyük ki a dolgokat, a helyzet szimplán az volt, hogy nem volt ram, nem nyitsz új appot, kész. Ez a lehetőség most is megvan. :)

Nem a négy giga ramra gondoltam. Az tényleg nehezen fogy el, ha épp nem futtatok három virtuális gépet, ami nem igazán általános használat.
Viszont két éve 1 giga ramom volt, és az alaprendszer böngészővel, skype-val meg egykét aprósággal már nem nagyon fért el az ubuntum, amikor lapoztam a böngészőben akkor a gép is lapozott, várakoztam sokat, és szar volt az élmény. Nyögdécselt a gépem amikor elindítottam egy inkscape-t, vagy akármi mást, be kellett zárnom a böngészőt néha hogy tudjam eredményesen használni a többi programot, stb.
Szerintem 1 giga ram nem kevés, főleg hogy annyival adnak el netbookokat.

Igaz, annyi appot kell használni ami elfér a memóriában, de a fenti esetben (ami szerintem általános) nem bosszantana téged, hogy mindent be kell zárogatni? :)

Annyira nem hozom elő most hogy mennyire bosszant az a hozzáállás is, hogy a gyengépp gépeket leszarják a fejlesztők, pl nincs optimalizálva a memóriahasználat, stb.

Az a baj, hogy nem engedhetek meg magamnak ilyesmit. Munkahelyemen meg nem biztos hogy jó ötlet panaszkodnom a rendszer teljesítményére, mert hamar ott találhatom magam, hogy windowst telepítek, mert azzal nincs gond, örülök hogy saját telepített rendszerrel dolgozhatok.

fogalmam sincs. Csak arra emlékszem, hogy annó amikor 256 mega memóriám volt, sokszor volt hogy lapozott a gépem, és tele volt a memória. Láttam olyat, hogy soronként rajzolja újra az ikonokat, meg az ablakokat az XP, de annyira nem volt kezelhetetlen soha, hogy rövid időn belül (20-30 mp max) ki ne tudtam volna lőni azt ami zabálja a procit

Windowson én már jártam úgy, hogy beindítottam valami szar javascriptes oldalt, a fos netscape elkezdte enni a memóriát, és a gép akkor lett legközelebb használható, amikor a teljes swap elfogyott, és az oprendszer kilőtte a netscape-et. "Szerencsére" csak 512MB swap volt, mert ha 10GB lett volna, akkor sok-sok percig is eltartott volna a dolog...

100k-s hardver eredendően diszkkorlátos. A feladatod NEM erre van méretezve.

(Amúgy 120eFt-ért (nettó) a jelenleginél alsó hangon 2-3szor jobb IOPS-ot rakok össze néked, hasonló CPU teljesítménnyel. Asztali gép, noname+, linugz.)

Ja, egy használható tippet is mondok:
Ha ubuntu, akkor méretezd rendesen a compcache-t (RAM 15%-ra minimum), a swap prioritásokat (ramz 100, diszkek -1) és a swappiness/cache-t (pl. vm.vfs_cache_pressure=10, vm.swappiness=90).
Ha debian, akkor ramzswap forgatás és a fentiek. (Vagy benne lenne már a vanilla kernelben..? Rég láttam...)

Szerk.: Ja, és a többi okosságot is fogadd meg: compiz kuka, elevator=deadline stb.

( Fisher v | 2011. 03. 21., h – 23:59 )

Köpjetek le, de én se iostat se vmstat se top, se iotop vagy bármi diagnosztikai program outputját nem látom, csak azt, hogy "lassú". És ilyen szűkös információ alapján én nem mernék semmit se ajánlani.

De miért kellene látnod? nem egy eset hibajavításán vagyok, hanem egy általános problémán, ami eddig 8-10 telepítésen keresztül különféle szoftverhasználati szokásokkal, 4 különböző teljesítményű és összesítésű számítógéppel elkísért. Egyébként nyomhatnék én neked most ide iostatot is, top-ot is, de lusta vagyok kiszedni az outputból az érzékenyebb információkat, és egyébként friss indítás után vagyok, szóval nem látnál benne semmit.

Azt hiszed, hogy ezek között hatalmas különbség van? Egyszer mérd ki, hogy hány IOPS-ot tudnak, és lesz meglepetés.

A 20 évvel ezelőtti gagyi vinyó és a mai átlag desktop diszk között jó, ha 2x-4x-os IOPS különbség van, ehhez képest a legeslegfaszább 15krpm-es enterprise sem tud max. további 2x annyit. Ez még egy nagyságrendnyi különbség sincs 20 év alatt, a leggagyibb és a legszuperebb diszket nézve.

Ehhez viszonyítva egy SSD hatalmas ugrás, mert egy jobb fajta (de még a sarki boltban kapható) SSD tud mondjuk 100x annyit, mint a legjobb most kapható diszk, és létezik sok pénzért olyan SSD, ami mondjuk 1000x annyi IOPS-t tud, mint a desktop vinyód.

+1. Plussz a 8GB DDR3 RAM ~16eFt (nettó). Asztali gépnél semmi értelme azon rugózni, hogy miért nem elég 2/4GB, szvsz, bele kő b@szni a 8-at oszt' hadd szójjon! :)

Amúgy az SSD se megváltás, ha swappel a gép, az is érezhetően lassú lesz. Annyi RAM kell, hogy ne legyen masszív swap I/O, másképp meg van b@szva az SSD is (nekem is az van, látom).

Először is gondolom a hdparm -m1 már megvolt, bár sehol se írtad hogy javított volna, pedig illene neki.
Másodszor meg:

A top folyamatosan írja az adatokat, halálosan mindegy, hogy friss indítás után vagy-e. Értelemszerűen nem az a rész az érdekes amikor megy a gép, hanem az, amikor döglik. Itt a legérzékenyebb adat a processek neve lehet, azt azért nem rettenetesen vérverejtékes munka kiszedni. Már ha ki kell.

Az iostat, vmstat nem tartalmaz sikítóan titkos adatokat, de ezt nyilván te is tudod.

Amit nem tudunk:

- írásra van gondja a diskeknek vagy olvasásra, random vagy seq, bw vagy tps? (iostat)
- van-e elég memória (top, vmstat:si, so)
- ha nincs, akkor hol van (top)
- ha van, akkor mégis mi tekeri a disket (iotop)

A dmesg-ben ez van: Memory: 3770392k/4587520k szóval a 4G se 4, inkább szűk 3.5, a virtuális gépek megehetik a ramot (mennyivel kevesebb a 2.5G-nál a foglalásuk?) és hamar elfogyhat minden cache... de ez csak ötletelés.

Lehet h kötekedő majom vagyok, vállalom, vagy hogy felületes voltam, de a fenti jelentéktelen információkat nem láttam leírva és szerintem ezek azért legalábbis hasznosak lennének.

A dstat amúgy egy másik kedvenc, szépen ki lehet okosítani és látványosan tudja mutatni az erőforrások alakulását.

( ang | 2011. 03. 22., k – 02:56 )

mondjon kernel verziot a lassuhoz, meg hogy milyen DE-t hasznal...

a mostani ujabb kernelekbe, 2.6.37 es 2.6.38-es be ha jol tudom, raktak kifejezetten erezheto, a desktop elmenyt befolyasolo fejleszteseket, javasolnam a 2.6.38-at, szerintem kifejezetten gyorsabba a korabbiaknal

es nem mind1 szerintem, hogy milyen io schedulert hasznalsz a vinyoidon, ssd vagy hdd-hez masmas ajanlott (ssd-hez noop-t irnak)

a memoria lehetoleg ne teljen be persze, megvallom nekem is van hasonlo kornyezetem, futtatok is neha kvm-ben gepeket, de lehet allitani a swapiness-t

lehetne flame kategoriaba is rakni a kovetkezot, de nekem ubuntu mindig lassunak tunt, inkabb dolgozom ezert gentoo vagy sabayon-al, vagy valami mas rolling-release-es disztroval, sabayon-ban ma delutan raktam fel a 2.6.38-at amd64 es x86-os gepekre is, mindket kornyezetben erezhetoen gyorsabb a bongeszes is

szerintem probalj ki masik disztrot

(vagy allitsd be az /etc/security/limits.conf-t, add meg a szolgaltatasaidnak, hogy milyen group vagy userrel fussanak, es ha elerik a beallitott korlatokat, majd kilovi oket helyetted a kernel ;)

Egy ideig én is azt gondoltam, hogy az Ubuntu túl lassú. De rá kellett jönnöm, hogy az Ubuntu semmivel nem lassabb, mint bármi más (jó, oké, Gentoo nem ér), ha az ember foglalkozik vele annyit, mint bármi mással. :)

Szerverből kell felrakni, és megválogatni, hogy miket teszel fel. Plusz a serverben az ütemező alapból deadline, stb. Elképzelhetetlen, hogy mennyi kis szutyok benne van egy alap Ubuntu telepítésben, amire soha nem lesz szükség.

gentoo-rol en is sabayon-ra valtottam lustasagbol, meg az megis meg1 plusz reteg csomagolastechnika, debugging csapat stb. ; esetleg calculate linuxot erdemes kiprobalni, gentoo alapu teljesen, portage fa-t hasznal eloreforgatott binaris csomagokkal.

egyebkent kb mind1, hogy alap telepitesben mennyi minden van a vinyon, kerdes mi fut abbol a rendszerben... "compiz - a fekete barany" es tarsai, pedig sokszor csak a rossz minosegu linuxos videokartya driver teszi... ;)

igazandibol ezert jobb a mac talan, mert ott valamelyest valogatva, meg szuk koru hardverre van programozva rendes driver, nem a low-end consumer market minden gyarto sajat kodot csinal es abbol van osszehanyva a gep marketing szempontokat figyelembeveve

(nem vagyok mac-fan, volt 3 maces gepen, soha tobbe nem fizetem meg a brand felarat, meg a proprietary kornyezetet, meg a sok limited shareware frontendet gpl-es toolok felett, es nem vagyok amerikai...)

viszont csak hogy mindenkit megnyugtassak, ilyen hibakat windows 7 is produkalt mar jonehany telepitesben, ott az NTFS jogosultsagkezelese birja megorjiteni rendesen a gepet, probalj tcommanderbol cmd-t futtatni... de lattam mar fullos belassulast win7 alatt ssd-re telepitett rendszerrel, oruletesen magas iowait es minden amit itt most linux leirt a kollega az eredeti felvetesben, oom kontextusban, csak ott meg oom sem volt.

( ang | 2011. 03. 22., k – 03:15 )

azert valahova pastebinbe egy dmesg outputot + "lspci -vn" tolhatnal, lehet csak valami driver gondod van

probald meg native ide-rol ahci modra kapcsolni a biost, azzal lehet mar mas drivert hasznalnal

nekem ilyen belassulast utoljara akkor csinalt gep, amikor egyszer egyik raid tombben hibas volt fizikailag a hdd (szallitaskor serult, de szoftveresen nem mutatott hibat, csak neha belassult az egesz, majd fagyott tole a gep), aztan meg nagyon regen volt amikor "kontaktos" lett az ide kabel a szereles kozbeni gyurogetestol, s az okozott ilyen lassulasokat...

logok kellenek a debugolashoz :)

Most benyomom a munkahelyi gépem dmesg-jét, és aki szemfüles észreveszi, hogy encryptelve van a vinyó, és emiatt elküld a fenébe, hogy akkor ez a gond, és emiatt lassú. (figyelmen kívül hagyva azt, hogy - ismétlem magam - eddig 4 gépen tapasztaltam ugyanezt, azok nem voltak encryptelve)

De azért itt van: http://pastebin.com/MYEW7pUS

szerk: lspci http://pastebin.com/nWCsvzhY

( zolpet | 2011. 03. 22., k – 10:28 )

Összefoglalva, hogy mit tudunk:
" a három összesen nem eszik 2.5 giga ramot (4 van összesen), ráadásul nem nagyon csináltak semmit"

Ha nem nagyon csinálnak semmit, és XP-k, akkor 512 mb ram/vm maximum. Ha jól vettem ki, csak a böngészőt használod, így akár még a 384 mb/gép is elég lehet, lévén ha van elég szabad ram, az Ubuntu aláteszi a cachet a vm swapjának ugyanúgy.

Van tehát 3 gép esetén 2,5 giga ramod az Ubuntunak. Ha ez elfogy, ott komoly gondok vannak. Márpedig hiába vergődnek a virtuális gépeid, ha a hostnak van ramja, nagy gond nem történhet.

Gnome panelen system monitorban figyeld, hogy mennyi ramod van. Ha nincs ramod, ne indíts el újabb dolgokat, mert fölöslegesen kinyírod a rendszert.

Ahogy mások is írták, deadline ütemező, swappiness értékét minél nagyobbra állítani.

Szerk: Ha a procid támogatja a virtualizációt, akkor azt mindenképp használd (Intel VT/AMD V). Ez néha a biosban nincs alapból bekapcsolva. E nélkül 3 gépet virtualizálni nemigen lehet.

Szerk. 2: plusz még amit vl írt, azt csináld meg a Windowsokon ([HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OptimalLayout]"EnableAutoLayout"=dword:00000000)

Szerk 3: ott vannak az overcommit-os dolgok, amit többen írtak, ha még ez sem segít. De ha ezeket megcsinálod, jónak kell lennie.

Köszi a tippeket. A deadline-vel próbálkoztam, nagy változást nem nagyon tapasztaltam, de fogom használni azért, hátha sok kicsi sokra megy alapon ad valamit :) A többit idővel beállítgatom, csak ma nem nagyon jutott időm munka mellett rá, meg még nem panaszkodott a gépem :D

Azt írtam korábban, hogy a virtuális gépeknek szánt memóriát nem nagyon tudom lejjebb venni (egyik gép hét, annak azért nem, másik gépen ps-t használok aktívan, annak azért nem, a harmadiké le van véve 376-ra vagy nemtommennyi).

Ha a procid támogatja a virtualizációt, akkor azt mindenképp használd (Intel VT/AMD V). Ez néha a biosban nincs alapból bekapcsolva.
Ez alap. A bios is be van lőve (illetve otthon igen, itt nem tudom, de meglesem) Registryket belőttem, még nem tudom, hogy segített-e.

Szóval használtam a tippeket, illetve fogom, köszönöm is őket. :)

Reméljük a legjobbakat.

Mindenképp hozd ki, hogy a hostnak maradjon egy kicsit több ram, mert az mindhárom VM-edet tudja "gyorsítani", ha gond van.

Ha Win 7-et nem terheled, akkor nem kell neki 1G, nekem szépen elfut 768-cal is, de megkockáztatom, hogy még kevesebbel is. Ki kell tapasztalni, meg ahogy írtam, nézni a memóriahasználatokat, és annál egy kicsit kevesebbet adni, mert vannak dolgok, amik ritkán kellenek, azok mehetnek swapba. Ahogy már más is írta rajtam kívül, a hostnál legyen inkább a több ram.

( zolti v | 2011. 03. 22., k – 20:30 )

ez a topic ugrott be, úgy látom még nem linkelték:
[Megoldva] Nagy I/O terhelésnél brutális latency

Nekem gyakran 5-600 Mb swap-em van 768Mb memória mellett, persze van fagyás közeli élmény általában alkalmazás váltásánál, de max 20-30 sec utána működik az adott alkalmazás.
Ubuntu 10.10 nem piszkáltam, de a compiz volt az első amit leszedtem .
Sztem ez természetes.