Particijų eiliškumas

Sveiki, ilgą laiką naudoju Ubuntu ir SWAP particiją kurdavau pačią paskutinę eilėje. Perskaičiau visai nesenai, kad ją kuriant pačią pirmą Ubuntu veikia greičiau. Tiesa? Ir šiaip klausimas dėl boot particijos. Ar ji padeda nors kiek greičiau užkrauti Ubuntu OS ? Na ir pagrindinis klausimas būtų koks visgi eiliškumas particijų geriausias? Pas mane šiuo metu yra taip:
swap - 4gb (Primary/Begin)
/boot - 1gb (Primary/Begin)
/ - 20gb (Primary/Begin)
/home - kas liko (Primary/Begin)

Ar reiktų kažką keisti? Laptopas gan senas su 2gb ramų ir dual core procesoriumi (Celeron) :) - IMB Thinkpad x60s .
Taip pat Ubuntu esu įdiegęs ant galingesnių kompiuterių (Tėvams ir draugei).

Ačiū

Sveiki, ilgą laiką naudoju Ubuntu ir SWAP particiją kurdavau pačią paskutinę eilėje. Perskaičiau visai nesenai, kad ją kuriant pačią pirmą Ubuntu veikia greičiau. Tiesa?

HDD veikia ne taip kaip CD, tai kad skirsnis bus pirmas nereiskia jog jis bus greiciau pasiektas HDD.

Ir šiaip klausimas dėl boot particijos. Ar ji padeda nors kiek greičiau užkrauti Ubuntu OS ?

Atskirai /boot gali praversti jeigu naudojamas RAID, LVM, encryption... Seniau su Grub budavo tokiu problemu kaip nepalaikomos failu sistemos, dabar tokiu problemu nebera tad desktopams atskiras /boot visiskai nereikalingtas.

Na ir pagrindinis klausimas būtų koks visgi eiliškumas particijų geriausias? Pas mane šiuo metu yra taip:
swap - 4gb (Primary/Begin)
/boot - 1gb (Primary/Begin)
/ - 20gb (Primary/Begin)
/home - kas liko (Primary/Begin)

Ar reiktų kažką keisti? Laptopas gan senas su 2gb ramų ir dual core procesoriumi (Celeron) :) - IMB Thinkpad x60s .
Taip pat Ubuntu esu įdiegęs ant galingesnių kompiuterių (Tėvams ir draugei).

swap - 4GB (priklauso nuo atminties)
/ - 20GB (iki 40GB, daugiau nera teke matyti kad naudotu).
/home - kiek liko (bet ir tai nera butina naudoti atskirai).

Jeigu nori pagreitinti tai pasirink kita desktop'a, ka nors daug lengvesnio. Swap nereikalingas jeigu atminties yra 8GB+, jeigu jau nutiks taip kad atminties neliks tai geriau programai leisti "mirti", nes programoms nebudinga naudoti tiek atminties (anyway jeigu pasieke 8Gb - pasieks ir 80GB).

BTW, del disku greicio pagal ideja tiesos tame yra...
https://www.youtube.com/watch?v=d0xn68w3KPE

@bICEQ said:
Sveiki, ilgą laiką naudoju Ubuntu ir SWAP particiją kurdavau pačią paskutinę eilėje. Perskaičiau visai nesenai, kad ją kuriant pačią pirmą Ubuntu veikia greičiau. Tiesa?

Štai čia yra visai gerai išaiškinta, kaip veikia HDD. Buvau kažkada skaitęs kažkokiuose (labiau autoritetingų žmonių) mailing-listuose apie tą patį, bet ten faktiškai reziumė to pokalbio pateiktas.

Taigi, HDD pradeda rašyti nuo išorinės briaunos, kur sukimosi momentas yra didžiausias, todėl ir sparta yra didžiausia, ir baigia ties vidine briauna, kur sparta mažiausia. Automatiškai pirmieji (maži) skirsniai bus sparčiausi. Jei sukursi 2 GB skirsnį patį paskutinį - jis turėtų atsidurti arčiausiai vidinės HDD briaunos, taigi turėtų būti lėtesnis.

Aš labai galvos dėl to nesukčiau, manau, greičių skirtumai yra labiau laboratoriniai nei kažką nulemiantys praktiškai.

Ir šiaip klausimas dėl boot particijos. Ar ji padeda nors kiek greičiau užkrauti Ubuntu OS ?

Greičiau - Ne. Tu tiesiog žinai, kad visi reikalingi duomenys, kad užkurti tavo kompiuterį, guli tame pačiame skirsnyje.

