d wersji 10.5 „Leopard”, Mac OS X posiada zestaw narzędzi o nazwie DTrace (ang. Dynamic Tracing Framework), który służy do analizy wydajności oraz rozwiązywania problemów z systemem. Zestaw ten dostarcza dane m.in dla narzędzi Apple Instruments, czy pozwala na wykorzystanie różnego rodzaju programów, które w rzeczywistości są skryptami DTrace. Autorem DTrace, jak i DTraceToolkit jest Brendan Gregg. Firma Apple po prostu dostosowała je do swojego systemu i umieściła jako standardowy pakiet oprogramowania Mac OS X.

Jak zaznacza sam autor DTrace może zostać wykorzystany, głównie do odpowiedzi na dwa pytania: - dlaczego mój Mac jest taki powolny? oraz - dlaczego mój wentylator zaczął tak głośno chodzić? W przeciwieństwie do DTrace – standardowe narzędzia do analizy, jak Monitor Aktywności (ang. Activity Monitor) oraz top(1) nie zawsze potrafią dostarczyć kluczowych informacji na temat aktywności programów w systemie np. jak wiele czasu procesora zajmują krótko żyjące procesy; które procesy powodują największe zużycie I/O dysku; ile czasu zajmuje odczyt / zapis danego procesu na dysku itd. Poniżej przedstawiam krótką listę i działanie niektórych skryptów DTrace:

1. iosnoop

- narzędzie to służy do „śledzenia” I/O dysku. Za każdym razem, kiedy operacja I/O się zakończy – na wyjściu programu wyświetlany jest wiersz z podsumowaniem całego procesu:

darkstar:~ root# iosnoop
      UID  PID D    BLOCK   SIZE   COMM PATHNAME
160951430  366 R 48634712   4096  iTerm ??/com.googlecode.iterm.savedState/window_2.data
160951430  366 R 48634696   8192  iTerm ??/com.googlecode.iterm.savedState/window_2.data
160951430  366 W 48634712   4096  iTerm ??/com.googlecode.iterm.savedState/window_2.data
160951430  366 W 48634848  28672  iTerm ??/com.googlecode.iterm.savedState/window_2.data
160951430  366 W 48634904   4096  iTerm ??/com.googlecode.iterm.savedState/windows.plist
160951430  280 W 46685144  16384  Google Chrome ??/Default/Current Session
160951430  280 W 48635248 106496  Google Chrome ??/Default/.com.google.Chrome.zuK91F
    0        1 W 48048904  12288  launchd ??/T/etilqs_hF8gPlcMjfI2taD
    0        1 W 55170792   4096  launchd ??/asl/2012.04.30.U160951430.asl
    0        1 W 55171216   4096  launchd ??/asl/2012.04.30.U160951430.asl
    0        1 W 40742344   4096  launchd ??/log/system.log
    0        1 W 19899032   4096  launchd ??/asl/StoreData

Pozwala to na ciągłe monitorowanie aplikacji, które używają dysku oraz jakie pliki są przez nie czytane lub zapisywane. Operacje I/O na normalnych dyskach obrotowych nadal są wąskim gardłem w wydajności sprzętowej dlatego programy, które bardzo często żądają dostępu do danych (15 razy lub więcej na sekundę) mają prawo czasami wolniej wykonywać swoje funkcje ze względu na oczekiwanie na zakończenie operacji zapisu/odczytu. Prezentowane powyżej kolumny oznaczają kolejno: UID = użytkownik, PID = identyfikator procesu, D = rodzaj operacji (R = odczyt / W = zapis), BLOCK = położenie na dysku, SIZE = wielkość procesowanych danych w bajtach, COMM = nazwa procesu, PATHNAME = końcowa część ścieżki do pliku. W powyższym przykładnie została przyłapana przeglądarka Google Chrome na zapisywaniu bieżącej sesji ??/Default/Current Session. Jeśli zależy nam na bardziej szczegółowej analizie możemy wykorzystać parametry „-stoD„, które zwrócą timestamp’y każdego startu i końca operacji I/O wyrażone w microsekundach – plus opis kilku innych typów operacji również z informacjami czasowymi:

darkstar:~ root# iosnoop -stoD
STIME       TIME        DELTA  DTIME  UID  PID D    BLOCK  SIZE     COMM PATHNAME
4149708383  4149709133  750    768      0    1 W 41878792  4096  launchd ??/Cache/data_1

2. hfsslower.d

