Tag: linux

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

Polskie radio w konsoli.

Dziś na kanale padło pytanie jak odtwarzać w konsoli radio z http://moje.polskieradio.pl? Na początku sądziłem, że chodzi o Trójkę itp., wtedy format URLa działający zarówno w mplayer jak i w MPD to wspominany we wpisie o MPD:

mms://stream.polskieradio.pl/program3

Okazało się jednak, że chodzi o pozostałe strumienie. I tu nie jest już tak różowo i prosto. Co prawda podczas poszukiwań (w sumie na koniec) ktoś natknął się na skrypt, który umożliwia odtwarzanie tych strumieni w konsoli, ale wędka lepsza od ryby więc:

  • Każda strona zawiera odtwarzacz w JS.
  • W kodzie odtwarzacza jest link do strumienia.
  • Link do odtwarzacza jest stały.
  • Link do strumienia również jest stały.
  • Strumień da się odtwarzać w mplayerze.

Przykładowo:

Minimax ma URL:

 http://moje.polskieradio.pl/station/33/Minimax

Player JS powstaje przez dodanie /_js/player.js, czyi ma URL:

 http://moje.polskieradio.pl/station/33/Minimax/_js/player.js

Strumienie są nazywane wg schematu k.stream, czyli szukamy:

wget -q -O - http://moje.polskieradio.pl/station/33/Minimax/_js/player.js| egrep "file.*k.*stream"

co daje nam wynik  _obj2.addVariable(’file’, 'k34.stream’);

Cały link do strumienia to:

rtmp://stream85.polskieradio.pl/live/k34.stream

Oczywiście nie dam głowy, że stream85 będzie stała i niezmienna, ale to również widać w źródle playera. Jedyną nieoczywistą częścią było dodanie live – wyłuskane z działających stacji (IIRC z Trójki).

Niestety, taką wersję obsłuży mplayer, ale już nie MPD. Jakby ktoś znalazł rozwiązanie jak tworzyć URL zdatny do MPD – proszę o info. Wersja ze skryptu odpada.

Wam życzę dobrego odbioru, a sobie, żeby stacje radiowe przestały utrudniać ludziom życie i dawały przyjazne konsolowym odtwarzaczom linki. Nie zawsze chce się/można włączyć ciężką przeglądarkę, by posłuchać radia. Niezrównanym ideałem jest tu dla mnie Radio Baobab, które nie tylko daje przyjazny konsoli format, ale również w wolnym formacie ogg (obok innych formatów) i w takiej formie, że się ładnie scrobble’uje.

UPDATE: Mpd w wersji 0.16.2 radzi sobie z URLami typu rtmp:// co oczywiście cieszy.

Opublikowane w

Sprawdzanie dysku USB w Debianie.

O tym, że warto monitorować stan dysku, nie trzeba – mam nadzieję – nikogo przekonywać. Wystarczy tylko dodać, że wczesne wykrycie anomalii może pozwolić na proste i bezpiecznie skopiowanie wszystkich danych. Jeśli ktoś nie chce lub nie czuje się na siłach we wnikanie w dobrze opisane na wiki parametry S.M.A.R.T, to jako wariant minimum proponuję przyjąć, że jakakolwiek różna od zera wartość dla Reallocated Sectors Count jest sygnałem, że warto szybko zrobić backup danych. A już na pewno warto spisać dysk na straty, jeśli ta wartość rośnie.

Jeśli chodzi o desktopy, to – jak podpowiada ike w komentarzu – dysk można sprawdzić korzystając z gsmartcontrol (zapewne dostępne w repozytorium pakietów dla Twojej dystrybucji). Na pewno wygodniejsze i łatwiejsze rozwiązanie.

Pisałem już o odczycie S.M.A.R.T w Debianie dla dysków w kieszeniach USB. W zasadzie temat wyglądał na wyczerpany, bo nowe smartmontools obsługują dyski w kieszeniach USB, ale… nie do końca. Niedawno miałem do czynienia z dwiema kieszeniami USB dla dysków 2,5″ – na jednej smartmontools nie umiało sprawdzić stanu dysku, na drugiej działało bez problemu.

Przeszedł bym nad tym do porządku dziennego, szczególnie, że żadna z kieszeni nie była moja, ale okazało się, że moja kieszeń 3,5″ też nie pozwala na sprawdzenie stanu dysku tak po prostu:

smartctl -a /dev/sdb
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

/dev/sdb: Unsupported USB bridge [0x04b4:0x6830 (0x001)]
Smartctl: please specify device type with the -d option.

Zatem jak sprawdzić dysk w kieszeni USB? Okazało się, że opcji do -d w smartmontools jest nieco więcej. Ten wpis podsunął rozwiązanie problemu, jest nim dodanie parametru -d usbcypress. Czyli ostatecznie komenda to:

smartctl -a -d usbcypress /dev/sdb

Wynik lsusb dla mojej kieszeni USB:

Bus 001 Device 002: ID 04b4:6830 Cypress Semiconductor Corp. CY7C68300A EZ-USB AT2 USB 2.0 to ATA/ATAPI

Podobno dość popularny producent chipsetów. Dla wyczerpania tematu – chyba wszystkie sprzętowe kontrolery RAID (przynajmniej znane mi) również pozwalają na sprawdzanie S.M.A.R.T dla dysków SATA. Też warto sprawdzać, bo można dostrzec nadchodzący błąd wcześniej, niż zgłosi go kontroler…