Miesiąc: wrzesień 2014

Opublikowane w

Smssender 0.9

Odezwał się użytkownik (ha! ktoś jednak tego używa! ;-)), że Mobitex przestał działać i zwraca status 104. Z racji niezbyt wczesnej pory lub po prostu zmęczenia[1], poszukałem pomocy nie u tego dostawcy, co trzeba. Ale albo statusy są zbieżne, albo dobry człowiek sprawdził we właściwej dokumentacji. Status 104, czyli brak zdefiniowanego From. Faktycznie, nie obsługiwałem tego. Tzn. była sobie zmienna w skrypcie, którą można było w skrypcie wyedytować. Niezbyt to piękne, więc w wersji 0.9 dodałem obsługę From w pliku konfiguracyjnym.

[1] Ślady zmęczenia widoczne w githubie, tak to jest jak się siada wieczorem do skryptu nietykanego od ponad roku.

Opublikowane w

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
Opublikowane w

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. 🙂