Na ir pagrindinis klausimas būtų koks visgi eiliškumas particijų geriausias? Pas mane šiuo metu yra taip:
swap - 4gb (Primary/Begin)
/boot - 1gb (Primary/Begin)
/ - 20gb (Primary/Begin)
/home - kas liko (Primary/Begin)

Aš asmeniškai labiau mėgstu turėti pirmą boot, tada swap, o paskui pagal situaciją.

Kaip ir minėjau, fizinė skirsnio padėtis turi įtakos spartai, tačiau keliasdešimties (gal labiau kelių šimtų) gigabaitų diske ar bus pirmi 2 GB boot, ar swap - tikrai nieko nelemia. Čia kur kas svarbiau loginis išdėstymas - boot reikalingas tavo sistemai užkrauti, taigi turėtų būti pats pirmas. swap bus naudojamas tik tada, jei tavo sistema užsikraus, taigi turėtų būti po boot skirsnio.

Beje, swap idealiu atveju turi būti naudojamas tik kraštutiniais atvejais, kai nebepakanka sparčiosios atminties. Lyginant su sparčiaja atmintimi (RAM) tavo diskas atrodys taip apgailėtinai lėtas, kad sutaupytos kelios mikrosekundės parenkant fizinę skirsnio vietą, vargu ar turės praktinės reikšmės.

Ar reiktų kažką keisti? Laptopas gan senas su 2gb ramų ir dual core procesoriumi (Celeron) :) - IMB Thinkpad x60s .

Standartinė swap formulė yra tokia: swap = 2 x RAM. Pas tave swap 4GB - tad šaunuolis Bet kaip jau minėjau, swap turi būti ir yra naudojamas tik kaip kraštutinė priemonė. Aš tavo vietoj skirčiau swap 2GB.

Iš esmės pritariu Ghost komentarui, tačiau norėčiau papildyti/paprieštarauti (taip pat ir Techtronic komentarams apie 8gb ram ir swap).

@Ghost said:
Beje, swap idealiu atveju turi būti naudojamas tik kraštutiniais atvejais, kai nebepakanka sparčiosios atminties. Lyginant su sparčiaja atmintimi (RAM) tavo diskas atrodys taip apgailėtinai lėtas, kad sutaupytos kelios mikrosekundės parenkant fizinę skirsnio vietą, vargu ar turės praktinės reikšmės.

Šiuolaikinėse sistemose atminties naudojimas yra labai gerai optimizuotas ir visos sistemos aktyviai naudoja ir taiko tokią praktiką, kaip atminties perkėlimas į swapus, o ypač su ssd diskais. Taip vyksta, nes tam tikra dalis atminties yra per retai naudojama, kad šiuos procesus/jų informaciją būtų verta laikyti RAM'e, jeigu ten jau peržengta kažkuri resursų riba. Dėl Ubuntu ar kitų Linux sistemų negaliu garantuoti, bet win ir osX su tuo susitvarko labai optimizuotai ir našiai. Viena didesnių išimčių - dideli JVM'ai, kadangi jie kartais gali siekti ir daaaaug gigabaitų (kompleksiškas projektas paleistas per kokį IDE) ir jis negali būt išskaidytas - tada sistema force'inama išsijungti ir tai nutinka netgi be jokio klaidos pranešimo :D . Šitą esu patyręs su 12GB RAM turinčia Ubuntu mašina :D

O kas dėl fizinės skirsnių vietos - jeigu nesiruoši naudoti pusės lėto disko vienai particijai, kuri bus visiškai užpildyta - tikrai nepajusi jokio skirtumo.

@eko said:
Šiuolaikinėse sistemose atminties naudojimas yra labai gerai optimizuotas ir visos sistemos aktyviai naudoja ir taiko tokią praktiką, kaip atminties perkėlimas į swapus, o ypač su ssd diskais. Taip vyksta, nes tam tikra dalis atminties yra per retai naudojama, kad šiuos procesus/jų informaciją būtų verta laikyti RAM'e, jeigu ten jau peržengta kažkuri resursų riba.

Dėkui, įdomios mintys. Bet kiek žinau, parenkant kur ir kiek padėti yra naudojama tam tikra reliatyvumo teorija (turiu raumeny, kad egzistuoja tamprūs ryšiai tarp to kiek reikia, ir kiek yra patiekta).

Čia turiu pacituoti Techtronic (paryškinau, kas manau, yra svarbiausia):

