Tag: ram

Opublikowane w

Praca na desktopie z małą ilością RAM po raz pierwszy

Tło problemu

Tak się składa, że apetyt programów i systemów na pamięć RAM systematycznie rośnie, a moje desktopy ilością RAMu nie grzeszą. Faktem jest, że RAM jest teraz tani i praktycznie nie sposób kupić nowego komputera z mniej niż 2-4 GB RAM (chyba, że netbook jakiś), ale… nie każdy sprzęt jest nowy (mój nie jest), nie każdy pozwala na większą ilość RAM no i – przede wszystkim – inwestowanie w stosunkowo drogi, stary RAM do równie starego sprzętu nie ma IMO sensu. A skoro działa, to po co wymieniać? 😉

Poza tym, Linux potrafi działać na komputerach z małą ilością RAMu. Przynajmniej powinien umieć. W każdym razie możliwa jest w miarę komfortowa praca na desktopach z 0,5-1 GB RAM, nawet z KDE (3.5). Chociaż ostatnio pożegnałem się z KDE i zwykle używam LXDE. Oczywiście zależy, co się robi, ale przy typowym korzystaniu, typu włączenie komputera, uruchomienie paru programów (komunikator, przeglądarka WWW, konsola, coś do PDF, jakiś arkusz kalkulacyjny czy edytor tekstu itp.) i wyłączenie komputera na koniec dnia, wszysko było OK. Nawet na 0,5 GB nie odczuwałem specjalnego spowalniania i wykorzystania swap (czasem się zdarzało, ale nie jakoś krytycznie), ale odkąd korzystam z laptopów, hibernacji lub niewyłączania komputera, jest znacznie gorzej.

Główni winowajcy (na laptopie firmowym) to: Firefox 4 – 21% RAM, Icedove – 7,5%, Xorg – 5,4%, plugin-container (czytaj: flash) 3,8%, psi – 3,4% i konsole 2,8%. Na prywatnym lapku podobnie, tylko Firefox 3.6 zajmuje 11%, i dochodzi Chromium 6,7% (najwyższe wystąpienie, jest ich kilka) i liferea 5,4%. Niby nic specjalnego, ale po kilkunastu dniach okazuje się, że na swapie użyte jest 100-400 MB, a przy odpaleniu jakiejś większej aplikacji (czytaj Openoffice) dysk zaczyna ostro pracować. Przy czym dyski w laptopach to zwykle 5400 rpm, więc raczej nie są demonami szybkości… Jednak najgorsze dzieje się przy instalacji aktualizacji. Polecenie wajig daily upgrade praktycznie zabija maszynę, do tego stopnia, że chwilowo traci responsywność – trzeba czekać na przełączenie się między oknami, kursor myszy nie porusza się płynnie itp.

Podejście pierwsze: zmiana parametru swappiness

Określa on, jak chętnie system korzysta ze swap na dysku i przyjmuje wartości od 0 do 100 (szerszy opis parametru swappiness i dyskusja). Domyślnie wynosi on 60, co niekoniecznie jest wartością dobrą dla desktopa. Jak widać, trwa spór o to, czy lepiej ustawić 0 czy 100. Wyszedłem z założenia, że 0 jest lepszą wartością.

Tymczasowe ustawienie wartości swappiness na 0:

echo 0 > /proc/sys/vm/swappiness

Sprawdzenie aktualnego ustawienia:

cat /proc/sys/vm/swappiness

Jeśli chcemy, aby zmiana była wykonywana przy każdym uruchomieniu, to do /etc/sysctl.conf dodajemy linię:

vm.swappiness = 0

Dla jasności: ustawienie swappiness na 0 nie powoduje, że system w ogóle nie korzysta ze swap. Korzysta, jeśli musi tylko mniej chętnie w normalnych warunkach. Efekt: większość czasu jest lepiej, widać, że system praktycznie nie korzysta ze swap. Niestety, jak już zacznie korzystać, to utrata responsywności jest większa, niż przy domyślnej wartości 60 (ocena metodą najdoskonalszą, czyli na oko), więc nie do końca o to mi chodziło.

Podejście drugie: dodanie compcache

Okazało się, że w Debianie w końcu pojawił się compcache w postaci pakietu o nazwie compcache-tools. Pakiet jest nieco śmieszny (tzn. kwalifikuje się to na bug report…), bo działa na kernelu 2.6.32 ze Squeeze, natomiast na 2.6.38 z testing/unstable brakuje modułu, choć sam pakiet właśnie testing/unstable jest. W skrócie – działa to tak, że zamiast po prostu zapisywać dane z RAM na dysk, najpierw dodatkowo je kompresuje (w RAM), a dopiero potem ew. zrzuca na dysk. Czyli większe użycie procesora w zamian za mniejsze zużycie pamięci i mniej operacji na dysku.

Aktywacja compcache (nieco inna, niż w manie, wersja z mana z insmod nie działała):