- skrypt ten tak naprawdę jest odpowiedzą na pytanie: - dlaczego iosnoop nie widzi wszystkich operacji I/O, jakie zachodzą na dysku? Odpowiedź jest prosta: w celu zwiększenia wydajności system plików zawsze będzie starał się cachować jak najwięcej danych w pamięci RAM. Czasami aplikacja wykonując operację odczytu „myśli”, że wykonuje odczyt z dysku – a tak naprawdę operacja ta jest wykonywana z bardzo szybkiej pamięci. Zapisy również mogą być buforowane w pamięci, a dopiero później zapisana wraz z innymi buforami na dysk, co również przyśpiesza działanie aplikacji. Skrypt hfsslower.d mierzy operacje I/O zanim zostaną one przetworzone przez system plików HFS+, a iosnoop mierzy je dopiero po przetworzeniu ich przez system plików i tylko jeśli dotrą do dysku. Dlatego można powiedzieć, że hfsslower.d jest w stanie zobaczyć znacznie więcej, w tym odzwierciedlić rzeczywistą wydajność aplikacji ze względu na pomiary opóźnienia, na które ona bezpośrednio cierpi. W dodatku hfsslower.d potrafi dostarczyć informacji o tym, że nie tylko wolne operacje I/O są powodowane przez dysk, ale na przykład może wystąpić zjawisko zakleszczenia w systemie plików (zjawisko to występuje kiedy jeden z procesów lub wątków przed uzyskaniem dostępu do zasobu próbuje uzyskać blokadę tego zasobu, która jest trzymana przez inny proces lub wątek). Skrypt ten pochodzi z książki DTrace i nie jest uwzględniony standardowo w dystrybucji systemu, dlatego można go ściągnąć stąd i przegrać z prawami 755 do katalogu /usr/local/bin. Jako argument może przyjąć liczbę określającą minimalną liczbę milisekund jaką zajęła operacja I/O:

[agresor@darkstar ~]$ sudo hfsslower.d 1
TIME                 PROCESS          D   KB     ms FILE
2012 May  1 13:33:46 esets_daemon     R    0     56 cursor.pdf/..namedfork/rsrc
2012 May  1 13:33:46 esets_daemon     R    4      7 cursor_1only_.png

Dlatego, jeśli użyjemy argumentu 0 będziemy w stanie śledzić każdą operację. Prezentowane powyżej kolumny oznaczają kolejno: TIME = czas zakończenia operacji I/O, PROCESS = nazwa aplikacji, D = rodzaj operacji (R = odczyt / W = zapis), KB = rozmiar operacji w Kilo Bajtach, ms = opóźnienie I/O w milisekundach, FILE = nazwa pliku, na którym wykonywana jest operacja.

3. execsnoop

- polecenie to śledzi wykonywanie nowych procesów. Szczególnie przydaje się w przypadku identyfikacji procesów o krótkim czasie życia tj. ich uruchomienie i zakończenie jest zbyt szybkie, aby wychwyciły je narzędzia typu top oraz Monitor Aktywności. Na przykład procesy te są uruchamiane podczas wykonania polecenia: ls man:

[agresor@darkstar ~]$ sudo execsnoop -v
STRTIME                UID    PID   PPID ARGS
2012 May  4 17:34:31 160951430    410     59 SFLSharedPrefsTo
2012 May  4 17:34:37 160951430    411    389 login
2012 May  4 17:34:37 160951430    412    411 bash
2012 May  4 17:34:37 160951430    414    413 path_helper
2012 May  4 17:34:42 160951430    415    412 man
2012 May  4 17:34:43 160951430    415    412 man
2012 May  4 17:34:43 160951430    415    412 man
2012 May  4 17:34:43 160951430    415    412 man
2012 May  4 17:34:43 160951430    416    415 sh
2012 May  4 17:34:43 160951430    416    415 gzip
2012 May  4 17:34:43 160951430    417    415 sh
2012 May  4 17:34:43 160951430    417    415 gzip
2012 May  4 17:34:43 160951430    425    424 less
2012 May  4 17:34:43 160951430    421    419 tbl
2012 May  4 17:34:43 160951430    426    422 troff
2012 May  4 17:34:43 160951430    423    420 sh
2012 May  4 17:34:43 160951430    423    420 gzip
2012 May  4 17:34:43 160951430    422    419 groff
2012 May  4 17:34:43 160951430    427    422 grotty

Prezentowane powyżej kolumny oznaczają kolejno: STRTIME = znacznik czasowy, UID = ID użytkownika, PID = ID procesu, PPID = ID rodzica procesu, ARGS = nazwa procesu (wyświetlane powinny być również argumenty przekazywane do procesów, ale nie działa to jeszcze w Mac OS X – więcej informacji na ten temat dostarcza pr_psargs w /usr/lib/dtrace/proc.d).

4. opensnoop

- pozwala na śledzenie plików, które są otwierane podczas uruchamiania programu. Pozwala to na wychwycenie różnego rodzaju błędów konfiguracyjnych, które zawierają złe ścieżki dostępu lub szczegółowo sprawdzić, co się dzieje podczas uruchamiania aplikacji:

[agresor@darkstar ~]$ sudo opensnoop -ve
STRTIME                UID   PID COMM          FD ERR PATH
2012 May  5 20:30:21     0   41 mds            9   0 .
2012 May  5 20:30:21     0  462 dtrace         6   0 /etc/localtime
2012 May  5 20:30:22     0  463 launchdadd     3   0 /dev/dtracehelper
2012 May  5 20:30:22     0  463 launchdadd     5   0 /var/db/launchd.db/com.apple.launchd
2012 May  5 20:30:22     0  463 launchdadd     6   0 /var/db/launchd.db/com.apple.launchd
2012 May  5 20:30:22     0  463 launchdadd     5   0 /usr/libexec
2012 May  5 20:30:22     0  463 launchdadd     5   0 /usr/libexec/launchdadd
2012 May  5 20:30:22     0   41 mds            9   0 .
2012 May  5 20:30:22    89  308 mdworker       9   0 /Library/PrivilegedHelperTools
2012 May  5 20:30:28     0  276 esets_daemon  15   0 /etc/localtime
2012 May  5 20:30:28     0  276 esets_daemon  15   0 /etc/localtime

Prezentowane powyżej kolumny oznaczają kolejno: STRTIME = znacznik czasowy, UID = ID użytkownika, PID = ID procesu, COMM = nazwa procesu / polecenie, FD = deskryptor pliku (-1 oznacza błąd ścieżki dostępu), ERR = kod błędu (szczegóły /usr/include/sys/errno.h), PATH = ścieżka dostępu.

5. dtruss

- poprzednie dwa narzędzia – opensnoop oraz execsnoop działały na podstawie śledzenia konkretnych wywołań systemowych. Wywołanie systemowe (ang. system call lub syscall) jest tym, o co aplikacja prosi jądro systemu operacyjnego kiedy przychodzi do wykonania uprzywilejowanego zadania, stworzenia procesu, operacji na plikach lub inne operacje I/O (dyskowe lub sieciowe). Wywołania systemowe są świetnym celem do analizy dla DTrace, ponieważ ich badanie często potrafi dostarczyć niezbędnych informacji (liczbę bajtów, nazwy plików i procesów, kody błędów, opóźnienia) o poczynaniach aplikacji. Narzędzie dtruss śledzi wszystkie rodzaje wywołań systemowych, co jest bardzo przydatne przy ogólnie pojętym debugowaniu (szczególnie, że Mac OS X tak naprawdę nie posiada typowego tracer’a syscall’i jak Linux „strace” lub Solaris „truss„). Jedną z zalet dtruss jest to, że może on śledzić kilka procesów w tym samym czasie – poprzez dopasowanie po nazwie procesu (opcja -n). Na przykład śledzenie przeglądarki Firefox po nazwie jej pliku binarnego:

[agresor@darkstar ~]$ sudo dtruss -n firefox-bin
	PID/THRD  SYSCALL(args) = return
  531/0x3738:  issetugid(0x100000000, 0x7FFF5FBFFDC9, 0x7FFF5FBFFC00) = 0 0
  531/0x3738:  csops(0x0, 0x0, 0x7FFF5FBFF84C) = 0 0
  531/0x3738:  shared_region_check_np(0x7FFF5FBFD798, 0x2, 0x55) = 0 0
  531/0x3738:  pread(0x3, "\312\376\272\276\0", 0x1000, 0x0) = 4096 0
  531/0x3738:  pread(0x3, "\317\372\355\376\a\0", 0x1000, 0x1000) = 4096 0
  531/0x3738:  mmap(0x100005000, 0x3000, 0x5, 0x12, 0x3, 0x100001F) = 0x5000 0
  531/0x3738:  mmap(0x100008000, 0x1000, 0x3, 0x12, 0x3, 0x100001F) = 0x8000 0
  531/0x3738:  mmap(0x100009000, 0x2C70, 0x1, 0x12, 0x3, 0x100001F) = 0x9000 0
  531/0x3738:  fcntl(0x3, 0x2C, 0x7FFF5FBFC678) = 0 0
  531/0x3738:  close(0x3) = 0 0
  531/0x3738:  stat64("/\0", 0x7FFF5FBFD2F0, 0x6) = 0 0
  531/0x3738:  getattrlist("/Applications\0", 0x7FFF684DC6F0, 0x7FFF5FBFD380) = 0 0
  531/0x3738:  getattrlist("/Applications/Firefox.app\0", 0x7FFF684DC6F0, 0x7FFF5FBFD380)

