Automatyczne testowanie jądra Linuksa

Transkrypt

1 Szymon Giżecki Chu Hong Hai Mateusz Kopeć Automatyczne testowanie jądra Linuksa Systemy Operacyjne Projekt studencki

2 Plan prezentacji...czyli o czym będziemy mówili: Metodologie testowania jądra Linuksa Testy poprawnościowe Testy wydajnościowe Mechanizmy testowania Fault Injection Zestawy testów Linux Test Project gcov i pokrycie kodu jądra testami Tracing Analiza procesu bootowania - Bootchart 2

3 Testy poprawnościowe Statyczna analiza kodu Przygotowanie testów Przeprowadzenie testów 3

4 Statyczna analiza kodu Idea: szukanie błędów przed budowaniem aplikacji Weryfikacja modelowa (model checking) Analiza przepływu danych (data-flow analysis) Abstract interpretation Asercje Semantyka Narzędzia: Sparse Cppcheck Coverity Prevent 4

5 Wybór zestawów testowych Obciążenie głównych zasobów Pokrycie dużej części kodu Automatyzacja Publikacja wyników 5

6 Ocena wykorzystania zasobów CPU Pamięć I/O Networking Narzędzia: top, sar i iostat (iostat -x 1) 6

7 Analiza pokrycia kodu jądra gcov lcov 7

8 Ocena końcowego testu Przed przeprowadzeniem testów: Uruchomienie wybranego zestawu na stabilnej wersji jądra Wykrycie konfliktów między testami Usunięcie Zbieranie statystyk narzędziem sar Punkt odniesienia dla przyszłych prawdziwych testów Bardzo ważne pytanie: skąd wziąć testy? Odpowiedź: LTP 8

9 Przeprowadzenie testu Za miarę stabilności i niezawodności systemu uznajemy jego czas ciągłego i bezawaryjnego działania. W związku z tym testy są uruchomione i działają bez przerwy przez długi okres czasu (30, 60, 90 dni). Przed testem właściwym często jest uruchomiony 24-godzinny test wstępny w celu sprawdzenia poprawności konfiguracji systemu. Podczas testowania odpowiednie narzędzia bez przerwy zbierają statystyki dotyczące systemu. Aby ustawić cykliczne zapisywanie danych statystycznych można używać narzędzia cron. 9

10 Testy wydajnościowe Co mierzymy Narzędzia 10

11 Co mierzymy Określenie miary np. ilość wysłanych wiadomości na sekundę Dobór odpowiednich benchmarków Tworzenie dokumentacji Wybór danych, które będą zbierane Zanim uruchomimy testy musimy odpowiednio dostosować sprzęt i oprogramowanie. 11

12 Narzędzia Wirtualny system plików /proc Lockmeter (SGI) Kernprof (SGI) Trace facility (IBM) sstat schedret acgparse 12

13 Narzędzia komercyjne 13

14 Mechanizmy testowania Fault Injection Czym jest mechanizm fault injection Rodzaje fault injection A jak to się robi w Unix'ie? Wparcie w Kernel u FERRARI A Flexible Software-Based Fault and Error Injection System 14

15 Linux Test Project Linus's Law (according to Eric S. Raymond) Given enough eyeballs, all bugs are shallow" Projekt założony w roku 2000 przez konsorcjum SGI (Silicon Graphics) Pierwszy zunifikowane podejście do testowania jądra linuxa Utrzymywany jako projekt OpenSource Na dzień dzisiejszy największy projekt testujący jądro 15

16 Linux Test Project Napisany głównie w C (~94.5%), pozostałe części Perl (~0.5%) oraz Shell (~5%) Ponad 3000 testów Kto i kiedy powinien używać Środowisko Zanim uruchomimy LTP 16

17 LTP rodzaje testów - Unit testing - Integration testing - System testing - Regression testing - Stress testing - Nie ma compilation ani performance 17

18 LTP zbiór testowanych właściwości Przejrzysta struktura LTP testuje: Zarządzanie pamięcią, Scheduler, Wątki jądra, System plików, LVM, EVMS, Kompresje, /proc, Zdalne polecenia, Sockets, NFS, NIS, IP/V6, Sieć (Ethernet i Wireless), FDDI, ATM, Napędy (CDROM, DVD, FDD, a nawet Tape), IDE, Sterowniki SCSI / RAID 18

