Saal

Allikas: Kuutõrvaja

Sissejuhatus

Nagu paljud UNIXilised võimaldab ka Linux kasutada füüsilise sisemälu (RAM) "pikenduseks" kõvaketast. Kõvaketta piirkonda mida operatsioonisüsteem käsitleb efektiivselt mäluna nimetatakse saaliks. Sisemälu ja saal moodustavad kokku arvuti efektiivse mälu. Töötavad programmid hoolivad arvuti efektiivsest mälust, vaatamata sellele, et saal toimib umbes tuhat korda rahulikamalt sisemälust.

Algse reeglina määrati saali suuruseks topelt sisemälu maht, näiteks omades sisemälu 64 MB tuleks tekitada 128 MB suurune saal. Saali suurus võiks olla arvu neli kordne.

Saal võib asuda failisüsteemi failis või eraldi partitsioonil. Kui süsteemis on mitu füüsilist kõvaketast, siis on mõtekas tekitada mitu saali erinevatele ketastele, eelistatult partitsioonina.

Linux võimaldab kuni 8 saali korraga kasutamist (vananenud väide, vajaks kontrollimist!).

Saali ehk swapi aktuaalsus tänapäeval

Jõude seisvaid mälu-lehekülgi svapitakse välja, et teha ruumi kettapuhvritele või muule, mis parasjagu mälu rohkem vajavad. Väidetakse ka, et tegemist Linuxi mäluhalduse eripäraga ja kui svappi ei tee, siis tabavad tõsised performance-probleemid (iga Linuxi install ütleb ju seda!). Ja et kui mälu juhtub ikkagi otsa saama, siis server krässib.

Päris nii see tegelikult pole.

kuna saal-swap tehakse ikkagi piiratud suurusega partitsioonile, siis on ka selle partitsiooni suurus lõpuks piiratud ja sellega lõplik ka summaarne virtuaalmälu kogus, mida füüsilise mälu ja svapi koosluses saab kasutusele võtta. Ja kui see otsa lõpeb, siis on ikkagi jama majas. Kui korrektne olla, siis tänasel päeval server ei krässi, vaid hakkab mälupuudused omi protsesse tapma. Ja normaalolukorras sellise olukorrani ei jõutagi. Ja KUI jõutakse, siis see tähendab, et kusagil mälu lekib ning siis see juhtub senikaua, kuni KOGU mälu on otsas, sõltumata sellest, kui palju ma seda svappi tegin. Küsimus on lihtsalt selles, kas see juhtub varem või natukene hiljem

Põhjus miks swapi loomise soovitus (ja teatud suurusega loomise) ikka veel "elus" on on hiberneerimine. Nimelt ei kirjuta Linux mälutõmmist mitte eraldi faili vaid hiberneerimiskäsu saades swapib kõigepealt kõik asjad välja ja siis salvestab protsessori registrid ja muud viimased nipet-näpet sinna otsa eraldi kohta. On selge, et kui swappi on liiga vähe, siis hiberneerimine ei õnnestu. Serverid on tavaliselt aga optimeeritud ja tuunitud ja hoolika adminni poolt kontrollitud, et seal töötavad ainult need protsessid mis vaja (ja need ise on ka tuunitud, et nad ei teeks midagi liigset).

Seetõttu serverites tavapärast swappimist kettapuhvrite nimel palju ei toimu. Lisaks, tuginedes aastatetagusele kogemusele suure veebiserveriga-ga, see olukord, kus RAM saab täis aktiivses kasutuses olevat mälu ja seda hakatakse juba otsast swappi kirjutama ja järgmisel hektel sealt siis lugema - selle puhul on asi juba lootusetu ja tegelikult, ma usun, taastuks süsteem kiiremini, kui tal üldse swappi poleks. Pika koomlemise asemel tapetaks lihtsalt läbustaja ära ja asi korras.

Ühesõnaga sawpi vajadus tänapäevastel serveritel on kaheldav ning üle 2GB ei maksa seda teha enam kuhugi. Kui sul on 24-48 GB mäluga server, siis ka RAM=swap lahendusega läheb mälulekkega swapima hakates masin nii kooma et sellega pole midagi võimalik teha.

Desktoppides on oluliselt rohkem rakendusi, mis tarbivad palju mälu, kuid mis ei kasuta seda pidevalt. Seega on seal palju mälulehti, mida tasub kettapuhvride suurendamise nimel välja saalida. Samas ka swappivas Desktopis ei ole võimalik töötada (minuarust isegi mitte SSDga). Seega, kui desktopi masinas on swap olemas, siis olgu vm.swappiness = 10 või isegi 0 Põhjus on see, et tööjaamas "munevad" ka "vajalikud" asjad (brauser, desktop jne) ning tüütu on pärast paaritunnist pausi arvuti juurde tagasi tulla ja peale hiire liigutamist oodata kuidas screensaver ja ülejäänud osa desktoppi swapist tagasi mällu krõbistatakse.

