Dobry cache, nie jest zły

Patryk Kuźmicz 3 komentarze

Żeby móc rozmawiać o cache'u, czy całych systemach cache'ujących spróbuję na początku wyjaśnić swoimi słowami co to właściwie jest. Pracując codziennie na komputerze, oglądając strony WWW nieświadomie wykorzystujemy wiele takich mechanizmów. Cache w skrócie to zapamiętanie zestawu danych i umieszczenie ich w takim miejscu by przy następnej próbie dostępu, nie sięgać znów do dysku, nie wykorzystywać mocy obliczeniowej CPU kolejny raz, tylko w celu wygenerowania dokładnie tych samych danych.

Idealnym miejscem do przechowywania informacji jest pamięć operacyjna, dostęp do niej jest kilka rzędów wielkości mniejszy niż w przypadku dysku twardego (chyba, że mówimy o dyskach SSD, ale to nie ta epoka). Świetnym przykładem łatwym do zobrazowania jest wykorzystania cache'u w bazach danych. Wykonując kwerendę SQL zwracającą 1,000,000 rekordów które nie są modyfikowane,  lub są modyfikowane rzadko, silnik bazy danych musiałby odczytywać za każdym razem te same informacje z dysku twardego, ale co zrobi baza danych? Baza wie co to cache, dlatego umieszcza ten zestaw informacji w pamięci podręcznej (RAM) i przy następnym takim zapytaniu, najpierw sprawdzi pamięć pod kątem dostępności tych danych i dopiero w przypadku kiedy ich nie będzie, sięgnie do dysku twardego, oszczędzając CPU, pamięć i dysk twardy.

Klasyczna architektura serwisu WWW.

Do wygenerowania dynamicznej strony np. skryptu PHP przez serwer WWW, wymagane jest:

  • odebranie połączenia od użytkowników
  • połączenia się z serwerem bazodanowym
  • odczyt danych z serwera plików (np. poprzez NFS, iSCSI)

Każda z tych operacji jest kosztowna, szczególnie jeśli chodzi o odpytanie bazy danych ciężką kwerendą SQL, dołączmy do tego czas odczytu plików ze zdalnego serwera storage przy każdym requeście i mamy klasyczny przykład architektury podatnej na zakleszczenia, gdzie w przypadku obciążonej bazy danych procesy serwera httpd czekają na odpowiedź i kolejne jeszcze bardziej pogarszają sytuację, analogicznie wolny czas dostępu do serwera plików, może bardzo wpłynąć na obciążenie serwera bazodanowego, ponieważ sesje do bazy będą dłuższe i będzie ich znacznie więcej.

Co można zrobić?

Możemy użyć akceleratora WWW (reverse proxy) i dodatkowo wykorzystać kilka poziomów cache (np. memcache, APC), sam serwer akcelerujący można umieścić na serwerze www lub przed nim, kolejny krok to ustawienie odpowiednich nagłówków HTTP dla strony WWW (Expires, Cache-Control, Pragma), to tylko kilka czynności które możemy wdrożyć, a dzięki nim sam przepływ ruchu może wyglądać następująco:

Jest to bardzo proste zobrazowanie działania mechanizmów cache'ujących, w tym przypadku zastosowany został mechanizm pracujący na warstwie HTTP. Reverse proxy zachowuje całą stronę wygenerowaną przez Apache (PHP) w swojej pamięci i przy następnym odwołaniu, żądanie nie jest nawet przekazywane do Apache, odpowiedź jest podawana z systemu cache. Nagłówki Expires, Cache-Control pomagają nam sterować czasem cache'owania, może to być zarówno kilka minut jak i lat.

Przykłady systemów cache pracujących na niższych warstwach:

memcached - jest daemonem pracującym w systemie, który potrafi przechowywać dane w pamięci RAM na zasadzie klucz => wartość, jest to chyba jeden z najczęściej używanych mechanizmów przy budowaniu wydajnych i wysoko skalowanych platform (nie tylko WWW). Działanie memcached opiera się na zapamiętywaniu danych przez określony przez nas czas pod konkretnym kluczem:

Przykład: umieszczamy dane "jamzed" (6 bajtów) pod kluczem "test", na okres 100 sekund

jamzed@yoursite:~$ telnet 127.0.0.1 11211
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
set test 0 100 6
jamzed
STORED

get test
VALUE test 0 6
jamzed
END

Najczęściej zapamiętywane są wyniki zapytań SQL, w prosty sposób budujemy klucz i pod nim zapisujemy zwrócone informacje z bazy danych, klucz taki możemy budować poprzez wyliczenie sumy MD5 z zapytania ($klucz = md5(SELECT * FROM TB_USERS);). Jeśli wykorzystujemy memcached z poziomu PHP, to istnieje gotowy moduł do wykorzystania.

APC - Alternative PHP Cache, w zasadzie działania niewiele się różni APC od memcached, również zapamiętuje wartości pod konkretnym kluczem, z tą różnicą, że dane są przechowywany w shared memory naszego serwera (lokalnie). Nie ma możliwości współdzielenia elementów pomiędzy różnymi serwerami zapamiętanych przy użyciu APC, każdy zestaw danych musi być indywidualnie zapamiętany na każdej maszynie osobno, co w przypadku klastrów może powodować desynchronizację i utratę spójności zwracanych użytkownikom danych.