modprobe ramzswap
rzscontrol /dev/ramzswap0 --memlimit_kb=153600 --backing_swap=/swapfile.swp --init
swapon /dev/ramzswap0

Kolejno: załadownie modułu, określenie parametrów i inicjacja kompresowanego swap (tu: 150 MB RAM i wykorzystanie swap w pliku /swapfile.swp), aktywacja swap. Miałem to włączone przez kilkanaście dni, łącznie ze swappiness 0, ale nie podejmuję się oceny. IMHO niespecjalnie się różni od gołego zmniejszonego swappiness. Natomiast po reboocie system podziałał z 2 dni (bez włączonego compcache) i… system plików (reiserfs) przemontował się w RO. Fsck znalazł błędy, przebudowanie drzewa naprawiło, ale… zgubił 76 plików – i tak były niedostępne (nic krytycznego, głównie moduły Perla).

WTF? Przecież nigdy wcześniej takich cyrków nie było. Co więcej, przy próbie włączenia compcache otrzymałem komunikat typu backing swapfile has holes. To z kolei naprowadziło mnie na ten opis problemu. Niestety, pasuje idealnie, co skutecznie zniechęciło mnie – przynajmniej na jakiś czas – do zabaw z compcache. Odkryłem co prawda nieużywaną partycję swap, której mógłbym użyć, zamiast pliku, ale najpierw doczytam dokładnie. Uszkodzenia systemu plików to nie jest to, co tygrysy lubią najbardziej.

The end?

Zanim będę kontynuował, pozwolę sobie zapytać, jakie ustawienia parametru swappiness i ew. inne ustawienia proponujecie dla desktopa z Linuksem i LXDE, stosunkowo mocnym procesorem i stosunkowo małą ilością pamięci RAM (1 GB)?

Opublikowane w

Grub2, memmap i problemy z upgrade do Squeeze.

Ostatni upgrade systemu (z prywatnych, głównie desktopy) do Squeeze’ego zakończony. Zasadniczo bez zgrzytów, poza tym, że wyglądał trochę inaczej niż inne, a pakietów było mnóstwo. Naprawdę mnóstwo, apt-cacher wiele nie pomógł, choć inny desktop też z niego korzysta. KDE4 robi swoje, niestety. Łącze 1Mbps to przeżytek. No i jeszcze szopka z upgrade do grub2 była.

Desktop ma uszkodzony RAM, więc korzystam ze sposobu na uszkodzoną pamięć RAM, który opisywałem wcześniej. W grub miałem wpis:

/boot/vmlinuz-2.6.32.11 root=/dev/hda2 ro memmap=2M$311M

Przy dist-upgrade wszytko wykrył poprawnie, łącznie z dodatkowymi opcjami. Oczywiście skorzystałem z proponowanej opcji chainload (i całe szczęście…). Po reboocie wchodzę do grub2, tam wybieram nowy kernel (dystrybucyjny) i… reboot. Bez żadnego komunikatu. Niefajnie. Niestety to samo powtórzyło się przy wybraniu z grub2 kernela własnej roboty, którego używałem na Lenny.

Za to – ku mojemu zdziwieniu – ze starego gruba nowy kernel zadziałał. Co ciekawe, w przeciwieństwie do wersji z Lenny’ego, obsługiwał poprawnie wpis dla memmap – przy szybkim teście podlinkowanym wyżej nie było błędów.

Chwila zabawy i jasne było, że coś się skopało. Zamiast memmap=2M$311M było widoczne… memmap=2M11M. WTF? A po usunięciu opcji memmap wszystko ładowało się poprawnie (tyle, że korzystając ze skopanego obszaru RAM). Chwila googlania i wydało się, że do /etc/default/grub trafiła linia

GRUB_CMDLINE_LINUX="memmap=2M$311M"

która po przetworzeniu przez *sh będzie faktycznie wyglądała tak, jak wyglądała, bo $3 zostanie uznane za zmienną… Grub2 dodatkowo wymaga w swoim menu postaci memmap=2M\$311M czyli ostatecznie poprawna wersja w pliku /etc/default/grub to:

GRUB_CMDLINE_LINUX="memmap=2M\\\$311M"

Jutro zgłaszam buga.

Opublikowane w

Jak bezpiecznie korzystać z uszkodzonej pamięci RAM bez BadRAM.

BadRAM był fajny, ale jest nieutrzymywany. Ostatnią działająca u mnie wersja była do kernela 2.6.25.x, późniejsze, choć istniały (np. dla 2.6.29; dead link), to nie udało się ich – wbrew wcześniejszej radości – zmusić do poprawnego działania – nadal pojawiały się błędy np. na liczeniu sum kontrolnych.

Winny w tej maszynie jest ewidentnie RAM, co zostało już dawno stwierdzone, ale maszyna na tyle niekrytyczna, że inwestować się nie opłaca (poza tym, szkoda środowiska), a ze starszym (tj. 2.6.25.x) kernelem spokojnie i poprawnie działa. Poza tym, przecież to Linux, więc da się poprawić. I jaki uroczy temat do notek jest. 😉 Z okazji świątecznej wizyty w domu, postanowiłem jednak zerknąć, czy nie pojawiły się patche BadRAM do jakichś nowszych kerneli (serii 2.6.3x, znaczy).