jeigu jau nutiks taip kad atminties neliks tai geriau programai leisti "mirti", nes programoms nebudinga naudoti tiek atminties (anyway jeigu pasieke 8Gb - pasieks ir 80GB).

Programos/apps'ai turi mokėti veikti be swap ir tai turi būti apibrėžta jų minimaliuose reikalavimuose, taškas. Jei sistema netenkina minimalių app reikalavimų - reikia susirūpinti (ir Neturiu galvoje didinti swap gigabaitų skaičių).

Prisimenant:

Taip vyksta, nes tam tikra dalis atminties yra per retai naudojama, kad šiuos procesus/jų informaciją būtų verta laikyti RAM'e, jeigu ten jau peržengta kažkuri resursų riba. <...> Viena didesnių išimčių - dideli JVM'ai, kadangi jie kartais gali siekti ir daaaaug gigabaitų (kompleksiškas projektas paleistas per kokį IDE) ir jis negali būt išskaidytas - tada sistema force'inama išsijungti ir tai nutinka netgi be jokio klaidos pranešimo :D . Šitą esu patyręs su 12GB RAM turinčia Ubuntu mašina :D

Manau, tas app labai neefektyviai naudojo resursus (priklausomai nuo situacijos bug report tinka) arba tavo workstation neatitiko minimalių app reikalavimų.

Taip pat (šiais laikais vis dar) dažnai pamirštama, kad daug resursų reikalaujančiom operacijom galima panirti į debesį (cloud-computing)

@eko Atminties perkėlimas į swapa? Gal galima placiau, nes nera teke girdeti tokios praktikos.

P.S. Kam jums atskirai /boot?

Dar viena rekomendacija, kuria primirsom jau visi(?!) - Jeigu jau tenka naudoti swap, tai bent su swappiness nustatom taip jog naudotu tik tada kai nera kitos iseities.

@Techtronic https://www.tenforums.com/tutorials/21904-disk-write-caching-enable-disable-windows-10-a.html
Vienas iš pavyzdžių, nors ir ne visai tai apie, ką kalbėjau, greitai nepavyko sugalvoti tikslesnės google paieškos. Mano apibūdinto scenarijaus principas tas pats, kaip ir aprašyto nuorodoje. Galbūt aš ne taip išsireiškiau, bet geriau to proceso apibrėžti negalėjau (labi (labai retai naudojamos laikinosios atminties-RAM perkėlimas į hdd-swap). Daugiau nelabai galiu papasakoti šiuo klausimu, tiesiog kažkada teko susidurt.

@Ghost IntelliJ nepavadinčiau neefektyviai resursus naudojančia programa. Workbookas minimalius reikalavimus tenkino, tiesiog projektas, kuris turėjo būti paleistas JVM'e buvo tiesiog per didelis likusiai RAM'o vietai. Ir taip, tai yra reliatyvumo teorija, nes tai yra visiška loterija ir sistema įprastai vengia tokių veiksmų, bet vistiek geriau, nei nieko, o su SSD diskais tam tikrais atvejais nepajusi skirtumo ar tau cache'ins į RAM'ą ar į SSD.

@eko said:
@Ghost IntelliJ nepavadinčiau neefektyviai resursus naudojančia programa. Workbookas minimalius reikalavimus tenkino, tiesiog projektas, kuris turėjo būti paleistas JVM'e buvo tiesiog per didelis likusiai RAM'o vietai. Ir taip, tai yra reliatyvumo teorija, nes tai yra visiška loterija ir sistema įprastai vengia tokių veiksmų, bet vistiek geriau, nei nieko, o su SSD diskais tam tikrais atvejais nepajusi skirtumo ar tau cache'ins į RAM'ą ar į SSD.

Tokiu atveju, IntelliJ IDE yra tik aplinka (shell), kurioje dirba (yra paleistas) tavo projektas. Kaip suprantu, auga ne IntelliJ IDE failai, bet tavo parašyto projekto failai. Jei taip, tada tavo app nelabai apdairiai naudoja sistemos resursus, neatsižvelgia į esamą RAM/SWAP kiekį ir augina savo cache kol visai užlaužia PC.

Jei teisingai supratau, žemiau esantis pavyzdys atspindi tavo situaciją. Kad ir kaip norečiau, bash (aplinkos, kurioje paleistas scenarijus) kaltinti negaliu, nes kaltas mano kvailas scenarijus, kuris neatsižvelgia į tai, kiek turiu RAM/SWAP, ir galiausiai užkimš visą atmintį, taip pat užlauš ir mano PC:

# mkdir /mnt/tmpfs
# mount -t tmpfs -o size=1000G tmpfs /mnt/tmpfs/
# dd if=/dev/zero of=/mnt/tmpfs/didesnis_nei_ram bs=1M

Taip, kaltas appsas, nes jis tikrai didelis.

Aš asmeniškai labiau mėgstu turėti pirmą boot, tada swap, o paskui pagal situaciją.

Super, galvojau taip pat jas paskirstyt nes tai tiesiog LOGIŠKAI atrodo :)

