Forum Debian Users Gang

a zobacz przy priorytecie typu 40 albo 80. Gdy zacznie brakować RAMu system wcześniej zacznie korzystać ze SWAPa niż nagle przy 95% zajętym RAMie zaczyna masowo przerzucać na SWAP.
pokaż też

swapon -s

na twoim miejscu zrobiłbym sobie test;

swapoff /dev/sdaX

wyłączył SWAP. z tego co pamiętam masz 1GB RAMu ,więc;

#!/bin/bash
modprobe zram
echo $((900*1024*1024)) > /sys/block/zram0/disksize
mkswap /dev/zram0
swapon -p 60 /dev/zram0

i zobacz co się stanie jak zajmiesz >1GB RAMu. Powinno być znacznie lepiej niż bez tego rozwiązania.

Próbuje włączyć u siebie to zram ale aptosid widać tego nie obsługuje:

root:~# modprobe zram
FATAL: Module zram not found

root:~# zcat /proc/config.gz | grep -i zram

Poszukałem zatem czy coś od zram mam na dysku:

root:~# find / -iname *zram*
/usr/src/linux-headers-3.10-3-amd64/include/config/zram.h
/usr/src/linux-headers-3.12-0.slh.1-aptosid-amd64/drivers/staging/zram
/usr/src/linux-headers-3.10-3-rt-amd64/include/config/zram.h
/lib/modules/3.10-3-rt-amd64/kernel/drivers/staging/zram
/lib/modules/3.10-3-rt-amd64/kernel/drivers/staging/zram/zram.ko
/lib/modules/3.10-3-amd64/kernel/drivers/staging/zram
/lib/modules/3.10-3-amd64/kernel/drivers/staging/zram/zram.ko

Doszukałem się jeszcze, że zram zależy od 3 parametrów CONFIG_BLOCK, CONFIG_SYSFS oraz CONFIG_ZSMALLOC:

Aptosid:

root:~# zcat /proc/config.gz | grep -i CONFIG_BLOCK
CONFIG_BLOCK=y
CONFIG_BLOCK_COMPAT=y
root:~# zcat /proc/config.gz | grep -i  CONFIG_SYSFS
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_SYSFS=y
root:~# zcat /proc/config.gz | grep -i  CONFIG_ZSMALLOC
# CONFIG_ZSMALLOC is not set

# CONFIG_ZRAM_DEBUG is not set
root:~# cat /boot/config-3.10-3-amd64 | grep -i CONFIG_ZSMALLOC
CONFIG_ZSMALLOC=y
root:~# cat /boot/config-3.10-3-amd64 | grep -i CONFIG_SYSFS
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_SYSFS=y
root:~# cat /boot/config-3.10-3-amd64 | grep -i CONFIG_BLOCK
CONFIG_BLOCK=y
CONFIG_BLOCK_COMPAT=y
root:~# cat /boot/config-3.10-3-amd64 | grep -i zram
CONFIG_ZRAM=m

Przełączyłem się póki co na debianowego kernela i tutaj już ładowanie modułu działa. Tylko mam parę pytań odnośnie tego textu http://rozie.blox.pl/2011/11/Praca-na-destkopie-z-m … M-po-raz.html

Tam są takie zapisy:

Idea działania jest prosta: tworzymy swap z wyższym priorytetem, niż swap na dysku, na urządzeniu blokowym umieszczonym w kompresowanym obszarze pamięci. Początkowo dane tradycyjnie są w RAM, w przypadku, gdy system musi korzystać z przestrzeni wymiany, umieszcza je najpierw na swapie w RAM, a dopiero później - tradycyjnie - na swapie na dysku.
...
określenie rozmiaru dysku dla urządzenia /dev/zram0 na 200 MB (i jest to rozmiar swap, będący jednocześnie maksymalną wielkością zużytej pamięci, nie rozmiarem przeznaczonej pamięci na swap!)

Czyli tak po ludzku, jak to działa?

Stworzyłem te 900MiB w /dev/zram0 i co to dokładnie jest? Za bardzo nie wiem jak traktować "maxymalną wielkość zużytej pamięci".

Zgodnie z tamtym textem,  jak zaczyna brakować ramu to wtedy są zrzucane do swap w ramie? Przecie już brakuje ramu. xD W każdym razie wyłączyłem swap kompletnie i przetestowałem te 900MiB, które nie wiem gdzie zostało utworzone, czy co tam z tym zostało zrobione. Załadował do pamięci jakieś 800MiB i jakieś 500 do tego swapramu po czym się powiesił. xD Ale dało radę go rebootnąć przez ctrl+print scr+alt + s+u+b.

Spróbowałem to samo zrobić tym razem nie wyłączając swapu z dysku, i też się powiesił tym razem po jakichś 220 MIB, i nawet reboot powyższy skrótem go nie ruszył, trzeba było ręcznie.

To chyba nie działa tak jak powinno.

Może jakość się zmieniła?

