Magas terhelés + akadás = van megoldás?

Linux-kezdő

Sziasztok!

Van egy nagyon általános, linuxos problémám. Ez azóta így van, amióta 2005-2006 környékén először találkoztam linuxszal. (Ubi 5.10 Breezy volt)
A helyzet az, hogy ha linuxon valami olyan alkalmazást futtatok, ami 100%-ra pörgeti a processzort, VAGY elhasználja a fizikai memória jelentős részét (vagy a kettő egyszerre), akkor a rendszer... angolosan mondva unreszponzívvá válik... nem tudok jobb szót rá kiagyalni. Más szóval, még az egérkurzor is megakad, vagy befagy. Persze ilyenkor a zenelejátszás is akadhat, meg minden egyéb is.

A saját elméletem szerint ez az X11 szerver-kliens felépítése miatt van így, de ebben nem lehetek biztos.

Ezzel ellentétben, bár nem szeretem a Windowst, ott jól meg van oldva, hogy csak nagyon kivételes esetekben nem működik az egér és a zenelejátszás, meg az egyéb kis processzoridejű háttéralkalmazások.

A kérdésem tehát az, hogy lehet-e valami módon javítani ezen a problémán? Vagy pont ez is az oka többek közt, hogy a Waylandet fejleszteni kezdték? Nem vagyok járatos a témában, meg még így is jobban szeretem az OpenSUSE-t, mint a Windowst, de azért ha egy mód van rá, én legalább is nem veszthetek azzal, ha kérdezek erről.

( ncc1701 | 2013. 09. 16., h – 14:53 )

Elég memória kell, és ssd. Onnantól már elég gyors minden. :)
Én ilyet csak akkor tapasztaltam, mikor véletlen több memóriát kapott egy virtuális gép, mint amit szabad lett volna. Normál használat esetén nem volt ilyesmim.

( locsemege v | 2013. 09. 16., h – 14:55 )

Szerintem a CPU 100 %-os kihasználtsága nem jár az általad írt jelenséggel, az ütemező ezt jól szokta kezelni. Gond akkor van, ha például memory leak miatt elkezd swap-elni, vagy egyszerűen csak azért, mert elfogyott a RAM. Valamint akkor, ha intenzív a HDD elérés. Csak gyanítom, hogy sokat DMA-zik, s nem nagyon marad ideje a CPU-nak kódfuttatásra.

Tegyél RAM-ot a gépbe.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jó, akkor ezt tegyük helyre! Az úgy picit kevés, hogy vagdalkozol. Elmondom, én mire gondolok, aztán javíts ki. Természetesen elfogadom az igazad.

Tehát CPU felprogramozza a DMA kontrollert, a HDD elkezdi ontani a RAM-ba az adatot, miközben a CPU felemeli a lábait a buszról, így a RAM-ot nem tudja elérni. Jobban belegondolva, valóban figyelmen kívül hagytam, hogy a CPU cache-ben képes kódot futtatni.

Amit linkeltél, azon miért gúnyolódsz? Nem értem. Egy ISA-buszos hardware-t csináltam, s a jelenség az volt, hogy bizonyos esetekben hiába szűntettem meg a BUSRQ-t, a BUSACK aktív maradt, tehát a gép nem tudott tovább kódot futtatni. (Ha esetleg abba kötsz bele, hogy nem pontosan így nevezik a vezérlővonalakat, magadra vess, mert abból legfeljebb annyit vonok le következtetésként, hogy nem akarod érteni, amit írok, és kötekszel.)

A valóság független attól, hogy mit gondolsz rólam. Igen, gyakran bénán fogalmazok. Kéretik több türelemmel lenni irántam is, mások iránt is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Látom, amit írsz, csak nem értem. Miért természetes? Mondjuk van egy burst-ös írás RAM-ba a CPU részéről, közben egy DMA kérés. Mi történik? Gondolom, a burst kiíródik, utána elfogadásra kerül a DMA kérelem. Hogyan tudja a DMA kontroller és a CPU egyszerre írni, olvasni a RAM-ot? Komolyan nem tiszta ez előttem. Mert ha egy adott fizikai címről olvas a CPU, egy másik fizikai címre írna a DMA kontroller, ott sem a cím, sem az adat, sem a vezérlővonalak állapota nem stimmel. Úgy értem, az én öreges gondolkodásommal azt képzelem, vagy a CPU-é, vagy a DMA kontrolleré a busz, az egyik nagyimpedanciás állapotban kellene legyen.

