Pomalé swapovanie
Chcem sa opýtať, či je pomalé swapovanie problémom Linuxu, problémom Ubuntu, alebo mám problém hľadať niekde celkom inde. Linux vnímam v porovnaní s Windows ako rýchlejší OS, ale len do chvíle, kým mi nezačne swapovať. Mám 4 GB RAM, po odpočítaní pre grafiku 3.7 GB. Keď prekročím cca 3.1 GB, môžem kľudne od počítača odísť, najbližších pár minút toho veľa neurobím. Nespomínam si, že by som také citeľné spomalenie počítača niekedy zažil vo Windows...
Pre pridávanie komentárov sa musíte prihlásiť.
Linux swapuje až keď nemá voľnú pamäť. A ak sa mu minie, tak zahodí diskovú cache aby jednoducho nemusel swapovať. Stále je to pri bežnej prevádzke swižnejšie ako v prípade windows.
Inak, pri 4G swaponanie? Skús povedať čo robíš, a ako sa má sledovanie vyťaženia systému cez napríklad
htopaiotop.Co robim? Webovy prehliadac mam otvoreny skoro vzdy a spravidla su to desiatky kariet. Kvoli tomu sa u mna opat na prve miesto vratil Firefox na ukor Chrome, kedze ten nepodporuje nacitavanie kariet podla potreby. Ale aj Firefox alebo Opera maju dost velke naroky na RAM. Ale to som trochu odbocil. Druha vec, co mam v takom pripade spustenu, je Virtualbox. Nechce sa mi restartovat PC vzdy, ked potrebujem urobit nieco vo Windows.
Takze to swapovanie je de facto vzdy pri sucasnom chode Virtualboxu a niektoreho z prehliadacov, pripadne este par dalsich aplikacii.
total used free shared buffers cached
Mem: 3794 3667 126 0 5 318
-/+ buffers/cache: 3344 449
Swap: 3908 1036 2872
top - 20:44:31 up 3:34, 2 users, load average: 4,53, 4,26, 3,25
Tasks: 220 total, 1 running, 219 sleeping, 0 stopped, 0 zombie
%Cpu(s): 14,4 us, 15,6 sy, 0,0 ni, 36,6 id, 33,3 wa, 0,0 hi, 0,2 si, 0,0 st
KiB Mem: 3885152 total, 3729076 used, 156076 free, 9644 buffers
KiB Swap: 4002812 total, 1314996 used, 2687816 free, 510120 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5732 lubo 20 0 3360m 1,6g 1,6g S 22,3 43,1 3:30.73 VirtualBox
5794 lubo 20 0 541m 14m 7976 S 11,6 0,4 2:26.38 gnome-system-mo
4306 root 20 0 183m 16m 3880 S 10,6 0,4 2:32.66 Xorg
5894 lubo 20 0 836m 50m 13m S 6,3 1,3 1:08.60 chrome
4665 lubo 20 0 1564m 23m 9800 S 5,6 0,6 3:48.62 compiz
5464 lubo 20 0 1537m 373m 18m S 2,7 9,8 3:20.58 firefox
5827 lubo 20 0 589m 11m 6868 S 2,7 0,3 0:01.62 gnome-terminal
5583 lubo 20 0 404m 4580 4016 S 1,0 0,1 0:19.55 plugin-containe
5970 lubo 20 0 930m 51m 8240 S 0,3 1,3 0:02.80 chrome
6014 lubo 20 0 941m 57m 8176 S 0,3 1,5 0:07.84 chrome
6489 root 20 0 0 0 0 S 0,3 0,0 0:00.09 kworker/0:1
6499 lubo 20 0 24952 1648 1144 R 0,3 0,0 0:00.03 top
1 root 20 0 24584 1684 1084 S 0,0 0,0 0:00.73 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:01.23 ksoftirqd/0
6 root rt 0 0 0 0 S 0,0 0,0 0:00.00 migration/0
7 root rt 0 0 0 0 S 0,0 0,0 0:00.04 watchdog/0
free -m
total used free shared buffers cached
Mem: 3794 3664 129 0 4 515
-/+ buffers/cache: 3143 650
Swap: 3908 1314 2594
Prideluješ VirtualBoxu (guest systemu na ňom) príliš veľa pamäte (RAM). Tá potom chýba host systému (UBUNTU) a všetko čo beží na UBUNTU ide pomaly a to čo beží na guest systeme "funguje". Zredukuj množstvo pridelenej RAM guest systému. Nastaviť to treba v konfigurácii danej VM vo VirtualBoxe.
SWAPovanie nie je určené na bežné fungovanie, je to východisko z núdze, aby systém nepadol. Navyše ak má VirtualBox určené, že sa swapovať nebude, tak aj keď v guest systéme nerobíš, zostane celý v RAM, namiesto toho, aby sa uložil do swapu. Zníženie priority aplikáciám v guest systéme v takom prípade nepomôže.
Jednoducho povedané, je to ako by si sa snažil na PC s 500 MB RAM pracovať s FF alebo Chrome pri desiatkach otvorených kariet.
Ani UBUNTU, linux kernel, ani Chrome či FF za spomalenie práce nemôžu. Za to môže nedostatok pamäťe RAM a o niekoľko rádov pomalší prenos údajov z disku oproti RAM. Presne ako písal WlaSaTy: Dokúpiť RAM je jedna možnosť. Druhá zredukovať objem RAM pridelenej guest systému.
Windows pouzivam cca 16 rokov a nieco podobne som zazil iba na starych masinach s velmi poddimenzovanou RAMkou.
Jediné čo má v tomto prípade Windows zdanlivo lepšie je, že umelo znižuje prioritu procesom na pozadí. Ale v reále je to opruz. Najmä ak potrebuješ databázu.
Inak, ak Ti vadí, že Ti virtuálka zabíja prostriedky a blokuje prehliadač, tak jej zníž prioritu a aj execution caps.
A porovnaj túto situáciu s windows. Nehaj si virtuálku Vah pozadí minimalizovanú a otvor si tú session vo firefoxe z Linuxu. A po hodinke browsovania si vyvolaj virtuálku na popredie.
PS preto som odporúčal iotop. V ňom by si to videl.
Ale asi s tym nic neurobim, ak som Ta dobre pochopil, je to vlastnost Linuxu, takze by mi nepomohla ani zmena distribucie.
Ak tú hatmatilku nerozumieš, tak si kúp dostatočné množstvo RAM. A prestaň sa chovať ako užívateľ v minulom tisícročí, najmä ak Ťa od neho odlišuje absencia trpezlivosti.
A ako sa chova uzivatel v 3. tisicroci? Kupi si 8 GB RAM, ked mu nestacia 4 GB?
Inak, ak bude bežať tá virtuálka, tak bude stále musieť mať svoju pamäť v RAM. Takže najjednoduchšie riešenie (ak nechceš zainvestovať do upgrade) je odsledovať si koľko swapu je použitého v danom prípade. A potom jej ubrať o kúsok viac.
Inak, to vypnutie defragmentácie by pomohlo, len ak by sa k tomu zaseknutiu dostalo len raz a kernel by defragmentoval pamäť tak aby boli najväčšsie kusy (v tomto prípade zrovna tá virtuálka a aj firefox) upratané. Ale, pokiaľ sa to opakuje, tak je naozaj žiadané neplytvať prostriedkami alebo si priradiť dostatok prostriedkov.
PS: Neviem do akej hĺbky Ťa zaujíma riešenie, ale tie cudzie slovíčka čo som spomínal majú pekné vysvetlenie aj s príkladmi. S ich pomocou sa dá krásne vytuniť aj priorita swaponavia a podobných vecí.
Keby sa mi nechcelo, tak si v kľude zaplatím za podporu ktorá to za mňa vyrieši sama do času definovaného v zmluve.
No, nič. Maj sa.
Teda este dokupit RAM-ku a ked na to nemam, tak si nainstalovat 32-bitovy system...
skus:
echo never >/sys/kernel/mm/transparent_hugepage/defragpripadne dalsie nastavenia v /sys/kernel/mm/transparent_hugepage/
bash: /sys/kernel/mm/transparent_hugepage/defrag: Prístup odmietnutý