Kogu jutu kokkuvõtteks oleks, et swap võiks olla eelkõige just desktopis hiberneerimise funktsiooni kasutades. Serverites võib julgemalt ära jätta, seal kipub mälu otsasaamine olema juba märk kroonilisest lekkest ja siis on hea kui jama maha lüüakse swapimise asemel (sekkub OOM Killer).

Serveris võiks igaks ka juhuks ilma swapita jooksutades sysctl-i abil vm.swappiness=0 peale sättida.

# cat /proc/sys/vm/swappiness
60

Muudame

# sudo sysctl vm.swappiness=0
vm.swappiness = 0

Ja kirjutame selle konfi ka /etc/sysctl.conf

Partitsiooni kasutamine saalina

Saali tekitamisel markeeritakse vastav partitsioon kusjuures hävivad seal olnud andmed. Partitsioonile soovitakse omistada vastav tüüp - 82. Tehke seda näiteks programmi Fdisk abil.

Näiteks otsustades markeerida partitsioon /dev/hda6 saalina anke korraldus

bash# mkswap /dev/hda6

Faili kasutamine saalina

Kasutamaks saalina 64MB faili tekitage esmal fail, näiteks selliselt

bash# dd if=/dev/zero of=/saal1 bs=1024 count=65536

ning seejärel markeerige

bash# mkswap /saal1                    
Setting up swapspace version 0, size = 67104768 bytes

Saale tuleb vaid üks kord markeerida, mitte enne iga kasutuselevõttu.

Saali kasutuselevõtt

Saali kasutuselevõtmisega näidatakse operatsioonisüsteemile, et ta võib vastavat seadet või faili saalina tarvitama hakata ning nii suureneb arvuti efektiivse mälu hulk.

Näiteks võtame kasutusele loodud saali faili /saal1

bash# swapon /saal1

Soovides uurida kas arvuti efektiivse mälu hulk muutus kasutage käsku top ja free.

Saali kõrvaldamiseks kasutage käsku swapoff, näiteks

bash# swapoff /saal1

Kui saal asub partitsioonil on otstarbekas ta kasutusele võtta juba süsteemi käivitumise ajal. Selleks lisage /etc/fstab faili vastav rida, näiteks

/dev/hda6       swap        swap        defaults   0   0

Kui saal asub failis, siis lisage vastav käsk süsteemi sobivasse käivitusskripti, näiteks /etc/rc.d/rc.local.

Saal ja mälu pakkimine

RAM access on ca 40-60ns latency, SSD puhul me räägime mikrosekunditest. Igal juhul on swap 2-3 suurusjärku aeglasem access niiet jäädes RAM juurde isegi kulutades CPU tsükleid pakkimisele ja lahti pakkimisele on võimalik tohutult aega kokku hoida

Linuxile on olemas ZRam http://en.wikipedia.org/wiki/ZRam lahendus, kus saalimise asemel hakkab kernel mälu pakkima. Ehk täpsemalt tekitab see lahendus mällu pakitud swap failid.

Paigaldamiseks ubuntul/debianil

# apt-get install zram-config

Seda kas zram toimib saab kontrollida proc failisüsteemis vaadates kas /dev/zram partitsioonid on sinna tekkinud.

# cat /proc/swaps

Dmesgis võib mälu otsalõppemisel näha sisselülitatud zrami korral nt järgnevat pilti:

[   17.894941] zram: module is from the staging directory, the quality is unknown, you have been warned.
[   17.898105] zram: Created 12 device(s) ...
[   17.902708] Adding 1369640k swap on /dev/zram0.  Priority:5 extents:1 across:1369640k SSFS
[   17.904935] Adding 1369640k swap on /dev/zram1.  Priority:5 extents:1 across:1369640k SSFS
[   17.907456] Adding 1369640k swap on /dev/zram2.  Priority:5 extents:1 across:1369640k SSFS
...
[   17.923969] Adding 1369640k swap on /dev/zram11.  Priority:5 extents:1 across:1369640k SSFS

Statistika

$ zramconfig /dev/zram0 --stats

Kui masinal on suurtes kogustes (nt 16-32G) mälu pole ilmseltn kasutamine väga mõtekas. Eemaldamiseks Debianis/Ubuntus

# apt-get purge zram-config

http://wiki.gentoo.org/wiki/Zram

OS X Mavericis on olemas RAM compression. Et kui RAM hakkab täis saama, siis ta enne swappimist hakkab hoopis low priority RAM kasutuse osa pakkima arvestades, et CPU tsüklid koos RAM accessiga on kordi ja kordi väiksem ajakulu kui disk access. Ning vähemalt testid mida netis on tehtud on näidanud, et indeed Mavericks hoiab swapist eemal nagu katkust. Pigem ta tõmbab oma buffreid kokku ning kukub pakkima ja igast muud tegema suutes mahutada kuni 50% asju RAM-i ja alles siis kapituleerub ja pistab varba swapi alasse. See on minumeelest väga progressiivne disain võttes arvesse mis on tegelt ka kiire ja mis ei ole