Nyilván a probléma abból fakad, hogy nem követem, milyen megoldásokat használnak manapság. Ugyanakkor jobban örülnék, ha az itt szokásos leugatás helyett - ez nem rád vonatkozik értelemszerűen - inkább elmondaná valaki, hogyan van ez. Mert szerintem nem hülyeség, amit írok, legfeljebb elavult. Mint én saját magam is. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az "egyszerre" alatt nyilván időosztást érts. Szigorúan véve a DMA tényleg blokkolja a RAM hozzáférést, de ez csak elméleti probléma, nem emiatt fog szaggatni az egér a képernyőn.

Egyszerűen azért nem, mert egyrészt tényleg ott a CPU cache, másrészt, mert rohadt gyors a RAM, a HDD/SSD/LAN IO egyszerűen nem tud annyi időt lefoglalni, hogy érezhető legyen. Én úgy értelmeztem amit mondtál, hogy szerinted ha van egy komótos chip a rendszerben, ami nekiáll csöpögtetni a biteket a RAM-ba, akkor az lockolja a buszt egészen a RAM-ig és addig mindenki kussol. Szerintem ilyen nincs: a mai rendszerekben nem vonalkapcsolt a RAM..

Meglehet, ám akkor ezt kellene elmondani a részletekkel együtt, a ROTFL, epicfail aligha a vitakultúra része. Attól még az, amit írtam nem hülyeség, legfeljebb manapság már egyre kevésbé aktuális. Legalább is PC-n. Azt már csak egészen óvatosan merem megjegyezni, az ipari PC-k mindig is konzervatívabb felépítésűek voltak, mint a desktop gépek, éppen a kompatibilitás miatt. Ha csináltak egyedi hardware-eket, azt ne kelljen kidobni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Még valami, amit megkérdezek, mert a cinikus hozzászólásodból azt érzékelem, valamit nagyon rosszul gondolok. Lehet, hogy így van, ezért is érdeklődöm. Nagy I/O terhelés esetén miért lesz kevésbé válaszolékony a gép? Teszem azt, miért akadozik az egér kurzor, vagy például az audio lejátszás, de akár a Compiz desktop effektjei?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szinte mindennek kell IO - ha versengeni kell érte, akkor minden lassabb lesz. Majdnem minden processz olvasgat/írogat a diszkre vagy kommunikál olyan processzel ami ezt teszi. Az elvileg IO mentes processzek sincsenek biztonságban, mert a kód ott is IO-ból származik és a VM azt is könnyedén kidobja ha memória kell, hiszen újra be lehet húzni a diszkről. A versengést pedig tovább rontja a thrashing, mivel a kernel intenzívebben fogja kidobálni a cache-elt lapokat ha masszív IO van, a visszatöltésnél pedig már versengenie kell. A mai kerneleknél szinte minden akadozás ebből fakad.

"Otthon" kb a következőket lehet könnyen meglépni:
0. a rendszerdiszket a rendszernek dedikáljuk és lehetőleg SSD
2. a thrashing ellen be lehet vetni a cgroup memory limiteket vagy alkalmazás szinten kezelni a problémát man 2 fadvise -zal (van belőle LD_PRELOAD lib is 3rd party alkalmazásokhoz)
3. bevetni a CFQ IO scheduler prioritásokat (cgroup vagy nice/ionice alapon)

Az IO prioritások variálása amúgy közel se elég megoldás, mert írásnál nem sokat ér: a journaling miatt össze vannak kötve az adott fájlrendszerre író processzek bizonyos pontokon (pl journal flush), azaz elég gyakran be kell várniuk egymást.. Ilyenkor a priorizált IO még ronthat is a helyzeten.

Jó összetett probléma, doktorit lehetne írni egy-egy aspektusáról :)

( Lacyc3 v | 2013. 09. 16., h – 15:53 )

Van megoldás, csak körülményes és nem biztos hogy eleget hoz a konyhára. Fordítani kell egy kernelt -ck patchsettel és engedélyezni benne a BFS process és BFQ I/O ütemezőt.

Esetleg érdemes még megpróbálkozni a pf-kernellel is. Bár ugyanúgy tartalmazza a -ck patchsettet is, sok extrát is tartalmaz ami esetleg érdekes lehet.

Gentoo alatt használom és bevált, főleg a 3.10-es kernellel vagyok nagyon megelégedve.

