Tag: skrypt

Opublikowane w

Praca na desktopie z małą ilością RAM po raz trzeci – zram.

W poprzednich wpisach było parę przemyśleń i sugestii poprawy komfortu pracy na desktopie wyposażonym w niewielką ilość pamięci RAM, bez finalnego rozwiązania choć z paroma trickami poprawiającymi pracę, więc pora na podejście trzecie do tematu, inspirowane przez kumpla z IRC, który sprzedał mi „newsa” o zram.

Od pewnego czasu (okolice kernela 2.6.37, jeśli dobrze widzę) w kernelu Linuksa obecny jest moduł zram, pozwalający na tworzenie kompresowanych urządzeń blokowych w pamięci RAM. Wykorzystać to można podobnie jak compcache, czyli do tworzenia kompresowanego obszaru pamięci, używanego przez system przed przeniesieniem danych na swap na dysku. Idea jest prosta – swap na dysku jest tragicznie wolny i obciąża I/O, procesor zwykle się trochę nudzi, zresztą nie będzie miał dużo więcej pracy, a ilość wolnej pamięci się zwiększy.

Ogólnie zram jest ideowym spadkobiercą compcache, ale wygląda mi na prostszy i ideowo, i w użyciu. No i jest obecny w kernelu. 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.

Prosty skrypt realizujący powyższe:

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

Kolejno: załadowanie modułu zram (można korzystać z parametrów), 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!), utworzenie swapu na urządzeniu  /dev/zram0, włączenie utworzonego swap z priorytetem 60.

Podobno efekty są świetne – zaczynam testy u siebie, wstępnie nie wygląda źle, na pewno niebawem podzielę się wrażeniami (jako update do tego wpisu) po dłuższym teście. Jeśli chodzi o rozmiar swap dla modułu zram, to zacząłbym od 10-20% całości RAM (u mnie 200 MB przy 1 GB RAM). Z tego co zauważyłem, skompresowane dane zajmują w praktyce ok. 40-50% oryginalnych.

Parę przydatnych poleceń diagnostycznych:

  • cat /sys/block/zram0/compr_data_size – rozmiar danych po kompresji
  • cat /sys/block/zram0/orig_data_size – rozmiar nieskompresowanych danych
  • cat /sys/block/zram0/mem_used_total – całkowita ilość zużytej pamięci
  • swapon -s – rozmiar i wykorzystanie poszczególnych swap (inna jednostka!)

Linki w temacie, które zdecydowanie warto przejrzeć, jeśli ktoś jest bardziej zainteresowany:

Szczególnie ostatni wpis zawiera fajny, uwzględniający ilość procesorów skrypt startowy. Można rozważyć użycie po przeanalizowaniu. IMHO dla 1-2 procesorów trochę kosmiczne wartości będą, uzależnianie wielkości swap od ilości procesorów też jest średnie, ale poprawienie to nic trudnego. Za to obsługą utworzonego urządzenia blokowego zajmie się w tamtym wariancie więcej, niż jeden procesor. Z drugiej strony kto ma więcej niż dwa rdzenie i mało RAM?

Miałem obawy co do działania hibernacji (z użyciem pm-utils, z uswsusp miałem problem…) w takiej konfiguracji. Niepotrzebnie, bo wygląda, że działa OK – zapewne hibernacja jest na tyle inteligentna, że rozpoznaje, czy ma do czynienia z fizycznym urządzeniem blokowym.

Oczywiście swap to nie jedyne możliwe zastosowanie modułu zram – więcej przykładów w linku do wiki Gentoo.

Opublikowane w

Częstość piątku trzynastego.

Czy naprawdę piątek przypada trzynastego dnia miesiąca częściej, niż inne dni tygodnia, jak wynika z tego wpisu? Postanowiłem to sprawdzić, metodą najdoskonalszą, czyli brute force. Co prawda tylko dla lat 1970-2037 czyli w Unix Epoch (pełne lata).

Kod był praktycznie gotowy z czasów obliczeń, czy pracownicy zyskają, czy stracą na wolnym 6. stycznia. Ostatecznie wygląda on tak:

a wynik działania wygląda tak:

DOW - ilosc
1 - 116
2 - 118
3 - 115
4 - 117
5 - 117
6 - 116
7 - 117
Suma: 816

1 - Monday, ... , 7 - Sunday

Piątek oznaczony jest cyfrą 5, jak widać występuje on jako trzynasty dzień miesiąca 117 razy, podobnie jak czwartek i niedziela , więcej w badanym okresie jest wtorków trzynastego (118), a najmniej śród (113).

Pozostaje pytanie, dla jakich dokładnie lat prowadzona była analiza w oryginalnym wpisie. Na oko wygląda na jakieś 335 lat, pytanie które dokładnie. W każdym razie w badanym okresie nic nie wskazuje na większą częstotliwość występowania piątku w trzynasty dzień miesiąca.

Opublikowane w

Quagga, czyli czemu czasem warto zerwać z kompatybilnością wsteczną.

Tak się złożyło, że w użyciu jest sobie Quagga. Złożyło się też tak, że pobierane z niej są pewne dane przy pomocy polecenia vtysh. W postaci:

vtysh -c "show ip bgp neighbors  advertised-routes"

Następnie wynik polecenia jest parsowany skryptem. Generalnie chodzi o pobranie sieci w notacji CIDR. I wszystko byłoby fajnie, ale Quagga w ramach kompatybilności wstecznej (it’s not a bug, it’s a feature!) zwraca czasem samo IP. Niejednoznacznie, przez co z prostego w założeniu skryptu powinien zrobić się automat domyślający się, czy chodzi o /8, /16 czy /24.

Szukałem informacji czy można coś z tym zrobić na kanałach IRCowych, dostałem dane, że nie ma opcji, by zmienić takie zachowanie, tzn. aby Quagga zwracała jednoznacznie (np. uruchomienie z jakąś opcją). Za to było zainteresowanie ew. znalezionym rozwiązaniem. Nie znalazłem. Wygląda, że po prostu się nie da (tak, wiem, zawsze można pogrzebać w kodzie…).

Nie znalazłem też prostej koncepcji na określanie, o jaką długość prefiksu chodzi w danym przypadku. Akurat w przypadku, w którym używam średnio mi na tym zależy, ale elegancko byłoby móc jednoznacznie określić o jaki prefiks chodzi. Pomysły mile widziane. Przychodzi mi do głowy sprawdzanie, czy dla /8 i /16 nie ma nakładających się sieci z prefiksami określonymi wprost. Wtedy wiadomo, że chodzi o /24.

PS. Wiem, że jest BIRD. Jest rozważany, ale to trochę inny temat.