Nie sposób jest wymienić wszystkie dostępne rozwiązania, starałem się naświetlić jedynie możliwości tego typu rozwiązań, jeśli ktoś jest zainteresowany bardziej tematem, prosimy o informacje.

Jakie są korzyści i wady korzystania z takich rozwiązań:

+ zwiększenie wydajności platformy
+ zmniejszenie wykorzystania zasób serwera
+ przyśpieszenie pracy całego systemu
+ zmniejszenie kosztów (mniej serwerów, mniejsze koszty)

- należy dbać o czas przechowywania danych (nieaktualne dane powodują problemy)
- kosztowne wdrożenie systemu
- cache to kolejny element systemu (wydłużenie czasu diagnozy podczas awarii)

Należy przyjąć, że nie istnieją wydajne platformy bez cache'a, nie martwmy się tym, że możemy serwować dane użytkownikom z opóźnieniem kilki minut, przy odpowiednio zgranych parametrach te czasy można niwelować do minimum, ale nawet minimalny czas pozwoli nam uchronić się przed dużymi skokami ruchu (wykop effect).

Pomimo niektórych wad, warto poświęcić czas na dostosowanie konkretnych rozwiązań i uszyć coś na miarę naszych potrzeb, wykorzystanie cache'a z głową przyniesienie na pewno wiele korzyści i moim zdaniem jest to koszt który warto ponieść raz, by w przyszłości móc rozbudowywać i skalować łatwo i szybko nasz system.

A Wy jakie mechanizmy cache stosujecie w swoich systemach?

Apache walczy ze spamem

Patryk Kuźmicz Leave a Comment

Pojęcie spamu znane jest chyba wszystkim administratorom, zazwyczaj spotykamy się z nim w przypadku poczty, ale spam to nie tylko e-maile, to również komentarze na forach, blogach, księgach gości czy stronach internetowych z formularzem kontaktowym. Jak zabrać się do walki ze spamem w przypadku stron WWW? Tradycyjny sposób to budowanie własnych mechanizmów i weryfikowanie źródłowych adresów IP użytkowników, jeśli widzimy, że z jakiegoś konkretnego IP notorycznie pojawiają się reklamy w komentarzach to dodajemy źródło do blacklisty i blokujemy ruch, ale nasza własna baza adresów będzie ograniczona i nie zawsze uda nam się powstrzymać natarczywe roboty, a nikt nie będzie długo prowadził walki z wiatrakami. Osobiście preferują drugą metodę, czyli skorzystać z gotowych mechanizmów.

Doskonałym przykładem narzędzia które pomoże nam w "utrzymaniu czystości" na naszych stronach jest dedykowany moduł dla Apache mod_spamhaus. Zasada działania modułu jest bardzo prosta, a przez to bardzo skuteczna. Moduł wykorzystuje już gotowe bazy DNSBL zawierającą adresatów spamu i przy żądaniach do serwera WWW, weryfikuje IP nadawcy w bazie i podejmuje odpowienią akcję, przepuszcza request lub go blokuje.

Jak wygląda proces sprawdzenia danego IP? Wystarczy odpytać o IP odpowiedniego hosta. Bazy DNSBL jak sama nazwa wskazuje, działają w oparciu o serwery DNS:

Sprawdzane IP: 80.54.97.4, odpytujemy o IP w notacji odwróconej: 4.97.54.80 i dodajemy nazwę bazy DNSBL.

jamzed@makufka:~$ host 4.97.54.80.combined.abuse.ch
4.97.54.80.combined.abuse.ch has address 127.0.0.3
4.97.54.80.combined.abuse.ch has address 127.0.0.2

Jeśli w odpowiedzi na takie zapytanie otrzymamy hosty z przedziału: 127.0.0.0 - 127.0.0.255, oznacza to, że adres występuje w bazie DNSBL i jest zgłoszony jako nadawca spamu.

Instalacja modułu spamhaus sprowadza się do pobrania paczki tar.gz ze strony domowej projektu i jej kompilacji:

root@yoursite:/home/jamzed/Sources# tar zxvf mod-spamhaus-0.7.tar.gz
mod-spamhaus/
mod-spamhaus/ReadMe.txt
mod-spamhaus/LICENSE
mod-spamhaus/Makefile
mod-spamhaus/src/
mod-spamhaus/src/mod_spamhaus.c

Rozpakowane źródła należy teraz skompilować (wymagany jest apxs2, w Ubuntu należy doinstalować paczkę apache2-prefork-dev):

root@yoursite:/home/jamzed/Sources# cd mod-spamhaus
root@yoursite:/home/jamzed/Sources/mod-spamhaus# make