19 LTP jak to działa? 19

20 LTP Zbieranie danych Podejścia do zbierania danych Podział ze względu na logikę i funkcjonalności. Łatwe do zdefiniowania relacje Drzewo Pół-automatyzacja Dane jako kod ASCII 20

21 LTP Processing danych Przetwarzanie danych Raw test data + coverage data + raw coverage data W wyniku dokument HTML, zawierający: Części kernela, na które test miał wpływ Części kernela z powiązanego podsystemu, na które test nie miał wpływu Częstotliwość i liczba uruchomionych linii kodu 21

22 LTP rozwój 1 LTP 2002 LTP Marzec

23 LTP rozwój 2 Przyrost pomiędzy grudniem 2007 a marcem

24 LTP Tworzenie własnych testów Napisane w C - macra TEST() i zmienne TEST_RETURN TEST_ERRNO Nie powinien wymagać żadnej pre-konfiguracji 24

25 LTP Tworzenie własnych testów Bardzo przydatna funkcja parse_opts #include "test.h" #include "usctest.h" char *parse_opts(int argc, char *argv[], option_t option_array[], void (*user_help_func)()); typedef struct { char *option; int *flag; char **arg; } option_t; 25

26 LTP Przykładowe wyjście 1 26

27 LTP Przykładowe wyjście 2 27

28 LTP co dalej? Dodanie wsparcia dla różnych języków Dodanie nowych obszarów, np. zarządzania mocą, KDUMP, kontrolerów Nowe techniki raportowania, np. XML Dodanie benchmarków Oczywiście rozwój testów, w szczególności duży nacisk kładziony na functional i regression testing. 28

29 Jeśli nie LTP, to: Linux Benchmark Suite Czego nie ma w LTP: Kernel Lockmetering Kernel Profiling UnixBench Wysokopoziomowy zbiór benchmarków integrujący testy CPU i I/O, oraz zachowanie systemu pod zróżnicowanym obciążeniem SPEC CPU2000 Benchmark testujący surowe CPU oraz kompilację 29