Galima limituoti atminti per programa, tai nera sudetinga naudojant modernias distras (su systemd!):

Tarkim turime programa kuri naudoja labai daug atminties:

// gcc test.c -o test
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

int main(int argc, char** argv) {
    int max = -1;
    int mb = 0;
    char* buffer;

    if(argc > 1)
        max = atoi(argv[1]);

    while((buffer=malloc(1024*1024)) != NULL && mb != max) {
        memset(buffer, 0, 1024*1024);
        mb++;
        printf("Allocated %d MB\n", mb);
        sleep(1);
    }      
return 0;
}

Surenkame ir paleidziame: gcc test.c -o test && ./test

Allocated 1 MB
Allocated 2 MB
[...]
Allocated 9 MB
Allocated 10 MB
Allocated 11 MB
[...]

Atsargiai, ilgiau palikta veikti programa gali freeze visa sistema, kad taip nenutiktu galima limituoti kiek ji naudos atminties.

Sukuriame nauja cgroup:

cgcreate -g memory:/ubuntult

Nustatome kiek leisime naudoti atminties:

echo $((10 * 1024 * 1024)) > /sys/fs/cgroup/memory/ubuntult/memory.limit_in_bytes

Tikrinam ar veikia:

cgexec -g memory:ubuntult ./test

Dabar programa mirs pasiekus ta limita, o tai kur kas geriau nei freeeze visa sistema.

Allocated 1 MB
Allocated 2 MB
[...]
Allocated 7 MB
Allocated 8 MB
Allocated 9 MB
Killed

@eko Kaip ir visi siais laikais diskai turi savo cacha, taipogi kvaila manyti jog programa dirbs kaip priklauso sistemoje kuri neatitinka minimaliu tos programos reikalavimu.

P.S Kaip ir sulaukem nauju metu, kuom ir sveikinu visus. Tikiuosi siais metais nepaves GC musu sistemu!

@Techtronic said:

// gcc test.c -o test
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

int main(int argc, char** argv) {
    int max = -1;
    int mb = 0;
    char* buffer;

    if(argc > 1)
        max = atoi(argv[1]);

    while((buffer=malloc(1024*1024)) != NULL && mb != max) {
        memset(buffer, 0, 1024*1024);
        mb++;
        printf("Allocated %d MB\n", mb);
        sleep(1);
    }      
return 0;
}

Python versija :

#!/usr/bin/env python3
# coding: utf-8

from time import sleep
from sys import getsizeof

pow_of_two = ['B','KB','MB','GB','TB']
bytes_dict = {x: 1024**pow_of_two.index(x) for x in pow_of_two}

def write_buffer(
    step: 'default is 1MB' = 1 * bytes_dict['MB'],
    last: 'default is 4GB' = 4 * bytes_dict['GB']):
    while True:
        in_memory = getsizeof(bytearray(step))
        msg = 'Dumped to memory: {0} bytes (~{1}MB)'
        print(msg.format(in_memory, in_memory // bytes_dict['MB']))
        step += step
        if last % step >= last:
            break
        sleep(1)

write_buffer()

Išvestis:

# chmod +x test.py; ./test.py
Dumped to memory: 1048633 bytes (~1MB)
Dumped to memory: 2097209 bytes (~2MB)
Dumped to memory: 4194361 bytes (~4MB)
Dumped to memory: 8388665 bytes (~8MB)
Dumped to memory: 16777273 bytes (~16MB)
Dumped to memory: 33554489 bytes (~32MB)
Dumped to memory: 67108921 bytes (~64MB)
Dumped to memory: 134217785 bytes (~128MB)
Dumped to memory: 268435513 bytes (~256MB)
Dumped to memory: 536870969 bytes (~512MB)
Dumped to memory: 1073741881 bytes (~1024MB)
Dumped to memory: 2147483705 bytes (~2048MB)
Dumped to memory: 4294967353 bytes (~4096MB)