apxs2 -Wc, -Wc,-DDST_CLASS=3 -c src/mod_spamhaus.c
/usr/share/apr-1.0/build/libtool --silent --mode=compile --tag=disable-static i486-linux-gnu-gcc -prefer-pic -DLINUX=2 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -I/usr/include/apr-1.0 -I/usr/include/openssl -I/usr/include/xmltok -pthread     -I/usr/include/apache2  -I/usr/include/apr-1.0   -I/usr/include/apr-1.0   -DDST_CLASS=3  -c -o src/mod_spamhaus.lo src/mod_spamhaus.c && touch src/mod_spamhaus.slo
/usr/share/apr-1.0/build/libtool --silent --mode=link --tag=disable-static i486-linux-gnu-gcc -o src/mod_spamhaus.la  -rpath /usr/lib/apache2/modules -module -avoid-version    src/mod_spamhaus.lo

write "make install" to install module

root@yoursite:/home/jamzed/Sources/mod-spamhaus# make install
apxs2 -Wc, -Wc,-DDST_CLASS=3 -i -a -n spamhaus src/mod_spamhaus.la
/usr/share/apache2/build/instdso.sh SH_LIBTOOL='/usr/share/apr-1.0/build/libtool' src/mod_spamhaus.la /usr/lib/apache2/modules
/usr/share/apr-1.0/build/libtool --mode=install cp src/mod_spamhaus.la /usr/lib/apache2/modules/
libtool: install: cp src/.libs/mod_spamhaus.so /usr/lib/apache2/modules/mod_spamhaus.so
libtool: install: cp src/.libs/mod_spamhaus.lai /usr/lib/apache2/modules/mod_spamhaus.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/sbin" ldconfig -n /usr/lib/apache2/modules
----------------------------------------------------------------------
Libraries have been installed in:
/usr/lib/apache2/modules

Nasz moduł został zainstalowany w lokalizacji: /usr/lib/apache2/modules, teraz należy go skonfigurować i włączyć.

Konfiguracja modułu sprowadza się do stworzenia pliku /etc/apache2/mods-available/spamhaus.conf i umieszczenia w nim następujących informacji:

<IfModule mod_spamhaus.c>
MS_METHODS POST,PUT,OPTIONS,CONNECT
MS_CacheSize 256
</IfModule>

  • MS_METHODS - określamy dla których metod żądań moduł ma sprawdzać IP
  • MS_WhiteList - opcjonalnie możemy podać ścieżkę do pliku z whitelist'ą, adresy IP w nim zamieszczone zawsze będą przepuszczane
  • MS_CacheSize - ilość adresów która będzie w cache i nie będzie konieczności odpytywania za każdym razem baz DNSBL

po stworzeniu konfiguracji, pora dodać moduł do Apache2 (Ubuntu way):

root@yoursite:/etc/apache2/mods-available# echo "LoadModule spamhaus_module /usr/lib/apache2/modules/mod_spamhaus.so" > /etc/apache2/mods-available/spamhaus.load

root@yoursite:/etc/apache2/mods-available# a2enmod

szukamy czy na liście modułów jest spamhaus jeśli jest to wszystko ok, wpisujemy spamhaus i potwierdzamy enterem.

Which module(s) do you want to enable (wildcards ok)?
spamhaus
Enabling module spamhaus.
Run '/etc/init.d/apache2 restart' to activate new configuration!

Pozostaje już zrestartować Apache, jeśli wszystkie powyższe kroki zostały przeprowadzone, nasz moduł powinien działać prawidłowo i odsiewać większość robotów (źródłem informacji jest error_log serwera WWW):

[Fri Feb 26 00:09:05 2010] [crit] [client 80.54.97.4] mod_spamhaus: address 4.97.54.80.sbl-xbl.spamhaus.org is blacklisted. Deny connection to www.varlog.pl/xxxxxx.php, referer: http://www.varlog.pl/yyyyyy.php

Powodzenia w walce ze złem ;-)

10 narzędzi które powinien znać każdy administrator

Patryk Kuźmicz 9 komentarzy

Codzienna administracja systemami, to wykonywanie setek poleceń, niekiedy bardzo złożonych, czasem mniej, ale są takie narzędzia bez których nie jesteśmy w stanie sprawnie diagnozować problemów systemowych, ani monitorować bieżącej pracy serwera. Chciałbym Wam przedstawić swoje TOP10 narzędzi bez których nie potrafiłbym pracować.

1. ps

ps - służy do wyświetlenia aktualnie działających procesów w systemie, jest to niezwykle przydatne narzędzie jeśli chcemy sprawdzić PID, zużycie pamięci, czy czas procesora zajmowany przez konkretny proces.

Przykładowe użycie: ps axuw

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mysql 2301 0.0 3.8 131408 19564 ? Sl Feb21 1:05 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306

W wyniku otrzymaliśmy wiele informacji, podzielonych w kolumny:

  • USER - z jakimi uprawnieniami działa proces (mysql),
  • PID - jest to pid procesu w systemie (2301),
  • %CPU - procentowe wykorzystanie procesora (0.0%),
  • %MEM - przedstawia procentowe zużycie pamięci (0.0%),
  • VSZ - wirtualne zużycie pamięci przez proces przedstawiane w KiB (131408),
  • RSS - rzeczywista ilość pamięci przyznaną procesowi bez uwzględnienia SWAP (19564),
  • TTY - podaje nam terminal w którym pracuje aplikacja, jeśli jest to daemon to najczęstszym wynikiem będzie ?, ponieważ proces jest pozbawiony terminala (działa w tle)
  • STAT - stan w którym aktualnie znajduje się proces (Sl) - S = czekający na zdarzenie, l = proces jest wielowątkowy
  • START - czas uruchomienia procesu
  • TIME - skumulowany czas zużycia procesora zarówna w sekcji user jak i system
  • COMMAND - dokładne polecenie jakie zostało wykonane