Nie pojawiły się, ale zamiast tego, trafiłem na pierwszej stronie wyników na sposób radzenia sobie z uszkodzoną pamięcią pod Ubuntu, który w ogóle z BadRAM nie korzysta. Chwilę później trafiłem na ten wpis (dead link). Okazuje się, że za pomocą parametrów, które można przekazać kernelowi, w szczególności mem=XX oraz memmap=X$YY, można wyłączyć obszary pamięci z użytkowania, co przekłada się w praktyce, na możliwość bezpiecznego korzystania z uszkodzonej i dotychczas powodującej błędy pamięci. Więcej o parametrach w kernelowym Documentation/kernel-parameters.txt, ale na potrzeby tego zagadnienia wystarczą te dwa.

Pierwszy parametr (mem=) ogranicza wykorzystaną pamięć. Jeśli uszkodzenie jest w okolicy 312 MB (memtest+ prawdę powie), to mem=310M co prawda obniży dostępną pamięć do 310 MB, za to system będzie działał bez problemów. Tyle tylko, że stracimy 200 MB pamięci. Trochę sporo, zwłaszcza, jeśli całość do dyspozycji to tylko 512 MB.

Drugi (memmap=) jest ciekawszy, bo rezerwuje X pamięci od adresu YY. Przykładowo memmap=10M$305M oznaczy pamięć od  305 MB do 315 MB jako wykorzystaną. Czyli stracimy raptem 10 MB, a zyskamy niezawodny system. Tyle teorii. W praktyce na dystrybucyjnym 2.6.26 z Lenny’ego, mem=300M działało poprawnie (najprościej sprawdzić przez free -m), natomiast memmap=10M$305M był radośnie olewany – nadal pokazywało dostępną całą pamięć.

Przyczyny tego stanu rzeczy nie udało mi się ustalić (podejrzewam limit 4GB zamiast 1GB, błąd w kernelu lub korzystanie z initrd – jeśli ktoś zna odpowiedź, to proszę o info), natomiast skompilowanie własnego 2.6.32.2 na podstawie konfiga od 2.6.25.x (z którego spatchowanego BadRAM korzystałem do tej pory) rozwiązało problem – memmap=2M$311M, czyli wyłączenie tylko 2 MB spowodowało, że system działa poprawnie.

Ponieważ najłatwiej zaobserwować błędy było dotychczas na sumach kontrolnych, to testowanie wykonałem prostym skryptem (brzydki bash napędzany perlem – pewnie dałoby się prosto przespisać na gołego basha, ale kto tam ma czas…; skrypt na końcu wpisu). Stosunkowo duży plik (większy, niż dostępna pamięć RAM, mój tworzony przez dd if=/dev/urandom of=random.dat bs=1MB count=1024), z losową zawartością (tworzony raz, bo czasochłonne), liczenie sum kontrolnych. Jeśli błąd pojawi się w buforze dyskowym, to przy braku wielkiego pecha suma kontrolna będzie się różnić przed i po skopiowaniu. Zapuszczone w pętli, z logowaniem do pliku – nawet przy uszkodzonej pamięci nie wystarczy 1 przebieg – błąd nie pojawia się za każdym razem. Natomiast choćby jeden błąd oznacza, że coś jest nie tak jak być powinno.

Podstawą jest jednak free -m. Jeśli on nie widzi mniej pamięci, to można nie zaczynać nawet ze skryptem.

Jeśli po dłuższym teście brak błędów (pojedynczy błąd oznacza, że nie jest dobrze), to wystarczy dopisać linię do konfigu gruba, by przy każdej aktualizacji kernela dodawał do parametrów określony argument:

#kopt=root=/dev/hda2 ro memmap=2M$311M

Dzięki temu możemy korzystać z dowolnej (najnowszej!) wersji jądra, bez upierdliwego patchowania (cóż, patche badram były dość kijowe, włączenie z tym, że zdarzało im się mieć literówki uniemożliwiające kompilację).

Na koniec wspomniany skrypcik:

#!/usr/bin/perl
$src="/random.dat";
$dst="/tmp/memtest_tmp.dat";
$log="memtest_copy.log";
if (-f $dst){
   system (" rm $dst ");
}
system (" date >> $log ");
while (1){
  system (" cp $src $dst ");
  $res = `md5sum $dst`;
  $res2 = `sha1sum $dst`;
  $res_ = `md5sum $src`;
  $res2_ = `sha1sum $src`;
  $check = "ERROR";
   if (($res == $res_) && ($res2 == $res2_)){
     $check="OK";
   }
 system (" echo \"$check $res $res_ $res2 $res2_ \" >> $log ");
 system ("rm $dst");
}

Podsumowując: żegnaj BadRAM!