Háááát akkor azt hiszem, ezt most kihagyom. :(

Egyszer fordítottam kernelt, a 3.10-est, de nem tudtam működésre bírni. Nem értek eleget hozzá, még linuxszal is kezdő vagyok elvégre. Meg én OS-t használok ami ugye 3.7-es kernelhez van összeállítva. Na most látom akkor, miért is jó, ha az ember rolling release distrot használ. Csak annak meg más hátrányai vannak.
A kernel fordítás még egyelőre úgy érzem, hogy túl "hardcore" nekem. Pontosabban amig a menüconfigban fogalmam sincs miket pipálok be, addig értelmetlen.

Szerk.: Amúgy 4GB ramom van, 8GB SWAP mellett. Ha pedig pl Chrome-ban megnyitok >egyszerre< 15-20 fület és közben megy a zene Deadbeef alatt, akkor simán megakad. A proci egy Phenom II X4 955.

openSUSE 12.3 64-bit w/ KDE

Firefoxot próbáltad már? Miért van ilyen sok swap ennyi ram mellett?

A kernel fordítás nem vészes. Elméletileg csak le kell töltened az OpenSUSE alapértelmezett kernelének a forrását és megkeresni a konfigurációs beállításokat (talán le is csurog a forráscsomaggal együtt, fogalmam sincs). Majd letölteni a kívánt patchsettet és integrálni (1db patch parancs).

A menuconfig sem harap. Meg kell vele etetni az OpenSUSE kernel konfigurációs beállításait és csak a -ck vagy -pf specifikus beállításokat kell átnézni, ami nagyjából egy bekapcsolás és egy alapértelmezettnek kiválasztást takar. Esetleg érdemes lehet még beállítani a processzor specifikus optimalizációt, de anélkül is megy.

A neheze itt véget ért. Fordítod a kernelt, majd a kimeneteket be kell másolni a /boot -ba és felvenni a Grub-ban egy új bejegyzést (vagy update-grub).

Ha minden jól ment, akkor futnia kell. Ahol gáz lehet, az a patch folyamat. Lehet hogy az SüSü gyári foltok inkompatibilisek a patchsettel. Ilyenkor vagy előveszed a C tudásodat, vagy megkockáztatsz egy vanilla kernelt.

Nekem is gyanús...
Nálam nincs swap (8GB RAM/32bit OS), a gépem általában reggeltől estig megy, FF szinte folyamatosan (3-4 lap mindig nyitva, gyakra 20+ is), TB 8 IMAP postafiókkal, de soha ilyet nem tapasztaltam: 


top - 17:37:52 up  9:14,  4 users,  load average: 0.24, 0.29, 0.28
Tasks: 252 total,   1 running, 196 sleeping,   0 stopped,  55 zombie
Cpu(s):  1.6%us,  0.7%sy,  0.0%ni, 97.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8200896k total,  3496944k used,  4703952k free,      652k buffers
Swap:        0k total,        0k used,        0k free,  2483540k cached

És az elfogyasztott 3,4GB-ból 2,4 buffercache... Vagyis 1GB van aktív használatban...

--
PtY - www.onlinedemo.hu

zsigmond@opensuse:~> free
             total       used       free     shared    buffers     cached
Mem:       4052668    3552784     499884          0      93220    2256308
-/+ buffers/cache:    1203256    2849412
Swap:      8391676       2164    8389512

Ha jól olvasom ki, több mint a fele ram használatban van? Kíváncsi lennék, mire...
Fut a Chrome 3-4 füllel, az X-Chat 1 szobával meg a Deadbeef tolja a zenét. Háttérben csendben csücsül a dropbox, de nincs aktivitás.

Így fest a Ksysguard: http://kepfeltoltes.hu/130916/ramusage_www.kepfeltoltes.hu_.png

Szerk.:
Amúgy arra gondolok, hogy a rendszer bezony' kifogy a ramból... Ha becsukom a chromeot, akkor is csak ~400MB ram szabadul fel a free szerint.

openSUSE 12.3 64-bit w/ KDE

Nettó baromság. Valahol régen, 10 éve Windows alá volt szokás ilyesmiket javasolni. 4GB ram mellé mondjuk 1GB swap a max. amit raknék, talán sok is.

Ahogy a többiek is írják, nem kéne ilyen gondokkal küszködnöd.

1. Valami feltűnő hibaüzenet a dmesg -ben?
2. Megfelelő a processzor hűtése? lm-sensors, konzolos céleszköz. Telepítés után sensors-detect kell, majd simán sensors parancs kiadásával megmondja a processzor hőmérsékletét (is).

A hűtés remek, egy CM Hyper 212+ csücsül... izé lóg rajta és a hőmérsékletek is rendben. :)

Nem annyira rossz amúgy az említett dolog, mint hangzik egyébként. Normál használatnál nincs ilyen. Tényleg csak ha pl kezdek kifogyni a ramból, vagy mondjuk 20 fület tölt a chrome vagy valami.
Lehet a Swapom lenne talán túl sok akkor? Mert amikor elkezd swapolni a rendszer- noha igen ritka, akkor bizony kemény lassulások jönnek.
Tehát 1-2GB elég lenne? És menet közben tudod csökkenteni a swap méretét? Aztán a felszabadult helyre menet közben ki tudom terjeszteni a rendszerlemezt? Vagy ehhez egy liveCD kéne?