Więcej informacji znajdziecie w manualu (man ps).

2. top

top - jest narzędziem bardzo zbliżonym działaniem do 'ps', również pokazuje aktualnie działające procesy, ale z tą różnicą, że wyniki prezentuje na bieżąco (częstotliwość odświeżania jest konfigurowalna).

Prezentowane dane możemy sortować dowolnie po wybranym parametrze (Shift + f), osobiście najczęściej używam sortowania po ilości zużytej pamięci SWAP (Shift +f, p), dzięki temu szybko jestem w stanie określić które procesy mają wycieki pamięci, oraz po zużyciu pamięci (Shift +f, n).

Dodatkową zaletą polecenia top jest przedstawienie w bardzo czytelny sposób aktualnego wykorzystania zasobów serwera, na samej górze mamy posegregowane informacji na temat aktualnego LOADu, ilości procesów, wykorzystania CPU, MEM i SWAP.

Wciskając klawisz '1', rozwinie się lista wykorzystania CPU i wyniki będą prezentowane per core każdego procesora.

3. iostat

iostat - jest narzędziem prezentującym wykorzystanie naszych urządzeń blokowych, czyli w praktyce jest to monitorowanie pracy dysków twardych, tzw. I/O. Saturacja dysków twardych jest zjawiskiem bardzo niepożądanym, które automatycznie przekłada się na zwolnienie pracy całego systemu, dzięki iostatowi, możemy szybko się przekonać czy przyczyna naszych problemów leży właśnie w za dużym wykorzystaniu zasobów I/O.

Przykładowe użycie: iostat -x 1

avg-cpu:  %user %nice %system %iowait %steal %idle
0,46    0,00    0,08    0,02    0,00   99,44

Device rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm util
sda 0,09 0,77 0,07 0,23 2,69 7,87 35,74 0,00 4,49 0,84 0,02

W wyniku widzimy dane dla naszego urządzenia 'sda'.

  • rrqm/s - ilość skolejkowanych żądań odczytu z dysku na sekundę
  • wrqm/s - ilość skolejkowanych żądań zapisu na dysk na sekundę
  • r/s - ilość odczytów z dysku na sekundę
  • w/s - ilość zapisów na dysk na sekundę
  • rsec/s - ilość sektorów czytanych na sekundę
  • wsec/s - ilość sektorów zapisywanych na sekundę
  • avgrq-sz - średni rozmiar w sektorach
  • avgqu-sz - średnia wielkość kolejki oczekujących żądań dostępu do dysku
  • await - średni czas dostępu do dysku (z uwzględnieniem kolejki) w milisekundach
  • svctm - średni czas obsługi żądania w milisekundach
  • %util - procentowe zużycie procesora potrzebne do obsłużenia żądania, jeśli wynosi 100% dochodzi do sytuacji saturacji zasobów

Jeśli wskazania iostata pokazują utylizację na poziomie 80-100% należy znaleźć przyczynę i ją wyeliminować, sytuacja ta oznacza, że nasz procesor spędza głównie czas w oczekiwaniu na dane a nie na ich przetwarzaniu.

4. vmstat

vmstat - narzędzie monitorujące wykorzystanie pamięci w naszym systemie.

Przykładowe użycie: vmstat 1

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd free   buff cache   si   so bi    bo   in   cs us sy id wa
1  1   7292  24436  77408 215936    0    0     1     4   27   25  0  0 99  0
0  0   7292  24428  77408 215928    0    0     0     0   36   36  0  0 100  0

Dzięki vmstatowi możemy sprawdzić wykorzystanie pamięci i procesora naszego serwera.

  • procs r - ilość procesów aktualnie czekających na czas procesora
  • procs b - ilość procesów aktualnie oczekujących na zdarzenie systemowe (uninterruptible sleep)
  • memory swpd - wielkość użytej pamięci SWAP
  • memory free - ilość wolnej pamięci
  • memory buff - ilość zajętej pamięci na bufory (m.in. uprawnienia do plików)
  • memory cache - ilość zajętej pamięci na cache dyskowy (dane z dysku najczęściej czytane są wrzucane do pamięci RAM i z niej podawane)
  • swap si - ilość stron pamięci czytanych ze SWAP
  • swap so - ilość stron pamięci zapisywany do SWAP
  • io bi - ilość bloków czytanych z dysku
  • io bo - ilość bloków danych zapisywanych na dysk
  • system in - ilość obsługiwanych przerwań na sekundę
  • system cs - ilość przełączeń kontekstu procesora
  • cpu us - procentowe wykorzystanie procesora w sekcji user
  • cpu sy - procentowe wykorzystanie procesora w sekcji system
  • cpu id - procentowo wolne zasoby procesora - idle
  • cpu wa - procentowe oszacowanie oczekiwania procesora na zasoby np. I/O