Ekran wyjściowy oczywiście jest znacznie dłuższy ze względu na wykonywanie bardzo dużej ilości wywołań. Jeśli ominiemy opcję -n – spowodujemy, że dtruss sam uruchomi wybraną aplikację i rozpocznie jej śledzenie. Dzięki wielu innym opcją możemy na przykład dodać znaczniki czasowe (-e), śledzić podprocesy (-f), sprawdzić ilość wywołań systemowych (-c) oraz wiele innych. Ryan Dahl (twórca node.js używał tak często narzędzia dtruss, że wprowadził własne usprawnienia i opublikował swoją wersję na github’ie.

6. soconnect_mac.d

- skrypt ten również nie wchodzi w standardowy zestaw narzędzi DTrace. Oczywiście można go ściągnąć w wgrać do systemu z oficjalnej strony książki poświęconej DTrace. Pozwala on na śledzenie wychodzących z systemu połączeń TCP.

[agresor@darkstar ~]$ sudo sconnect.d
PID    PROCESS          FAM ADDRESS          PORT   LAT(us) RESULT
534    ssh              2   11.111.11.11     22       39993 Success
19     opendirectoryd   2   12.123.12.123    389        107 In progress
543    Adium            2   22.222.222.222   5222        88 In progress
543    Adium            2   32.32.321.32     5222       113 In progress

Istnieje również narzędzie o nazwie soaccept_mac.d, które służy z kolei do śledzenia połączeń przychodzących.

7. errinfo

- narzędzie to dostarcza podsumowania, które z wywołań systemowych zakończyły się błędem. Oprócz kodu błędu możemy uzyskać krótki opis kodu oraz nazwę procesu, który go wygenerował. Dzięki temu możemy szybko wyśledzić źle skonfigurowane lub nieprawidłowo obsługujące kody błędów aplikacje:

[agresor@darkstar ~]$ sudo errinfo
            EXEC          SYSCALL  ERR  DESC
            ntpd       sigsuspend    4  Interrupted system call
            ntpd        sigreturn   -2
            ntpd __pthread_canceled   22  Invalid argument
          iTerm             read   35  Resource temporarily unavailable
        perl5.12             read    4  Interrupted system call
        perl5.12        sigreturn   -2
        perl5.12 __pthread_canceled   22  Invalid argument

Innymi ciekawymi skryptami są:

• bitesize.d – charakterystyka rozkładu obciążenia I/O dysku według programów z podliczaniem liczby bajtów,
• iotop – funkcjonalnością to samo narzędzie, co iosnoop, lecz prezentujące dane bardzo podobnie do narzędzia top,
• maclife.d – skrypt śledzący tworzenie i kasowanie plików.

Oprócz w/w skryptów w systemie Mac OS X istnieje jeszcze wiele narzędzi – wystarczy w konsoli uruchomić polecenie: man -k dtrace, aby naszym oczom ukazała się pełna lista:

bitesize.d(1m)           - analyse disk I/O size by process. Uses DTrace
cpuwalk.d(1m)            - Measure which CPUs a process runs on. Uses DTrace
creatbyproc.d(1m)        - snoop creat()s by process name. Uses DTrace
dappprof(1m)             - profile user and lib function usage. Uses DTrace
dapptrace(1m)            - trace user and library function usage. Uses DTrace
diskhits(1m)             - disk access by file offset. Uses DTrace
dispqlen.d(1m)           - dispatcher queue length by CPU. Uses DTrace
dtrace(1)                - generic front-end to the DTrace facility
dtruss(1m)               - process syscall details. Uses DTrace
errinfo(1m)              - print errno for syscall fails. Uses DTrace
execsnoop(1m)            - snoop new process execution. Uses DTrace
fddist(1m)               - file descriptor usage distributions. Uses DTrace
filebyproc.d(1m)         - snoop opens by process name. Uses DTrace
hotspot.d(1m)            - print disk event by location. Uses DTrace
httpdstat.d(1m)          - realtime httpd statistics. Uses DTrace
iofile.d(1m)             - I/O wait time by file and process. Uses DTrace
iofileb.d(1m)            - I/O bytes by file and process. Uses DTrace
iopattern(1m)            - print disk I/O pattern. Uses DTrace
iopending(1m)            - plot number of pending disk events. Uses DTrace
iosnoop(1m)              - snoop I/O events as they occur. Uses DTrace
iotop(1m)                - display top disk I/O events by process. Uses DTrace
kill.d(1m)               - snoop process signals as they occur. Uses DTrace
lastwords(1m)            - print syscalls before exit. Uses DTrace
loads.d(1m)              - print load averages. Uses DTrace
newproc.d(1m)            - snoop new processes. Uses DTrace
opensnoop(1m)            - snoop file opens as they occur. Uses DTrace
pathopens.d(1m)          - full pathnames opened ok count. Uses DTrace
pidpersec.d(1m)          - print new PIDs per sec. Uses DTrace
plockstat(1)             - front-end to DTrace to print statistics about POSIX
                           mutexes and read/write locks
priclass.d(1m)           - priority distribution by scheduling class. Uses DTrace
pridist.d(1m)            - process priority distribution. Uses DTrace
procsystime(1m)          - analyse system call times. Uses DTrace
runocc.d(1m)             - run queue occupancy by CPU. Uses DTrace
rwbypid.d(1m)            - read/write calls by PID. Uses DTrace
rwbytype.d(1m)           - read/write bytes by vnode type. Uses DTrace
rwsnoop(1m)              - snoop read/write events. Uses DTrace
sampleproc(1m)           - sample processes on the CPUs. Uses DTrace
seeksize.d(1m)           - print disk event seek report. Uses DTrace
setuids.d(1m)            - snoop setuid calls as they occur. Uses DTrace
sigdist.d(1m)            - signal distribution by process. Uses DTrace
syscallbypid.d(1m)       - syscalls by process ID. Uses DTrace
syscallbyproc.d(1m)      - syscalls by process name. Uses DTrace
syscallbysysc.d(1m)      - syscalls by syscall. Uses DTrace
topsyscall(1m)           - top syscalls by syscall name. Uses DTrace
topsysproc(1m)           - top syscalls by process name. Uses DTrace
weblatency.d(1m)         - website latency statistics. Uses DTrace

Plus te dostępne na stronie książki o DTrace. Na koniec wypada przypomnieć, że DTrace nie tylko służy do wykonywania skryptów, ale jako framework umożliwia pisanie własnych programów, skryptów, czy jednolinijkowców. I nie chodzi tylko o MacBooki, ale jeśli używamy serwerów opartych na systemie operacyjnym Solaris lub FreeBSD możemy wykorzystać te wszystkie skrypty do codziennych prac administracyjnych i diagnozy problemów wydajnościowych.

Więcej informacji: DTrace Tools, Solaris Dynamic Tracing Guide, Top 10 DTrace scripts for Mac

eśli zależy nam na wykonaniu przekierowania HTTP 301 na poziomie varnish‘a np. z adresu www.domena.pl na domena.pl razem z uwzględnieniem przekazanych adresów URL w domenie www.domena.pl wystarczy w podprogramie vcl_recv odpowiedzialnym za procesowanie żądania HTTP dodać kod:

if (req.http.host == "www.domena.pl") {
    error 301;
}

- spowoduje to wyłapywanie nagłówka „Host” z ustawioną wartością na: www.domena.pl, zgłoszonego przez przeglądarkę lub inny program i przekazanie całego żądania do podprogramu vcl_error, gdzie możemy obsłużyć „błąd” 301:

if (obj.status == 301 && req.http.host == "www.domena.pl") {
    set obj.http.location = "http://domena.pl" + req.url;
    set obj.status = 301;
    return (deliver);
}

W przypadku kiedy chcemy wykonać dużo przekierowań pomiędzy dwoma domenami bez uwzględnienia adresów URL – możemy skorzystać z specjalnego rozszerzenia do varnish’a redirect, któremu wystarczy w przekazać wszystkie informacje w vcl_recv:

import redirect;

sub vcl_recv {
    if (req.http.host == "www.domena.pl") {
        error(redirect.location(301,"http://domena.pl"), "Moved Permanently");
    }
}

Więcej informacji: Varnish Configuration Language

icholas Tang napisał w perlu mały skrypt, który pozwala na wyciągnięcie z poziomu konsoli statystyk dla daemona memcached. Przyjmuje on następujące parametry:

#   If Getopt::Long is installed:
#     - Specify instances w/ --instances (multiple times or comma separated)
#     - Specify default port w/ --port (defaults to 11211)
#     - Specify sleep time w/ --sleep (default 3)
#     - Specify color output w/ --color (default) or --nocolor
#     - Specify lifetime stats w/ --lifetime or --nolifetime (default)
#       NOTE: lifetime stats break thresholds for evictions, bytes.
#     - Specify read and write bytes w/ --bytes (default) or --nobytes
#     - Specify get and set commands w/ --commands or --nocommands (default)
#     - Specify cumulative numbers w/ --cumulative (don't use with lifetime)

Opcja instances pozwala na monitorowanie wielu instancji daemona na raz – mogą one znajdować się na pojedynczym serwerze i różnych portach lub na tych samych portach, ale na różnych serwerach. Bez skryptu zawsze możemy skorzystać z interfejsu telnet.

Więcej informacji: memcache-top

edług protalu webhosting.pl od wersji 3.2 jądra Linuksa został zwiększony rozmiar okna ograniczenia przesyłu (ang. the initial congestion window) z 3 do 10. Sam Saffron po wykonaniu kilku testów udowodnił, że tuning mechanizmu Slow-start pozwala na przyśpieszenie ładowania strony WWW (jeśli zastosujemy zmiany na maszynie pełniącej rolę web serwera) nawet do 25% – bez żadnej ingerencji w warstwę aplikacji. Podobne testy przeprowadzili technicy wyszukiwarki Cheméo uzyskując w własnych warunkach 20% przyśpieszenie. Czy osoby pragnące wprowadzić podobne zmiany skazane są na oczekiwanie, aż popularne dystrybucje zaczną używać jądra w wersji 3.2 – jak np. Ubuntu 12.04?

Otóż nie. Okazuje się, że zmiany rozmiaru okna zostały już wprowadzone w jądrze w wersji 2.6.39. A, co z takimi dystrybucjami jak np. Debian 6.0 lub CentOS 6.2, które korzystają jeszcze z wersji 2.6.32 ? W celu osiągnięcia tych samych rezultatów mogą skorzystać z polecenia:

ip route change default via $MYGATEWAY dev $MYDEVICE initcwnd 10

Gdzie: $MYGATEWAY to standardowa brama sieciowa oraz $MYDEVICE to karta sieciowa podłączona do tej bramy.

[root@stardust ~]# ip route show | egrep ^default
default via 91.121.72.254 dev eth0

Niestety ze względu na błąd polecenie to poprawnie zadziała tylko dla jądra Linuksa równego lub większego od wersji 2.6.30.

[root@stardust ~]# ip route show | egrep ^default
default via 91.121.72.254 dev eth0  initcwnd 10

Poniżej zamieszczam wyniki mini testów dla głównej strony tego bloga, jakie wykonałem przy pomocy serwisu Pingdom Tools. Pierwszy test wykonywany był z initcwnd ustawionym na wartość 3. Kolejne dwa testy odbyły się już z wartością 10 (zmienna waga strony wynika z ładowania różnych zewnętrznych reklam pochodzących z serwisu AdTaily).

[initcwnd 03] Ilość żądań: 44 | czas ładowania: 1.92s | waga strony: 265.1 KB
[initcwnd 10] Ilość żądań: 44 | czas ładowania: 604ms | waga strony: 265.1 KB
[initcwnd 10] Ilość żądań: 44 | czas ładowania: 526ms | waga strony: 271.1 KB

Należy jednak zaznaczyć, że ustawienie większego initcwnd nie oznacza, że klient komunikujący się z serwerem zawsze skorzysta z tej wielkości. Wynika to z faktu, że podczas „potrójnego uścisku dłoni” serwer i klient przedstawiają rozmiary swoich okien – serwer congestion window, a klient okna odbiorczego (ang. receive window aka RWIN), które określa w bajtach maksymalną ilość danych, które nadawca może wysłać bez otrzymywania potwierdzenia. Niezależnie, po której stronie wartość ta będzie mniejsza – zostanie ona przyjęta jako podstawa transmisji – nadawca nie może przekroczyć wielkości odbiorcy i na odwrót. Dlatego ograniczenie może występować zarówno po stronie serwera, jak i klienta (różne systemy posiadają różne wartości).

Receive window w systemie Linux nazywa się initrwnd – i może zostać zmienione od wersji 2.6.33 poleceniem:

ip route change default via $MYGATEWAY dev $MYDEVICE initrwnd 10

Ciekawe podejście zaprezentowali Aaron Peters oraz Sajal Kayan – konsultanci od webowej wydajności prowadzący serwis CDN planet sugerując podniesienie zarówno initcwnd oraz initrwnd na serwerach pośredniczących np. frontowych maszynach serwujących obrazki, które obsługują żądania przeglądarek, a kontaktującymi się z backendem w razie cache missów np. serwery Varnishowe, czy Nginx cacheujące ruch do Apache (na których został podniesiony tylko rozmiar initcwnd):

[IE / Firefox / Chrome] <------------> [ CDN server ] <------------> [ Backend server ]
-------| RWIN |-------------------| initcwnd |-| initrwnd |----------| initcwnd |------

Ustawienie dla serwera CDN możemy osiągnąć za pomocą polecenia:

ip route change default via $MYGATEWAY dev $MYDEVICE initrwnd 10 initcwnd 10

Autorzy serwisu przeprowadzili również serię testów różnych dostawców CDN i ich ustawień wielkości okna, z których wynika, że jeszcze nie wszystkie firmy uważają tą zmianę za konieczną. Tym bardziej, że zwiększenie initcwnd, jest jednym z wielu parametrów wydajności, jakie można zmienić w stosie sieciowym systemu Linux.

Więcej informacji: An Argument for Increasing TCP’s Inital Congestion Window

obert Tappan Morris to amerykański informatyk, znany z napisania pierwszego robaka komputerowego. Jest on synem szefa informatyków w National Security Agency. W 1988 był doktorantem na wydziale informatyki Uniwersytetu Cornell. Prowadził w tym czasie badania nad błędami z systemami 4 BSD Unix. Korzystając z wykrytych błędów napisał program nazywany dzisiaj robakiem Morrisa, który potrafił mnożyć się na tych systemach. Robak został uruchomiony 2 listopada 1988 r. Miał on mnożyć się w ograniczony sposób jednak na wskutek błędu programisty nie zadziałało wbudowane ograniczenie i robak w krótkim czasie praktycznie sparaliżował działanie ówczesnego bardzo jeszcze skromnego Internetu zarażając ponad 6 tysięcy maszyn.

Robert miał wówczas 23 lata. Uczęszczał na studia doktoranckie na wydziale informatyki Uniwersytetu Cornell. Spokojny, sympatyczny młody człowiek ze stopniem magistra Uniwersytetu Harward nigdy nie miał nic wspólnego z przestępstwami czy hackingiem. Miał jednak słabość – lubił wykrywać błędy w systemach operacyjnych. Na jesieni 1988 roku Morris zaczął prace nad programem mającym na celu ukazanie wykrytych błędów w zabezpieczeniach systemu 4 BSD Unix. Program, po „wpuszczeniu” w sieć miał wykazać możliwość uzyskania dostępu do dowolnego innego komputera w sieci i np. zainfekowania go innym wirusem. „Czerw” (ang. worm), jak nazywano później program Morrisa. Miał mniej niż 100 linii kodu, a jednak Robert pisząc ten program popełnił drobny błąd, który kosztował go bardzo wiele. Czerw po uruchomieniu zajmował bardzo mało czasu procesora. Miał on pozostać w ukryciu, być niezauważalny nawet dla administratora (rootkit) i nie powodować w żadnych problemów. Morrisowi chodziło jedynie o udowodnienie, że może on się przenosić z komputera na komputer. Rozmnażanie czerwia było możliwe poprzez skorzystanie z błędów w kilku elementach systemu UNIX oraz poprzez odkrywanie łatwych do odgadnięcia haseł użytkowników. Główna część robaka mogła tylko infekować maszyny Digital Equipment Corporation klasy VAX, na których był uruchomiony system 4BSD oraz Sun-3. Cześć przenośna napisana w języku „C” – była hakiem abordażowym, czyli komponentem czerwia, który używany był do zaciągania głównej części kodu na innych systemach czyniąc z nich drugoplanowe ofiary. Morris przewidział, że nieskończone rozmnażanie się czerwia spowoduje zablokowanie komputerów. Dlatego też czerw „pytał się”, czy infekowany serwer zawiera już kopię programu, czy nie. To jednak mogłoby ułatwić administratorom pozbycie się programu, więc Robert zdecydował się, że mimo odpowiedzi „tak” w jednym na siedem przypadków czerw i tak uruchamiał się na komputerze jako nowy proces. Miało to ograniczyć prędkość rozmnażania się programu i uniknąć blokady systemu. Obliczenia Morrisa okazały się jednak błędne. Niecierpliwy Robert zdecydował się wprowadzić program do Internetu 2 listopada 1988 r. ok. godziny 20:00, mimo iż wymagał on jeszcze kilku poprawek. W celu ukrycia faktu, że program jest jego autorstwa – uruchomił go z jednego z serwerów uniwersytetu Harvard, do którego miał jeszcze dostęp. Czerw rozmnażał się powoli, ale sukcesywnie. Już w kilkanaście minut po uruchomieniu czerwia wiele komputerów zaczęło dotkliwie odczuwać jego obecność.

3 listopada o godzinie 00:34 obecność wirusopodobnego programu odkrył Andy Suddyth z Harvardu. W około dwie godziny od uruchomienia programu do większości maszyn nie mogli się dostać nawet administratorzy. Nie pomagało ich ponowne uruchomienie – czerw znów infekował system i powodował jego zawieszenie. Kiedy Morris zorientował się, co się dzieje, przy pomocy kolegi przygotował rozwiązanie problemu i rozesłać anonimowo po Sieci. Niestety, było już za późno. Czerw uniemożliwił w większości przypadków odebranie i przeczytanie listu. Nad zwalczeniem złośliwego programu pracowali specjaliści z tysięcy placówek w USA. Już w 12 godzin od infekcji informatycy z Uniwersytetu Kalifornijskiego w Berkeley i z Massachussetts Institute of Technology odkryli metodę likwidacji czerwia. Ze względu na odłączenie wielu komputerów od sieci dopiero 10 listopada udało się całkowicie przywrócić normalną pracę Internetu. Zainfekowanych zostało ponad 6000 komputerów klasy Sun 3 i VAX. Straty w każdej lokalizacji sięgały nierzadko od 200 do 50 tys. USA, a łączenie oceniono je na ok. 10 mln USD. Robert przyznał się do popełnionego błędu. W grudniu 1990 roku skazano go na 3 lata obserwacji sądowej, 400 godzin prac społecznych i grzywnę w wysokości 10 tyś. USD. Jego apelacja została odrzucona w marcu następnego roku. Algorytm działania czerwia był następujący:

1. Utworzenie listy wszystkich „sąsiednich komputerów” za pomocą mechanizmu „trusted hosts” w UNIXie.
2. Próba znalezienia haseł dostępu użytkowników sąsiednich komputerów poprzez permutacje nazwy użytkownika korzystającego z protokołu rexec / rsh bez wymogu podania hasła; porównanie z listą 432 haseł dostarczonych przez i sprawdzenie w słowniku typowych haseł.
3. Próba zainfekowania komputera poprzez:

- skorzystanie z znalezionego w kroku 2 dostępu,
- błędu typu buffer overrun w daemonie fingerd,
- wykorzystanie „tylnego wejścia” pozostawionego w programie sendmail w trybie debug.

4. Sprawdzenie czy sąsiednie komputery są już zainfekowane – w jednym na siedem przypadków jeśli odpowiedź była pozytywna – ponowne zainfekowanie maszyny.
5. Przesłanie krótkiego kodu startowego do zainfekowanego komputera oraz jego automatyczna kompilacja i uruchomienie.
6. Po 120 sekundach – pobranie z komputera źródłowego pełnego kodu czerwia i jego automatyczna kompilacja, a następnie uruchomienie – powrót do kroku 1.

Obecnie Robert pracuje jako profesor w Massachusetts Institute of Technology, ale nie zajmuje się już kwestią bezpieczeństwa systemów. Wpadka kosztowała go zbyt wiele. Jego wyrok był pierwszym jaki wydano na podstawie Ustawy z 1984 r. o Przestępstwach i Nadużyciach Komputerowych. Morris jest również bardzo dobrym przyjacielem Paula Graham’a. Graham zadedykował mu swoją książkę „ANSI Common Lisp” oraz nazwał język programowania, który generuje strony web sklepów online – RTML – ku jego czci. Graham również wypowiada się o nim jako osobistym bohaterze, który „nigdy się nie myli”. Razem z Graham’em w 1995 roku założyli firmę „Viaweb„, która zajmowała się tworzeniem sklepów online. W 1998 roku firma ta została kupiona przez Yahoo za 48 milionów dolarów.

Więcej informacji: Strona domowa RTM

ak w „szybki i brudny” sposób odczytać z powłoki bash prawa dostępu do kilku plików prezentując je w sposób dziesiętny? Możemy do tego wykorzystać polecenie: stat i jego parametr -c, który pozwala na sformatowanie informacji wyjściowych:

Wersja standardowa:

[root@stardust ~]# stat logo1.png
  File: `logo1.png'
  Size: 8474      	Blocks: 32         IO Block: 4096   zwykły plik
Device: 808h/2056d	Inode: 4851410     Links: 1
Access: (0644/-rw-r--r--)  Uid: (  500/ agresor)   Gid: (  500/ agresor)
Access: 2011-08-27 18:05:40.000000000 +0200
Modify: 2009-10-11 00:00:00.000000000 +0200
Change: 2012-04-21 20:53:20.000000000 +0200

Wstępnie sformatowana:

[root@stardust ~]# stat -c "%n %a %G %g" logo1.png
logo1.png 644 agresor 500

Interesująca nas lista plików:

[root@stardust ~]# stat -c "%a %n" logo*
644 logo1.png
644 logo2.png
644 logo.cdr
644 logo.eps
644 logo.png

Analogiczna lista za pomocą polecenia find:

[root@stardust ~]# find logo* -printf '%m %p\n'
644 logo1.png
644 logo2.png
644 logo.cdr
644 logo.eps
644 logo.png

Więcej informacji: man stat, man find

2008 roku Tollef Fog Heen (Varnish Software) napisał i wykonał pierwsze szkice do szkolenia „Varnish System Administration„. Od tego czasu rozwój nad materiałem przejął Kristian Lyngstøl (Varnish Software). W 2011 roku do przystosowania materiałów dla webdeveloperów został poproszony Jérôme Renard (39Web). Tak cała przygotowana treść została połączona w jedną zwartą publikację, która została opublikowana i udostępniona on-line 28 marca 2012 roku jako „Varnish Book” na licencji Creative Commons CC-BY-NC-SA.

Książka ta nie nauczy nas wszystkiego o akceleratorze HTTP Varnish, ale jak zaznaczają jej autorzy – zapoznając się z jej materiałem i wykonując ćwiczenia (bez oszukiwania!) poznamy podstawowe arkana pracy jego silnika, konfiguracji i administracji, jak i zrozumiemy w jaki sposób działa cacheowanie po stronie serwera i przeglądarki. Publikacja szczególnie polecana dla osób zaczynających przygodę z tym proxy serwerem.

Więcej informacji: The Varnish Book, Źródła książki