És persze a mágikus kérdés:
2x2GB DDR2-800 CL5 ramom van. Ganged, vagy Unganged módban érdemesebb használni? Most unganged.

openSUSE 12.3 64-bit w/ KDE

<off>

Van erről gondolatom, de nem írom, mert megint jön egy-két tag - értsd: intelligens, ám gyermeteg lélek -, akik úgy gondolják, náluk a bölcsesség, s minden hülyeség, ami attól eltér, vagy, mint sok esetben kiderül, nem is nagyon tér el, csak másképp kerül megfogalmazásra, mint ahogy ők helyesnek gondolnák. Mindeközben hardware fejlesztőként dolgoztam sokáig, itt meg valaki elmagyarázza nekem, hogy nem tudom, mi az a DMA. Kíváncsian várom, mikor derül ki rólam, hogy az Ohm-törvényt sem tudom. Úgy izgulok! ;)

</off>

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Carlcolt kolléga mutatott egy megoldást, kipróbáltad? Bizonyos rendszereken (Ubuntu pl.) nagyon magas a swapiness értéke (default 60). Ha ezt lentebb veszed (mondjuk 10), akkor nem fog a gép olyan agresszívan swappolni. echo 10 > /proc/sys/vm/swappiness

A túl sok swap ártani nem árt, szimplán pazarlás. Lehet 20GB swappod is, az nem befolyásolja a teljesítményt.
Csökkenteni úgy tudod, hogy:
1. Kikapcsolod a swappot: swapoff -a
2. Valamilyen particionáló programmal (kde partition manager pl.) törlöd a partíciót és újra létrehozod a kívánt méretben, a merevlemez végétől kezdve.
3. Formázod a kicsi swappot, majd lekérdezed a hozzá tartozó UUID-t (valahol a partíció információi között lesz).
4. Az fstab-ban a "swap sw" -t tartalmazó sorban kicseréled az UUID= értéket az újra.
5. swapon -a, bekapcsolod a swappot.

Az ext4 partíció online átméretezhető. A legtöbb partíciókezelő támogatja is a műveletet. Ha mégse, akkor resize2fs.

"Nettó baromság."

Ne olyan hevesen...

Van szerencsém papíron (értsd: semmi közöm hozzá, csak cseszegethető vagyok, ha gáz van) adminisztrálni olyan gépet, amin a swap messze nagyobb, mint amit az én sváb természetem átengedett volna a lemezből.

A használóinak kollektívája írt egy fork bombát (besegített nekik egy bug), és csak akkor szóltak, amikor a load 600 (hatszáz!) fölött járt. Fizikai memóriája régen nem volt már, és a swapnak is az utolsó negyedét rágta. Ezzel együtt hatalmas késleltetéssel, de elvégezte a hálistennek nem időkritikus munkáját, és még ssh sessiont is képes volt nekem adni, és (megint hatalmas késleltetéssel) befogani meg lefuttatni a tűzszerészeti célú parancsokat.

Annyi swappal, amit én adtam volna neki, ha én rakom össze, vagy ha érdekelt volna annyira a dolog, hogy visszavegyem, régen földbe állt volna az egész.

Háááát a rendszer egy 160GB-os samu IDE lemezről futkosik, de az egészet a rendszer használja. Van még 2 sata diszk is, egy 200GB-os samu és egy 500GB-os WD.
Amúgy riccenés nélkül megy, de valamiért mint írtam, sok ram van használatban és nem értem miért...

Elvileg az összes diszk 7200rpm-es.

openSUSE 12.3 64-bit w/ KDE

( carlcolt | 2013. 09. 16., h – 19:02 )

echo 1 > swappiness (nekem amúgy azóta nincs ilyen problémám mióta nem csinbálok swap space-t)
BFQ/BFS (Con Kolivas kernel patch) nem tudom van-e még, de én mielőtt SSD-re váltottam, azzal oldottam meg ezt a kérdéskört (SSD óta a noop is tökéletesen megfelel)

( tbs v | 2013. 09. 17., k – 07:07 )

Legutóbb akkor láttam ilyet, mikor a PCI buszon túl sokan ültek ugyanarra az irq vonalra (hálókártyák és alaplapi eszközök vegyesen)... Kézzel szétszedtem a bios segedelmévél, és lőn csoda.

De ez sem tegnap volt... :D :D

"PCI buszon túl sokan ültek ugyanarra az irq vonalra"
Ebben szerintem is lehet valami. Bár a mostani linux kernelek el szokták programozni a perifériákat egymástól. (dmesg-ben látszik)
De az biztos hogy 4g rammal phenom x4-gyel nem szabadna ezt csinálnia.
Nekem is ilyen gépem van. Ha nem bírsz vele, leírhatom minden optimalizációmat.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.