Bardzo ważne elementy to procs, mówią nam one o tym czy nasz procesor jest wystarczająco mocny by obsługiwać wszystkie nasze pracujące aplikacje, jeśli liczba przy procs r jest duża oznacza, że tyle procesów oczekuje na obsłużenie. Kolejnym istotnym elementem jest sekcja swap si/so, jeśli mamy duży przyrost w so a nie mamy w si, może to oznaczać, że któryś proces ma wycieki pamięci, ponieważ występuje tylko zrzucanie stron pamięci, a nie ma żadnych odczytów, natomiast w znacznie gorszej dla nas sytuacji, braku pamięci występuje zjawisko (page'ingu), czyli zarówno si jak i so zwiększają się (dużo stron jest czytanych jak i pisanych).

Należy sukcesywnie monitorować pracę naszego serwera, najlepiej za pomocą wykresów (munin, cacti) by móc jednoznacznie określić czy występuje sytuacja braku zasobów, czy po prostu nasz system jest optymalnie wykorzystany. Każdy system jest inny i  posiada inną charakterystę pracy, a wzrost niektórych wartości wcale nie musi od razu oznaczać braku zasobów, ale każde takie zjawisko powinno być poddane analizie.

5. pmap

pmap - narzędzie raportujące mapę pamięci dla procesu, dzięki niemu możemy dokładnie odczytać ilość pamięci wykorzystywanej przez proces.

Przykładowe użycie: pmap -x $pid

jamzed@yoursite:~$ pmap -x 26046
26046:   tail -f /var/log/apache2/varlog.pl.access.log /var/log/apache2/sysfault.pl.access.log
Address Kbytes RSS    Anon Locked Mode   Mapping
0061d000       4       -       -       - r-x--    [ anon ]
00906000    1272       -       -       - r-x--  libc-2.10.1.so
00a44000       4       -       -       - -----  libc-2.10.1.so
00a45000       8       -       -       - r----  libc-2.10.1.so
00a47000       4       -       -       - rw---  libc-2.10.1.so
00a48000      12       -       -       - rw---    [ anon ]
00a52000     108       -       -       - r-x--  ld-2.10.1.so
00a6d000       4       -       -       - r----  ld-2.10.1.so
00a6e000       4       -       -       - rw---  ld-2.10.1.so
08048000      52       -       -       - r-x--  tail
08055000       4       -       -       - r----  tail
08056000       4       -       -       - rw---  tail
0915c000     132       -       -       - rw---    [ anon ]
b7732000     344       -       -       - r----  locale-archive
b7788000       4       -       -       - rw---    [ anon ]
b778c000      12       -       -       - rw---    [ anon ]
bfaad000      84       -       -       - rw---    [ stack ]
-------- ------- ------- ------- -------
total kB    2056       -       -       -

6. strace

strace - o strace można pisać godzinami, jest to doskonałe i bardzo zaawansowane narzędzie służące do monitorowania pracy naszych procesów. Główne zalety strace to możliwość podpięcia się do aktualnie pracującej aplikacji w celu "podglądania", co aktualnie się w niej dzieje. strace pokazuje wszystkie wywoływane funkcje przez proces, dzięki temu możemy odczytać np. ile czasu spędza nasza aplikacja na pobieraniu danych z zewnętrznego systemu (bazy danych), ile czasu trwa zapis lub odczyt danych z dysku/na dysk, lub po prostu sprawdzić na czym zawiesza się nasz proces.

Przykładowe użycie w trybie podpinania się: strace -s 8192 -r -p $pid, lub trybie wsadowym: strace ls

Aby biegle odczytywać informacje zwracane przez strace należy znać budowę formatu wyjścia, w przypadku uruchomienia strace ls, otrzymujemy funkcję systemową i argumenty jakie aktualnie są wykonywane, jeśli nie wiemy co robi dana funkcja możemy skorzystać z pomocy manualów, np. man 2 open. (należy mieć zainstalowany pakiet manpages-dev)

Zapraszam do przeczytania również wpisu strace - czyli o śledzeniu słów kilka.

7. ltrace

ltrace - jest to analogicznie działające narzędzie do strace, z tym, że zamiast funkcji systemowych, ltrace pozwala na śledzenie wywołań bibliotecznych.

8. uptime

uptime - to jedne z kluczowych narzędzi, bardzo proste w obsłudze i bardzo użyteczne. Dzięki uptime dowiemy się nie tylko ile czasu nasz system aktualnie już pracuje, ale również poznamy jego load. Czym właściwe jest load? Istnieje bardzo dużo wytłumaczeń na to pytanie, w skrócie load jest przede wszystkim wartością którą należy rozpatrywać indywidualnie na każdym serwerze, load to ilość procesów aktualnie oczekujących na obsługę przez procesor.

Jest to dość kontrowersyjne wytłumaczenie, najprościej to pokazać na przykładzie serwera z jednym procesorem (ponieważ w serwerze 8 core'owym wartość loadu 8 wcale nie musi oznaczać problemów z wydajnością).

Przykładowe użycie: uptime

root@yoursite:/home/jamzed# uptime
19:38:48 up 3 days,  7:07,  5 users,  load average: 0.00, 0.02, 0.00

Wynik polecenia mówi nam, że nasz system pracuje 3 dni 7h 7m, zalogowanych aktualnie jest 5 użytkowników, pozostałe 3 wartości to reprezentacji loadu w przedziałach czasowych:

  • 1min - 0.00
  • 5min - 0.02
  • 15min - 0.00

Pierwsza wartość była wyznaczona 1 minutę temu, druga 5 minut temu, trzecia 15 minut temu. Wartość loadu 1 na serwerze z jednym procesorem oznacza, że nasz procesor obsługuje w trybie ciągłym procesy i teoretycznie nic na nic nie czeka, ale wartość pożądana to 0.70-0.80 per core procesora, wtedy możemy mieć pewność, że nie dojdzie do sytuacji kiedy procesy będą musiały oczekiwać na czas procesora.

9. netstat

netstat - to doskonały monitor połączeń sieciowych, który pokaże nam wszystkie trwające aktualnie sesje TCP, otwarte sockety w systemie, również aplikacje które są do nich przybindowane, ale również dzięki netstat'owi możemy poznać trasy routingu.

Przykładowe użycie: netstat -rn
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
195.205.203.224 0.0.0.0         255.255.255.240 U         0 0          0 eth0
0.0.0.0         195.205.203.225 0.0.0.0         UG        0 0          0 eth0

# netstat -nplut
Proto Recv-Q Send-Q Local Address Foreign Address State       PID/Program name
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      2301/mysqld
tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN      2515/memcached
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      25630/apache2
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      6697/vsftpd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      840/sshd
tcp6       0      0 :::113                  :::*                    LISTEN      843/gidentd
tcp6       0      0 :::22                   :::*                    LISTEN      840/sshd
udp        0      0 127.0.0.1:11211         0.0.0.0:*                           2515/memcached

# netstat -nap
tcp        0      0 127.0.0.1:11211         127.0.0.1:50655         ESTABLISHED 2515/memcached

  • netstat -rn - pokazuje nam aktualne trasy routingu, wraz z domyślną bramą (analogicznie do route -n)
  • netstat -nplut - pokaże nam wszystkie procesy wraz z portami do których są przybindowane
  • netstat -nap - aktualnie trwające sesje TCP wraz z aplikacjami

Gdy w systemie uruchamiamy jakiś daemon sieciowy, to właśnie netstat nam pokaże czy poprawnie się podpiął do interfejsu, lub kto/co jest z nim połączone.

10. tcpdump

tcpdump - jest snifferem interfejsów sieciowych, gdy chcemy sprawdzić jaki ruch odbywa się na naszym interfejsie sieciowym, lub diagnozujemy problemy z połączeniem, wykorzystamy do tego właśnie tcpdump'a.

Przykładowe użycie: tcpdump -ni eth0 host www.varlog.pl and port 80

20:25:55.370858 IP 195.205.203.232.51875 >195.205.203.232 .80: Flags [S], seq 3417027291, win 5840, options [mss 1460,sackOK,TS val 71849864 ecr 0,nop,wscale 5], length 0
20:25:55.377122 IP195.205.203.232 .80 > 195.205.203.232.51875: Flags [S.], seq 1583835480, ack 3417027292, win 5792, options [mss 1460,nop,nop,TS val 187148228 ecr 71849864,nop,wscale 9], length 0
20:25:55.377144 IP 195.205.203.232.51875 > 195.205.203.232.80: Flags [.], ack 1, win 183, options [nop,nop,TS val 71849865 ecr 187148228], length 0
20:25:57.249727 IP 195.205.203.232.51875 > 195.205.203.232.80: Flags [F.], seq 1, ack 1, win 183, options [nop,nop,TS val 71850334 ecr 187148228], length 0
20:25:57.258143 IP195.205.203.232 .80 > 195.205.203.232.51875: Flags [F.], seq 1, ack 2, win 12, options [nop,nop,TS val 187148416 ecr 71850334], length 0
20:25:57.258160 IP 195.205.203.232.51875 > 195.205.203.232.80: Flags [.], ack 2, win 183, options [nop,nop,TS val 71850336 ecr 187148416], length 0
^C
6 packets captured
11 packets received by filter

tcpdump -ni eth0 host www.varlog.pl and port 80 - oznacza, że chcemy śledzić ruch dot. hosta www.varlog.pl oraz portu 80, nie określamy czy ruch ma być wychodzący czy przychodzący (przełączniki src/dst), więc będziemy sniffować oba przypadki., przełącznik -i służy do określenia intefejsu sieciowego który chcemy podsłuchiwać a -n wyłącza resolve'owanie IP na host (przyśpiesza działanie).

tcpdump jest doskonałym narzędziem do diagnozowania problemów sieciowych, jeśli chcemy sprawdzić czy dany pakiet jest poprawnie przekazywany pomiędzy interejsami, czy dociera do nas, lub czy jest od nas wysyłany. Z dodatkowych przełączników polecam -xXv pozwala na podglądanie zawartości ramek TCP, szczególnie przydatne w przypadku ruchu HTTP.

Podzieliłem się z Wami swoimi narzędziami z listy TOP10, teraz chciałbym abyście Wy w komentarzach podali mi swoje ulubione zabawki ;-)

Platforma hostingowa, czy własny VPS?

Patryk Kuźmicz 3 komentarze

Administrując naszymi stronami WWW dochodzimy do momentu, kiedy nasza platforma hostingowa przestaje być wystarczająca, nasza strona dojrzewała przez długi okres czasu i zdobyła już rzeszę fanów, z czego bardzo się cieszymy, ale z drugiej strony rozrost i duża liczba odbiorców spowodowała napływającą falę złych opinii. Użytkownicy nie są zadowoleni z jakości pracy naszego serwisu, skarżą się, że każde kliknięcie to sekundy oczekiwania, sytuacja wbrew pozorom jest niebezpieczna, ponieważ nasza strona istnieje dzięki użytkownikom, a Ci jeśli nie będą zadowoleni, przejdą na konkurencyjne serwisy. Co możemy w tej sytuacji zrobić? Mamy kilka opcji, możemy poszukać kolejnego dostawcy z nadzieją na udostępnianie większej mocy obliczeniowej w tej samej cenie, możemy zainwestować w większy pakiet hostingowy, lub zdobyć się na duży krok i wykupić własny serwer wirtualny lub dedykowany, który przygotujemy sobie sami dokładnie wg naszych potrzeb.

Co najczęściej otrzymujemy wraz z klasycznym hostingiem?

  • zamkniętą platformę (gotowe rozwiązania),
  • wsparcie usługodawcy
  • panel do zarządzania
  • limity (pasmo, dysk, ilość baz danych)

Zamknięta platforma oznacza, że będzie nam ciężko wymusić na usługodawcy zmianę parametrów, bądź doinstalowanie niestandardowego modułu. Zazwyczaj otrzymujemy z góry określone rozwiązanie które jest opisane w umowie/regulaminie/ofercie i wpłynięcie na zmianę czegokolwiek graniczy z cudem. Atutem platformy hostingowej może być support administratorów i jest to na pewno jeden z kilku czynników które powinniśmy brać pod uwagę kupując konto, bo co nam z płatnego hostingu, jeśli rozwiązanie każdego problemu zajmie 2 tygodnie. Panel zarządzający to najczęściej strona WWW która umożliwia wgranie plików z naszym serwisem i ich edycję. To właśnie w panelu skonfigurujemy konta pocztowe, sprawdzimy nasze limity transferu czy zajętość dysku twardego, to są najczęstsze ograniczenia naszego konta i w zależności od opcji (pakietu hostingowego) te limity będą mniejsze lub większe. Pojemność konta nie jest tak bardzo istotna o ile nie zamierzamy tworzyć i utrzymywać stron zawierających galerie zdjęć, zdecydowanie ważniejszym parametrem jest właśnie miesięczne dostępne pasmo. Można spotkać się z limitami rzędu kilkuset MB, kilku GB, a w bardzo dużych hostingach nawet TB. To właśnie ten limit potrafi nas skutecznie zablokować, dla przykładu obliczmy, posiadamy konto z rocznym limitem 2000GB, wielkość naszej strony to kilka MB z grafiką, załóżmy, że średnio użytkownik pobiera 5MB danych poruszając się po naszej stronie.

2097152000 - tyle bajtów mamy do wykorzystania na rok
5120 - tyle bajtów pobiera średnio 1 użytkownik
2097152000/5120 = 409600 - tyle razy nasza strona będzie mogła być pobrana w ciągu roku
409600/365 = 1122 - dziennie nasza strona będzie mogła być oglądana 1122 razy

Powyższe wyliczenia dotyczą sytuacji kiedy na stronie nie umieszczamy plików do pobrania, każde pobranie takiego pliku to kolejne MB mniej naszego ogólnego pasma, ale jak widać powyższe limity są raczej bezpieczne dla małych/średnich zastosowań biznesowych czy domowych (strona firmowa, blog, forum).

Zupełnie inaczej wygląda sytuacja kiedy posiadamy stronę tworzoną na nasze zamówienie, np. jakiś mini portal. Jeśli programiści znali się na rzeczy to prawdopodobnie napisali serwis wydajnie i bezpiecznie, ale są sytuacje kiedy nasz serwis wykorzystuje technologie rzadko dostępne, jest napisany z wykorzystaniem Ruby on Rails (Ruby), lub oparty o framework Django (Python). Co wtedy możemy zrobić? Zapłaciliśmy już pieniądze za stworzenie serwisu, nie znaliśmy się na technologiach i nikt nas nie poinformował, że będą problemy z uruchomieniem serwisu na pierwszym lepszym hostingu... W takiej sytuacji pozostaje jedynie skorzystać z opcji dedykowanego serwera, np. wirtualnego (VPS).

Czym jest VPS (Virtual Private Server)? Jest to wirtualny prywatny serwer, w praktyce jest to uruchomiony system operacyjny na już działającym. Uruchomiony jest serwer główny (fizyczny) i na nich uruchomionych jest kilka/kilkanaście instancji środowisk wirtualnych. Każdy z takich serwerów jest odseparowany i nie ma możliwości podglądania co znajduje się na innej maszynie obok, taki serwer należy traktować jak niezależny normalny serwer który jedynie współdzieli zasoby z innymi wirtualnymi serwerami.

Czym się charakteryzuje serwer dedykowany?

  • powierzchnia dyskowa
  • taktowanie procesora
  • ilość dostępnej pamięci operacyjnej
  • system operacyjny

Powyższe parametry są głównymi miernikami jakości naszego serwera, ważne jest by serwer otrzymał jak najwięcej czasu procesora, posiadał jak największą przestrzeń dyskową (1-2GB powierzchni dyskowej może być ilością zbyt małą, ponieważ nie jest to miejsce jedynie na naszą stronę, ale na cały system operacyjny, w pełni funkcjonalny Linuks pracujący jako serwer WWW, to zajętość od kilkuset MB w górę). Drugim elementem zaraz po procesorze jest ilość dostępnej pamięci, to głównie od niej zależy ile aplikacji będziemy w stanie uruchomić na serwerze i czy nasz serwer będzie pracował szybko i wydajnie. Kolejny istotny element to możliwe do wyboru systemy operacyjne, jeśli nasza storna jest stworzona w ASP to musimy wybrać VPS wspierający systemy z rodziny Windows.

Zasadniczą różnicą pomiędzy własnym serwerem dedykowanym a gotową platformą hostingową jest to, że otrzymujemy jedynie goły system operacyjny, na którym musimy sami uruchomić serwer WWW, serwer baz danych np. MySQL czy PostgreSQL. Dzięki temu otrzymujemy bardzo duże możliwości konfiguracyjne, posiadamy jasno określone zasoby których nikt nam nie zabierze i w ramach tego możemy uruchamiać nawet najbardziej przedziwne serwisy, jeśli brakuje nam jakiegoś modułu to po prostu go doinstalujemy, czyli sytuacja jest zupełnie odwrotną do tej w przypadku platformy hostingowej.

Musisz wiedzieć, że utrzymywanie własnego serwera nie jest łatwym zadaniem, jeśli nie posiadasz doświadczenia w administracji Linuksem, utrzymywania serwisów WWW od strony systemu operacyjnego to korzystanie z takiego serwera będzie dla Ciebie utrapieniem, ale to co możesz zrobić to poprosić znajomego administratora o zainstalowanie np. panelu do zarządzania, nie daję gwarancji, że z darmowych znajdziesz dla siebie idealne rozwiązanie, ale wspierając się pomocą na pewno razem uruchomicie platformę która spełni Twoje oczekiwania i zaspokoi potrzeby użytkowników.

Wybór pomiędzy hostingiem a VPSem to tak naprawdę wybór pomiędzy tym co nam dają, a tym co możemy sami zrobić. Jeśli interesujesz się administracją to VPS będzie dla Ciebie idealnym rozwiązaniem, pozwoli Ci podszkolić swoje umiejętności i jednocześnie uruchomić środowisko, natomiast jeśli uciekasz od techniki, nie masz czasu na zabawę w konfigurację Apache czy MySQL to powinieneś wybrać platformę hostingową z bardzo dobrym wsparciem.

A Wy co preferujecie?

Nakładamy napisy na film

Patryk Kuźmicz 2 komentarze

Jeśli masz stare DVD które nie czyta poprawnie napisów w filmach a jesteś użytkownikiem Linuksa, możesz spróbować nałożyć napisy bezpośrednio na film. Jaka jest różnica w stosunku do normalnego odtwarzania filmu z napisami? Bardzo duża, ponieważ napisy nie są czytane z pliku podczas odtwarzania, ale stają się nieodłączną częścią filmu, wygląda to mniej więcej tak jak nałożenie dwóch obrazów na siebie, jednego z filmem, a drugiego z samymi napisami.

W systemie Linux Ubuntu możemy to zrobić dzięki aplikacji mencoder. Jeśli nie posiadamy zainstalowanego pakietu z mencoderem, instalację przeprowadzamy poprzez wydanie polecenia:

# apt-get install mencoder

Po tym, powinniśmy już mieć w pełni działający kombajn do konwersji audio/wideo w systemie. Teraz pozostaje sam proces nałożenia napisów, ale wcześniej wypada jeszcze doinstalować czcionki (pakiet msttcorefonts).

# apt-get install msttcorefonts
$ mencoder -oac copy -ovc xvid -xvidencopts pass=1:turbo:threads=2 -sub napisy.txt -o wideo-out-with-sub.avi wideo-in.avi -font /usr/share/fonts/truetype/msttcorefonts/arial.ttf -subfont-text-scale 3 -subcp cp1250

Skrócony opis poszczególnych parametrów:

-ovc - wybór kodeka wyjściowego video (XVID)
-oac - wybór kodeka wyjściowego audio (copy, ten sam który jest na wejściu)
-sub - ścieżka do pliku z napisami
-o - plik wyjściowy (video+audio+napisy)
-subfont-text-scale - wielkość czcionki użytej dla naszych napisów
-font - czcionka użyta do napisów (arial.ttf)
-subcp - kodowanie znaków pliku z napisami (cp1250 - kodowanie z MS Windows)

Powodzenia ;-)