Jak obliczyć wolną pamięć RAM w Linuksie?

Ile mam wolnej pamięci w systemie? to częste pytanie i użytkowników desktopów, i administratorów. Na każde pytanie istnieje prosta, błędna odpowiedź i podobnie jest w tym przypadku, choć ustalanie ilości wolnej pamięci RAM wydaje się trywialną sprawą. Większość ludzi korzysta z polecenia free, którego przykładowy wynik może wyglądać następująco (desktop):

total       used       free     shared    buffers     cached
Mem:       3926996    3614388     312608          0      82656    1305692
-/+ buffers/cache:    2226040    1700956
Swap:      1022964      20480    1002484

Typowa interpretacja byłaby zapewne w tym przypadku taka, że wolnych jest 312608 kB RAM. Niezupełnie jest to prawdą. Tzn. tyle pamięci faktycznie jest zupełnie nieużywanej, ale tak naprawdę w razie potrzeby dla aplikacji dostępne jest znacznie więcej pamięci i należałoby raczej patrzeć na drugi wiersz, nie pierwszy, czyli bliższym prawdy wynikiem jest, że wolnych w tym przypadku jest 1700956 kB RAM.

W przypadku serwerów z Linuksem, ilość wolnej pamięci łatwiej odczytać, szczególnie na potrzeby skryptów, z /proc/meminfo/:

cat /proc/meminfo | head -n 5
MemTotal:        3926996 kB
MemFree:          296944 kB
MemAvailable:    1589592 kB
Buffers:           82692 kB
Cached:          1305316 kB

Patrząc na wartości z /proc/meminfo, ilość zajętej i wolnej pamięci RAM można liczyć w następujący sposób:

Free RAM = MemFree + Buffers + Cached
Used RAM = MemTotal - (MemFree + Buffers + Cached)

Jednak i to niezupełnie jest prawdą, bo do w skład Cached wchodzą np. obszary używane przez tmpfs, które nie mogą być zwolnione. Dlatego niedawno w /proc/meminfo dodano kolejną wartość MemAvailable, której zadaniem jest podawanie wprost ilości dostępnej do wykorzystania przez programy (czyli, potocznie, wolnej) pamięci. Jeśli taka wartość jest podana, to zamiast powyższych wzorów lepiej skorzystać z:

Free RAM = MemAvailable
Used Ram = MemTotal - MemAvailable

Linki:

  1. http://www.linuxatemyram.com/
  2. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773

Piwik 2.6.0 i problemy z upgrade

Od jakiegoś czasu korzystam ze statystyk Piwik na większości moich stron ii generalnie jestem zadowolony. Do tej pory aktualizacje wersji były totalnie bezproblemowe (klikalne), ale aktualizacja wersji do 2.6.0 zakończyła się niepowodzeniem.

Od początku wyglądało dziwnie, bo kliknięcie w changelog w mojej instalacji Piwika nie pokazywało listy zmian dla wersji 2.6.0, a w dziale download najnowsza wersja opisana była jako 2.5.0 (choć faktycznie archiwum zawierało 2.6.0).

Automatyczny upgrade zakończył się klęską i pokazywaniem białej strony, postanowiłem zrobić aktualizację ręcznie, jak opisano na stronie. Okazało się, że pobrany plik piwik.zip rozpakowuje się w ślimaczym tempie (ok. 20kB/s). Także na innej, szybszej maszynie, z nowszym Debianem (unstable). Ostatecznie rozpakowałem na tej szybszej, przepakowałem do tar.gz. Przy okazji rozmiar spadł do 8MB w porównaniu z 11MB oryginalnego zip, a rozpakowanie odbyło się w normalnym tempie, czyli parę MB/s. Następnie przeprowadziłem aktualizację ręcznie.

Niewiele to pomogło, bo nadal była biała strona. Ręczne wywołanie pliku piwik.php dało więcej informacji:

PHP Warning:  require(/var/www/piwik/vendor/facebook/xhprof/xhprof_lib/utils/xhprof_lib.php): failed to open stream: No such file or directory in /var/www/piwik/vendor/composer/autoload_real.php on line 58
PHP Fatal error:  require(): Failed opening required '/var/www/piwik/vendor/facebook/xhprof/xhprof_lib/utils/xhprof_lib.php' (include_path='/var/www/piwik/vendor/phpunit/php-text-template:/var/www/piwik/vendor/phpunit/phpunit-mock-objects:/var/www/piwik/vendor/phpunit/php-timer:/var/www/piwik/vendor/phpunit/php-file-iterator:/var/www/piwik/vendor/phpunit/php-code-coverage:/var/www/piwik/vendor/phpunit/phpunit:/var/www/piwik/vendor/symfony/yaml:.:/usr/share/php:/usr/share/pear') in /var/www/piwik/vendor/composer/autoload_real.php on line 58

Szybki debug i znalazł się winny. W pliku /var/www/piwik/vendor/composer/autoload_files.php należy zakomentować odwołania do nieistniejących plików:

#    $vendorDir . '/facebook/xhprof/xhprof_lib/utils/xhprof_lib.php',
#    $vendorDir . '/facebook/xhprof/xhprof_lib/utils/xhprof_runs.php'

Po tej operacji wszystko działa poprawnie. HTH

http://pastebin.com/S4Hxjw6B

UPDATE: Szybcy są i czytają Twittera, już (podobno) poprawili wydając 2.6.1. 🙂

Sortowanie – Bash vs Perl benchmark

Dziś na kanale IRC znajomy szukał błędu w skrypcie bashowym. Danych dużo, skrypt wykonuje się długo (kilkadziesiąt minut). Błąd pojawiał mu się w sort, skrypt złożony. Jakoś tak stwierdził, że przepisze na Perla, będzie szybciej. Tyle tytułem wstępu, bo potem rozpoczęliśmy akademickie rozważania pt. czy sortowanie w Perlu będzie szybsze.

Postanowiłem się pobawić w praktykę. Nie ukrywam, że sporą rolę maiła tu niedawna dyskusja nt. algorytmów (i czemu zabawy z nimi są fajne) z M.[0]

Najpierw wygenerowanie sporego zestawu danych testowych [1]. 10 mln liczb z zakresu 0-99, 28999760 bajtów.

Następnie prosty sort [2]. Wyniki oscylują w granicach 16-18 sekund.

Pierwszy skrypt w Perlu[3] Jest minimalnie szybciej, bo 15 sekund.

Widać parę niepotrzebnych przepisań i da się to skrócić [4]. Po skróceniu wyniki oscylują w granicach 14,4 sekundy.

Pora na mały cheat, bo wiemy, że większość danych się powtarza. Czyli wersja z hashem – zliczamy ilości wystąpień, a na koniec sortujemy tyko klucze hasha (których jest 100) i wyświetlamy tyle razy, ile razy wystąpiły [5].

Jest dużo szybciej. Okolice 4,7 sekundy. Szczerze mówiąc nie sądziłem, że aż tyle da się urwać.

Na koniec postanowiłem sprawdzić, czy różnica wynika z powtarzających się danych. Wygenerowałem mały plik z praktycznie niepowtarzającymi się danymi [6]

Tutaj sort wykonywał się ok. 70 ms, natomiast – ku mojemu zdziwieniu – Perl nadal był szybszy i wykonywał się ok. 50 ms.

Daleki jestem od wyciągania z tego benchmarku daleko idących wniosków, nikogo też na przechodzenie wszędzie na Perla nie namawiam. Bardziej chodziło mi o pokazanie ciekawostki. Zwykle 10 sekund różnicy nie ma znaczenia, narzut na pisanie nie zwróci się nigdy, a wersja z sort jest po prostu czytelniejsza. I pewnie nadal będę używał sort. Niemniej warto wiedzieć, że w prosty sposób da się szybciej. Taki mały hack.

Inna sprawa, że IMVHO pisanie skryptów w bashu zwykle nie ma sensu i lepiej użyć Perla, Pythona itp. Szybciej, więcej można w prosty sposób zrobić, a skrypty bashowe mają tendencję do puchnięcia z elementami dziwnych rzeźb.

Uwagi: Wynik sortowania jest identyczny, choć nie to było priorytetem. Sortowanie nie jest numeryczne (jak ktoś chce, może się bawić, stawiam, że wyniki będą podobne). Skrypty są pisane mało optymalnie, mało czytelnie itd. ale tak na szybko piszę onelinery z głowy, a nie bawiłem się w upiększanie, bardziej chciałem szybko notkę zrobić. Tak, wiem nie ma close (F), w skryptach, ale nie jest tu potrzebne. Nie ma potrzeby korzystania z open, spokojnie można było robić „tradycyjne” while (<>) i czytać ze STDIN; jak sprawdziłem później nie powoduje to zauważalnej różnicy w czasie wykonania.

Ponieważ Blox wyczynia cuda z tekstami w pre podczas edycji notki, efektem czego jest znikanie większej części skryptów i tekstu, poniżej wklejka z wszystkimi poleceniami (odnośniki powyżej).

 

[0] Jest szansa, że pojawi się parę zadań z algorytmami. Ale niczego nie obiecuję. Zresztą, chyba lepiej, żeby takie rzeczy działy się na blogu jakiegoś programisty… A jak zobaczyłem, co robi Blox z groźnymi nawiasami trójkątnymi, to zupełnie odeszła mnie ochota na pisanie czegoś wymagającego fragmentów kodu tutaj.

UPDATE: Jak trafnie zauważyli czytelnicy w komentarzach, sort można przyspieszyć (analogicznie, jak przyspieszyć można grep) poprzez ustawienie LC_ALL=C lub LANG=C. Po tym zabiegu sort, dla podanych danych, działa szybciej od dotychczasowego najszybszego Perla, w okolicach 4,2 sekundy.