Testuje sobie to i generalnie to nie działa najlepiej. Nie ma przycinek, po prostu swap w ramie się wypełnia i nagle ścina dźwięku i nie idzie kompa wybudzić. Zmniejszyłem to nawet do 200M + zwykły swap, i niby swapram jest zajęty w full, i część danych w normlanym swapie, ale też się wiesza. Próbowałem przestawić ten vm.swappiness na 95, że niby by zrzucał dane do sawp a ten by był w ramie, to mogłoby nawet coś z tego być ale to albo nie działa albo działa inaczej niż ja przypuszczam, że powinno. xD Bo myślałem, że zacznie spuszczać dane od 100MiB max a to przy 700dopiero zaczeło.

Generalnie to to działa na takiej zasadzie, że się montuje urządzenie w ramie, i wypełnia się je danymi, coś jak ramdisk i można to też tak używać, niekoniecznie musi być to pod swap. Czytam sobie parę rzeczy, min to: http://wiki.gentoo.org/wiki/Zram i tam jest ciekawa kwestia tworzenia urządzeń z zależności od liczby rdzeni, czyli przykładowo, jak mam 2, to muszę utworzyć 2 urządzenia a nie 1, bo wtedy jak procki będą próbować zapełniać jeden swap, może być problem.

No i oczywiście przydałoby się to jakoś zautomatyzować, Póki co mój system tworzy dwa urządzenia na starcie systemu, ale nie mogę ich zamienić w swap.

Dodałem do /etc/modules:

zram

i stworzyłem /etc/modprobe.d/zram.conf

options zram num_devices=2

Na tym gentowskim wiki jest by dodać wpisy do /etc/udev/rules.d/10-zram.rules

0ERNEL=="zram0", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{disksize}=="0", ATTR{disksize}="100M", RUN+="/sbin/mkswap $env{DEVNAME}"
KERNEL=="zram1", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{disksize}=="0", ATTR{disksize}="100M", RUN+="/sbin/mkswap $env{DEVNAME}"

No i do fstaba:

/dev/zram0                    swap        swap            pri=16383       0 0
/dev/zram1                    swap        swap            pri=16383       0 0

Wszystko zrobiłem ale coś nie działa.

Co ciekawe jeszcze, przy reboocie, jeśli mam urządzenia podmontowane za pomocą:

#!/bin/bash

modprobe zram num_devices=2

SIZE=100
echo $(($SIZE*1024*1024)) > /sys/block/zram0/disksize
echo $(($SIZE*1024*1024)) > /sys/block/zram1/disksize

mkswap /dev/zram0
mkswap /dev/zram1


swapon /dev/zram0 -p 60
swapon /dev/zram1 -p 60

Komp dostaje taką  samą zwiechę co normalnie przy pracy, za każdym razem.

dominbik napisał(-a):

No to jest, że 900MB może być skompresowane a reszta (czyli 100MB jest nietykalne).

A czemu nie kompresować tych 100MiB?

Ja bym sobie ten system zaimplementował u siebie, gdyby tylko się to przestało wieszać.

fervi: ale z powodu ramu czy procesora? Jeśli procesora, to może to pomoże: dug.net.pl/tekst/152 (aczkolwiek nie jestem pewien czy ten tekst jest aktualny, u siebie używam liquorixa).

ArnVaker napisał(-a):

fervi: ale z powodu ramu czy procesora? Jeśli procesora, to może to pomoże: dug.net.pl/tekst/152 (aczkolwiek nie jestem pewien czy ten tekst jest aktualny, u siebie używam liquorixa).

Ciekawe...może sprawdzi się na netbooku. Przetestuję.
Swoją drogą, skoro to usprawnia działanie systemu, dlaczego jest domyślnie wyłączone?

dominbik napisał(-a):

http://www.komputerswiat.pl/nowosci/programy/2010/46/kernel-linuksa-szybki-jak-diabli.aspx
nie ma opcji jak wrócę do domu włączam to u siebie

Ta łatka chyba jest domyślnie wbudowana już ... (i działająca)

Fervi

Wątpię żeby w kernelach Debiana ta opcja była domyślnie włączona. To raczej rozwiązanie desktopowe z tego co pamiętam, a kernel Debiana ma być do wszystkiego.

18:47 ~/: cat /proc/sys/kernel/sched_autogroup_enabled 
1

okazuje się, że mam domyślnie to włączone.

a sory. o Archu wogóle mowiłem ;p na Debianie nie patrzyłem.

Ja także włączyłem dopisując sysctl.conf ale w zasadzie na pierwszy rzut oka nie widać aby wydajność skoczyła ostro w górę. Ale muszę przyznać, że na netbooku od chyba 3-4 ostatnich aktualizacji jajka ten mały kasprzak chodzi o wiele szybciej, więc moje odczucie co do usprawniania kernela z każdą aktualizacją są jak najbardziej pozytywne ;-)

Czyli u mnie powinno być to jakoś odczuwalne, ale jak dla mnie, chodzi jak chodziło. xD