30 Jeśli nie LTP, to: HINT HINT ( (Hierarchical INTegration) Benchmark, używający świeżego podejścia QUIPS (QUality Improvement Per Second). HINT odzwierciedla zmiany prędkości działanie maszyny w miarę wzrastania uptime'u. Bardzo łatwo skalowalny i dostępny na wiele architektur 30

31 Jeśli nie LTP, to: HINT 31

32 GCOV i pokrycie kodu jądra testami Czym jest COV? Sprawdzenie stopnia przetestowania kodu White box testing Jedna z pierwszych technik Kryteria pokrycia: Pokrycie funkcji Pokrycie instrukcji (statement coverage) Pokrycie decyzji/rozgałęzień (decision/branch coverage) Pokrycie warunków (condition coverage) Pokrycie ścieżek (path coverage) Pokrycie wejścia/wyjścia (entry/exit coverage) 32

33 GCOV i pokrycie kodu jądra testami Istnieją zależności między kryteriami Niektóre aplikacje potrzebują 100% pokrycia Niemniej jednak, na ogół jest to niemożliwe Problemy z pełnym pokryciem: Duża ilość ścieżek Nieskończona ilość ścieżek Ścieżki niewykonywalne przy żadnym wejściu problem stopu Techniki radzenia sobie z tym: Grupowanie ścieżek w klasy 33

34 GCOV i pokrycie kodu jądra testami Pokrycie testami kodu jądra czemu tak potrzebne? Intensywne użycie zasobów nie zawsze implikuje intensywne użycie kodu jądra. Użyteczne narzędzia: gcov lcov Jak używamy? Sekwencyjnie! 34

35 GCOV i pokrycie kodu jądra testami gcov przykładowe wyjście 35

36 GCOV i pokrycie kodu jądra testami lcov przykładowe wyjście 36

37 GCOV i pokrycie kodu jądra testami lcov przykładowe wyjście (szczegółowe) 37

38 Tracing Czym jest tracing? Logging vs. tracing 38

39 Tracing Najważniejsze cechy narzędzia do trace'u: Zajrzenie w głąb działającego systemu Wyszukiwanie wąskich gardeł systemu Śledzenie wykonań procesów i środowiska, w którym się wykonują Tryb flight-recorder (coś jak czarna skrzynka samolotu) Możliwość zaglądania w przestrzeń użytkownika i jądra Przykładowe narzędzia: SystemTap Dtrace for Linux Kprobes LTTng i LLTV 39

40 Tracing SystemTap przykład 40

41 Przykładowe testy jądra - Bootchart Bootchart narzędzie do analizy procesu ładowania systemu operacyjnego Linux Powstał jako odpowiedź na wyzwanie postawione przez Owena Taylora: Wyzwaniem jest stworzenie aplikacji ukazującej na jednym rysunku, co dzieje się podczas bootowania systemu i wskazanie szans na optymalizację tego procesu, poprzez ukazanie jak bardzo rzeczywiste bootowanie odbiega od idealnego, w którym nieustannie występuje 100% zapotrzebowanie na procesor i dostęp do dysku. 41

42 Przykładowe testy jądra - Bootchart Jak to działa? Uruchamia /sbin/bootchartrd zamiast /sbin/init Bootchart od razu uruchamia /sbin/init, ale sam zaczyna zbierać statystyki do tymczasowego systemu plików (tmpfs) Skąd dane? /proc/stat /proc/diskstats /proc/[pid]/stat Warunek zakończenia działania pojawienie się jednego z wyróżnionych procesów Domyślne zbieranie statystyk co 0.2 sekundy Możliwość użycia process accounting 42

43 Przykładowe testy jądra - Bootchart Wizualizacja Za pomocą aplikacji java lub formularza na stronie internetowej Konieczność uproszczenia wykresu: Łączenie podobnych procesów w jedną grupę procesów Usuwanie krótko żyjących i bezczynnych procesów Graficzny sposób przedstawiania wyników (PNG, SVG, EPS) 43

44 Przykładowe testy jądra - Bootchart Przykład Fedora Core 3 44

45 Przykładowe testy jądra - Bootchart 45

46 Przykładowe testy jądra - Bootchart 46

47 Przykładowe testy jądra - Bootchart 47

48 Przykładowe testy jądra - Bootchart 48

49 Przykładowe testy jądra - LKP Linux Kernel Performance Project projekt mający na celu zwiększenie wydajności systemów Linux Częste testy wydajnościowe na tym samym sprzęcie różnych wersji jądra Linuxa Wydawałoby się, że każda kolejna wersja jądra powinna być lepsza od poprzedniej :) Spójrzmy zatem na przykładowe wyniki... 49

50 Przykładowe testy jądra VolanoMark 50

51 Przykładowe testy jądra Netperf tcp TCP-S-112k test strumienia TCP z 112KB socket buffers i wiadmościami 4KB TCP-S-64k test strumienia TCP z 64KB socket buffers i wiadmościami 4KB TCP-RR-1 test TCP Request/Response z 1 byte'owymi zapytaniami i odpowiedziami 51

52 Przykładowe testy jądra Netperf udp UDP-RR-1 test UDP Request/Response z 1 byte'owymi zapytaniami i odpowiedziami UDP-RR-516 test UDP Request/Response z 516 byte'owymi zapytaniami I 4 byte'owymi odpowiedziami UDP-U-4k test UDP Unidirectional z 64KB socket buffers i 4KB wiadomościami UDP-U-1k test UDP Unidirectional z 64KB socket buffers i 1KB wiadomościami 52

53 Przykładowe testy jądra Mmbench 53

54 Przykładowe testy jądra Fileio 54

55 Przykładowe testy jądra Iozone 50% obciążenie pamięci 55

56 Przykładowe testy jądra Iozone 120% obciążenie pamięci 56

57 Przykładowe testy jądra Tiobench różne operacje, algorytm cfq 57

58 Przykładowe testy jądra Tiobench różne operacje, algorytm noop 58

59 Przykładowe testy jądra Tiobench random read, różne algorytmy 59