Wydajne systemy komputerowe. Przewodnik dla administratorów systemów lokalnych i w chmurze [PDF]

Zitiervorschau

Więcej na: www.ebook4all.pl

Spis treści Wstęp

19

Podziękowania

27

O autorze

31

Rozdział 1. Wprowadzenie

33

1.1. Wydajność systemów 1.2. Role 1.3. Działania 1.4. Perspektywy 1.5. Zapewnienie wydajności to wyzwanie 1.5.1. Wydajność jest subiektywna 1.5.2. Systemy są skomplikowane 1.5.3. Może istnieć wiele problemów związanych z wydajnością 1.6. Opóźnienie 1.7. Monitorowanie dynamiczne 1.8. Przetwarzanie w chmurze 1.9. Studium przypadku 1.9.1. Wolno działające dyski 1.9.2. Zmiana oprogramowania 1.9.3. Co dalej?

33 34 35 36 37 37 37 38 39 40 41 42 42 44 46

3

4

Spis treści

Rozdział 2. Metodologia 2.1. Terminologia 2.2. Modele 2.2.1. Wydajność systemu podczas testu 2.2.2. Systemy kolejkowe 2.3. Koncepcje 2.3.1. Opóźnienie 2.3.2. Skala czasu 2.3.3. Kompromisy 2.3.4. Dostrajanie wydajności 2.3.5. Poziomy trafności 2.3.6. Rekomendacje w danym momencie 2.3.7. Obciążenie kontra architektura 2.3.8. Skalowalność 2.3.9. Znane niewiadome 2.3.10. Metryki 2.3.11. Poziom wykorzystania 2.3.12. Nasycenie 2.3.13. Profilowanie 2.3.14. Buforowanie 2.4. Perspektywy 2.4.1. Analiza zasobów 2.4.2. Analiza obciążenia 2.5. Metodologia 2.5.1. Jawna antymetoda 2.5.2. Antymetoda losowej zmiany 2.5.3. Antymetoda obwiniania kogoś innego 2.5.4. Metoda przygotowanej ad hoc listy rzeczy do sprawdzenia 2.5.5. Opis problemu 2.5.6. Metoda naukowa 2.5.7. Cykl diagnostyczny 2.5.8. Metoda narzędzi 2.5.9. Metoda USE 2.5.10. Charakterystyka obciążenia 2.5.11. Analiza drążąca 2.5.12. Analiza opóźnienia 2.5.13. Metoda R 2.5.14. Monitorowanie zdarzeń 2.5.15. Dane statystyczne będące punktem odniesienia 2.5.16. Statyczne dostosowanie wydajności 2.5.17. Dostosowanie bufora 2.5.18. Mikrotesty wydajności 2.6. Modelowanie 2.6.1. Biznes kontra chmura 2.6.2. Identyfikacja wizualna

47 48 49 49 50 50 50 52 52 54 55 56 56 57 59 59 60 62 63 63 66 66 67 68 70 70 71 71 72 73 74 75 76 83 84 85 87 87 89 89 90 91 91 92 92

5

Spis treści

2.6.3. Prawo skalowalności Amdahla 2.6.4. Prawo skalowalności uniwersalnej 2.6.5. Teoria kolejek 2.7. Planowanie pojemności 2.7.1. Ograniczenia zasobu 2.7.2. Analiza współczynnika 2.7.3. Skalowanie rozwiązań 2.8. Statystyka 2.8.1. Ocena wydajności 2.8.2. Wartość średnia 2.8.3. Odchylenie standardowe, percentyle i mediana 2.8.4. Współczynnik zmienności 2.8.5. Rozkład wielomodalny 2.8.6. Elementy odstające 2.9. Monitorowanie 2.9.1. Wzorce na podstawie czasu 2.9.2. Produkty służące do monitorowania 2.9.3. Podsumowanie od chwili uruchomienia systemu 2.10. Wizualizacja 2.10.1. Wykres liniowy 2.10.2. Wykres punktowy 2.10.3. Mapy cieplne 2.10.4. Wykres warstwowy 2.10.5. Narzędzia wizualizacji 2.11. Ćwiczenia 2.12. Odwołania

Rozdział 3. Systemy operacyjne 3.1. Terminologia 3.2. Środowisko 3.2.1. Jądro 3.2.2. Stosy 3.2.3. Przerwania i wątki przerwań 3.2.4. Poziom priorytetu przerwania 3.2.5. Procesy 3.2.6. Wywołania systemowe 3.2.7. Pamięć wirtualna 3.2.8. Zarządzanie pamięcią 3.2.9. Algorytm szeregowania 3.2.10. Systemy plików 3.2.11. Buforowanie 3.2.12. Sieci 3.2.13. Sterowniki urządzeń 3.2.14. Wieloprocesorowość

94 95 96 100 100 102 103 103 104 105 106 107 107 108 108 109 110 110 111 111 112 113 114 115 115 116

117 118 119 119 122 123 124 125 127 129 130 130 132 134 134 135 136

6

Spis treści

3.2.15. Wywłaszczenie 3.2.16. Zarządzanie zasobami 3.2.17. Monitorowanie 3.3. Jądra systemów 3.3.1. UNIX 3.3.2. Systemy Solaris 3.3.3. Systemy Linux 3.3.4. Różnice 3.4. Ćwiczenia 3.5. Odwołania

Rozdział 4. Narzędzia monitorowania 4.1. Rodzaje narzędzi 4.1.1. Liczniki 4.1.2. Monitorowanie 4.1.3. Profilowanie 4.1.4. Monitorowanie (sar) 4.2. Źródła danych statystycznych 4.2.1. Interfejs /proc 4.2.2. Interfejs /sys 4.2.3 Framework kstat 4.2.4. Zliczanie opóźnienia 4.2.5. Zliczanie mikrostanu 4.2.6. Inne narzędzia monitorowania 4.3. DTrace 4.3.1. Monitorowanie statyczne i dynamiczne 4.3.2. Sondy 4.3.3. Dostawcy 4.3.4. Argumenty 4.3.5. Język D 4.3.6. Wbudowane zmienne 4.3.7. Akcje 4.3.8. Typy zmiennych 4.3.9. Jednowierszowe wywołania DTrace 4.3.10. Skrypty 4.3.11. Obciążenie 4.3.12. Dokumentacja i zasoby 4.4. SystemTap 4.4.1. Sondy 4.4.2. Zestawy tapset 4.4.3. Akcje i wbudowane zmienne 4.4.4. Przykłady 4.4.5. Obciążenie 4.4.6. Dokumentacja i zasoby

136 137 137 138 139 139 143 146 147 147

149 150 150 152 153 154 155 156 161 162 165 166 166 168 170 171 172 172 173 173 173 173 177 177 178 179 180 181 181 182 182 184 185

7

Spis treści

4.5. perf 4.6. Obserwowanie monitorowania 4.7. Ćwiczenia 4.8. Odwołania

Rozdział 5. Aplikacje 5.1. Podstawy dotyczące aplikacji 5.1.1. Cele 5.1.2. Optymalizacja najczęstszego sposobu użycia aplikacji 5.1.3. Monitorowanie 5.1.4. Notacja „duże O” 5.2. Techniki sprawdzania wydajności aplikacji 5.2.1. Ustalenie wielkości operacji wejścia-wyjścia 5.2.2. Pamięć podręczna 5.2.3. Buforowanie 5.2.4. Technika odpytywania 5.2.5. Współbieżność i równoległość 5.2.6. Nieblokujące operacje wejścia-wyjścia 5.2.7. Powiązanie z procesorem 5.3. Języki programowania 5.3.1. Języki kompilowane 5.3.2. Języki interpretowane 5.3.3. Maszyny wirtualne 5.3.4. Mechanizm usuwania nieużytków 5.4. Metodologia i analiza 5.4.1. Analiza stanu wątku 5.4.2. Profilowanie procesora 5.4.3. Analiza wywołań systemowych 5.4.4. Profilowanie operacji wejścia-wyjścia 5.4.5. Charakterystyka obciążenia 5.4.6. Metoda USE 5.4.7. Analiza drążąca 5.4.8. Analiza blokad 5.4.9. Statyczne dostosowanie wydajności 5.5. Ćwiczenia 5.6. Odwołania

Rozdział 6. Procesory 6.1. Terminologia 6.2. Modele 6.2.1. Architektura procesora 6.2.2. Pamięci podręczne w procesorze 6.2.3. Kolejki działania w procesorze 6.3. Koncepcje

185 186 187 187

189 190 191 192 193 193 194 194 195 195 196 196 199 200 200 201 202 203 203 204 205 208 210 218 219 219 220 221 223 224 226

227 228 229 229 230 230 231

8

Spis treści

6.3.1. Częstotliwość taktowania zegara 6.3.2. Instrukcje 6.3.3. Potok instrukcji 6.3.4. Wielkość instrukcji 6.3.5. Wartości CPI, IPC 6.3.6. Poziom wykorzystania 6.3.7. Czasy użytkownika i jądra 6.3.8. Poziom nasycenia 6.3.9. Wywłaszczenie 6.3.10. Odwrócenie priorytetów 6.3.11. Wieloprocesowość, wielowątkowość 6.3.12. Długość słowa 6.3.13. Optymalizacja kodu wynikowego 6.4. Architektura 6.4.1. Sprzęt 6.4.2. Oprogramowanie 6.5. Metodologia 6.5.1. Metoda narzędzi 6.5.2. Metoda USE 6.5.3. Charakterystyka obciążenia 6.5.4. Profilowanie 6.5.5. Analiza cykli 6.5.6. Monitorowanie wydajności 6.5.7. Statyczne dostosowanie wydajności 6.5.8. Dostrojenie priorytetu 6.5.9. Kontrola zasobów 6.5.10. Powiązanie z procesorem 6.5.11. Mikrotesty wydajności 6.5.12. Skalowanie 6.6. Analiza 6.6.1. uptime 6.6.2. vmstat 6.6.3. mpstat 6.6.4. sar 6.6.5. ps 6.6.6. top 6.6.7. prstat 6.6.8. pidstat 6.6.9. time, ptime 6.6.10. DTrace 6.6.11. SystemTap 6.6.12. perf 6.6.13. cpustat 6.6.14. Inne narzędzia

231 232 232 232 233 233 234 234 235 235 236 237 238 238 238 246 253 254 255 256 257 259 260 260 261 262 262 262 263 264 265 267 268 270 271 272 273 275 276 277 284 284 292 293

9

Spis treści

6.6.15. Wizualizacja 6.7. Eksperymenty 6.7.1. Ad hoc 6.7.2. sysbench 6.8. Dostrajanie 6.8.1. Opcje kompilatora 6.8.2. Klasy i priorytety szeregowania 6.8.3. Opcje algorytmu szeregowania 6.8.4. Dołączanie procesu 6.8.5. Grupa procesorów na wyłączność 6.8.6. Kontrola zasobów 6.8.7. Opcje procesora (dostrajanie BIOS-u) 6.9. Ćwiczenia 6.10. Odwołania

Rozdział 7. Pamięć 7.1. Terminologia 7.2. Koncepcje 7.2.1. Pamięć wirtualna 7.2.2. Stronicowanie 7.2.3. Żądanie stronicowania 7.2.4. Przepełnienie 7.2.5. Wymiana 7.2.6. Użycie bufora systemu plików 7.2.7. Poziom wykorzystania i nasycenie 7.2.8. Alokatory 7.2.9. Długość słowa 7.3. Architektura 7.3.1. Architektura sprzętowa 7.3.2. Oprogramowanie 7.3.3. Przestrzeń adresowa procesu 7.4. Metodologia 7.4.1. Metoda narzędzi 7.4.2. Metoda USE 7.4.3. Charakterystyka użycia pamięci 7.4.4. Analiza cykli 7.4.5. Monitorowanie wydajności 7.4.6. Wykrywanie wycieków pamięci 7.4.7. Statyczne dostrojenie wydajności 7.4.8. Kontrola zasobów 7.4.9. Mikrotesty wydajności 7.5. Analiza 7.5.1. vmstat 7.5.2. sar 7.5.3. slabtop

294 297 297 298 298 299 299 300 302 302 303 303 303 305

307 308 309 309 310 311 313 313 314 314 315 315 315 315 321 328 332 333 334 335 337 337 337 338 339 339 339 340 343 345

10

Spis treści

7.5.4. ::kmastat 7.5.5. ps 7.5.6. top 7.5.7. prstat 7.5.8. pmap 7.5.9. DTrace 7.5.10. SystemTap 7.5.11. Inne narzędzia 7.6. Dostrajanie 7.6.1. Parametry możliwe do dostrojenia 7.6.2. Różnej wielkości strony 7.6.3. Alokatory 7.6.4. Kontrola zasobów 7.7. Ćwiczenia 7.8. Odwołania

Rozdział 8. Systemy plików 8.1. Terminologia 8.2. Modele 8.2.1. Interfejsy systemów plików 8.2.2. Bufor systemu plików 8.2.3. Bufory poziomu drugiego 8.3. Koncepcje 8.3.1. Opóźnienie systemu plików 8.3.2. Buforowanie 8.3.3. Losowe kontra sekwencyjne operacje wejścia-wyjścia 8.3.4. Mechanizm prefetch 8.3.5. Odczyt z wyprzedzeniem 8.3.6. Buforowanie operacji zapisu 8.3.7. Synchroniczne operacje zapisu 8.3.8. Niezmodyfikowane i bezpośrednie operacje wejścia-wyjścia 8.3.9. Nieblokujące operacje wejścia-wyjścia 8.3.10. Mapowanie plików w pamięci 8.3.11. Metadane 8.3.12. Logiczne kontra fizyczne operacje wejścia-wyjścia 8.3.13. Operacje nie są jednakowe 8.3.14. Specjalne systemy plików 8.3.15. Znaczniki czasu dotyczące dostępu 8.3.16. Pojemność 8.4. Architektura 8.4.1. Stos operacji wejścia-wyjścia systemu plików 8.4.2. VFS 8.4.3. Bufory systemu plików 8.4.4. Funkcje systemu plików

347 348 350 350 351 353 357 358 360 360 363 364 364 365 366

369 370 371 371 371 372 372 373 373 374 375 376 376 377 378 378 379 379 380 383 383 383 384 384 384 384 386 390

11

Spis treści

8.4.5. Rodzaje systemów plików 8.4.6. Woluminy i pule 8.5. Metodologia 8.5.1. Analiza dysku 8.5.2. Analiza opóźnienia 8.5.3. Charakterystyka obciążenia 8.5.4. Monitorowanie wydajności 8.5.5. Monitorowanie zdarzeń 8.5.6. Statyczne dostosowanie wydajności 8.5.7. Dostrajanie bufora 8.5.8. Separacja obciążenia 8.5.9. Systemy plików w pamięci 8.5.10. Mikrotesty wydajności 8.6. Analiza 8.6.1. vfsstat 8.6.2. fsstat 8.6.3. strace, truss 8.6.4. DTrace 8.6.5. SystemTap 8.6.6. LatencyTOP 8.6.7. free 8.6.8. top 8.6.9. vmstat 8.6.10. sar 8.6.11. slabtop 8.6.12. mdb ::kmastat 8.6.13. fcachestat 8.6.14. /proc/meminfo 8.6.15. mdb ::memstat 8.6.16. kstat 8.6.17. Inne narzędzia 8.6.18. Wizualizacje 8.7. Eksperymenty 8.7.1. Ad hoc 8.7.2. Narzędzia mikrotestów wydajności 8.7.3. Opróżnienie bufora systemu plików 8.8. Dostrajanie 8.8.1. Wywołania aplikacji 8.8.2. ext3 8.8.3. ZFS 8.9. Ćwiczenia 8.10. Odwołania

392 399 401 401 402 404 406 407 408 408 409 409 409 411 412 413 413 414 425 425 426 426 426 427 428 429 429 430 430 431 432 433 434 435 435 437 438 438 439 440 442 443

12

Spis treści

Rozdział 9. Dyski 9.1. Terminologia 9.2. Modele 9.2.1. Prosty dysk 9.2.2. Pamięć podręczna dysku 9.2.3. Kontroler 9.3. Koncepcje 9.3.1. Pomiar czasu 9.3.2. Skale czasu 9.3.3. Buforowanie 9.3.4. Losowe kontra sekwencyjne operacje wejścia-wyjścia 9.3.5. Współczynnik odczyt/zapis 9.3.6. Wielkość operacji wejścia-wyjścia 9.3.7. Wartości IOPS nie są równe 9.3.8. Polecenie dyskowe niedotyczące transferu danych 9.3.9. Poziom wykorzystania 9.3.10. Nasycenie 9.3.11. Oczekiwanie na zakończenie operacji wejścia-wyjścia 9.3.12. Operacje synchroniczne kontra asynchroniczne 9.3.13. Dyskowe kontra aplikacji operacje wejścia-wyjścia 9.4. Architektura 9.4.1. Rodzaje dysków 9.4.2. Interfejsy 9.4.3. Rodzaje pamięci masowej 9.4.4. Stos dyskowych operacji wejścia-wyjścia w systemie operacyjnym 9.5. Metodologia 9.5.1. Metoda narzędzi 9.5.2. Metoda USE 9.5.3. Monitorowanie wydajności 9.5.4. Charakterystyka obciążenia 9.5.5. Analiza opóźnienia 9.5.6. Monitorowanie zdarzeń 9.5.7. Statyczne dopasowanie wydajności 9.5.8. Dostrojenie bufora 9.5.9. Kontrola zasobów 9.5.10. Mikrotesty wydajności 9.5.11. Skalowanie 9.6. Analiza 9.6.1. iostat 9.6.2. sar 9.6.3. pidstat 9.6.4. DTrace 9.6.5. SystemTap

445 446 447 447 447 448 449 449 450 452 452 453 454 454 454 455 456 456 457 458 458 458 465 466 469 473 473 474 475 476 478 479 480 481 481 481 483 484 484 493 495 495 505

13

Spis treści

9.6.6. perf 9.6.7. iotop 9.6.8. iosnoop 9.6.9. blktrace 9.6.10. MegaCli 9.6.11. smartctl 9.6.12. Wizualizacje 9.7. Eksperymenty 9.7.1. Ad hoc 9.7.2. Własne generatory obciążenia 9.7.3. Narzędzia mikrotestów wydajności 9.7.4. Przykład losowego odczytu 9.8. Dostrajanie 9.8.1. Modyfikowalne parametry systemu operacyjnego 9.8.2. Modyfikowalne parametry urządzenia dyskowego 9.8.3. Modyfikowalne parametry kontrolera dysku 9.9. Ćwiczenia 9.10. Odwołania

Rozdział 10. Sieć 10.1. Terminologia 10.2. Modele 10.2.1. Interfejs sieciowy 10.2.2. Kontroler 10.2.3. Stos protokołów 10.3. Koncepcje 10.3.1. Sieci i routing 10.3.2. Protokoły 10.3.3. Hermetyzacja 10.3.4. Wielkość pakietu 10.3.5. Opóźnienie 10.3.6. Buforowanie 10.3.7. Dziennik połączeń 10.3.8. Negocjacja interfejsu 10.3.9. Poziom wykorzystania 10.3.10. Połączenia lokalne 10.4. Architektura 10.4.1. Protokoły 10.4.2. Sprzęt 10.4.3. Oprogramowanie 10.5. Metodologia 10.5.1. Metoda narzędzi 10.5.2. Metoda USE 10.5.3. Charakterystyka obciążenia 10.5.4. Analiza opóźnienia

505 506 509 512 514 515 516 520 520 520 521 521 522 523 525 525 525 527

529 530 530 531 531 532 532 532 533 534 534 535 537 537 538 538 539 539 539 543 545 550 550 551 552 553

14

Spis treści

10.5.5. Monitorowanie wydajności 10.5.6. Podsłuchiwanie pakietów 10.5.7. Analiza TCP 10.5.8. Analiza drążąca 10.5.9. Statyczne dostosowanie wydajności 10.5.10. Kontrola zasobów 10.5.11. Mikrotesty wydajności 10.6. Analiza 10.6.1. netstat 10.6.2. sar 10.6.3. ifconfig 10.6.4. ip 10.6.5. nicstat 10.6.6. dladm 10.6.7. ping 10.6.8. traceroute 10.6.9. pathchar 10.6.10. tcpdump 10.6.11. snoop 10.6.12. Wireshark 10.6.13. Dtrace 10.6.14. SystemTap 10.6.15. perf 10.6.16. Inne narzędzia 10.7. Eksperymenty 10.7.1. iperf 10.8. Dostrajanie 10.8.1. Linux 10.8.2. Solaris 10.8.3. Konfiguracja 10.9. Ćwiczenia 10.10. Odwołania

Rozdział 11. Przetwarzanie w chmurze 11.1. Wprowadzenie 11.1.1. Współczynnik cena/wydajność 11.1.2. Skalowalna architektura 11.1.3. Planowanie pojemności 11.1.4. Pamięć masowa 11.1.5. Multitenancy 11.2. Wirtualizacja systemu operacyjnego 11.2.1. Obciążenie 11.2.2. Kontrola zasobów 11.2.3. Monitorowanie

554 555 556 557 557 558 559 559 560 566 568 569 569 570 571 572 573 573 575 578 578 592 592 593 594 594 595 595 598 601 602 603

605 606 606 607 608 610 610 611 613 615 619

15

Spis treści

11.3. Wirtualizacja sprzętowa 11.3.1. Obciążenie 11.3.2. Kontrola zasobów 11.3.3. Monitorowanie 11.4. Porównania 11.5. Ćwiczenia 11.6. Odwołania

Rozdział 12. Testy wydajności 12.1. Wprowadzenie 12.1.1. Działania 12.1.2. Efektywne testy wydajności 12.1.3. Grzechy testów wydajności 12.2. Rodzaje testów wydajności 12.2.1. Mikrotesty wydajności 12.2.2. Symulacja 12.2.3. Powtarzalność 12.2.4. Standardy biznesowe 12.3. Metodologia 12.3.1. Pasywne testy wydajności 12.3.2. Aktywne testy wydajności 12.3.3. Profilowanie procesora 12.3.4. Metoda USE 12.3.5. Charakterystyka obciążenia 12.3.6. Własne testy wydajności 12.3.7. Stopniowa zmiana obciążenia 12.3.8. Sprawdzenie poprawności 12.3.9. Analiza statystyczna 12.4. Pytania dotyczące testu wydajności 12.5. Ćwiczenia 12.6. Odwołania

Rozdział 13. Studium przypadku 13.1. Studium przykładu: czerwony wieloryb 13.1.1. Zdefiniowanie problemu 13.1.2. Pomoc techniczna 13.1.3. Rozpoczęcie pracy 13.1.4. Wybierz własną drogę 13.1.5. Metoda USE 13.1.6. Czy to już koniec? 13.1.7. Podejście drugie 13.1.8. Podstawy 13.1.9. Zignorowanie czerwonego wieloryba 13.1.10. Sprawdzenie jądra

625 627 634 637 644 646 647

649 650 650 651 653 660 660 662 663 663 665 665 667 669 671 671 671 672 674 674 676 678 678

681 681 682 683 684 686 688 691 691 693 694 694

16

Spis treści

13.1.11. Dlaczego? 13.1.12. Epilog 13.2. Komentarze 13.3. Informacje dodatkowe 13.4. Odwołania

Dodatek A Metoda USE dla systemu Linux

Dodatek B

Dodatek C

701

Zasoby fizyczne Zasoby programowe Odwołania

702 705 706

Metoda USE dla systemu Solaris

707

Zasoby fizyczne Zasoby programowe Odwołania

707 710 711

Polecenie sar

713

Linux Solaris

713 714

Dodatek D Polecenie DTrace

Dodatek E

696 698 699 700 700

715

Dostawca syscall Dostawca proc Dostawca profile Dostawca sched Dostawca fbt Dostawca pid Dostawca io Dostawca sysinfo Dostawca vminfo Dostawca ip Dostawca tcp Dostawca UDP

715 718 718 720 720 721 722 722 723 723 723 724

Od DTrace do SystemTap

725

Funkcjonalność Terminologia Sondy Wbudowane zmienne Funkcje Przykład 1.: Wyświetlenie sond syscall:::entry Przykład 2.: Podsumowanie wielkości zwrotnej wywołania read() Przykład 3.: Zliczanie wywołań systemowych według nazwy procesu

725 726 726 727 727 728 728 730

17

Spis treści

Dodatek F

Przykład 4.: Zliczanie wywołań systemowych według nazwy wywołania systemowego dla procesu o identyfikatorze 123 Przykład 5.: Zliczanie wywołań systemowych według nazwy wywołania systemowego dla procesu o nazwie httpd Przykład 6.: Monitorowanie wywołania open() wraz z nazwą procesu i ścieżki Przykład 7.: Podsumowanie opóźnienia read() dla procesów mysqld Przykład 8.: Monitorowanie nowych procesów wraz z nazwą procesu i argumentami Przykład 9.: Monitorowanie stosów jądra z częstotliwością 100 Hz Odwołania

733 733 733

Odpowiedzi do wybranych ćwiczeń

735

Rozdział 2. „Metodologia” Rozdział 3. „Systemy operacyjne” Rozdział 6. „Procesory” Rozdział 7. „Pamięć” Rozdział 8. „Systemy plików” Rozdział 9. „Dyski” Rozdział 11. „Przetwarzanie w chmurze”

735 735 735 736 736 737 737

731 731 732 732

Dodatek G Wydajność systemów: kto jest kim?

739

Słowniczek

743

Bibliografia

749

Skorowidz

755

18

Spis treści

Wstęp Mamy znane wiadome. Rzeczy, o których wiemy, ľe je wiemy. Wiemy równieľ, ľe istniejæ znane niewiadome. Innymi sđowy, wiemy, ľe sæ pewne rzeczy, których nie wiemy. Ale sæ równieľ nieznane niewiadome — takie, o których nie wiemy, ľe ich nie wiemy. — Donald Rumsfeld, sekretarz Departamentu Obrony Stanów Zjednoczonych podczas konferencji prasowej w dniu 12 lutego 2002 roku Wprawdzie powyľsza wypowiedļ wywođađa cichy chichot wħród uczestników konferencji prasowej, ale jednoczeħnie stanowi podsumowanie waľnej reguđy, która dotyczy nie tylko ħwiata polityki, lecz takľe skomplikowanych systemów technicznych. Wspomniana reguđa mówi, ľe kwestie zwiæzane z wydajnoħciæ mogæ mieè swoje ļródđo praktycznie wszúdzie, nawet na obszarach systemu, które sæ Ci nieznane i dlatego ich nie sprawdzasz („nieznane niewiadome”). Celem niniejszej ksiæľki jest odkrycie wielu tego rodzaju obszarów, a takľe przedstawienie metodologii i narzúdzi sđuľæcych do ich analizy.

O tej książce Witaj na kartach ksiæľki Wydajne systemy komputerowe. Przewodnik dla administratorów systemów lokalnych i w chmurze ! Jej tematem jest wydajnoħè systemów operacyjnych i aplikacji w kontekħcie systemu operacyjnego. Zaprezentowane zagadnienia dotyczæ zarówno ħrodowiska biznesowego, jak i przetwarzania w chmurze. Chcú pomóc Ci w maksymalnym wykorzystaniu posiadanych systemów. 19

20

Wstęp

Podczas pracy z nieustannie rozwijanymi aplikacjami moľe pojawiaè siú pokusa uznania wydajnoħci systemu operacyjnego za problem juľ rozwiæzany — jædro zostađo przecieľ opracowane, a od dekad jest dostrajane. Problem jednak istnieje! System operacyjny to skomplikowane oprogramowanie zarzædzajæce wieloma nieustannie zmieniajæcymi siú urzædzeniami fizycznymi wykorzystywanymi z róľnymi zestawami aplikacji. Same jædra systemów równieľ sæ ciægle modyfikowane. Programiħci dodajæ funkcje poprawiajæce wydajnoħè jædra w okreħlonych sytuacjach oraz usuwajæ kolejne wykrywane wæskie gardđa, co pozwala na dalsze skalowanie systemów. Analiza wydajnoħci systemu operacyjnego i praca nad jej poprawæ to nieustannie wykonywane zadania, które powinny prowadziè do stađej poprawy wydajnoħci. Wydajnoħè aplikacji takľe moľna przeanalizowaè w kontekħcie systemu operacyjnego i ten temat równieľ zostanie omówiony w niniejszej ksiæľce.

Omówione systemy operacyjne W ksiæľce koncentrujemy siú na analizie wydajnoħci dziađania systemów operacyjnych. Wykorzystamy narzúdzia, przykđady i moľliwe do zmiany parametry w systemach operacyjnych z rodzin Linux i Solaris. O ile nie zaznaczono inaczej, konkretna dystrybucja systemu operacyjnego nie ma znaczenia. W przypadku systemów operacyjnych Linux przykđady pochodzæ z róľnych dystrybucji standardowych (miúdzy innymi Ubuntu, Fedora i CentOS), systemów zainstalowanych w komputerach fizycznych oraz egzemplarzy wirtualnych systemów operacyjnych dziađajæcych w „chmurze” (tego rodzaju system jest czústo okreħlany mianem tenant). Natomiast w przypadku rodziny Solaris przykđady opierajæ siú takľe na systemach Joyent SmartOS i OmniTI OmniOS, zainstalowanych w komputerach fizycznych lub w postaci systemów wirtualnych. SmartOS i OmniOS zbudowano na bazie jædra typu open source o nazwie illumos. Wspomniany illumos to aktywna gađæļ jædra OpenSolaris, które opracowano na podstawie systemu Open Solaris 11. Przedstawienie materiađu na podstawie dwóch róľnych systemów operacyjnych zapewnia czytelnikom dodatkowæ perspektywú, oferuje moľliwoħè dokđadniejszego zgđúbienia ich cech charakterystycznych, zwđaszcza ľe w obu wymienionych systemach operacyjnych zastosowano odmienne ħcieľki projektowe. Dlatego teľ czytelnik zyskuje moľliwoħè wszechstronniejszego zrozumienia kwestii wydajnoħci, bez koniecznoħci ograniczania siú do pojedynczego systemu operacyjnego, i moľe bardziej obiektywnie podejħè do zagadnieē zwiæzanych z systemami operacyjnymi. Z historycznego punktu widzenia znacznie wiúkszy postúp na polu wydajnoħci dokonađ siú w systemach z rodziny Solaris, co spowodowađo, ľe systemy te stađy siú lepszym wyborem dla niektórych zastosowaē. W przypadku systemów Linux sytuacja równieľ ulegđa wyraļnej poprawie. Gdy ponad dekadú temu Musumeci napisađ ksiæľkú System Performance Tuning (patrz odwođanie [Musumeci 02] na koēcu wstúpu), poruszone w niej zagadnienia dotyczyđy zarówno systemu Linux, jak i Solaris, ale materiađ byđ w duľej mierze poħwiúcony drugiemu z wymienionych systemów. Powody takiego podejħcia autor wyjaħniđ w nastúpujæcy sposób:

Wstęp

21

Wydaje siú, ľe komputery dziađajæce pod kontrolæ systemu Solaris sæ bardziej zoptymalizowane pod kætem wydajnoħci. Podejrzewam, ľe przyczynæ jest znacznie wiúkszy koszt komputerów opartych na systemie Solaris niľ ich odpowiedników dziađajæcych pod kontrolæ systemu Linux. Uľytkownicy sæ znacznie bardziej wybredni w kwestii wydajnoħci, a w systemie Solaris uczyniono wiele na tym polu. Jeľeli Twój komputer z systemem Linux nie dziađa wystarczajæco wydajnie, zawsze moľesz kupiè drugi i rozđoľyè obciæľenie — takie rozwiæzanie jest tanie. Natomiast jeħli kosztujæcy miliony dolarów komputer Ultra Enterprise 10000 nie dziađa wystarczajæco dobrze i w kaľdej minucie firma traci niebagatelne kwoty, wówczas moľesz zadzwoniè do Sun Service1 i zaczæè domagaè siú odpowiedzi.

To stanowi wyjaħnienie skoncentrowania siú firmy Sun na kwestiach zwiæzanych z wydajnoħciæ: zyski nierozerwalnie byđy zwiæzane z poziomem sprzedaľy sprzútu, a prawdziwe pieniædze najczúħciej moľna byđo zarobiè wđaħnie w wyniku poprawy wydajnoħci. Firma Sun potrzebowađa — i nie ukrywajmy, mogđa sobie pozwoliè na zatrudnienie w peđnym wymiarze godzin — ponad stu inľynierów zajmujæcych siú wydajnoħciæ. (Muszú tutaj dodaè, ľe do wspomnianych inľynierów zaliczađem siú, tak jak Musumeci, równieľ ja). W pođæczeniu z zespođami zajmujæcymi siú pracami nad jædrem inľynierowie odpowiedzialni za wydajnoħè wprowadzili wiele usprawnieē na polu wydajnoħci systemu. W obszarze wydajnoħci i monitorowania system Linux przeszedđ naprawdú dđugæ drogú. Ħwiadczy o tym fakt, ľe obecnie jest uľywany w ogromnych ħrodowiskach przetwarzania w chmurze. Wiele przedstawionych w niniejszej ksiæľce funkcji poprawiajæcych wydajnoħè w systemach Linux zostađo opracowanych w ostatnich piúciu latach.

Pozostałe zagadnienia poruszone w książce Przykđadowe rysunki przedstawiajæce uľywane narzúdzia nie zostađy zamieszczone jedynie w celu pokazania danych, ale równieľ typu dostúpnych danych. Wspomniane narzúdzia z reguđy prezentujæ dane w intuicyjny sposób, czústo w stylu wczeħniejszych narzúdzi systemu UNIX, wiúc wygenerowane dane wyjħciowe wyglædajæ znajomo i zwykle nie sæ potrzebne dodatkowe objaħnienia. Dlatego teľ rysunki zamieszczone w ksiæľce w doskonađy sposób pokazujæ przeznaczenie uľywanych narzúdzi i bardzo rzadko wymagajæ dodatkowych opisów. (Jeľeli narzúdzie wymaga szczegóđowego objaħnienia, to moľe oznaczaè, ľe zostađo kiepsko zaprojektowane!). Historia technologii moľe dostarczyè wielu cennych informacji pomagajæcych w pogđúbieniu wiedzy, wiúc w wielu miejscach búdú jæ przytaczađ. Ponadto warto poznawaè kluczowe osoby w branľy (to naprawdú mađe ħrodowisko), poniewaľ prawdopodobnie natkniesz siú na nie lub ich pracú, gdy búdziesz siú zajmowađ kwestiami wydajnoħci albo teľ w innym kontekħcie. Leksykon „kto jest kim” znajdziesz w dodatku G.

1

W roku 2010 firma Sun zostađa przejúta przez Oracle — przyp. tđum.

22

Wstęp

Tematy nieporuszone w książce W tej ksiæľce koncentrujemy siú na wydajnoħci. Wykonanie wszystkich przykđadowych zadaē búdzie czasami wymagađo pewnych operacji z zakresu administracji systemem, miúdzy innymi instalacji lub kompilacji oprogramowania (te tematy nie búdæ tutaj omawiane). W szczególnoħci, w systemie Linux, konieczne búdzie zainstalowanie pakietu sysstat, podobnie jak wielu innych narzúdzi, których uľycie pokazano w ksiæľce. W prezentowanej ksiæľce podsumowano takľe wiele komponentów skđadajæcych siú na system operacyjny, czúħè z nich jest bardziej szczegóđowo omówiona w oddzielnych ksiæľkach. Podsumowano równieľ zagadnienia dotyczæce zaawansowanej analizy wydajnoħci, búdziesz miađ wiúc ħwiadomoħè ich istnienia. Jeħli zajdzie potrzeba, wiúcej na ich temat búdziesz mógđ dowiedzieè siú z dodatkowych ļródeđ.

Jak zorganizowana jest ta książka? W niniejszej ksiæľce znajdziesz nastúpujæce rozdziađy: 















Rozdziađ 1. „Wprowadzenie” to wprowadzenie do analizy wydajnoħci systemów, podsumowanie kluczowych koncepcji oraz prezentacja przykđadów aktywnoħci zwiæzanej z wydajnoħciæ. Rozdziađ 2. „Metodologia” daje niezbúdne podstawy do analizy i dostrajania wydajnoħci. W tym rozdziale znajdziesz terminologiú, koncepcje, modele i metodologie przeznaczone do obserwacji, eksperymentowania, planowania pojemnoħci, analizy oraz generowania danych statystycznych. Rozdziađ 3. „Systemy operacyjne” stanowi podsumowanie informacji o komponentach jædra — informacje te warto znaè podczas analizy wydajnoħci. Przedstawiony tutaj materiađ to niezbúdne podstawy pozwalajæce na interpretacjú i zrozumienie sposobu dziađania systemu operacyjnego. Rozdziađ 4. „Narzúdzia monitorowania” zawiera prezentacjú róľnego rodzaju dostúpnych narzúdzi do monitorowania systemu, a takľe interfejsów i frameworków, na podstawie których utworzono wspomniane narzúdzia. Rozdziađ 5. „Aplikacje” zawiera omówienie tematów zwiæzanych z wydajnoħciæ aplikacji oraz jej monitorowaniem z poziomu systemu operacyjnego. Rozdziađ 6. „Procesory” zostađ poħwiúcony procesorom, rdzeniom, wætkom sprzútowym, pamiúci cache procesora, magistralom procesora oraz algorytmom szeregowania jædra. Rozdziađ 7. „Pamiúè” dotyczy pamiúci wirtualnej, stronicowania, przestrzeni wymiany, architektury pamiúci, szyn, przestrzeni adresowych i alokacji. Rozdziađ 8. „Systemy plików” dotyczy systemów plików i wydajnoħci wejħcia-wyjħcia, miúdzy innymi z uwzglúdnieniem róľnego rodzaju buforów.

Wstęp











23

Rozdziađ 9. „Dyski” to omówienie tematów zwiæzanych z urzædzeniami pamiúci masowej, dyskowym obciæľeniem wejħcia-wyjħcia, kontrolerami pamiúci masowej, macierzæ RAID, a takľe podsystemem wejħcia-wyjħcia w jædrze. Rozdziađ 10. „Sieè” zostađ poħwiúcony protokođom sieciowym, gniazdom, interfejsom oraz pođæczeniom fizycznym. Rozdziađ 11. „Przetwarzanie w chmurze” stanowi wprowadzenie do najczúħciej uľywanych w przetwarzaniu w chmurze metod wirtualizacji, zarówno sprzútowych, jak i na podstawie systemu operacyjnego. W wyniku lektury rozdziađu poznasz cechy charakterystyczne wspomnianych metod z uwzglúdnieniem wpđywu na wydajnoħè, izolacji oraz monitorowania. Rozdziađ 12. „Testy wydajnoħci” pokazuje, jak prawidđowo przeprowadzaè testy wydajnoħci, a takľe jak interpretowaè wyniki tego rodzaju testów przeprowadzonych przez innych. To zaskakujæco trudny temat, a dziúki materiađowi przedstawionemu w rozdziale dowiesz siú, jak unikaè najczúħciej popeđnianych pomyđek i najlepiej wykorzystywaè analizowane wyniki. Rozdziađ 13. „Studium przypadku” zawiera omówienie przykđadów wydajnoħci systemów. Z lektury tego rozdziađu dowiesz siú, jak od poczætku do koēca wyglæda rzeczywista analiza problemu zgđaszanego przez klienta.

W rozdziađach od 1. do 4. przedstawiono jedynie niezbúdne podstawy. Po lekturze wymienionych rozdziađów do pozostađych moľesz siúgaè wtedy, gdy zaistnieje taka koniecznoħè. Z kolei rozdziađ 13. zostađ napisany w odmienny sposób, z wykorzystaniem stylu charakterystycznego dla opowiadania, aby dziúki temu z szerszej perspektywy pokazaè pracú inľyniera odpowiedzialnego za wydajnoħè. Jeľeli jesteħ osobæ poczætkujæcæ na polu analizy wydajnoħci, ten rozdziađ moľesz przeczytaè jako pierwszy, co pozwoli Ci uzyskaè odpowiedni kontekst. Nastúpnie moľesz powróciè do niego po lekturze pozostađych rozdziađów ksiæľki.

Informacje na przyszłość Ksiæľkú napisano w taki sposób, aby pozostađa wartoħciowa przez wiele lat. Dlatego teľ koncentruje siú na podstawach i metodologiach stosowanych przez analityków wydajnoħci systemów. Aby osiægnæè wspomniany cel, wiele rozdziađów zostađo podzielonych na dwie czúħci. Pierwsza zawiera pojúcia, koncepcje i metodologie (bardzo czústo w podrozdziađach o nazwach takich jak wspomniane okreħlenia). Informacje przedstawione w czúħci pierwszej powinny pozostaè aktualne przez wiele lat od chwili wydania tej ksiæľki. Z kolei czúħè druga skđada siú z przykđadów pokazujæcych implementacje rozwiæzaē omówionych w czúħci pierwszej: architekturú, narzúdzia analizy i parametry do dostrojenia. Nawet wtedy kiedy informacje z czúħci drugiej stanæ siú nieaktualne, pozostanæ uľyteczne w kontekħcie przedstawionych przykđadów.

24

Wstęp

Przykłady monitorowania Bardzo czústo zachodzi potrzeba dokđadnego poznania dziađania systemu operacyjnego, do czego moľna wykorzystaè narzúdzia sđuľæce do monitorowania jædra. Istnieje wiele tego rodzaju narzúdzi, przeznaczonych do uľycia na róľnych etapach. Do wspomnianych narzúdzi zaliczamy: ftrace, perf, DTrace, SystemTap, LTTng i ktap. Jedno z nich — DTrace — zostađo wybrane i uľyte w wiúkszoħci przykđadów przedstawionych w ksiæľce, dotyczæcych zarówno systemów z rodziny Linux, jak i Solaris. Wymienione narzúdzie oferuje funkcje niezbúdne w przykđadach, a ponadto poħwiúcono mu ogromnæ iloħè materiađów zewnútrznych, miúdzy innymi skryptów, do których moľesz zajrzeè podczas wykorzystywania narzúdzia DTrace w bardziej zaawansowanych zadaniach. Byè moľe búdziesz musiađ lub po prostu búdziesz chciađ uľyè innych narzúdzi, co oczywiħcie nie stanowi problemu. Przykđady wykorzystujæce narzúdzie DTrace majæ na celu pokazanie sposobów monitorowania i rodzajów informacji, jakie moľna pobieraè z systemu operacyjnego. Bardzo czústo najtrudniejszym krokiem jest ustalenie, jakie informacje naleľy pobraè z systemu operacyjnego i jakie metodologie wykorzystaè w tym celu.

Do kogo skierowana jest ta książka? Niniejsza ksiæľka jest skierowana miúdzy innymi do administratorów systemów, a takľe do operatorów pracujæcych w ħrodowiskach biznesowych i przetwarzania w chmurze. Ksiæľka moľe staè siú uľytecznym przewodnikiem równieľ dla programistów, administratorów baz danych i serwerów WWW — dla wszystkich, którzy muszæ zrozumieè kwestie zwiæzane z wydajnoħciæ aplikacji i systemu operacyjnego. Jako gđówny inľynier wydajnoħci u dostawcy usđug przetwarzania w chmurze bardzo czústo wspóđpracujú z dziađem pomocy technicznej i klientami przy rozwiæzywaniu wielu kwestii zwiæzanych z wydajnoħciæ, wystúpujæcych u klientów, na których ciæľy ogromna presja czasu. Dla wielu osób zapewnienie wydajnoħci nie naleľy do podstawowych obowiæzków w pracy, muszæ oni jedynie wiedzieè, jak rozwiæzaè dany problem. To sprawiđo, ľe postanowiđem ograniczyè wielkoħè niniejszej ksiæľki — jestem przekonany, ľe czas, który moľesz poħwiúciè na lekturú, jest bardzo ograniczony. Ksiæľka nie jest jednak zbyt krótka, omówiono w niej bowiem wiele zagadnieē, aby dostarczyè Ci informacji niezbúdnych w róľnych sytuacjach. Kolejnæ grupæ docelowæ ksiæľki sæ studenci; omawiana pozycja moľe okazaè siú odpowiednim materiađem dodatkowym do wykorzystania na kursach poħwiúconych wydajnoħci systemu. Podczas tworzenia tej ksiæľki (i wiele lat wczeħniej) sam przygotowywađem i prowadziđem wspomniane kursy, w trakcie których zadaniem uczestników byđo rozwiæzywanie symulowanych problemów zwiæzanych z wydajnoħciæ. (Oczywiħcie uczestnicy nie otrzymywali wczeħniej ľadnych podpowiedzi!). Dziúki tej pracy przekonađem siú, jakie materiađy najlepiej pomagajæ uczestnikom w rozwiæzywaniu problemów dotyczæcych wydajnoħci. Zdobyte wówczas doħwiadczenie wykorzystađem w wyborze materiađu do prezentowanej ksiæľki.

Wstęp

25

Niezaleľnie od tego, czy jesteħ kursantem, czy nie, èwiczenia zamieszczone w ksiæľce dajæ Ci moľliwoħè sprawdzenia zdobytej wiedzy i zastosowania jej w praktyce. Wspomniane èwiczenia obejmujæ (zgodnie z sugestiami przedstawionymi przez recenzentów) pewne opcjonalne zadania zaawansowane, których nie musisz rozwiæzywaè. Ich rozwiæzanie moľe okazaè siú niemoľliwe, ale przynajmniej zadania te powinny zmusiè Ciú do myħlenia. Jeħli chodzi o wielkoħè firmy — prezentowana ksiæľka zawiera wystarczajæcæ iloħè informacji szczegóđowych, aby speđniè oczekiwania czytelników pracujæcych zarówno w mađych, jak i duľych ħrodowiskach firmowych, a takľe w ħrodowiskach zatrudniajæcych dziesiætki pracowników odpowiedzialnych za kwestie wydajnoħci. W wielu mađych przedsiúbiorstwach ksiæľka moľe sđuľyè w charakterze przewodnika, którego tylko niewielkie fragmenty búdæ wykorzystywane w codziennej pracy.

Konwencje zastosowane w książce W ksiæľce zastosowano nastúpujæce konwencje typograficzne: netif_receive_skb()

nazwa funkcji

iostat

strona podrúcznika man

Documentation/…

dokumentacja systemu Linux

CONFIG_...

opcja konfiguracyjna systemu Linux

kernel/…

kod ļródđowy jædra systemu Linux

fs/

kod ļródđowy jædra systemu Linux, systemy plików

usr/src/uts/…

kod ļródđowy jædra systemu Solaris

#

znak zachúty powđoki uľytkownika root

$

znak zachúty powđoki uľytkownika o zwykđych uprawnieniach

^C

polecenie, którego wykonywanie zostađo przerwane przez naciħniúcie Ctrl+C

[…]

skrócone dane

mpstat 1

wprowadzone polecenie lub pođoľenie nacisku na dany fragment

Materiały dodatkowe i odwołania Oto skrócona lista materiađów dodatkowych (peđnæ listú znajdziesz w bibliografii). Do wymienionych pozycji moľesz siúgnæè w celu uzyskania informacji dodatkowych o systemach operacyjnych i analizie wydajnoħci:

26

Wstęp

[Jain 91]

R. Jain, The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling, Wiley, 1991.

[Vahalia 96]

U. Vahalia, UNIX Internals: The New Frontiers, Prentice Hall, 1996.

[Cockcroft 98]

A. Cockcroft, R. Pettit, Sun Performance and Tuning: Java and the Internet, Prentice Hall, 1998.

[Musumeci 02]

G.D. Musumeci, M. Loukidas, System Performance Tuning, wyd. 2, O’Reilly, 2002.

[Bovet 05]

D. Bovet, M. Cesati, Understanding the Linux Kernel, wyd. 3, O’Reilly, 2005.

[McDougall 06a] R. McDougall, J. Mauro, Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture, 2nd Edition, Prentice Hall, 2006. [McDougall 06b] R. McDougall, J. Mauro, B. Gregg, Solaris Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris, Prentice Hall, 2006. [Gove 07]

D. Gove, Solaris Application Programming, Prentice Hall, 2007.

[Gregg 11]

B. Gregg, J. Mauro, DTrace: Dynamic Tracing in Oracle Solaris, Mac OS X and FreeBSD, Prentice Hall, 2011.

[Love 14]

R. Love, Jædro Linuksa. Przewodnik programisty, wyd. 3, Helion, 2014.

Podziękowania Deirdré Straughan ponownie niezwykle mi pomogła, ponieważ rozbudziła moje techniczne zainteresowania na tyle mocno, że umożliwiło mi to napisanie kolejnej książki. Całkowicie zaangażowała się w prace, począwszy od fazy koncepcji, aż po gotowy tekst. Najpierw pomogła mi w przygotowaniu planu książki, a następnie poświęciła niezliczoną ilość godzin na edycję i analizę każdej strony tekstu, wskazując przy tym wiele obszarów, które nie zostały wyjaśnione wystarczająco dokładnie. Jak dotąd, pracowaliśmy razem nad ponad 2000 stron o treści technicznej (nie licząc postów publikowanych na blogu!); mogę uznawać się za prawdziwego szczęściarza, mając do dyspozycji tak doskonałą pomoc. Barbara Wood w stosunkowo krótkim czasie przeprowadziła korektę tekstu i wprowadziła wiele zmian, poprawiając jego ogólną jakość, czytelność oraz spójność. Książka jest dość obszerna, poruszona w niej tematyka skomplikowana i dlatego praca nad tekstem na pewno nie była łatwa. Tym bardziej jestem wdzięczny Barbarze za jej pomoc i ciężką pracę. Dziękuję każdemu, kto przekazał komentarze i uwagi na temat książki bądź jej poszczególnych fragmentów. To jest książka wybitnie techniczna, porusza wiele nowych zagadnień, a przeprowadzenie recenzji materiału wymagało sporego wysiłku — często dokładnego sprawdzenia i zrozumienia kodu źródłowego jądra systemu. Darryl Gove dostarczył niezwykle cennych uwag zarówno na poziomie technicznym, jak i ogólnie dotyczących sposobu prezentacji i organizacji materiału. On sam jest autorem, a ja niecierpliwie czekam na jego kolejne książki, ponieważ wiem, jak wielką wagę przykłada do tego, aby przekazać czytelnikom materiał możliwie najwyższej jakości.

27

28

Podziękowania

Jestem niezmiernie wdziúczny Richardowi Lowe i Robertowi Mustacchiemu, którzy wspóđpracowali ze mnæ nad cađæ ksiæľkæ, a takľe wskazali tematy pominiúte lub wymagajæce lepszego objaħnienia. Wiedza Richarda z zakresu róľnych komponentów wewnútrznych jædra jest nadzwyczajna i jednoczeħnie nieco niesamowita. Robert bardzo pomógđ mi podczas pracy nad rozdziađem poħwiúconym przetwarzaniu w chmurze, dzielæc siú swoim doħwiadczeniem, jakie zdobyđ w trakcie prac nad przeniesieniem KVM-u do jædra illumos. Dziúkujú równieľ za uwagi, jakie otrzymađem od Jima Mauro i Dominica Kaya. Juľ wczeħniej wspóđpracowađem z nimi nad innymi ksiæľkami — oni bez wætpienia majæ doskonađe umysđy, umoľliwiajæce im zrozumienie trudnych zagadnieē technicznych, a takľe umiejútnoħci wyjaħnienia tych zagadnieē czytelnikom. Jerry Jelinek i Max Bruning, posiadajæcy doħwiadczenie w zakresie programowania jædra, dostarczyli wielu uwag dotyczæcych róľnych rozdziađów ksiæľki. Adam Leventhal przekazađ mi cenne informacje, które wykorzystađem w rozdziađach poħwiúconych systemom plików i dyskom. Przede wszystkim pomógđ mi zrozumieè aktualne niuanse w zakresie pamiúci flash — to obszar, na którym od dawna jest ekspertem. Warto tutaj dodaè, ľe pracujæc w firmie Sun, znalazđ wiele innowacyjnych zastosowaē dla pamiúci flash. David Pacheco dostarczyđ cennych uwag zwiæzanych z rozdziađem poħwiúconym aplikacjom, natomiast Dan MacDonald do rozdziađu o sieci. Jestem szczúħliwy, ľe mogđem wykorzystaè ich wiedzú w obszarach, w których sæ prawdziwymi ekspertami. Carlos Cardenas przeanalizowađ cađæ ksiæľkú i przekazađ unikalne, potrzebne mi wskazówki z zakresu analizy statystycznej. Dziúkujú równieľ Bryanowi Cantrillowi, Keithowi Wesolowskiemu, Paulowi Eggletonowi, Marsellowi Kukuljevic-Pearce’emu i Adrianowi Cockcroftowi za ich uwagi i wkđad. Komentarze Adriana zachúciđy mnie do zmiany kolejnoħci rozdziađów, co powinno pomóc czytelnikowi w jeszcze lepszym powiæzaniu materiađu. Jestem równieľ wdziúczy autorom ksiæľek wymienionych w bibliografii, którzy przecierali szlaki na polu wydajnoħci systemów i udokumentowali dokonane przez siebie odkrycia. Sam wiele nauczyđem siú od ekspertów z zakresu wydajnoħci, z którymi miađem przyjemnoħè pracowaè na przestrzeni lat, a byli nimi miúdzy innymi: Bryan Cantrill, Roch Bourbonnais, Jim Mauro, Richard McDougall oraz wielu innych. Dziúkujú Bryanowi Cantrillowi za wsparcie, jakiego mi udzieliđ podczas pracy nad tym projektem, oraz Jasonowi Hoffmanowi za jego entuzjazm. Podziúkowania skđadam równieľ Claire, Mitchell oraz innym czđonkom rodziny i przyjaciođom za poħwiúcenie i wsparcie udzielone mi podczas pracy na tæ ksiæľkæ. Specjalne podziúkowania kierujú do Grega Doencha — redaktora w wydawnictwie Pearson, za jego pomoc, cierpliwoħè i zaangaľowanie w projekt. Naprawdú dobrze siú bawiđem, pracujæc nad tæ ksiæľkæ, choè czasami bywađo bardzo trudno. Znacznie đatwiej byđoby mi napisaè tú ksiæľkú dekadú wczeħniej, poniewaľ wtedy miađem znacznie mniejszæ wiedzú dotyczæcæ zđoľonoħci i niuansów zwiæzanych z wydajnoħciæ systemów. W ciægu wspomnianej dekady pracowađem jako inľynier oprogramowania, jædra, wydajnoħci, a takľe zajmowađem siú projektowaniem, pamiúciæ masowæ i przetwarzaniem w chmurze. Rozwiæzywađem problemy zwiæzane z wydajnoħciæ praktycznie w kaľdym miejscu stosu, od aplikacji aľ po warstwú fizycznæ

Podziękowania

29

komputera. Dziúki zdobytemu w ten sposób doħwiadczeniu i ħwiadomoħci, jak wiele wiedzy z zakresu wydajnoħci nie zostađo udokumentowane, byđem jednoczeħnie zachúcony i zniechúcony do napisania ksiæľki poħwiúconej wydajnoħci systemów. Wedđug mnie jest to ksiæľka, która musiađa byè napisana; odczuwam ulgú, wiedzæc, ľe zostađa ukoēczona.

30

Podziękowania

O autorze Brendan Gregg to gđówny inľynier w Joyent, odpowiedzialny za analizú wydajnoħci i skalowalnoħè zarówno mađych, jak i duľych ħrodowisk przetwarzania w chmurze na dowolnym poziomie warstwy oprogramowania. Jest gđównym autorem ksiæľki DTrace: Dynamic Tracing in Oracle Solaris, Mac OS X and FreeBSD (Prentice Hall, 2011), wspóđautorem Solaris Performance and Tools (Prentice Hall, 2007) oraz autorem wielu artykuđów poħwiúconych wydajnoħci systemów. Wczeħniej pracowađ w Sun Microsystems jako gđówny inľynier odpowiedzialny za wydajnoħè i jædro oraz jako konsultant w zakresie wydajnoħci, a takľe prowadziđ szkolenia w tym zakresie. Opracowađ DTraceToolkit i ZFS L2ARC, a wiele przygotowanych przez niego skryptów DTrace domyħlnie znajduje siú w systemach Mac OS X i Oracle Solaris 11. Ostatnio zajmuje siú wizualizacjæ wydajnoħci.

31

32

O autorze

•••••

1 Wprowadzenie

�

�

Wydajność to ekscytująca, zmienna i w ająca dyscyplina. Ten rozdział stanowi wprowadzenie na polu wydajności, � cza wydajności systemów, a także prezen­ tuje role, działania, perspektywy i � nia w tym zakresie. Ponadto wprowadzone zostanie pojęcie opóźnienie -ak is�a metryka podczas pomiaru wydajności oraz przedstawione zostaną nows zWiązania, które pojawiły się w informatyce, czyli monitorowanie dynami z.2._ i � zetwarzanie w chmurze. W rozdziale zamieszczono � iązanych z wydajnością, aby w ten sposób dostarczyć również przykłady dzi la omawianych zagadnień. czytelnikom kontek

�

�

\ �

�

1.1. Wydajność systemów Wydajność systemu oznacza analizę całego systemu łącznie z jego wszystkimi kompo­ nentami sprzętowymi oraz pełnym stosem oprogramowania. Wszystko, co znajduje się na ścieżce danych, czyli oprogramowanie i sprzęt, może wpływać na wydajność. W przy­ padku systemów rozproszonych oznacza to wiele serwerów i aplikacji. Jeżeli nie po­ siadasz schematu pokazującego ścieżkę danych dla używanego środowiska, to powi­ nieneś go odszukać lub przygotować samodzielnie. Wspomniany schemat pomoże Ci w zrozumieniu relacji między poszczególnymi komponentami, a także da gwarancję, że nie przeoczysz całych obszarów.

33

34

Rozdział 1

•

Wprowadzenie

Na rysunku 1.1 pokazano ogólny stos oprogramowania systemu w pojedynczym serwerze. Schemat obejmuje jądro systemu operacyjnego, a także przykładowe warstwy bazy danych i aplikacji. Termin cały stos jest czasami używany w celu opisania jedynie środowiska aplikacji obejmującego bazy danych, aplikacje i serwery WWW. Jednak w analizie wydajności systemu wspomniane pojęcie musi oznaczać wszystko, łącznie z jądrem i bibliotekami systemowymi. r--------------------------------------

Aplikacja

� �

Poz· ---

-

own1ka

-

-----

ZIOmjądra

•

Algorytm

Systemy

szeregowania

plików

wątków

�

Rysunek

g� lny stos oprogramowania systemu

�

Pokazany na stos będzie omówiony w rozdziale 3. "Systemy operacyjne", a dokładnie przea any w kolejnych rozdziałach. Zamieszczone dalej podroz­ działy zawierają omówienie tematu wydajności systemów oraz wydajności w ogóle.

rys� �

1.2.

Role

Wydajność systemu rozpatrywana w kategorii działania może być określona za po­ mocą wielu ról, między innymi administratora systemu, pracownika pomocy technicznej, programisty aplikacji, administratora bazy danych, administratora witryny WWW itd. Dla wielu wspomnianych osób kwestie wydajności są jedynie zadaniami dodatkowymi. Można również zauważyć tendencję do analizy wydajności jedynie na obszarze od­ powiedzialności nakładanej przez daną rolę (zespół odpowiedzialny za sieć sprawdza sieć, zespół bazy danych sprawdza bazę danych itd.). Jednak w przypadku niektórych pro­ blemów związanych z wydajnością znalezienie źródła problemu wymaga współpracy różnych zespołów.

1.3. Działania

35

Firmy zatrudniajæ czasami tak zwanych inľynierów wydajnoħci, których podstawowym zadaniem jest zapewnienie maksymalnej wydajnoħci systemów. Wspomniani inľynierowie mogæ wspóđpracowaè z wieloma zespođami i przeprowadzaè holistycznæ analizú ħrodowiska — takie podejħcie okazuje siú niezbúdne w celu rozwiæzywania skomplikowanych problemów zwiæzanych z wydajnoħciæ. Zadaniem inľynierów moľe byè równieľ opracowywanie lepszych narzúdzi i metryk pomagajæcych w analizie na poziomie systemu oraz w planowaniu pojemnoħci na poziomie cađego ħrodowiska. W zakresie wydajnoħci istniejæ takľe zadania przeznaczone dla osób specjalizujæcych siú w konkretnych aplikacjach, na przykđad ludzi pracujæcych nad wydajnoħciæ Javy lub bazy danych MySQL. Takie osoby najczúħciej ograniczajæ siú do podstawowego sprawdzenia wydajnoħci systemu, a nastúpnie przechodzæ do narzúdzi charakterystycznych dla danej aplikacji.

1.3. Działania Obszar wydajnoħci oznacza podejmowanie nastúpujæcych dziađaē, które wymieniono ħciħle w kolejnoħci ich wykonywania: 1. Zdefiniowanie celów zwiæzanych z wydajnoħciæ oraz modelowaniem wydajnoħci. 2. Przygotowanie charakterystyki wydajnoħci prototypu oprogramowania i sprzútu. 3. Przeprowadzenie analizy wydajnoħci kodu ļródđowego, wstúpna integracja. 4. Przeprowadzenie testów nieregresywnych kompilowanego oprogramowania, wydania typu pre- i post-. 5. Wykonanie testów wydajnoħci danej wersji oprogramowania. 6. Testowanie dowodu koncepcji (ang. proof-of-concept) przed jego wdroľeniem w ħrodowisku docelowym. 7. Optymalizacja konfiguracji przed jej wdroľeniem w ħrodowisku produkcyjnym. 8. Monitorowanie oprogramowania dziađajæcego w ħrodowisku produkcyjnym. 9. Analiza zgđoszonych problemów dotyczæcych wydajnoħci. Kroki od 1. do 5. stanowiæ czúħè tradycyjnego modelu tworzenia oprogramowania. Przygotowywany produkt jest nastúpnie wypuszczany na rynek, a kolejnym krokiem jest przeprowadzenie testów dowodu koncepcji w ħrodowisku klienta lub wdroľenie i konfiguracja. Jeľeli w ħrodowisku klienta zostanæ odkryte problemy (w krokach od 6. do 9.), oznacza to, ľe nie zostađy zauwaľone lub usuniúte w trakcie prac nad danym produktem. Idealnym rozwiæzaniem búdzie, jeħli inľynier wydajnoħci rozpocznie pracú, jeszcze zanim nastæpi wybór sprzútu lub rozpocznie siú tworzenie oprogramowania. Zatrudnienie wspomnianego inľyniera oraz zdefiniowanie celów i utworzenie modelu wydajnoħci powinno byè pierwszym krokiem. Produkty jednak bardzo czústo sæ opracowywane bez tego kroku, w wyniku czego praca inľyniera wydajnoħci odsuwana jest na póļniej, czyli do chwili, gdy pojawiæ siú problemy. Na kaľdym kolejnym etapie procesu usuniúcie problemów zwiæzanych z wydajnoħciæ moľe okazaè siú coraz trudniejsze, gđównie ze wzglúdu na podjúte wczeħniej decyzje dotyczæce architektury danego produktu.

36

Rozdział 1



Wprowadzenie

Wyraľenie planowanie pojemnoħci moľe odnosiè siú do liczby wymienionych wczeħniej dziađaē. Na etapie projektowania obejmuje analizú poziomu wykorzystania zasobów podczas tworzenia oprogramowania, co pozwala na sprawdzenie, w jakim stopniu projekt speđnia wymagania stawiane produktowi. Natomiast juľ po wdroľeniu produktu obejmuje monitorowanie poziomu zuľycia zasobów, aby ewentualne problemy moľna byđo przewidywaè, zanim siú jeszcze pojawiæ. W niniejszej ksiæľce znajdziesz omówienie metodologii i narzúdzi pomagajæcych w przeprowadzaniu wspomnianych dziađaē. Ħrodowiska i konkretnie podejmowane dziađania búdæ siú róľniđy w zaleľnoħci od firmy i produktu; w wielu przypadkach nie sæ wykonywane wszystkie wymienione wczeħniej kroki. Twoim zadaniem moľe byè skoncentrowanie siú na wybranych dziađaniach lub tylko na jednym ze wspomnianych.

1.4. Perspektywy Poza koncentracjæ na róľnych dziađaniach role zwiæzane z wydajnoħciæ moľna postrzegaè z innych perspektyw. Dwie tego rodzaju perspektywy postrzegania analizy wydajnoħci zostađy na rysunku 1.2 oznaczone jako analiza obciæľenia i analiza zasobów; dotyczæ one spojrzenia z róľnych kierunków na stos oprogramowania.

Rysunek 1.2. Perspektywy analizy

Perspektywa analizy zasobów jest bardzo czústo stosowana przez administratorów danego systemu odpowiedzialnych za jego zasoby. Programiħci aplikacji, którzy sæ odpowiedzialni za wydajnoħè podczas obciæľenia, najczúħciej koncentrujæ siú na perspektywie analizy obciæľenia. Kaľda perspektywa ma wady i zalety, o czym siú przekonasz w rozdziale 2., zatytuđowanym „Metodologia”. W przypadku trudnych problemów pomocne moľe okazaè siú przeprowadzenie analizy z obu wymienionych perspektyw.

1.5. Zapewnienie wydajności to wyzwanie

37

1.5. Zapewnienie wydajności to wyzwanie Dziedzina wydajnoħci systemów to obszar stawiajæcy powaľne wyzwania z wielu róľnych powodów. Zaliczamy do nich miúdzy innymi fakt, ľe wydajnoħè jest subiektywna, skomplikowana i bardzo czústo obejmuje wiele kwestii.

1.5.1. Wydajność jest subiektywna Dyscypliny technologiczne z reguđy sæ w maksymalnym stopniu obiektywne, aby osoby dziađajæce w danej branľy wyraļnie wiedziađy, co jest biađe, a co czarne. Taka sytuacja ma miejsce na przykđad w zakresie rozwiæzywania problemów z oprogramowaniem, gdzie bđæd istnieje lub nie, zostađ usuniúty lub nie. Potwierdzeniem istnienia bđúdu najczúħciej jest komunikat bđúdu, który zwykle moľna đatwo zinterpretowaè i w efekcie zrozumieè przyczynú bđúdu. Natomiast wydajnoħè bardzo czústo jest subiektywna. W przypadku wystúpowania problemów zwiæzanych z wydajnoħciæ samo istnienie problemu nie musi byè oczywiste, podobnie jak kwestia, czy zostađ on usuniúty. To, co jeden uľytkownik uznaje za „niewystarczajæcæ” wydajnoħè, a tym samym za problem, inny uľytkownik moľe uznaè za „dobræ” wydajnoħè. Przeanalizujmy przedstawiony poniľej komunikat: ¥redni czas udzielenia odpowiedzi przez dysk wynosi 1 ms.

Jakæ wydajnoħè oznacza powyľszy komunikat: dobræ czy zđæ? Wprawdzie czas reakcji (inaczej opóļnienie) jest jednæ z najlepszych metryk, ale juľ interpretacja wartoħci opóļnienia stanowi trudnoħè. Do pewnego stopnia uznanie danej wartoħci metryki za dobræ lub zđæ moľe zaleľeè od wydajnoħci oczekiwanej przez twórców aplikacji lub uľytkowników koēcowych. Zmiany odczuè subiektywnych na obiektywne moľna dokonaè wskutek zdefiniowania jasnych celów, takich jak okreħlenie ħredniego czasu udzielenia odpowiedzi bædļ teľ wymaganie, aby okreħlony odsetek ľædaē byđ speđniany w podanym zakresie wartoħci opóļnienia. Inne sposoby radzenia sobie z subiektywnoħciæ przedstawiono w rozdziale 2. „Metodologia” — zaliczamy do nich analizú opóļnienia w celu wyraľania problemów jako wspóđczynnika ich opóļnienia operacyjnego.

1.5.2. Systemy są skomplikowane Oprócz wspomnianej wczeħniej subiektywnoħci wydajnoħè moľe byè bardzo wymagajæcæ dyscyplinæ ze wzglúdu na stopieē skomplikowania systemów oraz brak jasno zdefiniowanych pozycji wyjħciowych do analizy. Czasami rozpoczyna siú po prostu od zgadywania i obwiniania na przykđad sieci. Analityk wydajnoħci musi ustaliè, czy porusza siú we wđaħciwym kierunku. Kwestie zwiæzane z wydajnoħciæ mogæ mieè ļródđo równieľ w skomplikowanych interakcjach miúdzy podsystemami, które dziađajæ doskonale podczas ich analizy oddzielnie od pozostađych komponentów. Taka sytuacja moľe siú zdarzaè ze wzglúdu na tak zwanæ awariú kaskadowæ (ang. cascading failure), kiedy to jeden uszkodzony

38

Rozdział 1



Wprowadzenie

komponent powoduje problemy z wydajnoħciæ w innych komponentach. W celu zrozumienia pojawiajæcego siú problemu konieczne jest rozwikđanie relacji miúdzy poszczególnymi komponentami i poznanie sposobu, w jaki one ze sobæ wspóđpracujæ. Wæskie gardđa równieľ mogæ byè skomplikowane i powiæzane ze sobæ na wiele nieoczekiwanych sposobów. Usuniúcie jednego wæskiego gardđa moľe po prostu spowodowaè jego powstanie w innym miejscu systemu, a ogólna wydajnoħè nie búdzie poprawiona w oczekiwanym stopniu. Poza stopniem skomplikowania systemu problemy z wydajnoħciæ mogæ powstawaè na skutek zđoľonej charakterystyki obciæľenia systemu produkcyjnego. W takich przypadkach odtworzenie sytuacji moľe okazaè siú niemoľliwe w ħrodowisku testowym lub moľe udaè siú jedynie pođowicznie. Rozwiæzanie skomplikowanych problemów zwiæzanych z wydajnoħciæ czústo wymaga podejħcia holistycznego. Cađy system — interakcje zarówno wewnútrzne, jak i zewnútrzne — trzeba dokđadnie przeanalizowaè. Takie zadanie wymaga ogromnych umiejútnoħci, których zwykle nie posiada jedna osoba, co czyni je zmiennym i duľym wyzwaniem intelektualnym. Przeanalizowanie wszystkich zđoľonych aspektów moľe wymagaè zastosowania róľnych metodologii, jak pokazano to w rozdziale 2. Z kolei w rozdziađach od 6. do 10. znajdziesz omówienie konkretnych metodologii dotyczæcych poszczególnych zasobów systemowych: procesora, pamiúci, systemów plików, dysków i sieci.

1.5.3. Może istnieć wiele problemów związanych z wydajnością Wyszukanie konkretnej kwestii zwykle nie stanowi problemu, w skomplikowanym oprogramowaniu czústo jest ich wiele. Aby to zilustrowaè, spróbuj odszukaè bđæd bazy danych dla uľywanego przez Ciebie systemu operacyjnego lub aplikacji, a nastúpnie znajdļ sđowo performance (pol. wydajnoħè). Moľesz byè zaskoczony! Zwykle istnieje wiele problemów zwiæzanych z wydajnoħciæ, które sæ znane, ale jeszcze nie zostađy rozwiæzane nawet w dojrzađym oprogramowaniu uznawanym za oferujæce wysokæ wydajnoħè. Taka sytuacja odkrywa kolejnæ trudnoħè na polu analizy wydajnoħci: rzeczywistym zadaniem nie jest wykrycie problemu, ale identyfikacja tego problemu lub problemów, które majæ najwiúksze znaczenie. Dlatego teľ analityk zajmujæcy siú wydajnoħciæ musi oceniaè rzæd wielkoħci problemu. Pewnego rodzaju problemy mogæ nie wystúpowaè w generowanym przez Ciebie obciæľeniu lub búdæ miađy jedynie marginalny wpđyw. W idealnej sytuacji naleľy nie tylko oceniaè wielkoħè problemu, ale równieľ oszacowaè przyrost wydajnoħci, jaki moľna osiægnæè dziúki usuniúciu problemu. Tego rodzaju informacje okaľæ siú niezwykle cenne, gdy kierownictwo búdzie starađo siú znaleļè przekonujæcy powód do tego, aby poħwiúciè zasoby na usuniúcie problemu. Metrykæ doskonale pasujæcæ do oceny wydajnoħci — o ile moľna takæ zastosowaè — jest opóļnienie.

1.6. Opóźnienie

39

1.6. Opóźnienie Opóļnienie to miara czasu poħwiúconego na czekanie. W szerokim ujúciu moľe oznaczaè czas oczekiwania na ukoēczenie dowolnych operacji, takich jak: ľædania do aplikacji, zapytania do bazy danych, operacje systemu plików. Opóļnienie moľna okreħliè na przykđad jako czas cađkowitego wczytania strony internetowej, od chwili klikniúcia đæcza do wygenerowania i wyħwietlenia cađej treħci strony. To jest bardzo waľna metryka zarówno dla klienta, jak i dostawcy witryny internetowej. Duľe opóļnienie moľe powodowaè frustracjú, tak ľe klienci poszukajæ innej firmy ħwiadczæcej usđugi hostingowe. Jako metryka opóļnienie moľe umoľliwiè oszacowanie maksymalnej szybkoħci. Na przykđad na rysunku 1.3 pokazano zapytanie do bazy danych — jego wykonanie zabiera 100 ms (to wđaħnie jest opóļnienie), z których 80 ms to oczekiwanie na zakoēczenie operacji odczytu danych z dysku. Đatwo wiúc obliczyè maksymalnæ poprawú wydajnoħci moľliwæ do osiægniúcia wskutek eliminacji operacji odczytu danych z dysku (na przykđad dziúki zastosowaniu buforowania): do piúciu razy (5x). Podana wartoħè jest oszacowanym przyħpieszeniem, a przeprowadzone obliczenie zawiera takľe ocenú problemu zwiæzanego z wydajnoħciæ: odczyt danych z dysku powoduje, ľe zapytanie wykonywane jest do piúciu razy wolniej.

Rysunek 1.3. Przykład opóźnienia dyskowej operacji wejścia-wyjścia

Tego rodzaju obliczeē nie da siú przeprowadziè za pomocæ innych metryk. Weļmy na przykđad liczbú operacji wejħcia-wyjħcia przeprowadzanych w ciægu sekundy (IOPS) — konkretne wartoħci zaleľæ od typu operacji wejħcia-wyjħcia i bardzo czústo nie sæ porównywalne. Gdy wprowadzona zmiana spowoduje zmniejszenie wartoħci IOPS o 80%, wtedy trudno jest oceniè, jaki to búdzie miađo wpđyw na wydajnoħè. Operacji wejħciawyjħcia moľe byè piúè razy mniej, ale co siú stanie, jeħli wyraľona w bajtach wielkoħè kaľdej z nich wzroħnie dziesiúciokrotnie? W zakresie sieci opóļnienie moľe odnosiè siú do czasu potrzebnego na nawiæzanie pođæczenia, ale nie do rzeczywistego transferu danych. W tej ksiæľce terminologia jest dokđadnie objaħniana na poczætku rozdziađu, aby róľnice w kontekstach byđy czytelne. Wprawdzie opóļnienie zaliczamy do uľytecznych metryk, ale nie zawsze jest ono dostúpne wtedy, gdy go potrzebujemy. Na pewnych obszarach systemów mamy dostúp jedynie do ħredniej wartoħci opóļnienia, natomiast inne w ogóle nie oferujæ metryki w postaci opóļnienia. Wraz z nadejħciem monitorowania dynamicznego opóļnienie moľna mierzyè w dowolnych, interesujæcych miejscach, a uzyskane dane dostarczæ wówczas peđnych informacji o rozkđadzie opóļnienia.

40

Rozdział 1



Wprowadzenie

1.7. Monitorowanie dynamiczne Monitorowanie dynamiczne pozwala na diagnozowanie cađego oprogramowania na bieľæco oraz w trakcie jego tworzenia. To jest technika pobierania znajdujæcych siú w pamiúci instrukcji procesora i dynamicznego budowania instrumentarium na ich bazie. W ten sposób dane statystyczne dotyczæce wydajnoħci sæ generowane z dowolnego, dziađajæcego oprogramowania, co zapewnia moľliwoħè jego monitorowania w znacznie szerszym zakresie niľ w przypadku danych statystycznych zbieranych tradycyjnie. Problemy nierozwiæzywalne wczeħniej ze wzglúdu na brak monitorowania teraz okazujæ siú moľliwe do rozwiæzania. Kwestie, które wczeħniej byđy moľliwe do rozwiæzania, ale w niewyobraľalnie trudny sposób, teraz w wielu wypadkach stađy siú znacznie đatwiejsze do rozwiæzania. Monitorowanie dynamiczne tak bardzo róľni siú od tradycyjnego, ľe zrozumienie jego roli moľe byè bardzo trudne, przynajmniej na poczætku. Weļmy pod uwagú jædro systemu operacyjnego. Analizú wnútrza jædra moľna porównaè do wejħcia do ciemnego pokoju, w którym ħwiece (systemowe dane statystyczne) zostađy przez inľynierów pracujæcych nad jædrem umieszczone w wybranych przez nich miejscach. W przedstawionym porównaniu monitorowanie dynamiczne búdzie jak ħwiatđo latarki, które moľna skierowaè w dowolne miejsce. DTrace to pierwsze narzúdzie produkcyjne, które udostúpniđo moľliwoħè monitorowania dynamicznego. Wymienione narzúdzie oferuje jeszcze wiele innych funkcji, miúdzy innymi wđasny júzyk programowania o nazwie D. Narzúdzie DTrace zostađo opracowane przez firmú Sun Microsystems i wydane w roku 2005 dla systemu operacyjnego Solaris 10. To jednoczeħnie byđ pierwszy komponent systemu operacyjnego Solaris udostúpniony jako oprogramowanie typu open source. Nastúpnie narzúdzie to zostađo przeniesione do systemów Mac OS X i FreeBSD, a obecnie trwajæ prace nad jego przeniesieniem do systemu Linux. Przed pojawieniem siú narzúdzia DTrace monitorowanie systemu najczúħciej odbywađo siú za pomocæ sond statycznych, czyli mađego zestawu punktów instrumentacji rozmieszczonych w jædrze oraz innym oprogramowaniu. Ich dostúpnoħè byđa ograniczona, a uľycie bardzo czústo pochđaniađo ogromnie duľo czasu oraz wymagađo zastosowania cyklu: konfiguracja, monitorowanie, pobieranie danych i póļniej ich analiza. Narzúdzie DTrace umoľliwia prowadzenie zarówno statycznego, jak i dynamicznego monitorowania oprogramowania na poziomie uľytkownika i jædra; dane mogæ byè dostarczane w czasie rzeczywistym. Przedstawiony przykđad pokazuje monitorowanie wykonywania procesu podczas logowania SSH. Monitorowanie odbywa siú na poziomie systemu, to znaczy nie jest powiæzane z ľadnym konkretnym identyfikatorem procesu: # dtrace -n 'exec-success { printf("%d %s", timestamp, dtrace: description 'exec-success ' matched 1 probe CPU ID FUNCTION:NAME 2 1425 exec_common:exec-success 732006240859060 2 1425 exec_common:exec-success 732006246584043 5 1425 exec_common:exec-success 732006197695333 5 1425 exec_common:exec-success 732006202832470 0 1425 exec_common:exec-success 732007379191163 0 1425 exec_common:exec-success 732007449358980

curpsinfo->pr_psargs); }' sh -c /usr/bin/locale -a /usr/bin/locale -a sh -c /usr/bin/locale -a /usr/bin/locale -a uname -r sed -ne /^# START exclude/,/^#

1.8. Przetwarzanie w chmurze

FINISH exclude/p /etc/bash/bash_completion 1 1425 exec_common:exec-success 732007353365711 1 1425 exec_common:exec-success 732007358427035 2 1425 exec_common:exec-success 732007368823865 12 1425 exec_common:exec-success 732007374821450 15 1425 exec_common:exec-success 732007365906770

41

-bash /usr/sbin/quota /bin/mail -E uname -s /bin/cat -s /etc/motd

W przedstawionym przykđadzie narzúdzie DTrace otrzymađo polecenie wyħwietlenia znaczników czasu (wyraľonych w nanosekundach) wraz z nazwami procesów i ich argumentami. Bardziej zaawansowane skrypty utworzone w júzyku D pozwalajæ na tworzenie i obliczanie wđasnych miar opóļnienia. Do narzúdzia DTrace i monitorowania dynamicznego powrócimy w rozdziale 4., zatytuđowanym „Narzúdzia monitorowania”. W kolejnych rozdziađach ksiæľki znajdziesz wiele przykđadów uľycia narzúdzia DTrace, zarówno w poleceniach mieszczæcych siú w pojedynczym wierszu, jak i w skryptach. Wspomniane przykđady zostađy przygotowane dla systemów Linux i Solaris. Z kolei wiúcej informacji dotyczæcych zaawansowanych sposobów uľycia DTrace znajdziesz w innej mojej ksiæľce poħwiúconej temu narzúdziu (patrz odwođanie [Gregg 11] w bibliografii na koēcu ksiæľki).

1.8. Przetwarzanie w chmurze Najnowszymi opracowanymi rozwiæzaniami wpđywajæcymi na wydajnoħè systemu sæ: moľliwoħè przetwarzania w chmurze oraz technologie wirtualizacji, na podstawie których najczúħciej buduje siú wspomnianæ chmurú. Przetwarzanie w chmurze pozwoliđo na gwađtowne skalowanie wskutek uľycia architektury umoľliwiajæcej zrównowaľenie w coraz wiúkszej liczbie mađych systemów obciæľenia powodowanego przez aplikacjú. To jednoczeħnie zmniejszyđo potrzebú rygorystycznego planowania pojemnoħci, poniewaľ w stosunkowo krótkim czasie pojemnoħè chmury moľna zwiúkszyè. W pewnych przypadkach przetwarzanie w chmurze zwiúkszyđo zapotrzebowanie na przeprowadzanie analizy wydajnoħci: uľycie mniejszej iloħci zasobów oznacza moľliwoħè uľycia mniejszej liczby systemów do budowy chmury. Poniewaľ klient zwykle pđaci za kaľdæ godzinú uľycia chmury, wiúksza wydajnoħè oferowana przez mniejszæ liczbú systemów przekđada siú na oszczúdnoħci finansowe. Porównaj tú sytuacjú do sytuacji klienta korporacyjnego, który przez lata jest zwiæzany sztywnym kontraktem dotyczæcym pomocy technicznej i do chwili jego zakoēczenia zwykle nie zdaje sobie sprawy, jakie oszczúdnoħci mógđby poczyniè. Nowe trudnoħci powodowane przez przetwarzanie w chmurze i technologiú wirtualizacji dotyczæ zarzædzania wpđywem, jaki na wydajnoħè majæ inne tenanty (czasami nosi to nazwú izolacji wydajnoħci), oraz fizycznego monitorowania systemu w kaľdym tenancie. Na przykđad o ile nie búdæ wđaħciwie zarzædzane przez system, wydajnoħè dyskowych operacji wejħcia-wyjħcia moľe byè kiepska na skutek rywalizacji zachodzæcej miúdzy tenantami dziađajæcymi w tym samym fizycznym komputerze. W pewnych ħrodowiskach rzeczywiste uľycie dysku fizycznego moľe byè niemoľliwe do sprawdzenia w poszczególnych tenantach, co utrudnia identyfikacjú wspomnianego problemu. Tematy zwiæzane z przetwarzaniem w chmurze zostanæ omówione w rozdziale 11., zatytuđowanym „Przetwarzanie w chmurze”.

42

Rozdział 1



Wprowadzenie

1.9. Studium przypadku Jeľeli dopiero zaczynasz przygodú na polu wydajnoħci systemów, przykđady pokazujæce, kiedy i dlaczego podejmowane sæ okreħlone dziađania, mogæ pomóc Ci w dopasowaniu wspomnianych dziađaē do aktualnie uľywanego ħrodowiska. W tym miejscu przedstawiono dwa hipotetyczne przykđady. Pierwszy dotyczy problemu wydajnoħci zwiæzanego z dyskowymi operacjami wejħcia-wyjħcia, natomiast drugi — testowania wydajnoħci podczas zmiany oprogramowania. W zaprezentowanych tutaj przykđadach wymieniono podejmowane dziađania, których objaħnienie znajdziesz w kolejnych rozdziađach ksiæľki. Zastosowane podejħcie ma na celu pokazanie nie tyle prawidđowej lub jedynej drogi, ale raczej sposobu, za pomocæ którego moľna ustaliè dziađania konieczne do podjúcia.

1.9.1. Wolno działające dyski Stefan jest administratorem systemu w firmie ħredniej wielkoħci. Zespóđ bazy danych zgđosiđ problem polegajæcy na „wolnym dziađaniu dysków” w jednym z serwerów bazy danych. Pierwszym zadaniem Stefana jest zebranie wiúkszej iloħci informacji dotyczæcych problemu, co nastúpuje wskutek dokđadnej lektury zgđoszenia. W zgđoszeniu podano, ľe dyski dziađajæ wolno, choè brakuje w nim informacji, czy problem jest spowodowany przez bazú danych. Stefan odpowiada wiúc na zgđoszenie, zadajæc nastúpujæce pytania: 

Czy problem z wydajnoħciæ dotyczy równieľ bazy danych? W jaki sposób zostađo to zmierzone?



Od jakiego czasu istnieje problem?



Czy w bazie danych wprowadzono ostatnio jakiekolwiek zmiany?



Dlaczego podejrzane sæ dyski?

Zespóđ bazy danych odpowiada: „Mamy dziennik zdarzeē przeznaczony do rejestrowania zapytaē, których wykonanie zajmuje ponad 1000 ms. Normalnie takie zapytania nie zdarzajæ siú, ale w ostatnim tygodniu pojawiajæ siú w znacznej liczbie w kaľdej godzinie. Informacje uzyskane za pomocæ narzúdzia AcmeMon wskazujæ, ľe dyski sæ bardzo zajúte”. Uzyskana odpowiedļ potwierdza istnienie rzeczywistego problemu w bazie danych, choè jednoczeħnie sugeruje, ľe dyski jako ļródđo problemu zostađy wybrane na drodze zgadywania. Stefan chce sprawdziè dyski, ale takľe inne komponenty na wypadek, gdyby okazađo siú, ľe to jednak nie dyski sæ przyczynæ problemu. AcmeMon to uľywany przez firmú podstawowy program przeznaczony do monitorowania systemu. Jednæ z jego funkcji jest wyħwietlanie pokazujæcych historycznæ wydajnoħè wykresów wygenerowanych za pomocæ poleceē systemu operacyjnego: mpstat, iostat i innych. Stefan loguje siú wiúc do AcmeMon, aby samodzielnie obejrzeè wykresy wydajnoħci.

1.9. Studium przypadku

43

Na poczætek Stefan stosuje metodologiú o nazwie USE w celu szybkiego sprawdzenia wæskich gardeđ w zasobach. Zgodnie ze zgđoszeniem zespođu bazy danych poziom uľycia dysku jest wysoki i wynosi okođo 80%, podczas gdy innych zasobów (procesora, sieci) pozostaje na znacznie niľszym poziomie. Dane historyczne pokazujæ, ľe poziom uľycia dysku zaczæđ gwađtownie rosnæè w ostatnim tygodniu, natomiast uľycie procesora pozostaje niezmienne. Narzúdzie AcmeMon nie dostarcza danych statystycznych wskazujæcych na wykorzystanie przepustowoħci lub bđúdy dysków, a wiúc dokoēczenie metody USE wymaga od Stefana zalogowania siú do serwera i wydania kilku poleceē. Stefan sprawdza stan liczników bđúdów w /proc — ich wartoħè wynosi 0. Nastúpnie uruchamia polecenie iostat, podajæc odstúp czasu wynoszæcy sekundú, i zaczyna obserwowaè poziom wykorzystania dysku na przestrzeni czasu. Narzúdzie AcmeMon zgđasza wykorzystanie na poziomie 80%, choè pomiary sæ przeprowadzane co minutú. Stosujæc pomiar co sekundú, Stefan moľe siú przekonaè, ľe poziom wykorzystania dysku jest zmienny i czústo osiæga 100%, co oznacza maksymalne wykorzystanie przepustowoħci i zwiúkszenie opóļnienia dyskowych operacji wejħcia-wyjħcia. W celu uzyskania kolejnego potwierdzenia, ľe zaobserwowane zachowanie blokuje bazú danych — i nie jest powiæzane z zapytaniami wykonywanymi przez bazú — Stefan wykorzystuje skrypt oparty na monitorowaniu dynamicznym. Zadaniem wspomnianego skryptu jest przechwytywanie znaczników czasu i stosu bazy danych, gdy nie jest ona obsđugiwana przez jædro. Dane pokazujæ, ľe baza danych jest czústo blokowana na wiele milisekund w trakcie operacji odczytu danych w systemie plików i podczas wykonywania zapytania. Zebrane dane sæ wystarczajæce dla Stefana. Nastúpne pytanie brzmi: dlaczego? Dane statystyczne dotyczæce wydajnoħci dysku wskazujæ na wysokie obciæľenie. Stefan stosuje obciæľenie zgodne z typowæ charakterystykæ obciæľenia, co ma na celu dalsze zrozumienie problemu. Za pomocæ polecenia iostat mierzy wartoħci IOPS, przepustowoħè, ħrednie opóļnienie dyskowych operacji wejħcia-wyjħcia oraz wspóđczynnik operacji odczytu i zapisu. Na podstawie zebranych danych oblicza ħredniæ wielkoħè operacji wejħcia-wyjħcia i oszacowuje sposób dostúpu: losowy czy sekwencyjny. W celu uzyskania wiúkszej iloħci informacji szczegóđowych Stefan moľe przeprowadziè monitorowanie na poziomie dyskowych operacji wejħcia-wyjħcia. Jednak jest zadowolony z uzyskanych dotæd danych oraz przekonany, ľe problem nie dotyczy dysków. Stefan umieszcza dodatkowe informacje w zgđoszeniu, wskazuje przeprowadzone operacje sprawdzajæce, a nawet przedstawia zrzuty ekranu pokazujæce polecenia uľyte do analizy dysków. Wedđug niego obciæľenie dysków jest wysokie, co oznacza wiúksze opóļnienie operacji wejħcia-wyjħcia, a tym samym wydđuľenie wykonywania zapytaē. Wydaje siú jednak, ľe dyski dziađajæ normalnie jak na dany poziom obciæľenia. Koēczy pytaniem wskazujæcym najprostsze wyjaħnienie: czy wzrosđo obciæľenie bazy danych? Zespóđ bazy danych odpowiada negatywnie — podawany przez narzúdzie AcmeMon wspóđczynnik zapytaē pozostaje niezmienny. To jest zgodne z wczeħniejszymi odkryciami Stefana, czyli niezmiennym poziomem wykorzystania procesora. Stefan zastanawia siú, co jeszcze moľe doprowadziè do wiúkszego obciæľenia dyskowych operacji wejħcia-wyjħcia bez zauwaľalnego wzrostu zapotrzebowania na moc procesora, i rozmawia na ten temat z kolegami. Jeden z nich sugeruje fragmentacjú systemu plików, której naleľy siú spodziewaè, gdy system plików búdzie zajúty niemalľe w 100%. Stefan sprawdza ten trop i przekonuje siú, ľe zajútoħè systemu plików wynosi okođo 30%.

44

Rozdział 1



Wprowadzenie

Stefan ma ħwiadomoħè, ľe moľe przeprowadziè analizú dræľæcæ w celu okreħlenia powodu wykonywania dyskowych operacji wejħcia-wyjħcia, ale taka analiza búdzie wymagađa poħwiúcenia duľej iloħci czasu. Wykorzystujæc wiedzú z zakresu stosu wejħcia-wyjħcia w jædrze, próbuje znaleļè inne przyczyny, które moľna najpierw szybko sprawdziè. Przypomina sobie, ľe dyskowe operacje wejħcia-wyjħcia sæ w duľej mierze spowodowane brakiem odpowiednich danych w buforze systemu plików. Stefan sprawdza wspóđczynnik trafnoħci w buforze systemu plików i okazuje siú, ľe trafnoħè jest na poziomie 91%. Ta wartoħè wydaje siú cađkiem wysoka (dobra), ale brakuje danych historycznych, wzglúdem których moľna jæ porównaè. Loguje siú wiúc do innych serwerów baz danych o podobnym obciæľeniu i przekonuje siú, ľe tam poziom trafnoħci przekracza 97%. Ponadto ustala, ľe w pozostađych serwerach bufor systemu plików jest znacznie wiúkszy. W wyniku skierowania uwagi na wielkoħè bufora systemu plików i uľycie pamiúci serwera odkrywa coħ, co najwyraļniej zostađo wczeħniej przeoczone: projekt opracowywanej aplikacji zuľywa ogromnæ iloħè pamiúci, mimo ľe nie znajduje siú ona jeszcze pod obciæľeniem produkcyjnym. Wspomniana pamiúè zostađa zabrana z zasobów przeznaczonych dla bufora systemu plików. Spadđ wiúc poziom wykorzystania bufora, co z kolei zwiúkszyđo liczbú dyskowych operacji wejħcia-wyjħcia i to „uderzyđo” w produkcyjny serwer bazy danych. Stefan kontaktuje siú z zespođem pracujæcym nad aplikacjæ, prosi o jej wyđæczenie i przeniesienie do innego serwera, wskazujæc przy tym problemy zwiæzane z bazæ danych. Po speđnieniu proħby przez zespóđ Stefan obserwuje w narzúdziu AcmeMon zmniejszenie poziomu wykorzystania dysku, poniewaľ bufor systemu plików powróciđ do swojej wielkoħci poczætkowej. Liczba wolno wykonywanych zapytaē spada do zera, a Stefan moľe zamknæè zgđoszenie i oznaczyè problem jako rozwiæzany.

1.9.2. Zmiana oprogramowania Patrycja jest inľynierem wydajnoħci i skalowalnoħci w mađej firmie, odpowiada za wszystkie dziađania majæce zwiæzek z wydajnoħciæ. Programiħci aplikacji opracowali nowæ waľnæ funkcjú, ale nie byli pewni, czy jej wprowadzenie búdzie miađo jakikolwiek negatywny wpđyw na wydajnoħè. Patrycja zadecydowađa o przeprowadzeniu testów nieregresywnych nowej wersji aplikacji, zanim zostanie wdroľona w ħrodowisku produkcyjnym. (Testy nieregresywne to dziađania majæce na celu potwierdzenie, ľe zmiana oprogramowania lub sprzútu nie spowoduje spadku wydajnoħci. Stæd wziúđa siú nazwa — testy nieregresywne). Do celów testowych Patrycja wykorzystađa bezczynny serwer i zaczúđa szukaè symulatora obciæľenia generowanego przez klienta. Zespóđ odpowiedzialny za aplikacjú jakiħ czas temu opracowađ tego rodzaju symulator, choè nie byđ on pozbawiony ograniczeē i bđúdów. Mimo wszystko Patrycja zdecydowađa siú na jego uľycie, ale chciađa uzyskaè potwierdzenie, ľe generowane obciæľenie odpowiada produkcyjnemu. Skonfigurowađa serwer w sposób odpowiadajæcy bieľæcej konfiguracji serwera produkcyjnego, a nastúpnie uruchomiđa symulator obciæľenia przeznaczony do innego systemu. Obciæľenie generowane przez klienta moľna scharakteryzowaè przez analizú dziennika zdarzeē dostúpu. Firma opracowađa nawet odpowiednie narzúdzie do tego celu, którego Patrycja uľyđa. Kilka razy dziennie uruchamiađa wspomniane narzúdzie

1.9. Studium przypadku

45

wzglúdem dziennika zdarzeē w serwerze produkcyjnym i porównywađa obciæľenie. Wydawađo siú, ľe symulator generowađ obciæľenie porównywalne ze ħrednim obciæľeniem wystúpujæcym w serwerze produkcyjnym, ale nie brađ pod uwagú odchyleē. Patrycja zanotowađa to i kontynuowađa analizú. Na tym etapie Patrycja wiedziađa, jakie moľe przyjæè strategie. Zdecydowađa siú na najđatwiejszæ: zwiúkszanie obciæľenia generowanego przez symulator klienta aľ do osiægniúcia wartoħci granicznej. Symulator klienta moľna skonfigurowaè do wykonywania wskazanej liczby ľædaē w ciægu sekundy — wartoħciæ domyħlnæ jest 1000, której to wartoħci Patrycja uľywađa juľ wczeħniej. Zdecydowađa siú na rozpoczúcie testu od liczby 100 ľædaē i zwiúkszanie obciæľenia o kolejne 100 aľ do osiægniúcia wartoħci granicznej. Po kaľdej operacji zwiúkszenia obciæľenia test miađ byè wykonywany przez minutú. Przygotowađa wiúc odpowiedni skrypt powđoki odpowiedzialny za przeprowadzenie testu. Skrypt ten zapisywađ w pliku wyniki testu, na podstawie których inne narzúdzia mogđyby generowaè wykresy Podczas obciæľenia serwera Patrycja przeprowadzađa aktywne testy wydajnoħci w celu okreħlenia czynników, które mogæ stanowiè ograniczenie. Zasoby i wætki serwera pozostawađy w wiúkszoħci bezczynne. Symulator klienta pokazađ, ľe liczba ukoēczonych ľædaē zaczúđa spadaè na poziomie okođo 700 ľædaē na sekundú. Patrycja uruchomiđa nowæ wersjú oprogramowania i powtórzyđa test. W tym przypadku ponownie po osiægniúciu puđapu 700 na sekundú liczba ukoēczonych ľædaē zaczúđa spadaè. Patrycja zaczúđa analizowaè serwer w celu ustalenia czynników ograniczajæcych, ale nie mogđa ľadnego znaleļè. Wygenerowađa wiúc wykresy pokazujæce wspóđczynnik ľædaē ukoēczonych do obciæľenia, aby w ten sposób wizualnie przedstawiè profil skalowalnoħci. W obu przypadkach zauwaľyđa gwađtowny, nagđy spadek moľliwoħci skalowalnoħci. Wprawdzie wydawađo siú, ľe obie wersje oprogramowania majæ podobne charakterystyki wydajnoħci, ale Patrycja byđa rozczarowana brakiem moľliwoħci identyfikacji czynnika ograniczajæcego, który powodowađ nagđy spadek moľliwoħci skalowalnoħci. Wiedziađa, ľe sprawdziđa jedynie zasoby serwera, a czynnik ograniczajæcy mógđ byè spowodowany przez problem w logice aplikacji. Mógđ teľ znajdowaè siú w innym miejscu: w sieci lub symulatorze klienta. Patrycja zaczúđa siú zastanawiaè, czy nie naleľy zastosowaè innego podejħcia, na przykđad przeprowadziè stađæ liczbú operacji, a nastúpnie scharakteryzowaè uľycie zasobów (procesora, dyskowych operacji wejħcia-wyjħcia, sieciowych operacji wejħcia-wyjħcia). W ten sposób moľna przygotowaè charakterystykú pod kætem pojedynczego ľædania klienta. Wzglúdem bieľæcej i nowej wersji oprogramowania uruchomiđa wiúc symulator generujæcy obciæľenie w wysokoħci 700 ľædaē na sekundú i zaczúđa mierzyè zuľycie zasobów. Bieľæca wersja oprogramowania wykorzystywađa 32 procesory na ħrednim poziomie 20% dla danego obciæľenia. Z kolei nowa wersja oprogramowania tú samæ liczbú procesorów wykorzystywađa na ħrednim poziomie 30% przy takim samym obciæľeniu. Wydawađo siú, ľe nowa wersja oprogramowania rzeczywiħcie jest regresywna, poniewaľ zuľywa wiúcej zasobów procesora. Patrycja zainteresowađa siú wartoħciæ granicznæ, która wyniosđa 700 ľædaē na sekundú. Zwiúkszyđa wiúc obciæľenie, a nastúpnie zaczúđa analizowaè wszystkie komponenty znajdujæce siú na ħcieľce danych, czyli miúdzy innymi sieè, system klienta oraz generator obciæľenia powodowanego przez klienta. Przeprowadziđa teľ analizú dræľæcæ serwera

46

Rozdział 1



Wprowadzenie

i oprogramowania klienta. Swoje dziađania dokđadnie udokumentowađa i dođæczyđa zrzuty ekranu. Aby przeanalizowaè oprogramowanie klienta, sprawdziđa stan wætków i przekonađa siú, ľe aplikacja wykorzystuje tylko jeden wætek. Dlatego teľ przez cađy przeznaczony dla niego czas wætek dziađađ w procesorze. To przekonađo jæ, ľe wætek jest czynnikiem ograniczajæcym w przeprowadzonym przez niæ teħcie. W formie eksperymentu oprogramowanie klienta uruchomiđa jednoczeħnie w róľnych systemach klienckich. W ten sposób osiægnúđa wykorzystanie procesora w serwerze w 100% zarówno w bieľæcej, jak i nowej wersji oprogramowania. Wersja bieľæca osiægnúđa 3500 ľædaē na sekundú, podczas gdy nowa 2300 ľædaē na sekundú, co okazađo siú zgodne z wczeħniejszymi spostrzeľeniami dotyczæcymi zuľycia zasobów. Patrycja poinformowađa programistów aplikacji o regresji w nowej wersji oprogramowania i rozpoczúđa profilowanie uľycia procesora, aby zrozumieè, skæd wziúđa siú regresja. Która ħcieľka kodu jest odpowiedzialna za regresjú? Zwróciđa uwagú, ľe przetestowane zostađo ħrednie obciæľenie produkcyjne i ľe nie uwzglúdniono odchyleē. Patrycja zgđosiđa takľe bđæd polegajæcy na tym, ľe generator obciæľenia powodowanego przez klienta wykorzystuje tylko jeden wætek, co stađo siú wæskim gardđem.

1.9.3. Co dalej? Znacznie dokđadniejsze przykđady znajdziesz w rozdziale 13., zatytuđowanym „Studium przypadku”. Udokumentowađem w nim sposób, w jaki rozwiæzađem pewien problem dotyczæcy wydajnoħci przetwarzania w chmurze. W rozdziale 2. zamieszczono wprowadzenie do metodologii uľywanych podczas analizy wydajnoħci. Natomiast w kolejnych rozdziađach przedstawiono niezbúdnæ wiedzú i specyfikú.

2 Metodologia

Podstawowym bđúdem jest podawanie teorii, zanim uzyska siú dane. Niepostrzeľenie zaczyna siú dostosowywaè fakty, by zgadzađy siú z teoriami, zamiast próbowaè stworzyè teoriú, która byđaby zgodna z faktami. — Sherlock Holmes w opowiadaniu Niezwykđa kobieta1, napisanym przez sir Arthura Conan Doyle’a Kiedy stajesz przed skomplikowanym i niewystarczajæco wydajnie dziađajæcym systemem, wtedy pierwsze wyzwanie dotyczy ustalenia miejsca, w którym naleľy rozpoczæè analizú, okreħlenia danych do zebrania oraz sposobu ich analizy. Jak wspomniađem w rozdziale 1., problemy zwiæzane z wydajnoħciæ mogæ mieè ļródđo praktycznie wszúdzie, miúdzy innymi w oprogramowaniu, sprzúcie oraz dowolnym komponencie znajdujæcym siú na ħcieľce danych. Analitykowi badajæcemu wydajnoħè metodologie mogæ pomóc w wyborze odpowiedniego podejħcia do analizy skomplikowanych systemów, na przykđad przez wskazanie punktu wyjħcia i kroków, jakie naleľy podjæè w celu zlokalizowania i przeanalizowania problemów. Poczætkujæcym analitykom metodologia wskazuje miejsce, w którym warto rozpoczæè analizú, a takľe kolejne kroki do wykonania. Z kolei bardziej doħwiadczonym lub ekspertom metodologia moľe sđuľyè w charakterze listy rzeczy do zrobienia i tym samym zagwarantowaè, ľe ľadne szczegóđy nie zostanæ pominiúte. Analitycy definiujæ 1

Inny tytuđ tego opowiadania to Skandal w Bohemii — przyp. tđum. 47

48

Rozdział 2



Metodologia

metody oceny i potwierdzania odkryè oraz identyfikacji najwiúkszych problemów zwiæzanych z wydajnoħciæ. Ten rozdziađ skđada siú z trzech wymienionych poniľej czúħci: 





Tđo. W tej czúħci znajdziesz terminologiú, podstawowe modele, kluczowe koncepcje dotyczæce wydajnoħci i perspektywy. Metodologia. W czúħci drugiej przeanalizujemy metodologie analizy wydajnoħci, zarówno obserwacyjne, jak i eksperymentalne. Ponadto zajmiemy siú modelowaniem i planowaniem pojemnoħci. Metryki. Kolejna czúħè búdzie poħwiúcona danym statystycznym dotyczæcym wydajnoħci, jak równieľ monitorowaniu i wizualizacji.

Wiele wprowadzonych tutaj metodologii búdzie znacznie dokđadniej omówionych w kolejnych rozdziađach, a ħciħlej mówiæc, w odpowiednich podrozdziađach znajdujæcych siú w rozdziađach od 5. do 10.

2.1. Terminologia W tym podrozdziale wymieniono kluczowe okreħlenia stosowane w analizie wydajnoħci systemów. W kolejnych rozdziađach znajdziesz jeszcze inne okreħlenia, takľe przedstawione w tym miejscu, z tym ľe zaprezentowane w róľnych kontekstach. 









IOPS. Liczba przeprowadzanych w ciægu sekundy operacji wejħcia-wyjħcia jest miaræ pokazujæcæ iloħè przekazanych danych. W dyskowych operacjach wejħcia-wyjħcia wartoħè IOPS oznacza iloħè operacji odczytu i zapisu na sekundú. Przepustowoħè. Ta wartoħè wskazuje iloħè wykonanej pracy. Pojúcie to, zwđaszcza w komunikacji, jest uľywane w odniesieniu do szybkoħci przekazywania danych (wyraľanej w bajtach lub bitach na sekundú). W pewnych kontekstach (na przykđad w bazach danych) przepustowoħè moľe oznaczaè liczbú wykonywanych operacji (transakcji lub operacji na sekundú). Czas udzielenia odpowiedzi. To wyraľenie oznacza czas potrzebny do zakoēczenia operacji. Obejmuje czas poħwiúcony na oczekiwanie i ħwiadczenie usđugi (czas obsđugi), a takľe czas potrzebny na przekazanie wyniku operacji. Opóļnienie. Oznacza czas, w którym operacja czeka na przeprowadzenie. W pewnych kontekstach pojúcie to moľe odnosiè siú do cađkowitego czasu operacji, jest odpowiednikiem czasu udzielenia odpowiedzi. Przykđady znajdziesz w podrozdziale 2.3, zatytuđowanym „Koncepcje”. Poziom wykorzystania. W przypadku zasobów ľædanych przez usđugú poziom wykorzystania oznacza stopieē zajútoħci zasobu obliczany na podstawie iloħci czasu, który we wskazanym przedziale czasu byđ poħwiúcony na aktywne wykonywanie zadania. Z kolei dla zasobów dostarczajæcych pamiúci masowej wyraľenie to moľe oznaczaè zuľytæ pojemnoħè (na przykđad wykorzystanæ iloħè pamiúci operacyjnej).

2.2. Modele









49

Nasycenie. Pojúcie to oznacza poziom kolejkowania przez zasób zadaē, które nie mogđy byè wykonane w danej chwili. Wæskie gardđo. W analizie wydajnoħci systemów wæskie gardđo jest zasobem ograniczajæcym wydajnoħè badanego systemu. Wykrywanie i usuwanie wæskich gardeđ w systemach to kluczowe dziađania podejmowane w celu zapewnienia wysokiej wydajnoħci systemów. Obciæľenie robocze. Dane wejħciowe systemu lub generowane obciæľenie. W przypadku bazy danych obciæľeniem roboczym sæ wysyđane przez klientów polecenia i zapytania kierowane do bazy danych. Bufor. Szybki obszar pamiúci masowej pozwalajæcy na buforowanie ograniczonej iloħci danych, aby uniknæè koniecznoħci komunikacji ze znacznie wolniejszæ warstwæ pamiúci masowej. W ten sposób moľna poprawiè wydajnoħè dziađania urzædzenia. Z powodów ekonomicznych bufor jest zwykle mniejszy niľ wolniejsza warstwa pamiúci masowej.

W sđowniczku na koēcu ksiæľki znajdziesz podstawowæ uľywanæ w niej terminologiú.

2.2. Modele Przedstawione w tym podrozdziale proste modele prezentujæ wybrane podstawowe zasady stosowane w analizie wydajnoħci systemów.

2.2.1. Wydajność systemu podczas testu Na rysunku 2.1 pokazano wydajnoħè systemu w czasie wykonywania testu.

Rysunek 2.1. Wydajność systemu podczas testu

Trzeba mieè ħwiadomoħè, ľe wszelkie perturbacje (zakđócenia) mogæ wpđynæè na wynik testu. Dotyczy to perturbacji powodowanych przez zaplanowane dziađania systemu, pozostađych uľytkowników systemu oraz inne obciæľenie. Ļródđo wspomnianych zakđóceē wcale nie musi byè takie oczywiste, do jego ustalenia moľe byè konieczne przeprowadzenie dræľæcej analizy wydajnoħci systemu. To moľe byè szczególnie trudne w pewnych ħrodowiskach przetwarzania w chmurze, w których inna dziađalnoħè (czyli pozostađych tenantów) w fizycznym komputerze nie jest widoczna w analizowanym systemie.

50

Rozdział 2



Metodologia

Kolejna trudnoħè w nowoczesnych ħrodowiskach wiæľe siú z faktem, ľe mogæ byè one utworzone z wielu pođæczonych ze sobæ komponentów sieciowych wymaganych do obsđuľenia obciæľenia generowanego przez dane wejħciowe. Do wspomnianych komponentów zaliczamy urzædzenia sđuľæce do równowaľenia obciæľenia, serwery WWW, serwery baz danych, serwery aplikacji oraz systemy pamiúci masowej. Zwykđa operacja mapowania ħrodowiska moľe pomóc w odkryciu przeoczonych wczeħniej ļródeđ perturbacji. Na potrzeby analizy moľna równieľ przedstawiè ħrodowisko w postaci modelu sieci systemów kolejkowych.

2.2.2. Systemy kolejkowe Pewne komponenty i zasoby moľna modelowaè jako systemy kolejkowe. Przykđad tego rodzaju systemu pokazano na rysunku 2.2.

Rysunek 2.2. Prosty model kolejki

W pewnym zakresie teoria kolejek zostanie wprowadzona w podrozdziale 2.6, noszæcym tytuđ „Modelowanie”. Znajdziesz tam omówienie systemów i sieci systemów kolejkowych.

2.3. Koncepcje W tym podrozdziale przedstawiono najwaľniejsze koncepcje zwiæzane z wydajnoħciæ systemów. Znajomoħè tych koncepcji búdzie niezbúdna podczas lektury pozostađej czúħci ksiæľki. Poruszone w tym podrozdziale tematy zostađy omówione ogólnie. W podrozdziađach poħwiúconych architekturze i analizie, znajdujæcych siú w kolejnych rozdziađach, przedstawiono informacje szczegóđowe dotyczæce specyfiki implementacji omówionych tutaj koncepcji.

2.3.1. Opóźnienie W przypadku niektórych ħrodowisk opóļnienie jest jedynym obszarem, na którym siú koncentrujemy podczas analizy wydajnoħci. Z kolei w innych, obok przepustowoħci, to jeden z najwaľniejszych obszarów analizy.

2.3. Koncepcje

51

Jako przykđad opóļnienia na rysunku 2.3 pokazano transfer sieciowy (taki jak ľædanie HTTP GET), podzielony na komponenty opóļnienia i rzeczywistego przekazywania danych.

Rysunek 2.3. Opóźnienie w połączeniu sieciowym

Opóļnienie oznacza czas poħwiúcony na oczekiwanie, zanim nastæpi przeprowadzenie operacji. W omawianym przykđadzie operacja to ľædanie usđugi sieciowej dotyczæce przekazania danych. Zanim operacja ta búdzie mogđa byè wykonana, system musi poczekaè na nawiæzanie pođæczenia sieciowego, co w przypadku tej konkretnej operacji búdzie opóļnieniem. Czas udzielenia odpowiedzi skđada siú z opóļnienia i rzeczywistego czasu przekazywania danych. Poniewaľ opóļnienie moľna mierzyè z róľnych punktów, bardzo czústo podaje siú miejsce pomiaru. Na przykđad czas wczytania strony internetowej moľe skđadaè siú z trzech róľnych czasów zmierzonych w róľnych miejscach: opóļnienia DNS, opóļnienia pođæczenia TCP oraz czasu przekazywania danych za pomocæ TCP. Opóļnienie DNS odnosi siú do cađej operacji DNS, z kolei opóļnienie pođæczenia TCP — jedynie do fazy inicjalizacji (nawiæzania pođæczenia TCP). Na ogólnym poziomie wszystkie wymienione opóļnienia oraz czas przekazywania danych za pomocæ TCP mogæ byè potraktowane jako opóļnienia dotyczæce zupeđnie czegoħ innego. Na przykđad opóļnieniem moľna okreħliè czas, jaki upđynie od chwili klikniúcia đæcza na stronie internetowej przez uľytkownika do chwili cađkowitego wczytania ľædanej strony, co obejmuje takľe czas potrzebny przeglædarce internetowej na wygenerowanie strony. Poniewaľ opóļnienie jest metrykæ wyraľanæ w wartoħci czasu, istnieje moľliwoħè przeprowadzania róľnych obliczeē. Problemy zwiæzane z wydajnoħciæ moľna oceniaè na podstawie wartoħci opóļnienia, a nastúpnie ustalaè ich rangú, poniewaľ poszczególne problemy zostađy wyraľone za pomocæ tej samej jednostki (czasu). Oczekiwany wzrost szybkoħci równieľ moľna obliczyè dziúki rozwaľeniu, czy opóļnienie jest moľliwe do ograniczenia lub cađkowitego wyeliminowania. Tego rodzaju poprawnych obliczeē nie moľna przeprowadziè za pomocæ innej metryki, takiej jak IOPS. Dla porzædku w tabeli 2.1 wymieniono rzúdy jednostek czasu i ich skróty. Jeħli istnieje taka moľliwoħè, metryki innych typów mogæ byè skonwertowane na wartoħci opóļnienia lub czasu, co pozwoli na porównywanie metryk. Jeľeli masz wybór miúdzy 100 sieciowymi operacjami wejħcia-wyjħcia i 50 dyskowymi operacjami wejħcia-wyjħcia, to skæd búdziesz wiedziađ, które zapewniæ lepszæ wydajnoħè? To búdzie skomplikowany wybór, wymagajæcy uwzglúdnienia wielu czynników, takich jak: liczba koniecznych przeskoków sieciowych, wspóđczynnik utraconych pakietów i tym samym ponownie przekazywanych, wielkoħè operacji wejħcia-wyjħcia, rodzaj operacji

52

Rozdział 2



Metodologia

Tabela 2.1. Jednostki czasu Jednostka czasu

Skrót

Współczynnik względem 1 sekundy

Minuta

min

60

Sekunda

s

1

Milisekunda

ms

0,001, czyli 1/1000, inaczej 1∙10–3

Mikrosekunda

μs

0,000001, czyli 1/1 000 000, inaczej 1∙10–6

Nanosekunda

ns

0,000000001, czyli 1/1 000 000 000, inaczej 1∙10–9

Pikosekunda

ps

0,000000000001, czyli 1/1 000 000 000 000, inaczej 1∙10–12

wejħcia-wyjħcia (losowa lub sekwencyjna), typ dysku. Natomiast jeħli porównasz 100 ms cađkowitej sieciowej operacji wejħcia-wyjħcia z 50 ms cađkowitej dyskowej operacji wejħcia-wyjħcia, róľnica búdzie jasna i czytelna.

2.3.2. Skala czasu W porównywaniu wartoħci liczbowych czasu pomocne búdzie posiadanie pewnej wiedzy dotyczæcej czasu i oczekiwaē w zakresie opóļnienia w róľnych ļródđach. Komponenty systemu mogæ dziađaè w zupeđnie odmiennych skalach czasu (rzúdach wielkoħci), co znacznie utrudnia okreħlanie róľnic miúdzy mierzonymi czasami. W tabeli 2.2 przedstawiono przykđadowe opóļnienia, poczæwszy od dotyczæcego czasu dostúpu do rejestru procesora taktowanego z czústotliwoħciæ 3,3 GHz. Aby zademonstrowaè róľnice w skalach stosowanego czasu, w tabeli umieszczono takľe ħredni czas, jaki moľe byè potrzebny do wykonania operacji. Ten czas zostađ przeskalowany do fikcyjnego systemu, w którym czas dostúpu do rejestru (tutaj wynoszæcy 0,3 ns) to jedna, peđna sekunda. Jak moľesz siú przekonaè, skala czasu dla cykli procesora jest naprawdú niewielka. Czas potrzebny ħwiatđu na pokonanie odlegđoħci 0,5 m, czyli prawdopodobnie takiej, jaka dzieli tú stronú ksiæľki od Twojego oka, wynosi okođo 1,7 ns. W takim samym czasie nowoczesny procesor moľe wykonaè piúè cykli i przetworzyè wiele instrukcji. Wiúcej informacji na temat cykli procesora i opóļnienia znajdziesz w rozdziale 6. „Procesory”, natomiast o opóļnieniu dyskowych operacji wejħcia-wyjħcia w rozdziale 9. „Dyski”. Z kolei opóļnienie sieciowe przedstawiono w rozdziale 10. „Sieè”, w którym zamieszczono wiúcej przykđadów.

2.3.3. Kompromisy Powinieneħ mieè ħwiadomoħè istnienia pewnych kompromisów w zakresie wydajnoħci. Na rysunku 2.4 pokazano kompromis typu „wybierz dwa z dobrze, szybko, tanio”, ale z uľyciem terminologii stosowanej w projektach informatycznych.

2.3. Koncepcje

53

Tabela 2.2. Przykład skali czasu w celu pokazania opóźnień w systemie Zdarzenie

Opóźnienie

Wartość przeskalowana

1 cykl procesora.

0,3 ns

1s

Dostęp do pamięci podręcznej pierwszego poziomu.

0,9 ns

3s

Dostęp do pamięci podręcznej drugiego poziomu.

2,8 ns

9s

Dostęp do pamięci podręcznej trzeciego poziomu.

12,9 ns

43 s

Dostęp do pamięci operacyjnej (DRAM, z poziomu procesora).

120 ns

6 min

Dyskowa operacja wejścia-wyjścia w napędzie SSD (pamięć flash).

50 – 150 μs

2 – 6 dni

Dyskowa operacja wejścia-wyjścia w napędzie mechanicznym (typowy dysk twardy).

1 – 10 ms

1 – 12 miesięcy

Internet: przekazanie danych z San Francisco do Nowego Jorku.

40 ms

4 lata

Internet: przekazanie danych z San Francisco do Wielkiej Brytanii.

81 ms

8 lat

Internet: przekazanie danych z San Francisco do Australii.

183 ms

19 lat

Ponowna transmisja pakietu TCP.

1–3s

105 – 317 lat

Ponowne uruchomienie wirtualnego systemu operacyjnego.

4s

423 lata

Przekroczenie czasu ważności polecenia SCSI.

30 s

3000 lat

Ponowne uruchomienie systemu w wirtualizacji sprzętowej.

40 s

4000 lat

Ponowne uruchomienie systemu operacyjnego w fizycznym komputerze.

5 min

32 000 lat

Rysunek 2.4. Kompromis typu „wybierz dwa”

W wielu projektach stawia siú na elementy „na czas” i „niedrogo”, natomiast „wydajnoħè” pozostawia do poprawienia w póļniejszych fazach. Tego rodzaju wybór staje siú problematyczny, gdy wczeħniej podjúte decyzje uniemoľliwiajæ poprawú wydajnoħci. Do wspomnianych decyzji zalicza siú miúdzy innymi wybór nieoptymalnej architektury pamiúci masowej, uľycie júzyka programowania lub systemu operacyjnego, który nie udostúpnia zaawansowanych narzúdzi przydatnych w analizie wydajnoħci itd. Podczas dostosowywania wydajnoħci czústo kompromis dotyczy procesora i pamiúci, poniewaľ pamiúè moľna wykorzystaè do buforowania wyników operacji, a tym samym zmniejszyè obciæľenie procesora. W nowoczesnych systemach, wyposaľonych w duľæ

54

Rozdział 2



Metodologia

liczbú procesorów, zastosowany kompromis moľe przynieħè odwrotny skutek: procesory búdæ poħwiúcaè sporo czasu na kompresjú danych, aby w ten sposób zmniejszyè zuľycie pamiúci. Dostosowanie parametrów bardzo czústo wiæľe siú z kompromisem. Poniľej wymieniono dwa przykđady: 



Wielkoħè rekordu w systemie plików (inaczej wielkoħè bloku). Mniejszy rekord, porównywalny z wielkoħciæ operacji wejħcia-wyjħcia aplikacji, búdzie sprawdzađ siú lepiej w przypadku obciæľenia skđadajæcego siú z losowych operacji wejħcia-wyjħcia. To oznacza znacznie efektywniejsze uľycie bufora systemu plików w czasie dziađania aplikacji. Z kolei wiúkszy rekord poprawi wydajnoħè w przypadku obciæľenia strumieniowego, na przykđad w trakcie tworzenia kopii zapasowej systemu plików. Wielkoħè bufora sieciowego. Mniejszy bufor oznacza spadek zapotrzebowania na pamiúè dla danego pođæczenia, co pomaga podczas skalowania systemu. Z kolei wiúkszy bufor poprawia przepustowoħè sieci.

Wprowadzajæc zmiany w systemie, zwracaj uwagú na wspomniane kompromisy.

2.3.4. Dostrajanie wydajności Dostrajanie wydajnoħci jest najbardziej efektywne, gdy przeprowadza sie je w ħcisđym powiæzaniu z zadaniami, które majæ byè wykonywane w danym systemie. W przypadku obciæľeē powodowanych przez aplikacje oznacza to poszczególne aplikacje. W tabeli 2.3 pokazano przykđadowy stos oprogramowania i moľliwoħci dostrojenia. Tabela 2.3. Przykłady możliwości w zakresie dostrojenia wydajności Warstwa

Możliwości w zakresie dostrojenia wydajności

Aplikacja

Zapytania wykonywane do bazy danych.

Baza danych

Układ tabel bazy danych, indeksów i zastosowane buforowanie.

Wywołania systemowe

Mapowanie pamięci lub operacji odczytu i zapisu, przeprowadzanie synchronicznych lub asynchronicznych operacji wejścia-wyjścia.

System plików

Wielkość rekordu, wielkość bufora, dostrojenie parametrów systemu plików.

Pamięć masowa

Rodzaj macierzy RAID, liczba i typ dysków, dostrojenie parametrów pamięci masowej.

Dostrojenie na poziomie aplikacji umoľliwia eliminacjú lub ograniczenie zapytaē wykonywanych do bazy danych, a tym samym ogromnæ poprawú wydajnoħci, nawet rzúdu 20-krotnoħci. Z kolei dostrojenie na poziomie urzædzenia pamiúci masowej moľe wyeliminowaè lub poprawiè opóļnienie zwiæzane z operacjami wejħcia-wyjħcia, ale kosztem wykonywania kodu na wysokim poziomie, co moľe poprawiè wydajnoħè dziađania aplikacji wyraľonæ jedynie procentowo, na przykđad w 20%.

2.3. Koncepcje

55

Istnieje jeszcze inny powód wyszukiwania na poziomie aplikacji moľliwoħci znacznej poprawy wydajnoħci. W wielu obecnych ħrodowiskach stosowane sæ szybkie i krótkie fazy implementacji funkcji i funkcjonalnoħci. Dlatego teľ podczas pracy nad aplikacjæ oraz w fazie jej testowania nacisk kđadzie siú na poprawnoħè, a tylko niewiele czasu (o ile w ogóle) poħwiúca siú na sprawdzenie wydajnoħci oraz optymalizacjú oprogramowania przed jego wdroľeniem w systemie produkcyjnym. Tego rodzaju operacje przeprowadza siú dopiero w póļniejszym czasie, gdy niewystarczajæca wydajnoħè staje siú problemem. Wprawdzie aplikacja moľe stanowiè poziom najefektywniejszy do dostrajania, ale jednoczeħnie nie musi byè to najbardziej efektywny poziom, który moľna wykorzystaè do porównaē. Najlepszym sposobem poznania powodu, dla którego zapytania do bazy danych sæ wolno wykonywane, búdzie sprawdzenie czasu wykonywania tej operacji przez procesor bædļ teľ operacji wejħcia-wyjħcia wykonywanych przez system plików lub dysk. Informacje te moľna uzyskaè dziúki narzúdziom monitorowania oferowanym przez system operacyjny. W wielu ħrodowiskach (zwđaszcza przetwarzania w chmurze) aplikacje sæ nieustannie usprawniane, a zmiany w oprogramowaniu systemów produkcyjnych sæ wprowadzane w kaľdym tygodniu lub nawet codziennie. Ogromne zmiany w wydajnoħci, miúdzy innymi na skutek poprawek i regresji, sæ odkrywane bardzo czústo, gdy zmianie ulega kod aplikacji. W tego rodzaju ħrodowiskach moľliwoħè dostrojenia systemu operacyjnego i monitorowania moľna bardzo đatwo przeoczyè. Pamiútaj, ľe analiza wydajnoħci systemu operacyjnego ma na celu takľe identyfikacjú problemów na poziomie aplikacji, a nie jedynie problemów dotyczæcych systemu operacyjnego, które w pewnych przypadkach moľna đatwiej wyszukaè niľ w samej aplikacji.

2.3.5. Poziomy trafności Poszczególne organizacje i ħrodowiska majæ odmienne wymagania dotyczæce wydajnoħci. Byè moľe dođæczyđeħ do organizacji, gdzie normæ jest przeprowadzanie znacznie bardziej drobiazgowej analizy niľ ta, z któræ siú dotychczas spotykađeħ. O moľliwoħci prowadzenia tak dokđadnej analizy mogđeħ nawet nie wiedzieè. W innej sytuacji podstawowa analiza moľe byè uznawana za zaawansowanæ, czyli za takæ, która de facto nigdy wczeħniej nie byđa przeprowadzana (dobra wiadomoħè jest wówczas nastúpujæca: to búdzie đatwe zadanie). Wymienione wczeħniej sytuacje oczywiħcie nie oznaczajæ, ľe pewne organizacje przeprowadzajæ analizú prawidđowo, a inne bđúdnie. Wszystko zaleľy od stopy zwrotu inwestycji (ang. Return on Investment, ROI) oraz oczekiwanej wydajnoħci. Organizacje posiadajæce ogromne centra danych lub ħrodowiska przetwarzania w chmurze mogæ potrzebowaè inľynierów wydajnoħci, którzy búdæ analizowaè dosđownie wszystko, miúdzy innymi wewnútrzne dziađanie jædra i wartoħci liczników wydajnoħci procesora. Ponadto w tego rodzaju organizacjach bardzo czústo stosowane jest monitorowanie dynamiczne. Poza tym mogæ byè tworzone modele wydajnoħci oraz opracowywane poprawne prognozy dotyczæce polepszenia wydajnoħci. Mađe firmy najczúħciej majæ czas jedynie na ogólne sprawdzenie i pokđadajæ zaufanie w opracowanych przez firmy trzecie narzúdziach monitorowania, które wykorzystujæ do sprawdzania wydajnoħci i generowania ewentualnych komunikatów ostrzeľeē.

56

Rozdział 2



Metodologia

W najbardziej ekstremalnych ħrodowiskach, na przykđad na gieđdach papierów wartoħciowych, wydajnoħè i opóļnienie majæ znaczenie krytyczne, a wiúc koszty i wysiđek w celu zapewnienia maksymalnej wydajnoħci sæ jak najbardziej uzasadnione. Na przykđad szacowana na okođo 300 milionów dolarów operacja pođoľenia nowego kabla na dnie Atlantyku, đæczæcego gieđdy w Nowym Jorku i Londynie, ma spowodowaè, ľe opóļnienie transmisji spadnie o 6 ms (patrz odwođanie [1] na koēcu rozdziađu).

2.3.6. Rekomendacje w danym momencie Charakterystyka wydajnoħci ħrodowiska ulega nieustannej zmianie, na co wpđywa dodawanie kolejnych uľytkowników, nowego sprzútu, a takľe uaktualnianie oprogramowania i firmware’ów. Ħrodowisko ograniczone obecnie infrastrukturæ sieci o przepustowoħci 1 Gb/s moľe po zmianie sieci na oferujæcæ przepustowoħè 10 Gb/s zaczæè odczuwaè ograniczenia zwiæzane z wydajnoħciæ dysku lub procesora. Rekomendacje z zakresu wydajnoħci, w szczególnoħci wartoħci dostrajanych parametrów, sæ prawidđowe jedynie w okreħlonym momencie. Rozwiæzanie zaproponowane przez eksperta zajmujæcego siú wydajnoħciæ i najlepsze w danym tygodniu w kolejnym moľe okazaè siú nietrafione ze wzglúdu na uaktualnienie oprogramowania, sprzútu lub dodanie kolejnych uľytkowników. Znalezione w internecie wartoħci dostrajanych parametrów mogæ czasami przynieħè pewnæ poprawú wydajnoħci. Z drugiej strony, jeħli nie uwzglúdniajæ specyfiki uľywanego przez Ciebie sprzútu lub obciæľenia, skutkiem moľe byè spadek wydajnoħci. Inne moľliwoħci: wspomniane wartoħci byđy wđaħciwe wczeħniej, ale juľ nie w danym momencie, bædļ teľ byđy odpowiednie jako tymczasowe rozwiæzanie problemu powodowanego przez bđæd w oprogramowaniu, który zostađ usuniúty w kolejnych wersjach oprogramowania. Zaczyna to przypominaè sytuacjú, w której ktoħ siúga po lekarstwa zapisane innej osobie! Leki te mogæ byè nieodpowiednie dla siúgajæcego po nie, przeterminowane lub przeznaczone do zaľywania jedynie przez krótki czas. Przeglædanie rekomendacji znalezionych w internecie moľe byè uľyteczne, poniewaľ pozwala sprawdziè, jakie parametry moľna dostrajaè i jak to trzeba byđo postúpowaè w przeszđoħci. Nastúpnie zadanie polega na ustaleniu, czy znalezione wartoħci mogæ byè zastosowane w uľywanym systemie lub pod bieľæcym obciæľeniem oraz jak je wprowadziè. Mimo wszystko nadal moľna pominæè waľny parametr, jeħli inni nie musieli go dostrajaè w przeszđoħci lub dostrajali, ale nie podzielili siú ze ħwiatem swoimi doħwiadczeniami na tym polu.

2.3.7. Obciążenie kontra architektura Dziađanie aplikacji moľe byè wysoce niezadowalajæce ze wzglúdu na problem w konfiguracji oprogramowania i sprzútu, w którym jest ona uruchamiana — ogólnie jego architektury. Jednak aplikacja moľe dziađaè inaczej niľ oczekujemy po prostu z powodu zbyt duľego obciæľenia, które prowadzi do kolejkowania zadaē i powstawania duľych opóļnieē. Powiæzanie architektury i obciæľenia pokazano na rysunku 2.5.

2.3. Koncepcje

57

Rysunek 2.5. Obciążenie kontra architektura

Jeľeli analiza architektury wskazuje na kolejkowanie zadaē i jednoczeħnie na brak kđopotów z ich wykonywaniem, to problem moľe byè zwiæzany ze zbyt duľym obciæľeniem. W ħrodowisku przetwarzania w chmurze oznacza to potrzebú uľycia wiúkszej liczby wúzđów, aby obsđuľyè bieľæcy poziom zadaē. Na przykđad problemem zwiæzanym z architekturæ moľe byè opracowanie aplikacji w taki sposób, aby uľywađa tylko jednego wætku. W takim przypadku procesor jest obciæľony wykonywaniem zadaē, kolejne zadania sæ kolejkowane, podczas gdy pozostađe procesory w komputerze pozostajæ bezczynne. Tutaj wydajnoħè jest ograniczona przez architekturú aplikacji (jednowætkowa). Na problem dotyczæcy obciæľenia wskazuje sytuacja, gdy aplikacja wielowætkowa w peđni wykorzystuje wszystkie dostúpne procesory, a mimo to nadal musi kolejkowaè zadania. W tym przypadku czynnikiem ograniczajæcym wydajnoħè jest dostúpna pojemnoħè procesora. Ujmujæc rzecz inaczej, obciæľenie jest wiúksze niľ moľe byè w wypadku obciæľenia przez wszystkie dostúpne procesory.

2.3.8. Skalowalność Wydajnoħè systemu pod coraz wiúkszym obciæľeniem wskazuje na jego skalowalnoħè. Na rysunku 2.6 pokazano typowy profil przepustowoħci wraz ze wzrostem obciæľenia systemu. Przez pewien okres moľna zauwaľyè istnienie skalowalnoħci liniowej. Po osiægniúciu punktu oznaczonego na wykresie kropkowanæ liniæ coraz wiúksza rywalizacja o zasoby komputera negatywnie wpđywa na wydajnoħè dziađania systemu. Ten punkt moľna okreħliè mianem na kolanach — to jest granica miúdzy dwoma profilami. Po przekroczeniu wymienionego punktu, wraz z coraz wiúkszæ rywalizacjæ o zasoby, profil odbiega od skalowalnoħci liniowej. Ostatecznie obciæľenie zwiæzane z wiúkszæ rywalizacjæ i koherencjæ powoduje, ľe wykonywana jest mniejsza iloħè zadaē i przepustowoħè spada. Wspomniany punkt moľe wystæpiè wtedy, gdy wykorzystanie komponentu osiægnie 100% — to búdzie punkt nasycenia. Moľe on równieľ pojawiè siú, gdy komponent nie osiægnie jeszcze 100% nasycenia, kolejkowanie zacznie pojawiaè siú czústo i stanie siú istotnym czynnikiem.

58

Rozdział 2



Metodologia

Rysunek 2.6. Przepustowość kontra obciążenie

Oto przykđad systemu, w którym wystúpuje tego rodzaju profil. Mamy aplikacjú przeznaczonæ do powaľnych obliczeē, a dodatkowe obciæľenie pojawia siú w postaci kolejnych wætków. Gdy poziom wykorzystania procesora osiægnie 100%, wydajnoħè zacznie spadaè, poniewaľ procesor búdzie musiađ kolejkowaè zadania, co wiæľe siú z pewnym opóļnieniem. Po osiægniúciu maksymalnej wydajnoħci, przy 100-procentowym poziomie wykorzystania, przepustowoħè zacznie spadaè wraz z pojawieniem siú kolejnego wætku — to spowoduje wiúcej operacji przeđæczania kontekstu, a tym samym wiúksze zuľycie zasobów procesora, co oznacza mniejszæ liczbú rzeczywiħcie wykonanych zadaē. Ten sam wykres otrzymamy po zastæpieniu sđowa „obciæľenie” na osi X nazwæ zasobu, na przykđad rdzeniami procesora. Wiúcej informacji na ten temat znajdziesz w podrozdziale 2.6, noszæcym tytuđ „Modelowanie”. Degradacjú wydajnoħci w przypadku skalowalnoħci nieliniowej (z uwzglúdnieniem ħredniego czasu udzielania odpowiedzi, czyli opóļnienia) pokazano na rysunku 2.7 (patrz odwođanie [Cockcroft 95] na koēcu rozdziađu).

Rysunek 2.7. Degradacja wydajności

Im dđuľszy czas udzielania odpowiedzi, tym gorzej. Z takim profilem szybkiej degradacji moľemy siú spotkaè w przypadku wykorzystania pamiúci operacyjnej, gdy system zacznie korzystaè z pliku wymiany (lub przestrzeni wymiany), aby uzupeđniè braki w rzeczywistej pamiúci. Natomiast z profilem wolnej degradacji moľna siú spotkaè wtedy, gdy wykorzystywana jest cađa moc obliczeniowa procesora.

2.3. Koncepcje

59

Innym przykđadem szybkiej degradacji sæ dyskowe operacje wejħcia-wyjħcia. Wraz ze wzrostem obciæľenia (i tym samym poziomu wykorzystania dysku) dyskowe operacje wejħcia-wyjħcia prawdopodobnie búdæ kolejkowane czúħciej niľ inne operacje wejħcia-wyjħcia. Bezczynna macierz skđadajæca siú z mechanicznych dysków twardych moľe mieè czas udzielenia odpowiedzi na poziomie 1 ms, natomiast po wzroħcie obciæľenia czas ten moľe siú wydđuľyè do 10 ms. Model takiej sytuacji znajdziesz w punkcie 2.6.5, w którym pokazano wykorzystanie zasobów na poziomie 60%. Skalowalnoħè liniowa czasu udzielenia odpowiedzi moľe wystúpowaè, jeħli w przypadku braku zasobów aplikacja zaczyna zgđaszaè bđúdy, zamiast kolejkowaè zadania. Na przykđad serwer WWW moľe zwróciè kod bđúdu 503 wskazujæcego na niedostúpnoħè usđugi, zamiast dodawaè nowe ľædania do kolejki. W ten sposób dla ľædaē moľliwych do wykonania czas udzielenia odpowiedzi búdzie stađy.

2.3.9. Znane niewiadome Powracajæc do cytatu przedstawionego na poczætku ksiæľki, naleľy stwierdziè, ľe pojúcia znane wiadome, znane niewiadome i nieznane niewiadome majæ istotne znaczenie na polu wydajnoħci. Podziađ prezentuje siú nastúpujæco — dla kaľdego pojúcia przedstawiono przykđady przydatne z punktu widzenia analizy wydajnoħci systemów: 





Znane wiadome. To sæ rzeczy, o których wiesz. Masz ħwiadomoħè, ľe trzeba sprawdziè metryki wydajnoħci, a takľe znasz ich wartoħci bieľæce. Na przykđad zdajesz sobie sprawú z koniecznoħci sprawdzenia poziomu wykorzystania procesora i doskonale wiesz, ľe ħrednio wynosi on 10%. Znane niewiadome. To sæ rzeczy, o których wiesz, ľe ich nie znasz. Masz ħwiadomoħè koniecznoħci sprawdzenia metryki lub istnienia podsystemu, ale jeszcze go nie zaobserwowađeħ. Na przykđad wiesz o moľliwoħci uľycia profilowania do sprawdzenia tego, co wykorzystuje moc procesora, ale jeszcze tego nie zrobiđeħ. Nieznane niewiadome. To sæ rzeczy, o których nie wiesz, ľe powinieneħ je znaè. Na przykđad moľesz nawet nie wiedzieè, ľe przerwania generowane przez urzædzenia mogæ mieè ogromny wpđyw na wykorzystanie mocy procesora, a wiúc wspomnianych przerwaē nie búdziesz sprawdzaè.

Wydajnoħè to taka dziedzina, w której „im wiúcej wiesz, tym tak naprawdú wiesz mniej”. Moľna w tym miejscu przywođaè nastúpujæcæ reguđú: im lepiej poznasz dany system, tym mniejszej liczby nieznanych niewiadomych jesteħ ħwiadom i stajæ siú one wówczas znanymi niewiadomymi, które musisz sprawdziè.

2.3.10. Metryki Metryki wydajnoħci to dane statystyczne wygenerowane przez system operacyjny, aplikacje lub inne narzúdzia zapewniajæce moľliwoħè pomiaru interesujæcej nas aktywnoħci. Pod kætem analizy wydajnoħci i monitorowania wspomniane dane statystyczne sæ prezentowane liczbowo w powđoce lub graficznie za pomocæ wizualizacji.

60

Rozdział 2



Metodologia

Najczúħciej stosowane rodzaje metryk wydajnoħci systemu obejmujæ: 

IOPS — liczba operacji wejħcia-wyjħcia wykonywanych w ciagu sekundy,



przepustowoħè — liczba operacji lub ich wielkoħè w ciægu sekundy,



poziom wykorzystania,



opóļnienie.

Poziom uľycia przepustowoħci zaleľy od kontekstu. Przepustowoħè w bazie danych jest najczúħciej mierzona liczbæ zapytaē lub ľædaē (operacji) w ciægu sekundy. Z kolei przepustowoħè sieci wskazuje liczbú bitów lub bajtów (wielkoħè) danych przekazywanych w ciægu sekundy. IOPS jest miaræ przepustowoħci, ale jedynie dla operacji wejħcia-wyjħcia (odczytu i zapisu). Warto przypomnieè ponownie, ľe kontekst ma znaczenie i przedstawione definicje mogæ byè inne.

Obciążenie Metryka wydajnoħci wiæľe siú z pewnym kosztem, poniewaľ cykle procesora muszæ byè poħwiúcone na zebranie i przechowywanie wartoħci metryki. W ten sposób powstaje obciæľenie, które moľe mieè negatywny wpđyw na mierzonæ wydajnoħè analizowanego systemu. Nosi to nazwú efektu obserwatora. (Bardzo czústo jest mylony z zasadæ nieoznaczonoħci Heisenberga, która mówi o ograniczeniach dokđadnoħci pomiaru pewnych par wartoħci fizycznych, na przykđad pođoľenia i przyħpieszenia).

Kwestie Kuszæce jest przyjúcie zađoľenia, ľe twórca oprogramowania dostarcza metryk, które búdæ doskonale wybrane, pozbawione bđúdów, zapewniajæce dokđadny obraz sytuacji. W rzeczywistoħci metryki mogæ wprowadzaè zamieszanie, byè skomplikowane, zawodne, nieodpowiednie, a nawet po prostu zđe (ze wzglúdu na zawarte w nich bđúdy). Czasami zdarza siú, ľe metryka jest prawidđowa w pewnej wersji oprogramowania, ale nie zostaje uaktualniona w celu odzwierciedlenia nowo dodanego kodu i ħcieľek kodu. Wiúcej informacji dotyczæcych problemów z metrykami znajdziesz w podrozdziale 4.6 rozdziađu 4., zatytuđowanego „Narzúdzia monitorowania”.

2.3.11. Poziom wykorzystania Termin poziom wykorzystania jest czústo stosowany w kontekħcie systemów operacyjnych w celu wskazania poziomu uľycia urzædzenia, na przykđad procesora lub dysku twardego. Wspomniane wykorzystanie moľe byè mierzone na podstawie czasu lub pojemnoħci.

2.3. Koncepcje

61

Poziom wykorzystania na podstawie czasu Wykorzystanie na podstawie czasu zostađo formalnie zdefiniowane w teorii kolejek, na przykđad: „ħrednia iloħè czasu, w trakcie którego serwer lub zasoby byđy zajúte” (patrz odwođanie [Gunther 97] na koēcu rozdziađu). Poziom wykorzystania moľna wyraziè nastúpujæcym wzorem: U = B/T

gdzie U oznacza poziom wykorzystania, B — cađkowity czas zajútoħci systemu w trakcie okresu obserwacji wyraľonego w T. Wartoħci dotyczæce „poziomu wykorzystania” moľna równieľ bardzo đatwo pobraè za pomocæ oferowanych przez system operacyjny narzúdzi przeznaczonych do analizy wydajnoħci. Na przykđad w narzúdziu monitorowania dysków o nazwie iostat metryka ta jest prezentowana jako %b (ang. percent busy; procent zajútoħci), a pojúcie lepiej wyraľajæce metrykú to B/T. Metryka poziomu wykorzystania wskazuje poziom zajútoħci komponentu. Gdy wspomniana wartoħè osiægnie 100% dla komponentu, wydajnoħè moľe gwađtownie zmaleè ze wzglúdu na wystúpowanie zjawiska rywalizacji o zasoby. Wówczas moľna skorzystaè z innych metryk, aby potwierdziè, czy dany komponent rzeczywiħcie stađ siú wæskim gardđem w systemie. Pewne komponenty sæ przystosowane do jednoczesnego wykonywania wielu operacji. W takim przypadku osiægniúcie wykorzystania na poziomie 100% nie musi oznaczaè spadku wydajnoħci, poniewaľ komponent moľe akceptowaè kolejne zadania do wykonania. Aby to lepiej zrozumieè, posđuľymy siú przykđadem windy w budynku. Windú uznajemy za wykorzystanæ, gdy porusza siú miúdzy piútrami, a za niewykorzystanæ, gdy pozostaje bezczynna i czeka na pasaľerów do przewiezienia. Jednak winda moľe przewoziè wiúcej pasaľerów, nawet jeħli pracuje bez przerwy, czyli jest wykorzystana w 100%. Dysk twardy wykorzystany w 100% równieľ moľe akceptowaè i przetwarzaè kolejne zadania, na przykđad wskutek buforowania operacji zapisu w pamiúci podrúcznej napúdu, i ukoēczyè je póļniej. Macierze pamiúci masowej czústo sæ wykorzystywane w 100%, poniewaľ stopieē zajútoħci pewnych dysków wynosi 100% czasu, ale sama macierz zawiera wiele bezczynnych dysków, które mogæ akceptowaè kolejne zadania.

Poziom wykorzystania na podstawie pojemności Inna definicja poziomu wykorzystania jest stosowana przez profesjonalistów w branľy IT w kontekħcie planowania pojemnoħci (patrz odwođanie [Wong 97] na koēcu rozdziađu): System lub komponent (na przykđad dysk twardy) charakteryzuje siú okreħlonæ przepustowoħciæ. Na dowolnym poziomie wydajnoħci system lub komponent wykorzystuje tylko pewnæ czúħè pojemnoħci. Czúħè ta jest okreħlana mianem poziomu wykorzystania.

W ten sposób pojúcie wykorzystania zostađo zdefiniowane w kategoriach pojemnoħci, a nie czasu. W takiej sytuacji wykorzystanie dysku w 100% oznacza, ľe nie moľe on akceptowaè kolejnych danych. W definicji opartej na czasie wykorzystanie na poziomie 100% oznacza jedynie zajútoħè danego komponentu przez 100% czasu.

62

Rozdział 2



Metodologia

Pamiútaj, ľe 100% zajútoħci nie oznacza 100% pojemnoħci.

Powróèmy do przedstawionego wczeħniej przykđadu windy: 100% pojemnoħci moľe oznaczaè, ľe winda jest cađkowicie zapeđniona i nie zmieħci siú do niej juľ ľaden pasaľer. W idealnym ħwiecie mielibyħmy moľliwoħè pomiaru obu rodzajów wykorzystania danego urzædzenia. Dlatego teľ byđoby wiadomo, kiedy dysk jest zajúty w 100% i wydajnoħè zaczyna spadaè ze wzglúdu na rywalizacjú o zasoby, a kiedy jest zapeđniony w 100% i nie moľe przyjmowaè kolejnych danych. Niestety, tego rodzaju sytuacja praktycznie nigdy siú nie zdarza. W przypadku dysku twardego konieczna byđaby wiedza dotyczæca dziađaē wykonywanych przez kontroler znajdujæcy siú w dysku i przewidywanie pojemnoħci dysku. Obecnie dostúpne dyski nie oferujæ tego rodzaju informacji. W tej ksiæľce termin poziom wykorzystania zwykle oznacza definicjú opartæ na czasie. Definicja dotyczæca pojemnoħci búdzie stosowana w przypadku niektórych metryk, na przykđad poziomu uľycia pamiúci.

Czas niebezczynności W firmie, w której pracujú, problem zwiæzany z definiowaniem poziomu wykorzystania pojawiđ siú na etapie prac nad projektem monitorowania w chmurze. Gđówny inľynier, Dave Pacheco, poprosiđ mnie o zdefiniowanie pojúcia wykorzystania. Zrobiđem to w sposób, w jaki zaprezentowađem wczeħniej. Niezadowolony z powodu moľliwej dezorientacji pojúciowej Dave wymyħliđ inne wyraľenie, które wedđug niego jest wystarczajæco jasne: czas niebezczynnoħci. Wprawdzie to wyraľenie znacznie dokđadniej oddaje rzeczywistoħè, ale nie jest jeszcze powszechnie stosowane. (Odwođuje siú do metryki procent zajútoħci, któræ przedstawiđem juľ wczeħniej).

2.3.12. Nasycenie Nasycenie oznacza stan, w którym ľædania wykonania kolejnych zadaē przekraczajæ iloħè zasobów przeznaczonych do przetwarzania tych ľædaē. Z nasyceniem spotykamy siú przy 100-procentowym poziomie wykorzystania (w definicji opartej na pojemnoħci), kiedy kolejne napđywajæce ľædania nie mogæ byè przetworzone i zaczynajæ byè kolejkowane. Taka sytuacja zostađa pokazana na rysunku 2.8. Na rysunku wyraļnie pokazano, ľe wraz ze wzrostem obciæľenia nastúpuje równieľ liniowy wzrost nasycenia po przekroczeniu 100-procentowego poziomu wykorzystania (definicja oparta na pojemnoħci). Kaľdy poziom nasycenia oznacza problemy zwiæzane z wydajnoħciæ, poniewaľ marnuje siú wiúcej czasu na oczekiwanie (opóļnienie). W przypadku poziomu wykorzystania na podstawie czasu (procent zajútoħci) — kolejkowanie i tym samym nasycenie nie musi siú rozpoczynaè po osiægniúciu wartoħci 100% wykorzystania. Konkretna wartoħè graniczna zaleľy od stopnia, w jakim zasoby mogæ jednoczeħnie wykonywaè operacje.

2.3. Koncepcje

63

Rysunek 2.8. Wykorzystanie kontra nasycenie

2.3.13. Profilowanie Profilowanie pozwala na przygotowanie obrazu analizowanego systemu, który to obraz nastúpnie moľna przestudiowaè i zrozumieè. Na obszarze wydajnoħci systemów profilowanie najczúħciej odbywa siú przez próbkowanie stanu systemu w ustalonych odstúpach czasu, a póļniej przez analizú zebranych próbek. W przeciwieēstwie do wczeħniej przedstawionych metryk, miúdzy innymi wartoħci IOPS i przepustowoħci, zastosowanie próbkowania daje jedynie ogólny obraz aktywnoħci analizowanego systemu, zaleľny od czústotliwoħci próbkowania. Jako przykđad profilowania moľna podaè poziom uľycia procesora. Tú wartoħè moľna ustaliè w miarú dokđadnie przez próbkowanie w bardzo krótkich odstúpach czasu licznika programu procesora lub stosu wywođaē zwrotnych. W ten sposób zostanæ zebrane dane statystyczne dotyczæce ħcieľek kodu zuľywajæcych zasoby procesora. Ten temat búdzie omówiony w rozdziale 6. „Procesory”.

2.3.14. Buforowanie Buforowanie jest bardzo czústo stosowane w celu poprawy wydajnoħci. Dane pobrane z wolniejszej warstwy pamiúci masowej bufor przechowuje w znacznie szybszej warstwie pamiúci. Przykđadem buforowania moľe byè umieszczenie w pamiúci operacyjnej (RAM) danych znajdujæcych siú na dysku twardym. Istnieje moľliwoħè zastosowania wielu warstw buforowania. Procesory najczúħciej majæ wiele sprzútowych pamiúci podrúcznych (poziomu 1., 2. i 3.) dla pamiúci operacyjnej. Pamiúè poziomu 1. to bardzo szybka, choè jednoczeħnie niewielka pamiúè podrúczna. Kolejne pamiúci podrúczne sæ wiúksze, ale jednoczeħnie dostúp do nich wiæľe siú z rosnæcym opóļnieniem. To ekonomiczny kompromis miúdzy gústoħciæ a opóļnieniem: poziomy i wielkoħci pamiúci podrúcznej sæ wybierane w taki sposób, aby zapewniè najlepszæ wydajnoħè dla danego ukđadu scalonego z uwzglúdnieniem fizycznie dostúpnego w nim miejsca.

64

Rozdział 2



Metodologia

W systemie istniejæ jeszcze inne rodzaje buforów, wiele z nich zostađo zaimplementowanych w oprogramowaniu i opiera siú na uľyciu pamiúci operacyjnej do przechowywania danych. Listú dostúpnych warstw buforów przedstawiono w punkcie 3.2.11, znajdujæcym siú w rozdziale 3. „Systemy operacyjne”. Jednæ z metryk umoľliwiajæcych zrozumienie wydajnoħci dziađania bufora jest wspóđczynnik trafnoħci. Wskazuje on, ile razy ľædane dane zostađy znalezione w buforze (trafienie), a ile razy nie zostađy w nim znalezione (brak trafieē). wspóïczynnik trafnoĂci = trafienia/(trafienia+brak trafieñ)

Im wyľsza wartoħè wymienionego wspóđczynnika, tym lepiej, poniewaľ wyľsza wartoħè wskazuje na wiúkszæ iloħè danych pobranych ze znacznie szybszego medium. Na rysunku 2.9 pokazano oczekiwanæ poprawú wydajnoħci w stosunku do coraz wiúkszej wartoħci wspóđczynnika trafnoħci.

Rysunek 2.9. Współczynnik trafności a wydajność

Róľnica w wydajnoħci miúdzy wartoħciami 98% i 99% jest znacznie wiúksza niľ miúdzy 10% i 11%. Wykres pokazuje profil nieliniowy, co wynika z róľnic w szybkoħci miúdzy trafieniem i brakiem ľædanych danych w buforze — tutaj trzeba koniecznie pamiútaè o uľyciu dwóch warstw przechowywania danych. Im wiúksza róľnica, tym bardziej stroma jest krzywa pokazana na rysunku. Innæ metrykæ pomagajæcæ w zrozumieniu wydajnoħci dziađania bufora jest wspóđczynnik nietrafnoħci, okreħlajæcy, ile razy w ciægu sekundy ľædane dane nie zostađy znalezione w buforze. To jest wartoħè proporcjonalna (liniowa) do spadku wydajnoħci w przypadku kaľdego nietrafienia i moľe byè đatwo interpretowana. Na przykđad obciæľenia A i B wykonujæ dokđadnie to samo zadanie, ale za pomocæ róľnych algorytmów, oraz uľywajæ buforów w pamiúci operacyjnej w celu unikniúcia operacji odczytu danych z dysku. W przypadku obciæľenia A wspóđczynnik trafnoħci bufora wynosi 90%, natomiast dla obciæľenia B wynosi on 80%. Tego rodzaju informacje sugerujæ, ľe obciæľenie A charakteryzuje siú lepszæ wydajnoħciæ. Co dzieje siú w sytuacji, gdy dla obciæľenia A liczba nietrafieē bufora wynosi 200 na sekundú, natomiast dla obciæľenia B jedynie 20 nietrafieē na sekundú? Wówczas obciæľenie B wykonuje 10 razy mniej operacji odczytu danych z dysku, a tym samym moľe zakoēczyè wykonywanie zadaē znacznie szybciej niľ obciæľenie A. Aby mieè pewnoħè, cađkowity czas wykonywania zadaē przy danym obciæľeniu moľna obliczyè, korzystajæc z poniľszego wzoru:

2.3. Koncepcje

65

czas wykonywania zadañ = (wspóïczynnik trafnoĂci·opóěnienie trafnoĂci)+(wspóïczynnik nietrafnoĂci·opóěnienie nietrafnoĂci)

W obliczeniach z uľyciem przedstawionego wzoru naleľy wykorzystaè ħrednie wartoħci trafnoħci i opóļnienia nietrafnoħci oraz przyjæè zađoľenie, ľe praca do wykonania jest serializowana.

Algorytmy Polityki i algorytmy zarzædzania buforem okreħlajæ, jakie dane powinny byè przechowywane w ograniczonej przestrzeni przeznaczonej na bufor. Skrót MRU (ang. Most Recently Used; ostatnio uľywane) odwođuje siú do polityki zachowywania danych w buforze okreħlajæcej dane, które powinny pozostaè w buforze: w tym przypadku to ostatnio uľywane obiekty. Z kolei skrót LRU (ang. Least Recently Used; najdawniej uľywane) odwođuje siú do polityki usuwania danych z bufora, gdy zajdzie potrzeba umieszczenia w nim nowych obiektów. Istniejæ równieľ polityki okreħlane jako MFU (ang. Most Frequently Used; najczúħciej uľywane) i LFU (ang. Least Frequently Used; najrzadziej uľywane). Moľesz równieľ spotkaè siú z politykæ NFU (ang. Not Frequently Used; niezbyt czústo uľywane), która okazuje siú byè niedrogæ, choè jednoczeħnie mniej skutecznæ wersjæ LRU.

Bufor gorący, zimny i rozgrzewanie bufora Wymienione sđowa sæ najczúħciej uľywane do okreħlenia stanu bufora: 







Zimny. Bufor zimny jest pusty lub wypeđniony niechcianymi danymi. Wspóđczynnik trafnoħci tego rodzaju bufora wynosi 0 (lub waha siú w okolicach 0, gdy rozpocznie siú proces rozgrzewania bufora). Goræcy. Bufor goræcy jest wypeđniony najczúħciej ľædanymi danymi i charakteryzuje siú wysokim wspóđczynnikiem trafnoħci, na przykđad przekraczajæcym 99%. Rozgrzany. Bufor rozgrzany jest wypeđniony uľytecznymi danymi, ale nie ma jeszcze wystarczajæco wysokiego wspóđczynnika trafnoħci, aby mógđ zostaè uznany za goræcy. Ciepđo. „Ciepđoħè” bufora okreħla, jak zimny lub jak goræcy jest bufor. Dziađanie poprawiajæce „ciepđoħè” bufora jest jednym z tych, które prowadzæ do poprawy wspóđczynnika trafnoħci bufora.

Po zainicjalizowaniu bufora na poczætku jest on zimny, a nastúpnie powoli siú nagrzewa. Jeľeli bufor jest ogromny lub jeľeli kolejna warstwa pamiúci masowej jest wolna (bædļ teľ i jedno, i drugie), wtedy wypeđnienie oraz peđne rozgrzanie bufora moľe wymagaè dđugiego czasu. Pracowađem na przykđad z systemami wyposaľonymi w 128 GB pamiúci DRAM przeznaczonej na bufor systemu plików, 600 GB pamiúci flash stanowiæcej bufor drugiego poziomu i dyskami mechanicznymi jako podstawowæ pamiúciæ masowæ. W przypadku

66

Rozdział 2



Metodologia

obciæľenia skđadajæcego siú z losowych operacji odczytu dyski zapewniađy wydajnoħè wynoszæcæ okođo 2000 odczytów na sekundú. Przy wielkoħci operacji wejħcia-wyjħcia wynoszæcej 8 KB oznacza to, ľe rozgrzewanie bufora nastúpowađo z szybkoħciæ jedynie 16 MB/s (2000ŧ8 KB). Wtedy gdy zimne byđy oba bufory, rozgrzanie bufora znajdujæcego siú w pamiúci DRAM wymagađo okođo 2 godzin, podczas gdy znajdujæcego siú w pamiúci flash juľ okođo 10 godzin.

2.4. Perspektywy Podczas analizy wydajnoħci najczúħciej sæ stosowane dwie perspektywy róľniæce siú odbiorcami, metrykami i podejħciami. Wspomniane perspektywy to analiza obciæľenia i analiza zasobów. Jak pokazano na rysunku 2.10, moľna je rozpatrywaè w kategoriach analizy od poczætku do koēca lub od koēca do poczætku stosu oprogramowania.

Rysunek 2.10. Perspektywy analizy

W podrozdziale 2.5 „Metodologia” znajdziesz informacje o konkretnych strategiach stosowanych w poszczególnych perspektywach. Takľe same perspektywy zostanæ przedstawione nieco dokđadniej.

2.4.1. Analiza zasobów Analiza zasobów rozpoczyna siú od analizy zasobów systemu: procesorów, pamiúci, dysków, interfejsów sieciowych i magistrali. Najczúħciej búdzie przeprowadzana przez administratorów systemów, którzy sæ odpowiedzialni za fizyczne zasoby ħrodowiska. Podejmowane przez nich dziađania obejmujæ: 

Wyszukiwanie problemów zwiæzanych z wydajnoħciæ. Sprawdzanie, czy okreħlony typ zasobu jest odpowiedzialny za dany problem.

2.4. Perspektywy



67

Planowanie pojemnoħci. Zbieranie informacji pomagajæcych w ustaleniu wielkoħci nowych systemów oraz okreħlenie, kiedy zasoby istniejæcych systemów mogæ zostaè wyczerpane.

Ta perspektywa koncentruje siú na poziomie wykorzystania i ma sđuľyè do okreħlenia, kiedy zasoby osiægnæ wđasne granice lub kiedy búdæ bliskie ich osiægniúcia. Dla pewnego typu zasobów, miúdzy innymi procesorów, poziom wykorzystania moľna obliczyè na podstawie dostúpnych metryk, na przykđad szacujæc wykorzystanie interfejsu sieciowego przez porównanie liczby wysđanych i odebranych megabitów w ciægu sekundy (przepustowoħci) ze znanæ wartoħciæ maksymalnej przepustowoħci danego interfejsu. Najlepsze metryki do analizy zasobów to: 

IOPS,



przepustowoħè,



poziom wykorzystania,



nasycenie.

Dziúki wymienionym metrykom moľna zmierzyè iloħè pracy wykonywanej przez zasób, a takľe poziomy jego wykorzystania i nasycenia dla danego obciæľenia. Inne typy metryk, miúdzy innymi opóļnienie, równieľ sæ uľywane i dostarczajæ informacji o tym, jak zasób radzi sobie z udzielaniem odpowiedzi w przypadku danego obciæľenia. Analiza zasobów to najczústsze podejħcie w analizie wydajnoħci, w pewnym stopniu dlatego, ľe jest doħè dokđadnie udokumentowanym zagadnieniem. Wspomniana dokumentacja koncentruje siú na poleceniach systemu operacyjnego, takich jak vmstat, iostat i mpstat. W trakcie lektury dokumentacji powinieneħ koniecznie pamiútaè, ľe analiza zasobów nie jest jedynæ dostúpnæ perspektywæ.

2.4.2. Analiza obciążenia Analiza obciæľenia (patrz rysunek 2.11) pozwala na sprawdzenie wydajnoħci aplikacji: stosowanego obciæľenia oraz sposobów reakcji aplikacji na dane obciæľenie. Ten rodzaj analizy jest najczúħciej przeprowadzany przez programistów aplikacji oraz personel pomocy technicznej, czyli osoby odpowiedzialne za przygotowanie i konfiguracjú aplikacji.

Rysunek 2.11. Analiza obciążenia

68

Rozdział 2



Metodologia

Podczas analizy obciæľenia badane sæ nastúpujæce obszary: 

ľædania — aktualne obciæľenie,



opóļnienie — czas udzielenia odpowiedzi przez aplikacjú,



zakoēczenie pracy — sprawdzenie, czy wystæpiđy jakiekolwiek bđúdy.

Analiza ľædaē tworzæcych aktualne obciæľenie zwykle obejmuje sprawdzenie i podsumowanie ich atrybutów, to tak zwany proces charakteryzacji obciæľenia (znacznie dokđadniej zostađ omówiony w podrozdziale 2.5 „Metodologia”). W przypadku baz danych wspomnianymi atrybutami mogæ byè: komputer klienta, nazwa bazy danych, tabele i ciæg tekstowy zapytania. Dane takie okaľæ siú pomocne podczas identyfikacji niepotrzebnie wykonywanych zadaē. Wprawdzie tego rodzaju zadania mogæ byè wykonywane sprawnie (mađe opóļnienie), ale analiza wymienionych atrybutów moľe pomóc w znalezieniu sposobów zmniejszenia lub wyeliminowania zadaē do wykonania. (Pamiútaj, ľe najszybsze zapytanie to takie, które nie zostađo wykonane). Opóļnienie (czas udzielenie odpowiedzi) to najwaľniejsza metryka sđuľæca do wyraľania wydajnoħci aplikacji. W bazie danych MySQL búdzie to opóļnienie zwiæzane z wykonaniem zapytania, natomiast dla serwera Apache opóļnienie zwiæzane z ľædaniem HTTP itd. W tego rodzaju kontekstach termin opóļnienie ma takie samo znaczenie jak czas reakcji (wiúcej informacji dotyczæcych kontekstu znajdziesz we wczeħniejszym punkcie 2.3.1, zatytuđowanym „Opóļnienie”). Do zadaē analizy obciæľenia zaliczamy wykrywanie i potwierdzanie istnienia problemów, przykđadowo w wyniku wyszukania opóļnienia przekraczajæcego akceptowalnæ wartoħè. Nastúpnie trzeba znaleļè ļródđo opóļnienia (na przykđad za pomocæ analizy dræľæcej) i potwierdziè, ľe opóļnienie siú zmniejszy po zastosowaniu poprawki. Zwróè uwagú, ľe punktem wyjħcia jest aplikacja. Analiza opóļnienia zwykle wymaga zejħcia gđúboko w aplikacjú, biblioteki i system operacyjny (jædro). Kwestie zwiæzane z systemem mogæ byè identyfikowane za pomocæ analizy cech charakterystycznych zwiæzanych z zakoēczeniem zdarzenia. Do wspomnianych kwestii zaliczamy równieľ stan bđúdu. Wprawdzie ľædanie moľe byè obsđuľone bardzo szybko, ale jednoczeħnie ewentualny kod bđúdu spowoduje ponowne wykonanie ľædania, co zwiúkszy opóļnienie. Metryki najlepiej sprawdzajæce siú w trakcie analizy obciæľenia to: 

przepustowoħè (liczba transakcji w ciægu sekundy),



opóļnienie.

Wymienione metryki podajæ wspóđczynnik ľædaē oraz wydajnoħè koēcowæ.

2.5. Metodologia W tym podrozdziale zostanæ omówione róľne metodologie i procedury analizy wydajnoħci systemów oraz jej dostosowywania. Ponadto wprowadzone búdæ pewne nowe metodologie, w szczególnoħci metoda USE. Oczywiħcie poznasz takľe wybrane antymetody.

2.5. Metodologia

69

Aby uđatwiè podsumowanie ich ról, metodologie zostađy pogrupowane wedđug róľnych typów, na przykđad analiza oparta na obserwacji, analiza oparta na eksperymentach itd., jak pokazano w tabeli 2.4. Tabela 2.4. Ogólne metodologie wydajności systemu Metodologia

Rodzaj

Jawna antymetoda

Analiza oparta na obserwacji

Antymetoda losowej zmiany

Analiza oparta na eksperymentach

Antymetoda obwiniania kogoś innego

Analiza oparta na hipotezach

Metoda listy przygotowanej ad hoc

Analiza oparta na obserwacji i eksperymentach

Opis problemu

Zbieranie informacji

Metoda naukowa

Analiza oparta na obserwacji

Cykl diagnostyczny

Analiza cyklu życiowego

Metoda narzędzi

Analiza oparta na obserwacji

Metoda USE

Analiza oparta na obserwacji

Charakterystyka obciążenia

Analiza oparta na obserwacji, planowanie pojemności

Analiza drążąca

Analiza oparta na obserwacji

Analiza opóźnienia

Analiza oparta na obserwacji

Metoda R

Analiza oparta na obserwacji

Monitorowanie zdarzeń

Analiza oparta na obserwacji

Dane statystyczne będące punktem odniesienia

Analiza oparta na obserwacji

Monitorowanie wydajności

Analiza oparta na obserwacji, planowanie pojemności

Teoria kolejek

Analiza statystyczna, planowanie pojemności

Statyczne dostosowanie wydajności

Analiza oparta na obserwacji, planowanie pojemności

Dostosowanie bufora

Analiza oparta na obserwacji, dostrajanie

Mikrotesty wydajności

Analiza oparta na eksperymentach

Planowanie pojemności

Planowanie pojemności, dostrajanie

Monitorowanie wydajnoħci, teoria kolejek i planowanie pojemnoħci to zagadnienia, które zostanæ omówione w dalszej czúħci rozdziađu. W kolejnych rozdziađach powrócimy przynajmniej do wybranych metodologii, ale w róľnych kontekstach. Przedstawione búdæ równieľ dodatkowe metodologie, charakterystyczne dla danych obszarów analizy wydajnoħci. W kolejnych punktach na poczætku przedstawiono najczúħciej wykorzystywane, choè jednoczeħnie najsđabsze metodologie porównywania, uwzglúdniono takľe antymetody. W kontekħcie analizy problemów zwiæzanych z wydajnoħciæ pierwszæ metodæ wartæ zastosowania jest metoda opisu problemu. Dopiero póļniej moľna przejħè do kolejnych metod.

70

Rozdział 2



Metodologia

2.5.1. Jawna antymetoda Ta metoda w rzeczywistoħci oznacza brak wyboru przemyħlanej metodologii. Uľytkownik analizuje wydajnoħè za pomocæ wybranych narzúdzi monitorowania, które sæ mu znane, dostúpne w internecie, lub wybiera przypadkowe, aby przekonaè siú, czy ujawniæ cokolwiek ciekawego. Takie podejħcie moľna okreħliè mianem „albo siú uda, albo nie” i bardzo czústo prowadzi do przeoczenia wielu typów problemów. Dostosowanie wydajnoħci moľe odbywaè siú w podobny sposób, na zasadzie prób i bđúdów, w wyniku ustawiania znanym parametrom róľnych wartoħci w nadziei, ľe wprowadzona zmiana pomoľe poprawiè wydajnoħè. Nawet jeħli ta metoda pozwoli na odkrycie problemu, cađy proces búdzie powolny. Wynika to z wyszukiwania i wypróbowywania niepowiæzanych z rzeczywistym problemem róľnych narzúdzi i wartoħci parametrów tylko dlatego, ľe sæ znane uľytkownikowi. Nazwa tej metodologii wziúđa siú od nastawienia obserwacyjnego o nazwie efekt latarni ulicznej, które moľna zilustrowaè nastúpujæcæ przypowieħciæ: Pewnej nocy policjant zobaczyđ nietrzeļwego múľczyznú wyraļnie szukajæcego czegoħ na chodniku przy latarni. Zapytađ go wiúc, czego szuka. Nietrzeļwy múľczyzna odpowiedziađ, ľe zgubiđ klucze do mieszkania. Jednak policjant równieľ nie mógđ ich znaleļè i zapytađ: „Czy na pewno zgubiđeħ je tutaj, przy latarni?”. Nietrzeļwy odpowiedziađ: „Nie, ale tutaj mam najlepsze ħwiatđo”.

W analizie wydajnoħci odpowiednikiem powyľszej przypowieħci búdzie uľycie polecenia top, nie z powodu rozsædnego podejħcia, ale dlatego, ľe uľytkownik nie potrafi odczytywaè danych wyjħciowych generowanych przez inne narzúdzia. Wada tej metodologii jest taka, ľe odkrycie moľe byè problemem, ale nie tym, którego szukasz. Inne metodologie umoľliwiajæ dokonanie oceny odkryè, co pozwala na szybkie wychwytywanie fađszywych alarmów.

2.5.2. Antymetoda losowej zmiany To jest antymetoda oparta na eksperymentach. Uľytkownik próbuje odgadnæè przyczynú problemu, a nastúpnie zmienia róľne ustawienia w zaleľnoħci od aktualnego pomysđu. Aby okreħliè, czy wprowadzona zmiana przyniosđa poprawú wydajnoħci, analizowane sæ róľne metryki, na przykđad czas dziađania aplikacji, czas wykonywania operacji, opóļnienie, wspóđczynnik operacji (liczba operacji wykonywanych w ciægu sekundy) i przepustowoħè (bajty na sekundú). Tego rodzaju podejħcie przedstawia siú nastúpujæco: 1. Losowy wybór elementu, który zostanie zmodyfikowany (na przykđad parametr). 2. Modyfikacja wybranego elementu w jednym kierunku. 3. Pomiar wydajnoħci. 4. Modyfikacja wybranego elementu w przeciwnym kierunku. 5. Pomiar wydajnoħci. 6. Sprawdzenie, czy wynik otrzymany w kroku 3. lub 5. jest lepszy niľ wynik poczætkowy. Jeħli tak, pozostawienie zmiany i powrót do punktu 1.

2.5. Metodologia

71

Wprawdzie tego rodzaju proces moľe doprowadziè do modyfikacji sprawdzajæcej siú w danym obciæľeniu, ale búdzie bardzo czasochđonny. Ponadto skutkiem opisanego procesu moľe byè wprowadzenie zmiany bezsensownej w dđuľszej perspektywie czasu. Na przykđad modyfikacja aplikacji mogđa spowodowaè poprawú wydajnoħci ze wzglúdu na zastosowanie rozwiæzania umoľliwiajæcego obejħcie istniejæcego w bazie danych lub systemie operacyjnym bđúdu, który póļniej zostađ usuniúty. Jednak modyfikacja wprowadzona w aplikacji pozostađa i choè jej dalsze istnienie nie ma sensu, nikt na to nie wpadnie. Kolejne ryzyko wiæľe siú z faktem, ľe wprowadzenie nierozumianej do koēca zmiany powoduje problemy w trakcie maksymalnego obciæľenia produkcyjnego. Dlatego teľ naleľy pamiútaè, aby unikaè tego rodzaju zmian w ħrodowisku produkcyjnym.

2.5.3. Antymetoda obwiniania kogoś innego Ta antymetoda skđada siú z nastúpujæcych kroków: 1. Wyszukanie systemu lub komponentu ħrodowiska, za który nie odpowiadasz. 2. Postawienie hipotezy, ľe wybrany w punkcie 1. system lub komponent jest ļródđem problemu. 3. Przekazanie informacji o problemie zespođowi odpowiedzialnemu za wybrany w punkcie 1. system lub komponent. 4. Jeľeli hipoteza okaľe siú nieprawdziwa, powrót do punktu 1. Byè moľe ļródđem problemu jest sieè. Mógđbyħ sprawdziè w zespole opiekujæcym siú sieciæ, czy jego czđonkowie zauwaľyli gubienie pakietów lub coħ w tym stylu.

Zamiast zajæè siú wyszukaniem problemu zwiæzanego z wydajnoħciæ, uľytkownik omawianej metodologii zrzuca winú na innych. Takie podejħcie moľe doprowadziè do marnowania zasobów w innych zespođach szukajæcych problemu, który — jak siú póļniej okazuje — w ogóle ich nie dotyczy. Przyczynæ zastosowania tej antymetody moľe byè brak danych umoľliwiajæcych postawienie prawidđowej hipotezy dotyczæcej problemu. Aby nie staè siú ofiaræ osoby stosujæcej metodú obwiniania innych, warto poprosiè oskarľajæcego o przesđanie zrzutów ekranu pokazujæcych uruchomione przez niego narzúdzia i przedstawienie sposobu interpretacji danych wyjħciowych. Rozsædnym rozwiæzaniem búdzie zaprezentowanie otrzymanych zrzutów ekranu i interpretacji danych wyjħciowych innej osobie i przeprowadzenie z niæ konsultacji.

2.5.4. Metoda przygotowanej ad hoc listy rzeczy do sprawdzenia Wykonywanie kolejnych punktów na podstawie wczeħniej przygotowanej listy rzeczy do sprawdzenia to metodologia czústo stosowana przez profesjonalistów zajmujæcych siú pomocæ technicznæ, wtedy gdy zostanæ poproszeni o sprawdzenie i dostrojenie systemu w stosunkowo krótkim czasie. Typowy scenariusz takiej sytuacji polega na wdroľeniu w ħrodowisku produkcyjnym nowego serwera lub aplikacji — przez póđ

72

Rozdział 2



Metodologia

dnia profesjonalista z dziađu pomocy technicznej sprawdza najczúħciej wystúpujæce problemy w systemie znajdujæcym siú pod rzeczywistym obciæľeniem. Wspomniane wczeħniej listy rzeczy do sprawdzenia sæ przygotowywane ad hoc na podstawie ostatnich doħwiadczeē i problemów spotykanych w systemach danego rodzaju. Oto przykđad punktu, który moľe znajdowaè siú na liħcie: Wydaj polecenie iostat -x 1 i sprawdļ wartoħè kolumny await. Jeľeli jej wartoħè pod obciæľeniem utrzymuje siú na poziomie ponad 10 (ms), wówczas oznacza to, ľe dyski dziađajæ wolno lub sæ przeciæľone.

Lista rzeczy do sprawdzenia moľe skđadaè siú z wielu tego rodzaju punktów. Wprawdzie wspomniane listy rzeczy do zrobienia sæ szczególnie wartoħciowe, gdy presja czasu jest duľa, ale tak naprawdú sæ to zalecenia dotyczæce konkretnego punktu w czasie (patrz podrozdziađ 2.3 „Koncepcje”) i zwykle trzeba je modyfikowaè, aby nie straciđy na aktualnoħci. Listy najczúħciej zawierajæ opisy problemów, dla których istniejæ znane, doħè dobrze udokumentowane rozwiæzania. Przykđadem mogæ byè ustawienia parametrów, ale juľ nie wđasne poprawki dla kodu ļródđowego lub ħrodowiska. Jeľeli odpowiadasz za zarzædzanie zespođem profesjonalistów zajmujæcych siú pomocæ technicznæ, lista rzeczy do sprawdzenia moľe byè efektywnym sposobem potwierdzenia tego, ľe kaľdy wie, jak wyszukaè najtrudniejsze problemy, oraz gwarancjæ przeprowadzenia kontroli pod kætem wszystkich oczywistych scenariuszy. Lista rzeczy do sprawdzenia moľe byè przygotowana w sposób jasny i nakazowy, dokđadnie pokazujæc, jak identyfikowaè i usuwaè poszczególne problemy. Oczywiħcie trzeba pamiútaè o nieustannym uaktualnianiu listy.

2.5.5. Opis problemu Zdefiniowanie opisu problemu to rutynowe zadanie personelu pomocy technicznej, gdy po raz pierwszy odpowiada on na zgđoszenie. Opis problemu powstaje po uzyskaniu od uľytkownika odpowiedzi na wymienione pytania: 1. Dlaczego sædzisz, ľe wystúpuje problem zwiæzany z wydajnoħciæ? 2. Czy uľywany system kiedykolwiek oferowađ doskonađæ wydajnoħè? 3. Jakie zmiany zostađy ostatnio wprowadzone? Oprogramowanie? Sprzút? Czy zmieniđo siú obciæľenie? 4. Czy problem dotyczy takľe innych uľytkowników lub aplikacji (czy wystúpuje tylko u Ciebie)? 5. W jakim ħrodowisku pracujesz? Jaki sprzút i oprogramowanie sæ uľywane? Wersje? Konfiguracje? Po prostu zadanie tych pytaē i uzyskanie odpowiedzi na nie czústo prowadzi do poħredniej przyczyny problemu i w efekcie do jego rozwiæzania. Dlatego teľ opis problemu zostađ w tym podrozdziale przedstawiony jako samodzielna metodologia, któræ naleľy zastosowaè jako pierwszæ, gdy stawiamy czođa nowemu problemowi.

2.5. Metodologia

73

2.5.6. Metoda naukowa Metoda naukowa pozwala na analizú nieznanego przez tworzenie hipotez, które nastúpnie sæ sprawdzane. Tú metodú moľna sprowadziè do nastúpujæcych kroków: 1. Pytanie. 2. Hipoteza. 3. Przewidywanie. 4. Test. 5. Analiza. Pytanie to problem zwiæzany z wydajnoħciæ. Na jego podstawie moľna postawiè hipotezú o prawdopodobnej przyczynie niezadowalajæcej wydajnoħci. Nastúpnie przygotowywany jest test, który moľe mieè charakter obserwacyjny lub eksperymentalny. Dziúki wspomnianemu testowi moľna sprawdziè przewidywanie oparte na hipotezie. Na koēcu przeprowadzana jest analiza na podstawie danych zebranych podczas testu. Mogđeħ na przykđad zauwaľyè spadek wydajnoħci dziađania aplikacji po jej migracji do komputera wyposaľonego w mniejszæ iloħè pamiúci operacyjnej. Na tej podstawie stawiasz hipotezú, ľe przyczynæ gorszej wydajnoħci dziađania jest mniejszy bufor systemu plików. Moľesz skorzystaè z testu opartego na obserwacji, aby zmierzyè wspóđczynnik nietrafienia bufora w obu systemach — w przewidywaniu, ľe búdzie on miađ wiúkszæ wartoħè w komputerze wyposaľonym w mniejszæ iloħè pamiúci operacyjnej. Z kolei test oparty na eksperymentach búdzie obejmowađ zwiúkszenie wielkoħci bufora (przez dodanie do komputera pamiúci RAM) — w przewidywaniu, ľe to poprawi wydajnoħè. Inny i prawdopodobnie đatwiejszy test oparty na eksperymentach polega na zmniejszeniu wielkoħci bufora (za pomocæ odpowiednich parametrów) — w przewidywaniu, ľe spowoduje to pogorszenie wydajnoħci. W dalszej czúħci przedstawiono kilka przykđadów.

Przykład (oparty na obserwacji) 1. Pytanie: jaka moľe byè przyczyna wolnego wykonywania zapytaē do bazy danych? 2. Hipoteza: hađaħliwi sæsiedzi (czyli w przypadku ħrodowiska przetwarzania w chmurze — inne tenanty) wykonujæcy dyskowe operacje wejħcia-wyjħcia, co prowadzi do rywalizacji z wykonywanymi przez bazú danych dyskowymi operacjami wejħcia-wyjħcia (poprzez system plików). 3. Przewidywanie: jeħli opóļnienie systemowych operacji wejħcia-wyjħcia búdzie zmierzone w trakcie wykonywania zapytania, to pokaľe, ľe system plików jest odpowiedzialny za wolne wykonywanie zapytaē do bazy danych. 4. Test: monitorowanie opóļnienia systemu plików bazy danych jako wspóđczynnika opóļnienia zapytaē pokazuje, ľe mniej niľ 5% czasu zajmuje oczekiwanie na system plików. 5. Analiza: system plików i dyski nie sæ odpowiedzialne za wolne wykonywanie zapytaē do bazy danych.

74

Rozdział 2



Metodologia

Wprawdzie problem pozostađ nierozwiæzany, ale ogromne komponenty ħrodowiska udađo siú wyeliminowaè z grona podejrzanych o to, ľe sæ ļródđem problemu. Osoba przeprowadzajæca analizú moľe powróciè do punktu 2. i postawiè nowæ hipotezú.

Przykład (oparty na eksperymentach) 1. Pytanie: dlaczego wykonywanie ľædaē HTTP z komputera A do C zajmuje wiúcej czasu niľ z komputera B do C? 2. Hipoteza: komputery A i B znajdujæ siú w róľnych centrach danych. 3. Przewidywanie: przeniesienie komputera A do centrum danych, w którym znajduje siú komputer B, spowoduje rozwiæzanie problemu. 4. Test: przeniesienie komputera A i sprawdzenie jego wydajnoħci. 5. Analiza: problem zwiæzany z wydajnoħciæ zostađ rozwiæzany zgodnie z zađoľonæ hipotezæ. Jeľeli problem nie zostanie rozwiæzany, naleľy wycofaè wprowadzonæ zmianú (w tym przypadku oznacza to przeniesienie komputera A do jego pierwotnej lokalizacji) przed utworzeniem nowej hipotezy!

Przykład (oparty na eksperymentach) 1. Pytanie: dlaczego wzrost wielkoħci bufora systemu plików prowadzi do spadku wydajnoħci systemu? 2. Hipoteza: ogromny bufor zawiera duľæ liczbú rekordów, a wiúc zarzædzanie buforem tej wielkoħci wymaga przeprowadzania wiúkszej iloħci obliczeē niľ w przypadku mniejszego bufora. 3. Przewidywanie: progresywne zmniejszenie wielkoħci rekordu, a tym samym wywođanie sytuacji, w której wiúksza liczba rekordów jest uľywana do przechowywania tej samej iloħci danych, spowoduje progresywne pogorszenie wydajnoħci. 4. Test: rekordy o progresywnie zmniejszonej wielkoħci naleľy przetestowaè pod tym samym obciæľeniem. 5. Analiza: wyniki zostađy umieszczone na wykresie i okazađy siú spójne z przewidywaniem; nastúpnie przeprowadzana jest znacznie dokđadniejsza analiza procedur zarzædzania buforem. To jest przykđad testu negatywnego — celowo zmniejszono wydajnoħè, aby dowiedzieè siú wiúcej o analizowanym systemie.

2.5.7. Cykl diagnostyczny Do omówionej wczeħniej metody naukowej podobny jest cykl diagnostyczny: hipoteza ĺ weryfikacja hipotezy ĺ dane ĺ hipoteza

2.5. Metodologia

75

Podobnie jak w przypadku metody naukowej, takľe cykl diagnostyczny oznacza testowanie hipotezy po zebraniu odpowiednich danych. W cyklu kđadziony jest nacisk na moľliwoħè szybkiego zebrania danych dla nowej hipotezy, która jest nastúpnie sprawdzana, modyfikowana itd. Przypomina to wizytú u lekarza, który bazujæc na serii niewielkich testów, stara siú postawiè pacjentowi diagnozú i odpowiednio modyfikuje hipotezú na podstawie wyników poszczególnych testów. Oba wymienione podejħcia zapewniajæ rozsædnæ równowagú miúdzy teoriæ a zbieranymi danymi. Szybkie przejħcie od hipotezy do danych pozwala na równie szybkæ identyfikacjú nieprawidđowych teorii, ich wczesne odrzucenie i opracowanie znacznie lepszych.

2.5.8. Metoda narzędzi Podejħcie zorientowane na narzúdzia przedstawia siú nastúpujæco: 1. Przygotowanie listy dostúpnych narzúdzi z zakresu wydajnoħci (opcjonalnie — instalacja lub zakup kolejnych). 2. W przypadku kaľdego narzúdzia przygotowanie listy uľytecznych metryk dostarczanych przez dane narzúdzie. 3. Dla kaľdej metryki przygotowanie listy reguđ moľliwych do zastosowania podczas interpretacji. W wyniku wykonania tych czynnoħci powstanie nakazowa lista rzeczy do sprawdzenia, wskazujæca narzúdzia do uľycia, metryki do odczytania i sposoby ich interpretacji. Wprawdzie takie rozwiæzanie moľe okazaè siú cađkiem efektywne, ale w cađoħci opiera siú na dostúpnych (lub znanych uľytkownikowi) narzúdziach, które jednak mogæ dostarczyè niekompletnego obrazu systemu, podobnie jak w przypadku jawnej antymetody. Co gorsza, uľytkownik jest nieħwiadomy otrzymania niekompletnego obrazu i moľe w takiej nieħwiadomoħci pozostaè. Problemy wymagajæce uľycia wđasnych narzúdzi (na przykđad monitorowania dynamicznego) mogæ pozostaè niewykryte i nierozwiæzane. W praktyce metodú opartæ na narzúdziach moľna wykorzystaè do identyfikacji konkretnych wæskich gardeđ zwiæzanych z zasobami, wykrycia bđúdów oraz innego rodzaju problemów, choè czústo w sposób nieefektywny. W przypadku dostúpnoħci ogromnej liczby narzúdzi i metryk przeanalizowanie ich wszystkich moľe wymagaè duľej iloħci czasu. Sytuacja staje siú jeszcze gorsza, gdy wiele narzúdzi charakteryzuje siú podobnæ funkcjonalnoħciæ i trzeba poħwiúciè dodatkowy czas na poznanie ich wad i zalet. W przypadku pewnych narzúdzi, na przykđad sđuľæcych do przeprowadzania mikrotestów wydajnoħci systemów plików, dostúpnych sæ ich dziesiætki, z których búdziesz potrzebowaè zaledwie jednego2.

2

Czústo moľna siú spotkaè z argumentem, ľe istnienie wielu narzúdzi o pokrywajæcych siú funkcjach jest „dobre z punktu widzenia konkurencji”. Mój kontrargument jest nastúpujæcy: opracowanie takich narzúdzi wymaga podziađu zasobów, tworzy wiúcej kombinacji do sprawdzenia, a ponadto marnuje czas uľytkowników, którzy muszæ wybieraè spoħród nich.

76

Rozdział 2



Metodologia

2.5.9. Metoda USE Metoda USE (ang. Utilization, Saturation and Errors; poziom wykorzystania, nasycenie i bđúdy) powinna byè stosowana na wczesnych etapach analizy wydajnoħci, poniewaľ umoľliwia wykrycie systemowych wæskich gardeđ (patrz odwođanie [Gregg 13] na koēcu rozdziađu). Tú metodú moľna podsumowaè w taki sposób: Dla kaľdego zasobu sprawdļ poziom wykorzystania, nasycenia oraz bđúdy.

Uľyte w powyľszym zdaniu okreħlenia zostađy zdefiniowane nastúpujæco: 







Zasób. Wszystkie fizyczne, funkcjonalne komponenty serwera (procesory, szyny itd.). Pewne zasoby w postaci oprogramowania równieľ moľna przeanalizowaè, o ile dostarczane przez nie metryki búdæ miađy sens. Poziom wykorzystania. Dla zdefiniowanego przedziađu czasu oznacza procentowæ iloħè czasu, przez który zasób byđ zajúty wykonywaniem zadaē. Kiedy zasób pozostaje zajúty, nadal moľe akceptowaè kolejne zadania. Poziom, na którym traci tú moľliwoħè, jest wskazywany przez nasycenie. Nasycenie. Poziom, do którego zasób moľe akceptowaè dodatkowe zadania niemoľliwe do wykonania w danej chwili. Wspomniane zadania dodatkowe najczúħciej czekajæ w kolejce. Bđúdy. Liczba bđúdów.

W przypadku pewnego typu zasobów, na przykđad pamiúci operacyjnej, poziom wykorzystania jest równy pojemnoħci danego zasobu. To ma odmienne znaczenie od przedstawionej w punkcie 2.3.11 definicji opartej na czasie. Kiedy pojemnoħè zasobu osiægnie 100% wykorzystania, nie búdzie moľliwa akceptacja kolejnych zadaē do wykonania. Zasób búdzie musiađ kolejkowaè zadania (nasycenie) lub wygenerowaè bđæd, który równieľ jest uwzglúdniany przez metodú USE. Bđúdy naleľy sprawdziè, poniewaľ ich skutkiem moľe byè spadek wydajnoħci. Same bđúdy niekoniecznie mogæ byè dostrzeľone wtedy, gdy da siú je jeszcze usunæè. Obejmuje to operacje, które zakoēczyđy siú niepowodzeniem i zostađy powtórzone, oraz urzædzenia, które ulegđy awarii, ale znajdowađy siú w puli urzædzeē nadmiarowych. W przeciwieēstwie do metody opartej na narzúdziach metoda USE oznacza iteracjú przez zasoby systemu, a nie przez narzúdzia. W ten sposób moľna utworzyè peđnæ listú pytaē do zadania, a nastúpnie wyszukaè narzúdzia pomagajæce w uzyskaniu odpowiedzi na przygotowane pytania. Nawet jeħli nie búdzie moľna znaleļè narzúdzia umoľliwiajæcego udzielenie odpowiedzi na pytania, ħwiadomoħè istnienia takich pytaē bez odpowiedzi búdzie niezwykle uľyteczna dla analityka zajmujæcego siú wydajnoħciæ: to sæ „znane niewiadome”. Metoda USE kieruje analityka do ograniczonej liczby kluczowych metryk, aby wszystkie zasoby systemu mogđy byè sprawdzone tak szybko, jak to moľliwe. Jeľeli nie zostanæ znalezione ľadne problemy, to moľna zastosowaè innæ metodologiú.

2.5. Metodologia

77

Procedura Wykres ilustrujæcy sposób dziađania metody USE zostađ pokazany na rysunku 2.12. Operacja sprawdzenia pod kætem bđúdów jest przeprowadzana jeszcze przed sprawdzeniem poziomu wykorzystania i nasycenia. Bđúdy najczúħciej moľna szybko wychwyciè i đatwo zinterpretowaè. Dlatego teľ, z punktu widzenia efektywnoħci czasowej, dobrym rozwiæzaniem jest ich wykluczenie przed przystæpieniem do analizy innych metryk.

Rysunek 2.12. Sposób działania metody USE

Metoda USE pozwala zidentyfikowaè problemy, które prawdopodobnie búdæ wæskimi gardđami systemu. Niestety, system moľe cierpieè z powodu istnienia wiúcej niľ tylko jednego problemu dotyczæcego wydajnoħci. Dlatego teľ moľe siú okazaè, ľe znalazđeħ problem zwiæzany z wydajnoħciæ, ale to nie búdzie szukany przez Ciebie problem. Jeħli zachodzi potrzeba sprawdzenia nastúpnych zasobów, kaľde odkrycie trzeba przeanalizowaè za pomocæ kolejnych metodologii jeszcze przed powrotem do metody USE.

78

Rozdział 2



Metodologia

Wyrażanie metryk Metryki USE sæ zwykle wyraľane w nastúpujæcych postaciach: 





poziom wykorzystania — wartoħè procentowa w pewnym przedziale czasu, na przykđad: „jeden procesor zostađ wykorzystany w 90%”; nasycenie — dđugoħè kolejki oczekiwania, na przykđad: „ħrednia dđugoħè kolejki oczekiwania wynosi 4”; bđúdy — liczba zgđoszonych bđúdów, na przykđad: „ten interfejs sieciowy zgđosiđ 50 bđúdów”.

Wprawdzie moľe siú to wydawaè dziwne, ale krótkotrwađy wysoki poziom wykorzystania moľe doprowadziè do nasycenia i powstania problemów z wydajnoħciæ, nawet gdy ogólny poziom wykorzystania pozostaje niski przez dđugi czas. Niektóre narzúdzia monitorowania podajæ poziom wykorzystania w przedziale wynoszæcym 5 minut. Jednak poziom wykorzystania, na przykđad procesora, moľe ulec diametralnej zmianie z sekundy na sekundú i wówczas 5-minutowy przedziađ czasu moľe powodowaè ukrycie krótkich okresów 100-procentowego poziomu wykorzystania, a tym samym wystæpienia nasycenia. Weļmy za przykđad punkt pobierania opđat drogowych na autostradzie. Poziom wykorzystania moľna okreħliè jako liczbú stanowisk zajútych obsđugæ pojazdów. Wykorzystanie w 100% oznacza, ľe nie moľesz znaleļè wolnego stanowiska i musisz ustawiè siú za innym pojazdem (nasycenie). Jeľeli otrzymasz informacje o 40-procentowym poziomie wykorzystania stanowisk w ciægu dnia, na tej podstawie búdziesz mógđ stwierdziè, czy w ciægu dnia jakiekolwiek samochody stađy w kolejce. Kolejki prawdopodobnie pojawiajæ siú w godzinach szczytu i wówczas poziom wykorzystania wynosi 100%, natomiast ħrednio w ciægu dnia ich nie ma.

Lista zasobów Pierwszym krokiem w metodzie USE jest utworzenie listy zasobów. Spróbuj przygotowaè jak najpeđniejszæ listú. Poniľej przedstawiono ogólnæ listú zasobów sprzútowych serwera wraz z konkretnymi przykđadami: 

procesor — rodzaj gniazda, liczba rdzeni, wætki sprzútowe (procesory wirtualne);



pamiúè operacyjna — DRAM;



interfejsy sieciowe — porty Ethernet;



pamiúè masowa — dyski twarde;



kontrolery — pamiúè masowa, sieè;



magistrale — procesora, pamiúci, wejħcia-wyjħcia.

Kaľdy komponent zwykle dziađa w charakterze zasobu pojedynczego typu. Na przykđad pamiúè masowa jest zasobem o pewnej pojemnoħci, natomiast interfejsy sieciowe sæ zasobami wejħcia-wyjħcia (to moľe oznaczaè IOPS lub przepustowoħè). Niektóre komponenty mogæ byè zasobami o wielu typach, na przykđad urzædzenie pamiúci masowej jest

2.5. Metodologia

79

jednoczeħnie zasobem o danej pojemnoħci i zasobem wejħcia-wyjħcia. Pod uwagú weļ wszystkie typy, które mogæ powodowaè tworzenie wæskich gardeđ w wydajnoħci. Pamiútaj równieľ, ľe zasoby wejħcia-wyjħcia moľna jeszcze analizowaè jako systemy kolejkowe, które kolejkujæ, a nastúpnie obsđugujæ otrzymywane ľædania. Pewne komponenty fizyczne, takie jak sprzútowe bufory (na przykđad pamiúci podrúczne procesora), moľna pominæè na liħcie. Metoda USE jest najbardziej efektywna w przypadku zasobów, których dotyka spadek wydajnoħci na skutek duľego obciæľenia lub nasycenia, co z kolei prowadzi do powstania wæskich gardeđ systemu. Natomiast pamiúè podrúczna moľe poprawiè wydajnoħè w przypadku duľego obciæľenia. O tym moľna siú przekonaè za pomocæ innych metodologii. Jeľeli nie jesteħ pewien, czy dany zasób umieħciè na liħcie, wówczas umieħè go, a nastúpnie przekonaj siú, jak metryki sprawdzajæ siú w praktyce.

Wykres bloku funkcjonalnego Innym sposobem iteracji przez zasoby jest wyszukanie lub utworzenie wykresu bloku funkcjonalnego systemu, na przykđad takiego jak przedstawiony na rysunku 2.13. Tego rodzaju wykres pokazuje relacje miúdzy komponentami, co moľe okazaè siú niezwykle uľyteczne podczas wyszukiwania wæskich gardeđ w przepđywie danych.

Rysunek 2.13. Przykład wykresu dwuprocesorowego bloku funkcjonalnego

Procesor, pamiúè, magistrale i szyny wejħcia-wyjħcia to najczúħciej przeoczane komponenty. Na szczúħcie one nie sæ z reguđy wæskimi gardđami systemu, poniewaľ zwykle projektuje siú je w celu zapewnienia wystarczajæco duľej przepustowoħci. Niestety, jeħli jednak okaľæ siú problemem, wówczas niewiele da siú zrobiè. Byè moľe rozwiæzaniem okaľe siú wymiana pđyty gđównej lub zmniejszenie obciæľenia — na przykđad projekty typu „zero kopiowania” mogæ zmniejszyè obciæľenie szyny pamiúci. W celu analizy magistrali zapoznaj siú z punktem 6.4.1 w rozdziale 6., zatytuđowanym „Procesory”.

80

Rozdział 2



Metodologia

Metryki Po przygotowaniu listy zasobów trzeba wziæè pod uwagú typy metryk: wykorzystanie, nasycenie i bđúdy. W tabeli 2.5 przedstawiono wybrane przykđady zasobów i typów metryk wraz z ich moľliwymi wartoħciami (ogólnie dotyczæce systemu operacyjnego). Tabela 2.5. Przykłady metryk stosowanych w metodzie USE Zasób

Typ

Metryka

Procesor

poziom wykorzystania

Poziom wykorzystania procesora (względem poszczególnych procesorów lub wartość średnia dla komputera).

Procesor

nasycenie

Długość kolejki zadań do wykonania (inaczej długość kolejki zadań bieżących).

Pamięć

poziom wykorzystania

Ilość wolnej pamięci (wartość dla całego systemu).

Pamięć

nasycenie

Anonimowe stronicowanie, zrzucanie wątków (skanowanie stron to kolejny wskaźnik) i zdarzenia informujące o braku pamięci.

Interfejs sieciowy

poziom wykorzystania

Przepustowość wykorzystana/maksymalna, szybkość transmisji/maksymalna.

Wejście-wyjście urządzenia pamięci masowej

poziom wykorzystania

Wartość procentowa wskazująca stopień zajętości urządzenia.

Wejście-wyjście urządzenia pamięci masowej

nasycenie

Długość kolejki oczekiwania.

Wejście-wyjście urządzenia pamięci masowej

błędy

Błędy urządzenia („błahe” i „poważne”).

Wymienione metryki mogæ byè wartoħciami ħrednimi w danym przedziale czasu lub wartoħciami liczników. Proces trzeba powtórzyè dla wszystkich kombinacji i dođæczyè instrukcje pobrania wszystkich metryk. Pod uwagú weļ metryki aktualnie niedostúpne — to búdæ „znane niewiadome”. Przygotowana lista powinna zawieraè okođo 30 metryk, czúħè z nich okaľe siú trudna do zmierzenia, a inne w ogóle nie búdæ mierzalne. Na szczúħcie wiúkszoħè najczúħciej pojawiajæcych siú problemów moľna znaleļè dziúki uľyciu đatwych metryk (takich jak: nasycenie procesora, nasycenie pojemnoħci pamiúci, wykorzystanie interfejsu sieciowego, wykorzystanie dysku) i dlatego warto je sprawdziè w pierwszej kolejnoħci. W tabeli 2.6 znajdziesz przykđady trudniejszych kombinacji metryk. Czúħè z przedstawionych metryk moľe byè niedostúpna za pomocæ standardowych narzúdzi oferowanych przez system operacyjny, dlatego konieczne moľe okazaè siú uľycie monitorowania dynamicznego lub funkcji liczników wydajnoħci procesora. W dodatku A znajduje siú przykđadowa lista rzeczy do zrobienia w metodzie USE dla systemów operacyjnych z rodziny Linux. Dodatek ten pokazuje przeprowadzenie iteracji przez wszystkie kombinacje zasobów sprzútowych oraz narzúdzia monitorowania dostúpne w systemie Linux. Z kolei w dodatku B zamieszczono tú samæ listú, ale dla systemów Solaris. W obu wymienionych dodatkach uwzglúdniono zasoby oprogramowania.

2.5. Metodologia

81

Tabela 2.6. Przykłady zaawansowanych metryk stosowanych w metodzie USE Zasób

Typ

Metryka

Procesor

błędy

Na przykład możliwe do skorygowania (ang. Error-Correcting Code; kodowanie korekcyjne) zdarzenia bufora procesora lub wadliwe działanie procesora (o ile system operacyjny i sprzęt obsługują tę możliwość).

Pamięć

błędy

Na przykład zakończone niepowodzeniem wywołania malloc() — jest to jednak zwykle wynikiem wyczerpania pamięci wirtualnej, a nie fizycznej.

Sieć

nasycenie

Błędy związane z nasyceniem interfejsu sieciowego z systemem operacyjnym, na przykład przepełnienie bufora w systemie Linux lub błąd typu „nocanput” w systemie Solaris.

Kontroler pamięci masowej

poziom wykorzystania

Zależy od kontrolera, może to być maksymalna wartość IOPS lub przepustowość, którą można porównać z aktualną działalnością.

Magistrala procesora

poziom wykorzystania

Przepustowość maksymalna i poszczególnych portów (liczniki wydajności procesora).

Magistrala pamięci

nasycenie

Cykle opóźnienia pamięci, liczba cykli na instrukcję (liczniki wydajności procesora).

Magistrala wejścia-wyjścia

poziom wykorzystania

Przepustowość szyny i przepustowość maksymalna (liczniki wydajności mogą istnieć w sprzęcie, na przykład wbudowane w mikroprocesorach firmy Intel zdarzenia „uncore”).

Zasoby oprogramowania W podobny sposób moľna przeanalizowaè pewne zasoby w postaci oprogramowania. To z reguđy dotyczy mniejszych komponentów oprogramowania, a nie cađych aplikacji, na przykđad: 







Blokady muteksu. Poziom wykorzystania moľna zdefiniowaè jako czas trwania blokady, natomiast nasycenie jako wætki kolejkowane w oczekiwaniu na zniesienie blokady. Pule wætków. Poziom wykorzystania moľna zdefiniowaè jako czas, przez jaki wætki byđy zajúte wykonywaniem zadaē. Natomiast nasycenie to liczba ľædaē oczekujæcych na obsđugú przez pulú wætków. Pojemnoħè proces/wætek. System moľe mieè ograniczonæ liczbú procesów lub wætków, których bieľæce uľycie moľna zdefiniowaè jako poziom wykorzystania. Oczekiwanie na alokacjú moľna okreħliè jako nasycenie. Bđúdy wystúpujæ, gdy alokacja zakoēczy siú niepowodzeniem (na przykđad bđæd typu „cannot fork”). Pojemnoħè deskryptorów plików. Podobnie jak w przypadku pojemnoħci proces/wætek, ale dotyczy deskryptorów plików.

82

Rozdział 2



Metodologia

Jeľeli w analizowanym przez Ciebie przykđadzie metryki sprawdzajæ siú dobrze, wtedy uľywaj ich. W przeciwnym razie naleľy stosowaè alternatywne metodologie, na przykđad analizú opóļnienia.

Zalecane interpretacje Poniľej przedstawiono pewne ogólne sugestie dotyczæce interpretacji typów metryk: 





Poziom wykorzystania. Wykorzystanie na poziomie 100% najczúħciej jest oznakæ wæskiego gardđa (aby to potwierdziè, sprawdļ nasycenie i jego wpđyw). Wykorzystanie na poziomie przekraczajæcym 60% moľe byè problemem co najmniej z kilku powodów, miúdzy innymi zaleľnoħci od przedziađu czasu i moľliwoħci ukrycia krótkotrwađych skoków wykorzystania do poziomu 100%. Ponadto operacje wykonywane przez pewne zasoby, takie jak dyski twarde (ale nie procesory), zwykle nie mogæ byè przerywane, nawet przez zadania o wyľszym priorytecie. Wraz ze wzrostem poziomu wykorzystania opóļnienie zwiæzane z kolejkowaniem staje siú coraz czústsze i zauwaľalne. Zapoznaj siú z punktem 2.6.5 „Teoria kolejek”, w którym znajdziesz wiúcej informacji na temat zagroľeē przy poziomie wykorzystania przekraczajæcym 60%. Nasycenie. Kaľdy niezerowy poziom nasycenia moľe byè problemem. Nasycenie moľna mierzyè dđugoħciæ kolejki oczekiwania lub czasem oczekiwania w kolejce. Bđúdy. Niezerowe liczniki bđúdów warto sprawdziè, zwđaszcza jeħli liczba bđúdów roħnie, a wydajnoħè jest kiepska.

Bardzo đatwo moľna interpretowaè przypadki negatywne: niski poziom wykorzystania, brak nasycenia, brak bđúdów. Taka moľliwoħè jest znacznie uľyteczniejsza, niľ mogđoby siú wydawaè, poniewaľ zawúľenie obszaru analizy pomaga skoncentrowaè siú na problemie. Odbywa siú to wskutek uznania, ľe dany zasób prawdopodobnie nie stanowi ļródđa problemu — to jest proces eliminacji.

Przetwarzanie w chmurze W ħrodowisku przetwarzania w chmurze kontrola zasobów oprogramowania moľe byè stosowana w celu ograniczenia liczby tenantów wspóđdzielæcych pojedynczy system. W firmie Joyent koncentrujemy siú przede wszystkim na wirtualizacji systemu operacyjnego (strefy SmartOS), co wiæľe siú z ograniczeniami dotyczæcymi pamiúci, procesora i wejħcia-wyjħcia pamiúci masowej. Kaľde ograniczenie wymienionych zasobów moľna przeanalizowaè za pomocæ metody USE, podobnie jak w przypadku analizy zasobów fizycznych. Na przykđad „wykorzystanie pamiúci” moľe oznaczaè stopieē uľycia pamiúci przez tenant wzglúdem cađkowitej iloħci przydzielonej mu pamiúci. Z kolei na „nasycenie pamiúci” wskazuje wystúpowanie anonimowego stronicowania, nawet gdy tradycyjny skaner stron pozostaje bezczynny.

2.5. Metodologia

83

2.5.10. Charakterystyka obciążenia Charakterystyka obciæľenia to prosta i efektywna metoda identyfikacji problemów pojawiajæcych siú na skutek danego obciæľenia. W tej metodzie koncentrujemy siú na danych wejħciowych systemu zamiast na osiægniútej wydajnoħci koēcowej. W systemie mogæ nie wystúpowaè problemy natury architekturalnej lub konfiguracyjnej, ale zadane mu obciæľenie moľe okazaè siú wiúksze niľ moľliwoħci systemu w zakresie jego rozsædnej obsđugi. Obciæľenie moľna scharakteryzowaè, udzielajæc odpowiedzi na nastúpujæce pytania: 







Co powoduje obciæľenie? Jaki jest identyfikator procesu lub uľytkownika powodujæcego obciæľenie? Jaki jest zdalny adres IP? Dlaczego dane obciæľenie zostađo zastosowane? Jaka jest ħcieľka kodu i stos wywođaē? Jak przedstawia siú charakterystyka danego obciæľenia? Jakie sæ wartoħci IOPS, przepustowoħci i jaki jest wykonywany rodzaj operacji (odczyt/zapis)? Kiedy zachodzi potrzeba, umieħè tutaj informacje o zaobserwowanych zmianach (odchylenie standardowe). Czy dane obciæľenie ulega zmianie na przestrzeni czasu? Czy istnieje jakiħ wzorzec, który moľna przypisaè obciæľeniu?

Rozsædne búdzie znalezienie odpowiedzi na wszystkie wymienione pytania. Nawet jeħli jesteħ przekonany, ľe wiesz, jak búdæ przedstawiađy siú odpowiedzi — moľesz byè zaskoczony. Przeanalizujmy nastúpujæcy scenariusz: masz problem zwiæzany z wydajnoħciæ dziađania bazy danych, której klientami jest pula serwerów WWW. Czy powinieneħ sprawdzaè adresy IP systemów, z których pochodzæ zapytania wykonywane do bazy danych? Oczekujesz, ľe zgodnie z konfiguracjæ búdæ to serwery WWW. Mimo wszystko sprawdzasz to i przekonujesz siú, ľe cađy internet wđaħnie stara siú uzyskaè dostúp do bazy danych, co przekđada siú na znaczny spadek wydajnoħci jej dziađania. Tak naprawdú baza danych jest celem ataku typu DoS (ang. Denial of Service; odmowa usđug)! Najlepszym sposobem zwiúkszenia wydajnoħci dziađania búdzie pozbycie siú niepotrzebnie wykonywanych zadaē. Czasami zadania siú wykonywane niepotrzebnie ze wzglúdu na bđúdne funkcjonowanie aplikacji, na przykđad gdy wætek búdzie zablokowany w pútli i spowoduje zbúdne obciæľenie procesora. Powodem moľe byè równieľ nieprawidđowa konfiguracja, na przykđad wykonywana w trakcie godzin pracy kopia zapasowa cađego systemu. Inny powód to atak typu DoS, jak przedstawiono w poprzednim akapicie. Dziúki przygotowaniu charakterystyki obciæľenia moľna wykryè wspomniane problemy, które na skutek obsđugi bædļ ponownej konfiguracji mogæ zostaè wyeliminowane. Jeľeli zidentyfikowane obciæľenie nie moľe byè wyeliminowane, moľna zastosowaè inne podejħcie, polegajæce na uľyciu zasobów systemowych pozwalajæcych na kontrolú wspomnianego obciæľenia. Na przykđad operacja tworzenia kopii zapasowej wpđywa negatywnie na dziađanie produkcyjnej bazy danych, poniewaľ wykorzystuje moc procesora do kompresji kopii zapasowej oraz uľywa zasobów sieciowych do jej transferu.

84

Rozdział 2



Metodologia

Poziom uľycia procesora i sieci moľna wiúc ograniczyè przez kontrolú zasobów (o ile system obsđuguje takæ funkcjú), aby tworzenie kopii zapasowej nadal siú odbywađo (jednak znacznie wolniej), lecz bez negatywnego wpđywu na bazú danych. Poza identyfikacjæ problemów charakterystyka obciæľenia moľe dostarczaè takľe danych przydatnych podczas przygotowywania testów wydajnoħci. Jeľeli zmierzone obciæľenie jest ħredniæ, idealnym rozwiæzaniem búdzie zebranie takľe danych dotyczæcych rozkđadu i odchylenia obciæľenia. To jest bardzo potrzebne do symulacji róľnorodnoħci oczekiwanego obciæľenia — nie naleľy ograniczaè siú do przetestowania ħredniego obciæľenia. W rozdziale 12. „Testy wydajnoħci” i podrozdziale 2.8 „Statystyka” znajdziesz wiúcej informacji na temat wartoħci ħrednich oraz ich zmian (odchylenie standardowe). Analiza obciæľenia pomaga równieľ w oddzieleniu problemów zwiæzanych z obciæľeniem od problemów zwiæzanych z architekturæ, co odbywa siú na skutek identyfikacji tych pierwszych. Zagadnienie „obciæľenie kontra architektura” zostađo wprowadzone w podrozdziale 2.3, zatytuđowanym „Koncepcje”. Konkretne narzúdzia i metryki sđuľæce do przeprowadzania charakterystyki obciæľenia zaleľæ od sprawdzanego systemu. Niektóre aplikacje dokđadnie rejestrujæ dziađalnoħè klienta. Uzyskane w ten sposób dane mogæ sđuľyè do analizy statystycznej, a takľe do przygotowywania dziennych lub miesiúcznych raportów zawierajæcych dokđadne informacje dotyczæce dziađalnoħci klienta.

2.5.11. Analiza drążąca Analiza dræľæca rozpoczyna siú od przeanalizowania problemu na ogólnym poziomie, a nastúpnie polega na coraz wiúkszym zawúľaniu badanego obszaru na podstawie wczeħniejszych odkryè. Odbywa siú to wskutek odrzucania nieinteresujæcych obszarów i dræľenia coraz bardziej tych, które wydajæ siú interesujæce. Cađy proces moľe wymagaè przekopania siú przez gđúbokie warstwy stosu oprogramowania aľ do warstwy sprzútowej (o ile to konieczne), aby znaleļè przyczynú problemu. Metodologia analizy dræľæcej dotyczæcej wydajnoħci systemu zostađa omówiona w ksiæľce Solaris Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris (patrz odwođanie [McDougall 06b] na koēcu rozdziađu). Moľna jæ podzieliè na trzy etapy: 1. Monitorowanie. Nieustanne rejestrowanie danych statystycznych na ogólnym poziomie, a takľe identyfikowanie ewentualnych problemów i informowanie o nich. 2. Identyfikacja. W przypadku podejrzenia istnienia problemu ten etap pozwala zawúziè analizú do konkretnych zasobów lub obszarów zainteresowania i zidentyfikowaè moľliwe wæskie gardđa. 3. Analiza. Dalsza analiza okreħlonych obszarów systemu jest przeprowadzana w celu znalezienia ļródđa problemu i dokonania jego oceny. Monitorowanie moľe byè przeprowadzane na poziomie firmy, a wyniki uzyskane dla wszystkich serwerów lub egzemplarzy w chmurze mogæ byè zagregowane. Tradycyjne rozwiæzanie polega na uľyciu protokođu SNMP (ang. Simple Network Monitoring Protocol), który moľna wykorzystaè do monitorowania wszelkich urzædzeē istniejæcych

2.5. Metodologia

85

w sieci i obsđugujæcych wymieniony protokóđ. Zebrane w wyniku monitorowania dane mogæ pokazywaè dđugoterminowe wzorce, które wczeħniej mogđy zostaè pominiúte podczas uľywania narzúdzi powđoki przez krótki czas. Wiele narzúdzi monitorowania umoľliwia wygenerowanie ostrzeľeē, gdy istnieje prawdopodobieēstwo problemu. Dziúki temu moľna przejħè do kolejnego kroku. Identyfikacja odbywa siú interaktywnie w serwerze i jest przeprowadzana za pomocæ standardowych narzúdzi przeznaczonych do sprawdzania komponentów systemu: procesorów, dysków, pamiúci itd. Z reguđy oznacza sesjú powđoki z uľyciem poleceē, takich jak: vmstat, iostat i mpstat. Niektóre nowsze narzúdzia umoľliwiajæ przeprowadzanie analizy wydajnoħci w czasie rzeczywistym za pomocæ graficznego interfejsu uľytkownika (przykđadem moľe byè tutaj Oracle ZFS Storage Appliance Analytics). Narzúdzia analizy bazujæ na monitorowaniu lub profilowaniu, co pozwala na dokđadniejsze zbadanie podejrzanych obszarów. Tego rodzaju gđúbsza analiza moľe obejmowaè takľe utworzenie wđasnych narzúdzi oraz przeglæd kodu ļródđowego (o ile jest dostúpny). W taki wđaħnie sposób przeprowadzana jest wiúkszoħè analizy dræľæcej — przedzierajæc siú przez warstwy stosu oprogramowania, szukasz przyczyny problemu. Narzúdzia sđuľæce do tego rodzaju analizy to miúdzy innymi: strace, truss, perf i DTrace.

Pięć pytań typu „dlaczego” Dodatkowæ metodologiæ, której moľna uľyè podczas omawianej fazy analizy, jest technika piúciu pytaē typu „dlaczego”: zadaj sobie pytanie, a nastúpnie udziel na nie odpowiedzi. Procedurú powtórz co najmniej piúciokrotnie. Oto przykđadowa procedura: 1. W przypadku wielu zapytaē wydajnoħè dziađania bazy danych spadđa. Dlaczego? 2. Opóļnienie jest powodowane przez dyskowe operacje wejħcia-wyjħcia wystúpujæce ze wzglúdu na stronicowanie. Dlaczego? 3. Baza danych zaczúđa uľywaè ogromnych iloħci pamiúci. Dlaczego? 4. Biblioteka zuľywa wiúcej pamiúci niľ powinna. Dlaczego? 5. W bibliotece istnieje problem fragmentacji pamiúci. Dlaczego? Powyľsze pytania to rzeczywisty przykđad, w tym przypadku doprowadziđy one do usuniúcia problemu zwiæzanego z alokacjæ pamiúci w bibliotece. Procedura polegađa na ciægđym dræľeniu w celu dotarcia do przyczyny problemu i jego wyeliminowania.

2.5.12. Analiza opóźnienia Analiza opóļnienia oznacza sprawdzenie iloħci czasu koniecznego do ukoēczenia danej operacji. Wspomniana analiza jest dzielona na mniejsze fragmenty, które z kolei sæ dzielone na kolejne. Ma to na celu rozbicie fragmentów o najwiúkszym opóļnieniu, aby moľna byđo znaleļè przyczynú problemu i jego rozwiæzanie. Podobnie jak w przypadku analizy dræľæcej, analiza opóļnienia moľe oznaczaè dræľenie przez warstwy stosu oprogramowania, aľ do znalezienia ļródđa problemów zwiæzanych z opóļnieniem.

86

Rozdział 2



Metodologia

Analizú moľna rozpoczæè od przejrzenia nađoľonego obciæľenia, zbadaè sposób jego przetwarzania w aplikacji, a nastúpnie przystæpiè do dræľenia w kierunku bibliotek systemu operacyjnego, wywođaē systemowych, jædra oraz sterowników urzædzeē. Na przykđad analiza opóļnienia zapytania MySQL moľe obejmowaè udzielenie odpowiedzi na przedstawione pytania (podano równieľ przykđadowe odpowiedzi): 1. Czy jest opóļnienie podczas wykonywania danego zapytania? (Tak) 2. Czy podczas wykonywania zapytania wiúkszoħè czasu jest poħwiúcona na operacje wykonywane przez procesor, czy na oczekiwanie na system? (Oczekiwanie na system) 3. Na co dokđadnie trzeba czekaè? (Na zakoēczenie operacji wejħcia-wyjħcia systemu plików) 4. Czy czas wykonywania operacji wejħcia-wyjħcia systemu plików wiæľe siú z dyskowymi operacjami wejħcia-wyjħcia, czy raczej z oczekiwaniem na zwolnienie blokady? (Z dyskowymi operacjami wejħcia-wyjħcia) 5. Czy czas trwania dyskowych operacji wejħcia-wyjħcia wiæľe siú z losowymi operacjami wyszukiwania, czy raczej z transferem danych? (Z transferem danych) W omawianym przykđadzie w trakcie kaľdego kroku procedury zadawane jest jedno pytanie dzielæce opóļnienie na dwie czúħci, nastúpnie przechodzimy do analizy wiúkszego opóļnienia. Moľna to nazwaè wyszukiwaniem binarnym. Sam proces zostađ pokazany na rysunku 2.14.

Rysunek 2.14. Procedura analizy opóźnienia

Po zidentyfikowaniu wiúkszego opóļnienia (A lub B) odpowiedni fragment jest dalej dzielony na A i B, analizowany, ponownie dzielony itd.

2.5. Metodologia

87

Analiza opóļnienia zapytaē wykonywanych do bazy danych jest przedmiotem metody R.

2.5.13. Metoda R Metoda R to metodologia analizy wydajnoħci opracowana dla baz danych Oracle. Koncentruje siú na znalezieniu ļródđa opóļnienia na podstawie analizy zdarzeē monitorowania Oracle (patrz odwođanie [Millsap 03] na koēcu rozdziađu). Metodologia ta jest opisana jako „oparta na czasie udzielania odpowiedzi metoda poprawy wydajnoħci, oferujæca maksymalnæ wartoħè ekonomicznæ dla Twojego biznesu” oraz jako skoncentrowana na identyfikacji i ocenie tego, co zajmuje najwiúcej czasu podczas wykonywania zapytaē. Wprawdzie omawiana metoda jest uľywana w przypadku baz danych, jednak stosowane przez niæ podejħcie moľna wykorzystaè takľe do analizy systemów. Dlatego zostađa tutaj wymieniona, jako jedna z moľliwoħci, któræ warto sprawdziè.

2.5.14. Monitorowanie zdarzeń Dziađanie systemu operacyjnego polega na przetwarzaniu poszczególnych zdarzeē. Obejmujæ one instrukcje procesora, dyskowe operacje wejħcia-wyjħcia i inne polecenia, pakiety systemowe, wywođania systemowe, wywođania bibliotek, transakcje aplikacji, zapytania do bazy danych itd. Analiza wydajnoħci zwykle wymaga zbadania podsumowania przygotowanego na podstawie wymienionych zdarzeē, na przykđad przybierajæcego postaè liczby operacji na sekundú, bajtów na sekundú lub ħredniego opóļnienia. Czasami dzieje siú tak, ľe waľne szczegóđy ginæ w podsumowaniu; zdarzenia moľna najlepiej zrozumieè, gdy sæ analizowane pojedynczo. Problemy zwiæzane z sieciæ najczúħciej wymagajæ analizy pakiet po pakiecie, przeprowadzanej za pomocæ polecenia takiego jak tcpdump. Przedstawione dane wyjħciowe zawierajæ podsumowanie pakietów obejmujæcych dane skđadajæce siú na jeden wiersz tekstu: # tcpdump -ni eth4 -ttt tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth4, link-type EN10MB (Ethernet), capture size 65535 bytes 00:00:00.000000 IP 10.2.203.2.22 > 10.2.0.2.33986: Flags [P.], seq 1182098726:1182098918, ack 4234203806, win 132, options [nop,nop,TS val 1751498743 ecr 1751639660], length 192 00:00:00.000392 IP 10.2.0.2.33986 > 10.2.203.2.22: Flags [.], ack 192, win 501, options [nop,nop,TS val 1751639684 ecr 1751498743], length 0 00:00:00.009561 IP 10.2.203.2.22 > 10.2.0.2.33986: Flags [P.], seq 192:560, ack 1, win 132, options [nop,nop,TS val 1751498744 ecr 1751639684], length 368 00:00:00.000351 IP 10.2.0.2.33986 > 10.2.203.2.22: Flags [.], ack 560, win 501, options [nop,nop,TS val 1751639685 ecr 1751498744], length 0 00:00:00.010489 IP 10.2.203.2.22 > 10.2.0.2.33986: Flags [P.], seq 560:896, ack 1, win 132, options [nop,nop,TS val 1751498745 ecr 1751639685], length 336 00:00:00.000369 IP 10.2.0.2.33986 > 10.2.203.2.22: Flags [.], ack 896, win 501, options [nop,nop,TS val 1751639686 ecr 1751498745], length 0

W zaleľnoħci od potrzeb polecenie tcpdump moľe wyħwietlaè róľnego rodzaju informacje (wiúcej na ten temat znajdziesz w rozdziale 10. „Sieè”).

88

Rozdział 2



Metodologia

W przypadku urzædzenia pamiúci masowej operacje wejħcia-wyjħcia na poziomie warstwy bloku urzædzenia moľna monitorowaè za pomocæ polecenia iosnoop (opartego na DTrace; wiúcej informacji na ten temat znajdziesz w rozdziale 9. „Dyski”). # ./iosnoop -Dots STIME(us) TIME(us) 722594048435 722594048553 722594048879 722594048983 722594049335 722594049552 722594049900 722594050029 722594050336 722594050457 722594050760 722594050864 722594051190 722594051262 722594051613 722594051678 722594051977 722594052067 722594052417 722594052515 722594052840 722594052902 722594053220 722594053290

DELTA 117 104 217 128 121 103 72 65 90 98 62 69

DTIME 130 109 229 137 127 110 80 72 97 105 68 77

UID 0 0 0 0 0 0 0 0 0 0 0 0

PID 485 485 485 485 485 485 485 485 485 485 485 485

D W W W W W W W W W W W W

BLOCK 95742054 95742106 95742154 95742178 95742202 95742226 95742250 95742318 95742342 95742366 95742422 95742446

SIZE 8192 8192 8192 8192 8192 8192 8192 8192 8192 8192 8192 8192

COMM ... zpool-... zpool-... zpool-... zpool-... zpool-... zpool-... zpool-... zpool-... zpool-... zpool-... zpool-... zpool-...

W przedstawionych danych znajduje siú wiele znaczników czasu, miúdzy innymi: poczætek (STIME), koniec (TIME), czas miúdzy ľædaniem a jego wykonaniem (DELTA), a takľe oszacowany czas potrzebny do obsđugi danej operacji wejħcia-wyjħcia (DTIME). Warstwa wywođaē systemowych to kolejny, czústo monitorowany obszar za pomocæ poleceē takich jak strace (systemy Linux) i truss (systemy Solaris). Wiúcej informacji na ich temat znajdziesz w rozdziale 5., zatytuđowanym „Aplikacje”. Wymienione narzúdzia oferujæ opcje umoľliwiajæce wyħwietlanie znaczników czasu. Podczas monitorowania zdarzeē skoncentruj siú na wyszukaniu poniľszych informacji: 





dane wejħciowe — wszystkie atrybuty ľædania zdarzenia: typ, kierunek, wielkoħè itd.; czas — czasy rozpoczúcia i zakoēczenia zdarzenia, a takľe opóļnienie (róľnica miúdzy wymienionymi czasami); wynik — bđúdy stanu, wynik zdarzenia (wielkoħè).

Niekiedy problem zwiæzany z wydajnoħciæ moľna zrozumieè za pomocæ analizy atrybutów zdarzenia (samego ľædania lub jego wyniku). Znaczniki czasu zdarzenia sæ szczególnie uľyteczne podczas analizy opóļnienia, czústo sæ wiúc umieszczane w danych wyjħciowych generowanych przez narzúdzia sđuľæce do monitorowania zdarzeē. Pokazane wczeħniej dane wyjħciowe polecenia tcpdump zawierajæ znaczniki czasu — pomiar czasu miúdzy poszczególnymi pakietami odbywa siú w wyniku uľycia opcji -ttt. Analiza wczeħniejszych zdarzeē moľe dostarczyè wiúkszej iloħci informacji. Zdarzenie o wrúcz koszmarnym opóļnieniu, nazywane elementem odstajæcym opóļnienia, moľe byè skutkiem wczeħniejszych zdarzeē. Na przykđad zdarzenie znajdujæce siú na koēcu kolejki moľe mieè wysokie opóļnienie, ale wynikajæce z wczeħniej kolejkowanych zdarzeē, a nie jego wđaħciwoħci. Tego rodzaju sytuacje moľna zidentyfikowaè dziúki monitorowaniu zdarzeē.

2.5. Metodologia

89

2.5.15. Dane statystyczne będące punktem odniesienia Porównanie bieľæcych metryk wydajnoħci z wczeħniejszymi wartoħciami czústo jest pouczajæce. Umoľliwia to identyfikacjú zmian w obciæľeniu lub poziomie uľycia zasobów oraz odkrycie ļródeđ ewentualnych problemów. Niektóre narzúdzia sđuľæce do monitorowania (bazujæce na licznikach znajdujæcych siú w jædrze) mogæ wyħwietlaè podsumowanie informacji dotyczæce okresu od chwili uruchomienia komputera, co pozwala na porównanie z bieľæcæ dziađalnoħciæ. To niezbyt dokđadne, ale i tak lepsze niľ nic. Inne podejħcie to zebranie danych statystycznych búdæcych punktem odniesienia. Wspomniana operacja moľe obejmowaè uruchomienie szeregu narzúdzi monitorowania na poziomie systemu i zapisanie zebranych informacji w celu póļniejszego odnoszenia siú do nich. W przeciwieēstwie do podsumowania dotyczæcego czasu od chwili uruchomienia komputera, które moľe ukrywaè odchylenia, dane statystyczne búdæce punktem odniesienia mogæ zawieraè dane dla krótkiego przedziađu czasu (na przykđad 1 s), co pozwoli na dostrzeľenie ewentualnych odchyleē. Dane statystyczne búdæce punktem odniesienia moľna zbieraè zarówno przed wprowadzeniem zmiany w systemie lub aplikacji, jak i po jej wprowadzeniu, co umoľliwia przeanalizowanie zmiany wydajnoħci. Wspomniane dane moľna zbieraè nieregularnie i dođæczyè odpowiedniæ dokumentacjú lokalnæ, aby administratorzy systemów wiedzieli, co jest uznawane za „normú”. Aby zadanie moľna byđo wykonywaè w regularnych odstúpach czasu kaľdego dnia, tego rodzaju aktywnoħè jest obsđugiwana przez monitorowanie wydajnoħci (patrz podrozdziađ 2.9 „Monitorowanie”).

2.5.16. Statyczne dostosowanie wydajności Statyczne dostosowanie wydajnoħci koncentruje siú na kwestiach skonfigurowanej architektury. Inne metodologie skupiajæ siú na wydajnoħci przy danym obciæľeniu: to jest wydajnoħè dynamiczna (patrz odwođanie [Elling 00] na koēcu rozdziađu). Statyczna analiza wydajnoħci moľe byè przeprowadzona, gdy system jest bezczynny, czyli nie znajduje siú pod ľadnym obciæľeniem. W przypadku statycznej analizy wydajnoħci i jej dostosowywania naleľy przejrzeè wszystkie komponenty systemu i odpowiedzieè na nastúpujæce pytania: 

Czy dany komponent ma sens?



Czy dana konfiguracja ma sens, bioræc pod uwagú przewidywane obciæľenie?





Czy dany komponent jest skonfigurowany w najlepszy sposób, bioræc pod uwagú przewidywane obciæľenie? Czy wystæpiđy jakiekolwiek bđúdy zwiæzane z danym komponentem i czy dziađa on w ograniczonym zakresie?

Oto kilka przykđadów problemów, które moľna odkryè, posđugujæc siú statycznym dostosowaniem wydajnoħci: 

negocjacja szybkoħci interfejsu sieciowego: wybór 100 Mb/s zamiast 1 Gb/s;



uszkodzony dysk w puli macierzy RAID;

90

Rozdział 2

 

 



Metodologia

uľyta starsza wersja systemu operacyjnego, aplikacji lub firmware’u; wielkoħè rekordu systemu plików niedopasowana do wielkoħci obciæľenia wejħcia-wyjħcia; serwer przypadkowo skonfigurowany jako router; serwer skonfigurowany do uľycia zasobów, takich jak mechanizm uwierzytelnienia, ze zdalnego centrum danych zamiast danych lokalnych.

Na szczúħcie tego rodzaju problemy moľna đatwo znaleļè. Najtrudniejsze w cađym procesie jest pamiútanie o koniecznoħci ich wyszukania!

2.5.17. Dostosowanie bufora Systemy operacyjne i aplikacje mogæ wykorzystywaè wiele buforów w celu poprawy wydajnoħci wejħcia-wyjħcia. Wspomniane bufory mogæ znajdowaè siú na róľnych poziomach, od aplikacji po fizyczne dyski. Dokđadne omówienie buforów znajdziesz w punkcie 3.2.11 w rozdziale 3. „Systemy operacyjne”. Oto ogólna strategia dotyczæca dostrajania buforów na poszczególnych poziomach: 1. Staraj siú stosowaè bufor na jak najwyľszym poziomie na stosie, aby znajdowađ siú maksymalnie blisko wykonywanych zadaē. W ten sposób moľna zmniejszyè operacyjne obciæľenie zwiæzane z trafnoħciæ bufora. 2. Upewnij siú, ľe bufor zostađ wđæczony i dziađa. 3. Sprawdļ wskaļniki trafnoħci/nietrafnoħci i trafnoħci bufora. 4. Jeľeli bufor ma dynamicznie ustalanæ wielkoħè, sprawdļ jego wielkoħè bieľæcæ. 5. Dostosuj bufor do danego obciæľenia. Wykonanie tego zadania zaleľy od dostúpnych parametrów dostrajania bufora. 6. Dostosuj obciæľenie do danego bufora. Wykonanie tego zadania oznacza usuniúcie z bufora niepotrzebnych obiektów i tym samym zwolnienie miejsca dla potrzebnych obiektów. Sprawdļ, czy nie wystúpuje podwójne buforowanie — to mogæ byè na przykđad dwa róľne bufory zuľywajæce pamiúè operacyjnæ i dwukrotnie buforujæce te same dane. Rozwaľ równieľ ogólny przyrost wydajnoħci na skutek dostrajania buforów na poszczególnych poziomach. Dostrojenie pamiúci podrúcznej poziomu pierwszego dla procesora moľe zaoszczúdziè nanosekundy, a nietrafienie bufora búdzie obsđuľone przez pamiúè podrúcznæ poziomu drugiego. Jednak poprawienie pamiúci podrúcznej poziomu trzeciego moľe pozwoliè uniknæè uľycia znacznie wolniejszej pamiúci DRAM i przynieħè najwiúkszy przyrost wydajnoħci dziađania. (Wymienione pamiúci podrúczne procesorów zostađy dokđadniej omówione w rozdziale 6., zatytuđowanym „Procesory”).

2.6. Modelowanie

91

2.5.18. Mikrotesty wydajności Mikrotesty wydajnoħci pozwalajæ na sprawdzenie wydajnoħci w przypadku prostego i sztucznego obciæľenia. Moľna je przeprowadzaè w celu uzupeđnienia metody naukowej, testujæc hipotezú i sprawdzajæc przewidywany wynik, lub teľ wykorzystaè jako czúħè wiúkszego èwiczenia polegajæcego na planowaniu pojemnoħci. To siú znacznie róľni od przemysđowych testów wydajnoħci, których celem jest najczúħciej przetestowanie wydajnoħci pod rzeczywistym i naturalnym obciæľeniem. Tego rodzaju testy wydajnoħci sæ przeprowadzane w wyniku uruchomienia symulatorów obciæľenia i mogæ byè trudne do przeprowadzenia oraz zrozumienia. Mikrotesty wydajnoħci sæ znacznie mniej skomplikowane do przeprowadzenia i đatwiejsze do zrozumienia, poniewaľ mniejsza liczba czynników odgrywa w nich rolú. Mogæ byè przeprowadzane za pomocæ narzúdzia sđuľæcego do mikrotestów, które powoduje nađoľenie obciæľenia i wykonanie pomiaru wydajnoħci. Ewentualnie moľna uľyè generatora obciæľenia, który jedynie nakđada obciæľenie, a pomiar wydajnoħci pozostawia standardowym narzúdziom systemowym. Oba wymienione podejħcia sæ dobre, ale bezpieczniejszym rozwiæzaniem búdzie uľycie narzúdzia do przeprowadzania mikrotestów oraz dwukrotne sprawdzenie wydajnoħci za pomocæ standardowych narzúdzi systemowych. Poniľej wymieniono przykđady mikrotestów wydajnoħci: 





Czas wywođaē systemowych. Dotyczy wywođaē takich jak: fork(), exec(), open(), read() i close(). Odczyty systemu plików. Dotyczy odczytu buforowanych plików o wielkoħciach od 1 B do 1 MB. Przepustowoħè sieci. Dotyczy przekazywania danych miúdzy punktami koēcowymi TCP z zastosowaniem róľnych wielkoħci bufora gniazda.

Mikrotesty wydajnoħci zwykle bardzo szybko wykonujæ zleconæ im operacjú i podajæ czas, jaki zajúđoby wykonanie ogromnej liczby takich operacji. Nastúpnie moľna obliczyè czas ħredni (czas ħredni = czas dziađania / liczba operacji). W dalszych rozdziađach znajdziesz przedstawienie metodologii charakterystycznych dla mikrotestów wydajnoħci wraz z ich celami i atrybutami. Szczegóđowe omówienie tematu testów wydajnoħci przedstawiono w rozdziale 12., zatytuđowanym „Testy wydajnoħci”.

2.6. Modelowanie Analityczne modelowanie systemu moľna wykorzystaè do wielu róľnych celów, w szczególnoħci do analizy skalowalnoħci, czyli sprawdzenia, jak wydajnoħè búdzie skalowana wraz ze zmianæ obciæľenia lub zasobów. Wspomnianymi zasobami mogæ byè komponenty sprzútowe, takie jak rdzenie procesora, bædļ teľ oprogramowanie, na przykđad procesy lub wætki. Modelowanie analityczne moľna uwaľaè za trzeci rodzaj oceny dziađaē wydajnoħci, obok omówionych wczeħniej: monitorowania systemu produkcyjnego (pomiar) i testowania

92

Rozdział 2



Metodologia

eksperymentalnego (symulacja) — (patrz odwođanie [Jain 91] na koēcu rozdziađu). Wydajnoħè moľna najlepiej zrozumieè po wykonaniu przynajmniej dwóch z wymienionych dziađaē: modelowania analitycznego i symulacji lub symulacji i pomiaru. Jeľeli analiza dotyczy istniejæcego systemu, to moľna rozpoczæè od pomiaru: scharakteryzowaè obciæľenie i osiæganæ wydajnoħè. Analiza eksperymentalna na skutek testowania symulowanego obciæľenia równieľ moľe byè zastosowana, jeħli system nie znajduje siú jeszcze pod obciæľeniem produkcyjnym lub gdy zachodzi potrzeba przetestowania obciæľenia wiúkszego niľ stosowane w produkcji. Modelowanie analityczne moľna wykorzystaè do przewidywania wydajnoħci i opieraè na wynikach pomiaru lub symulacji. Analiza skalowalnoħci moľe ujawniè, ľe w okreħlonym punkcie wydajnoħè przestaje byè skalowania liniowo. Ten punkt nosi nazwú punktu zađamania, poniewaľ stanowi ograniczenie wynikajæce z zasobów. Wyszukanie tego rodzaju punktów oraz miejsca, do którego prowadzæ, moľe okazaè siú pomocne podczas analizy problemów wydajnoħci, zwiæzanych z niewydolnæ skalowalnoħciæ. Umoľliwi to usuniúcie znalezionych problemów, zanim pojawiæ siú w ħrodowisku produkcyjnym. Wiúcej informacji na temat wymienionych wczeħniej kroków znajdziesz w punktach 2.5.10 „Charakterystyka obciæľenia” i 2.5.18 „Mikrotesty wydajnoħci”.

2.6.1. Biznes kontra chmura Wprawdzie modelowanie pozwala na symulowanie ogromnych systemów biznesowych bez koniecznoħci ponoszenia wydatków na ich zakup, ale wydajnoħè w wielkich ħrodowiskach jest bardzo czústo skomplikowana i trudna do prawidđowego modelowania. W przypadku tak zwanej chmury istnieje moľliwoħè dzierľawy ħrodowiska o dowolnej skali i praktycznie na dowolny czas — nawet jedynie na czas potrzebny do przeprowadzenia testu wydajnoħci. Zamiast tworzyè matematyczny model przeznaczony do przewidywania wydajnoħci, obciæľenie moľna scharakteryzowaè, zasymulowaè, a nastúpnie — dziúki chmurze — moľna przetestowaè w róľnej skali. Niektóre odkrycia, na przykđad punkty zađamania, mogæ byè takie same, ale ich pođoľenie búdzie opierađo siú na zmierzonych wartoħciach, a nie na modelach teoretycznych. Dziúki przetestowaniu rzeczywistego ħrodowiska moľna odkryè ograniczenia, które nie búdæ widoczne w przygotowanym modelu.

2.6.2. Identyfikacja wizualna Jeľeli istnieje moľliwoħè zebrania wystarczajæcej iloħci wyników na drodze eksperymentów, umieszczenie ich na wykresie pokazujæcym wydajnoħè kontra skalowany parametr moľe pokazaè pewien wzorzec. Na rysunku 2.15 zobrazowano przepustowoħè aplikacji kontra liczba skalowanych wætków. Z wykresu wynika, ľe punkt zađamania znajduje siú w wætku ósmym. Dodanie kolejnego wætku nie powoduje juľ zwiúkszenia wydajnoħci na oczekiwanym poziomie. Dysponujæc takimi informacjami, moľna przystæpiè do dalszej analizy, na przykđad polegajæcej na badaniu aplikacji i konfiguracji systemu w poszukiwaniu jakiegokolwiek ustawienia o wartoħci w okolicach oħmiu.

2.6. Modelowanie

93

Rysunek 2.15. Wynik testu skalowalności

W omawianym przypadku system byđ wyposaľony w osiem rdzeni, z których kaľdy miađ dwa wætki sprzútowe. Aby uzyskaè kolejne potwierdzenie, ľe problem ze skalowalnoħciæ wiæľe siú z liczbæ rdzeni procesora, sprawdzamy wpđyw procesora na mniejszæ i wiúkszæ liczbú wætków, a nastúpnie porównujemy otrzymane wyniki (na przykđad wartoħè CPI — patrz rozdziađ 6. „Procesory”). Ewentualnie moľna przeprowadziè analizú eksperymentalnæ przez powtórzenie skalowania w systemach wyposaľonych w innæ liczbú rdzeni i sprawdziè, czy punkt zađamania búdzie wystúpowađ w oczekiwanym miejscu. Istnieje wiele róľnych profili skalowalnoħci, które bez problemów moľna zidentyfikowaè wizualnie, nie patrzæc nawet na formalny model. Wspomniane profile pokazano na rysunku 2.16. Dla kaľdego z profili pokazanych na rysunku 2.16 oħ X jest kierunkiem skalowania, natomiast oħ Y wskazuje osiægniútæ wydajnoħè (przepustowoħè, liczbú transakcji na sekundú itd.). Pokazane wzorce przedstawiajæ siú nastúpujæco: 





Skalowalnoħè liniowa. Wydajnoħè roħnie proporcjonalnie do skalowanego zasobu. Taka skalowalnoħè moľe w pewnym punkcie siú skoēczyè; w ten sposób stanowi wczesne etapy innego wzorca skalowalnoħci. Rywalizacja. Pewne komponenty architektury sæ wspóđdzielone i mogæ byè uľywane jedynie szeregowo. Wystúpuje wiúc zjawisko rywalizacji miúdzy wspóđdzielonymi zasobami, co prowadzi do spadku efektywnoħci skalowania. Koherencja. Koszt zapewnienia koherencji danych, miúdzy innymi w zakresie propagacji zmian, búdzie znacznie przekraczađ zalety, jakie przynosi skalowanie.

94

Rozdział 2



Metodologia

Rysunek 2.16. Profile skalowalności 



Punkt zađamania. Czynnik spotykany w punkcie skalowalnoħci, w którym nastúpuje zmiana profilu skalowalnoħci. Puđap skalowalnoħci. Osiægniúte zostađo niemoľliwe do przeskoczenia ograniczenie. To moľe byè wæskie gardđo urzædzenia, na przykđad osiægniúcie maksymalnej przepustowoħci magistrali bædļ teľ ograniczenie nakđadane przez oprogramowanie (system kontroli zasobów).

Wprawdzie identyfikacja wizualna moľe byè đatwa i efektywna, ale tak naprawdú wiúcej o skalowalnoħci systemu moľesz siú dowiedzieè, uľywajæc modelu matematycznego. Wspomniany model moľe w nieoczekiwany sposób odbiegaè od danych, co zdecydowanie warto poddaè dalszej analizie. Oznacza to bowiem problem w modelu, a tym samym wskazuje na bđúdne zrozumienie systemu, lub teľ oznacza problem w rzeczywistej skalowalnoħci systemu. Kolejne punkty zawierajæ wprowadzenie do prawa skalowalnoħci Amdahla, prawa skalowalnoħci uniwersalnej i teorii kolejek.

2.6.3. Prawo skalowalności Amdahla Nazwa wziúđa siú od twórcy architektury komputerowej — Gene’a Amdahla (patrz odwođanie [Amdahl 67] na koēcu rozdziađu) i dotyczy skalowalnoħci systemu z uwzglúdnieniem szeregowych komponentów obciæľenia, które nie skalujæ siú równoczeħnie. To prawo moľna wykorzystaè do analizy skalowania procesorów, wætków, obciæľeē itd. Prawo skalowalnoħci Amdahla na wczeħniejszym rysunku pokazujæcym profile skalowalnoħci zostađo przedstawione jako rywalizacja o dostúp do zasobu szeregowego lub komponent obciæľenia. Wzór omawianego prawa przedstawia siú nastúpujæco (patrz odwođanie [Gunther 97] na koēcu rozdziađu): C(N) = N/(1+Į(N-1))

2.6. Modelowanie

95

W powyľszym wzorze C(N) oznacza wzglúdnæ pojemnoħè, N wymiar skalowania, taki jak liczba procesorów lub obciæľenie. Parametr Į (gdzie 0 cache_name), stack()] = count(); }' dtrace: description 'fbt::kmem_cache_alloc:entry ' matched 1 probe [...] zio_cache zfs`zio_create+0x79 zfs`zio_null+0x77 zfs`zio_root+0x2d zfs`dmu_buf_hold_array_by_dnode+0x113 zfs`dmu_buf_hold_array+0x78 zfs`dmu_read_uio+0x5c zfs`zfs_read+0x1a3 genunix`fop_read+0x8b genunix`read+0x2a7 genunix`read32+0x1e unix`_sys_sysenter_post_swapgs+0x149 38686 streams_dblk_16 genunix`allocb+0x9e fifofs`fifo_write+0x1a5 genunix`fop_write+0x8b genunix`write+0x250 unix`sys_syscall+0x17a 38978

Dane wyjħciowe zawierajæ nazwú bufora, informacje o stosie jædra pokazujæcym alokacje, a takľe liczbú tych alokacji.

356

Rozdział 7



Pamięć

W dalszej czúħci zaprezentowano wiele jednowierszowych wywođaē DTrace, które pokazujæ róľne sposoby monitorowania alokacji przez alokatory dziađajæce na poziomie zarówno jædra, jak i uľytkownika.

Jednowierszowe wywołania DTrace Podsumowanie wielkoħci przeprowadzanych na poziomie uľytkownika ľædaē malloc() dla procesu o podanym identyfikatorze: dtrace -n 'pid$target::malloc:entry { @["request"] = quantize(arg0); }' -p PID

Podsumowanie wielkoħci przeprowadzanych na poziomie uľytkownika ľædaē malloc() dla procesu o podanym identyfikatorze. Uwzglúdniany jest stos wywođaē: dtrace -n 'pid$target::malloc:entry { @[ustack()] = quantize(arg0); }' -p PID

Zliczenie liczby wywođaē funkcji biblioteki libumem: dtrace -n 'pid$target:libumem::entry { @[probefunc] = count(); }' -p PID

Zliczenie stosów na poziomie uľytkownika dla sterty (za pomocæ brk()): dtrace -n 'syscall::brk:entry { @[execname, ustack()] = count(); }'

Monitorowanie alokacji slab na poziomie jædra, uwzglúdniono nazwú bufora i stos (system Solaris): dtrace -n 'fbt::kmem_cache_alloc:entry { @[stringof(args[0]->cache_name), stack()] = count(); }'

Monitorowanie awarii stron Monitorowanie awarii stron moľe dostarczyè informacji dodatkowych dotyczæcych obsđugi pamiúci w systemie. Operacjú moľna przeprowadziè za pomocæ dostawcy monitorowania dynamicznego fbt lub dostawcy statycznego vminfo, o ile búdzie dostúpny. Na przykđad w systemie Solaris przedstawione jednowierszowe wywođanie DTrace powoduje monitorowanie mniejszych awarii stron dla procesu o nazwie beam.smp (to maszyna wirtualna Erlang, która w omawianym przykđadzie zawiera uruchomionæ bazú danych Riak) oraz liczników czústotliwoħci stosu na poziomie uľytkownika. Monitorowanie odbywa siú do piúciu poziomów gđúbokoħci: # dtrace -n 'vminfo:::as_fault /execname == "beam.smp"/ { @[ustack(5)] = count(); } dtrace: description 'vminfo:::as_fault ' matched 1 probe [...] beam.smp`erts_add_monitor+0x29d beam.smp`monitor_2+0x293 beam.smp`process_main+0x51db

7.5. Analiza

357

beam.smp`sched_thread_func+0x1cf beam.smp`thr_wrapper+0xbe 723 beam.smp`erts_sweep_monitors+0xae beam.smp`process_info_aux+0x154a beam.smp`process_info_2+0x70f beam.smp`process_main+0x69e8 beam.smp`sched_thread_func+0x1cf 43745

Dane wyjħciowe zawierajæ podsumowanie dotyczæce ħcieľek kodu zuľywajæcych pamiúè i prowadzæcych do mniejszych awarii stron. W omawianym przypadku to mechanizm zbierania nieuľytków maszyny wirtualnej Erlang. Mniejsze awarie stron moľna równieľ monitorowaè za pomocæ sond vminfo::maj_fault. Innæ uľytecznæ sondæ zwiæzanæ z awariami stron jest vminfo::anonpgin. Odpowiada ona za ħledzenie anonimowego stronicowania, na przykđad: # dtrace -n 'vminfo:::anonpgin { @[pid, execname] = count(); }' dtrace: description 'vminfo:::anonpgin ' matched 1 probe ^C 26533 26067 4937

node node redis-server

1 6 907

Powyľsze polecenie monitoruje na poziomie systemu czústotliwoħè i nazwú procesu powodujæcego powstawanie anonimowych operacji stronicowania. To jest dokđadnie ten sam system, który przedstawiono we wczeħniejszym przykđadzie polecenia vmstat (identyfikujæcego anonimowe operacje wczytywania stron z dysku) oraz w przykđadzie prstat (identyfikujæcego, ľe proces redis-server sporo czasu oczekiwađ na dane). Powyľsze, jednowierszowe wywođanie narzúdzia DTrace pozwoliđo pođæczyè wszystko w cađoħè. Uzyskaliħmy potwierdzenie, ľe proces redis-server poħwiúca czas na przeprowadzanie anonimowego wczytywania stron z dysku, które jest skutkiem niewystarczajæcej iloħci pamiúci w systemie i stronicowania.

Demon operacji page-out Jeľeli zachodzi potrzeba, za pomocæ dostawcy fbt moľna monitorowaè takľe wewnútrzny sposób dziađania demona operacji page-out. Konkretna specyfika zaleľy od wersji jædra.

7.5.10. SystemTap W systemie Linux narzúdzie SystemTap równieľ moľna wykorzystaè do monitorowania dynamicznego zdarzeē systemu plików. Informacje dotyczæce konwersji przedstawionych wczeħniej skryptów DTrace na wersje dla narzúdzia SystemTap znajdziesz w podrozdziale 4.4 w rozdziale 4. „Narzúdzia monitorowania” oraz w dodatku E.

358

Rozdział 7



Pamięć

7.5.11. Inne narzędzia W systemie Linux do monitorowania wydajnoħci pamiúci moľna wykorzystaè jeszcze inne narzúdzia, miúdzy innymi: 















free. Podaje informacje o iloħci wolnej pamiúci oraz wielkoħciach buforów, w tym takľe bufora stron. Wiúcej informacji na ten temat znajdziesz w rozdziale 8. „Systemy plików”. dmesg. Umoľliwia wyszukanie komunikatów „Out of memory” wygenerowanych przez mechanizm OOM killer. valgrind. To jest zestaw narzúdzi przeznaczonych do analizy wydajnoħci. Zawiera miúdzy innymi memcheck, czyli narzúdzie do analizy uľycia pamiúci przez alokatory na poziomie uľytkownika i wykrywania wycieków pamiúci. Koszt wiæľæcy siú z uľyciem omawianego narzúdzia jest znaczny. Wedđug informacji zamieszczonych w podrúczniku uľytkownika dla zestawu — uruchomienie narzúdzia memcheck moľe spowodowaè, ľe sprawdzany system búdzie dziađađ od 20 do 30 razy wolniej (patrz odwođanie [3] na koēcu rozdziađu). swapon. Pozwala monitorowaè fizyczne urzædzenia przestrzeni wymiany lub pliki wymiany. iostat. Jeľeli urzædzeniem przestrzeni wymiany jest dysk fizyczny, to dyskowe operacje wejħcia-wyjħcia moľna monitorowaè za pomocæ polecenia iostat, które poinformuje, gdy system búdzie przeprowadzađ operacje stronicowania. perf. To narzúdzie zostađo wprowadzone w rozdziale 6. „Procesory”. Moľna je wykorzystaè do analizowania wartoħci CPI, zdarzeē MMU/TSB, bezczynnych cykli szyny procesora na podstawie liczników wydajnoħci procesora. Narzúdzie oferuje równieľ sondy umoľliwiajæce monitorowanie awarii stron i róľnych zdarzeē zwiæzanych z uľyciem pamiúci przez jædro (kmem). /proc/zoneinfo. Dane statystyczne dotyczæce stref pamiúci (wúzđy w architekturze NUMA). /proc/buddyinfo. Dane statystyczne dotyczæce alokatora bliļniaków dla jædra systemu.

W systemie Solaris do monitorowania wydajnoħci pamiúci moľna wykorzystaè jeszcze inne narzúdzia, miúdzy innymi: 

 



prtconf. Wyħwietla wielkoħè fizycznie zainstalowanej pamiúci w komputerze (w nowszych wersjach moľna jæ wyodrúbniè za pomocæ | grep Mem lub opcji -m). prtdiag. Pokazuje ukđad pamiúci fizycznej (o ile system na to pozwala). swap. Dane statystyczne dotyczæce przestrzeni wymiany: lista urzædzeē przestrzeni wymiany (-l) oraz podsumowanie jej uľycia (-s). iostat. Jeľeli urzædzeniem przestrzeni wymiany jest dysk fizyczny, to dyskowe operacje wejħcia-wyjħcia moľna monitorowaè za pomocæ polecenia iostat, które poinformuje, gdy system búdzie przeprowadzađ operacje stronicowania lub wymiany.

7.5. Analiza







359

cpustat. To narzúdzie zostađo wprowadzone w rozdziale 6., zatytuđowanym „Procesory”. Moľna je wykorzystaè do analizowania wartoħci CPI, zdarzeē MMU/TSB, bezczynnych cykli szyny procesora na podstawie liczników wydajnoħci procesora. trapstat. Dane statystyczne dotyczæce puđapek, miúdzy innymi wspóđczynnik nietrafnoħci TLB/TSB dla róľnej wielkoħci stron, a takľe procentowe uľycie procesora. Obecnie dostúpne jedynie dla procesorów SPARC. kstat. Narzúdzie dostarcza jeszcze wiúkszej iloħci danych statystycznych pomagajæcych w poznaniu sposobu uľycia pamiúci przez jædro. Informacje o przeznaczeniu wiúkszoħci z nich znajdziesz jedynie w kodzie ļródđowym (o ile búdzie dostúpny).

Aplikacje i maszyny wirtualne (na przykđad wirtualne maszyny Javy) takľe mogæ oferowaè wđasne narzúdzia przeznaczone do analizy pamiúci. Wiúcej informacji na ten temat przygotowano w rozdziale 5. „Aplikacje”. Niektóre alokatory obsđugujæ wđasne dane statystyczne przydatne podczas monitorowania. Na przykđad w systemie Solaris bibliotekú libumem moľna przeanalizowaè za pomocæ poleceē debugera mdb: # mdb leaky_core.11493 Loading modules: [ libumem.so.1 libc.so.1 ld.so.1 ] > ::vmem ADDR NAME INUSE TOTAL SUCCEED FAIL fffffd7ffdb6d4f0 sbrk_top 14678769664 31236771840 34038748 64125 fffffd7ffdb6e0f8 sbrk_heap 14678769664 14678769664 34038748 0 fffffd7ffdb6ed00 vmem_internal 320589824 320589824 71737 0 fffffd7ffdb6f908 vmem_seg 293679104 293679104 71699 0 fffffd7ffdb70510 vmem_hash 26870272 26873856 33 0 fffffd7ffdb71118 vmem_vmem 46200 55344 15 0 000000000067e000 umem_internal 91463936 91467776 20845 0 000000000067f000 umem_cache 113696 180224 44 0 0000000000680000 umem_hash 7455232 7458816 54 0 0000000000681000 umem_log 0 0 0 0 0000000000682000 umem_firewall_va 0 0 0 0 0000000000683000 umem_firewall 0 0 0 0 0000000000684000 umem_oversize 5964579061 6179110912 32905555 0 0000000000686000 umem_memalign 0 0 0 0 0000000000695000 umem_default 8087601152 8087601152 1040611 0 > ::umem_malloc_info CACHE BUFSZ MAXMAL BUFMALLC AVG_MAL MALLOCED OVERHEAD %OVER 0000000000697028 8 0 0 0 0 0 0.0% 0000000000698028 16 8 19426 8 155400 160349 103.1% 0000000000699028 32 16 19529 16 312464 322383 103.1% 000000000069a028 48 32 1007337 24 24186306 24933364 103.0% 000000000069b028 64 48 54161 40 2166755 1354569 62.5% [...] 00000000006b7028 4096 4080 5760 3489 20096972 3956788 19.6% 00000000006b8028 4544 4528 205210 4294 881092360 70876830 8.0%

360

00000000006b9028 00000000006ba028 00000000006bb028 00000000006bc028

Rozdział 7

8192 9216 12288 16384

8176 9200 12272 16368

544525 44217 76066 43619

5560 3027503427 1476807373 8653 382609833 26574285 10578 804644858 136139430 13811 602419234 115723982



Pamięć

48.7% 6.9% 16.9% 19.2%

Przedstawione dane wyjħciowe pokazujæ, ľe polecenie ::vmem wyħwietla informacje o wewnútrznych strukturach pamiúci wirtualnej wykorzystywane przez bibliotekú libumem oraz poziomy ich uľycia. Z kolei polecenie ::umem_malloc_info wyħwietla dane statystyczne dotyczæce bufora. Wspomniane dane mogæ dostarczaè informacji o sposobie uľycia pamiúci i o poszczególnych wielkoħciach (porównaj BUFSZ z MALLOCED). Wprawdzie dostarczajæ jedynie podstawowych atrybutów, ale wymienione polecenia mogæ rzuciè nieco ħwiatđa na to, co zwykle kryje siú w stercie procesu.

7.6. Dostrajanie Najwaľniejszym aspektem dostrojenia wydajnoħci jest zagwarantowanie, ľe aplikacje pozostanæ w pamiúci operacyjnej, a stronicowanie i wymiana nie búdæ pojawiađy siú zbyt czústo. Wykrywanie tego rodzaju problemów zostađo omówione w podrozdziađach 7.4 i 7.5. W tym podrozdziale búdæ przedstawione inne rodzaje dostrajania: modyfikacja parametrów jædra, konfiguracja ogromnych stron pamiúci, alokatorów i mechanizmów kontroli zasobów. Specyfika dostrajania — dostúpne opcje i przypisywane im wartoħci — zaleľæ od rodzaju procesora, wersji uľywanego systemu operacyjnego oraz planowanego obciæľenia. W dalszej czúħci przedstawiono pogrupowane wedđug typu przykđady opcji, które mogæ byè dostúpne, i powody ich dostrajania.

7.6.1. Parametry możliwe do dostrojenia W tym punkcie znajdziesz omówienie przykđadów dostrajania parametrów w systemach Linux i Solaris.

Linux W dokumentacji kodu ļródđowego jædra systemu, a dokđadnie w pliku Documentation/sysctl/vm.txt, przedstawiono róľne parametry dotyczæce pamiúci, które moľna dostroiè za pomocæ sysctl. Przykđady wymienione w tabeli 7.7 dotyczæ jædra w wersji 3.2.6, a ich wartoħci domyħlne pochodzæ z dystrybucji Fedora 16. Moľliwe do dostrojenia parametry stosujæ spójnæ konwencjú nazw obejmujæcæ jednostki. Zwróè uwagú, ľe opcje dirty_background_bytes i dirty_background_ratio sæ wzajemnie wykluczajæce siú, podobnie jak dirty_bytes i dirty_ratio (tylko jedna z nich moľe byè ustawiona). Wielkoħè vm.min_free_kbytes jest ustawiana dynamicznie jako wskazana czúħè pamiúci operacyjnej. Wybrany algorytm nie jest liniowy, poniewaľ potrzeba zwalniania pamiúci nie skaluje siú liniowo wraz ze zmianæ iloħci pamiúci operacyjnej (odpowiedniæ dokumentacjú znajdziesz w pliku mm/page_alloc.c). Wartoħè vm.min_free_kbytes

7.6. Dostrajanie

361

Tabela 7.7. Przykłady parametrów dotyczących pamięci możliwych do dostrojenia w systemie Linux Opcja

Wartość domyślna

vm.dirty_background_bytes

0

Ilość zmodyfikowanych stron pamięci wyzwalających przeprowadzaną w tle operację ich zapisu na dysku.

vm.dirty_background_ratio

10

Procentowa liczba zmodyfikowanych stron pamięci wyzwalających przeprowadzaną w tle operację ich zapisu na dysku.

vm.dirty_bytes

0

Ilość zmodyfikowanych stron pamięci, które powodują zainicjalizowanie procesu rozpoczynającego ich zapis na dysku.

vm.dirty_ratio

20

Współczynnik zmodyfikowanych stron pamięci, które powodują zainicjalizowanie procesu rozpoczynającego ich zapis na dysku.

vm.dirty_expire_centisecs

3000

Minimalna ilość czasu, w którym zmodyfikowana strona jest dostępna do zapisu (promocja write cancellation).

vm.dirty_writeback_centisecs

500

Odstęp czasu, w którym następuje uruchomienie pdflush (wartość 0 wyłącza uruchamianie operacji).

vm.min_free_kbytes

dynamiczna

Ustawienie żądanej ilości wolnej pamięci (pewne niepodzielne alokacje przeprowadzane przez jądro mogą zużyć tę pamięć).

vm.overcommit_memory

0

Wartość 0 oznacza użycie heurystyki w celu zezwolenia na sensowne przepełnienie, wartość 1 zawsze zezwala na przepełnienie, natomiast wartość 2 wyłącza przepełnienie.

vm.swappiness

60

Stopień, do którego preferowane będzie przeprowadzanie operacji wymiany (stronicowania) w celu zwolnienia pamięci zamiast jej odzyskiwania z bufora stron.

vm.vfs_cache_pressure

100

Stopień, do którego preferowane jest odzyskiwanie buforowanego katalogu i obiektów i-węzła. Niższe wartości oznaczają zachowanie większej liczby elementów. Wartość 0 oznacza brak odzyskiwania, co może bardzo łatwo doprowadzić do wyczerpania wolnej pamięci w systemie.

Opis

moľna zmniejszyè i tym samym zwolniè pewnæ iloħè pamiúci dla aplikacji. Jednak takie dziađanie moľe spowodowaè, ľe jeħli w systemie pozostanie niewystarczajæca iloħè wolnej pamiúci, jædro wczeħniej zainicjalizuje dziađanie mechanizmu OOM killer. Kolejnym parametrem pozwalajæcym uniknæè wywođania mechanizmu OOM killer jest vm.overcommit_memory, któremu przypisanie wartoħci 2 powoduje wyđæczenie wymienionego mechanizmu. Jeľeli dziađanie mechanizmu OOM killer definiujesz dla poszczególnych procesów, to sprawdļ wersjú jædra w interfejsie /proc pod kætem parametrów, takich jak oom_adj i oom_score_adj. Powinny byè opisane w pliku Documentation/ filesystems/proc.txt.

362

Rozdział 7



Pamięć

Wartoħè parametru vm.swappiness ma znaczny wpđyw na wydajnoħè, poniewaľ moľe doprowadziè do wczeħniejszego niľ to konieczne przeprowadzenia operacji wymiany aplikacji. Wartoħè omawianego parametru mieħci siú w zakresie od 0 do 100 — im wyľsza, tym bardziej preferowana búdzie wymiana aplikacji i tym samym pozostawienie zawartoħci bufora stron. Rozsædne moľe byè ustawienie wartoħci 0, aby pamiúè przydzielona aplikacji pozostađa niemodyfikowana jak najdđuľej, choè odbywa siú to kosztem bufora stron. Jeľeli w systemie zacznie brakowaè wolnej pamiúci, jædro búdzie miađo moľliwoħè przeprowadzenia operacji wymiany.

Solaris W tabeli 7.8 wymieniono dotyczæce pamiúci kluczowe parametry wraz z wartoħciami domyħlnymi, które moľna ustawiè w /etc/system. Peđnæ listú, razem z instrukcjami ustawiania poszczególnych parametrów, opisami i ostrzeľeniami, znajdziesz w dokumentacji dostarczanej przez producenta systemu operacyjnego. Niektóre z opcji wymienionych w tabeli pokazano wczeħniej na rysunku 7.11. Tabela 7.8. Przykłady parametrów dotyczących pamięci możliwych do dostrojenia w systemie Solaris Opcja

Wartość domyślna

Jednostka

Opis

lotsfree

1/64 pamięci

strony

Wartość graniczna, poniżej której rozpocznie się skanowanie stron (deficyt).

desfree

1/128 pamięci

strony

Docelowa ilość wolnej pamięci. Jeżeli przez 30 s będzie niższa, to rozpocznie się operacja wymiany.

minfree

1/256 pamięci

strony

Wartość graniczna, poniżej której rozpocznie się blokowanie operacji alokacji pamięci.

throttlefree

1/256 pamięci

strony

Wartość graniczna, poniżej której rozpocznie się blokowanie operacji alokacji pamięci (uśpienie).

pageout_reserve

1/512 pamięci

strony

Liczba stron zarezerwowanych dla operacji page-out i algorytmu szeregowania.

slowscan

100

strony/s

Wartość prowadząca do rozpoczęcia skanowania.

fastscan

64 MB

strony/s

Maksymalna szybkość skanowania.

maxpgio

40

strony

Maksymalna dozwolona liczba stron kolejkowanych żądań operacji wejścia-wyjścia.

Polecenia pagesize moľna uľyè do ustalenia znaczenia poszczególnych jednostek. Warto pamiútaè, ľe dostosowanie pewnych parametrów jædra czasami jest niedozwolone ze wzglúdu na politykú firmy lub producenta (sprawdļ to wczeħniej). W takim przypadku w systemie sæ juľ zdefiniowane odpowiednie wartoħci i nie wymagajæ one dostrajania.

7.6. Dostrajanie

363

W komputerach wyposaľonych w ogromnæ iloħè pamiúci (powyľej 100 GB) warto zmodyfikowaè pewne parametry i przypisaè im niľsze wartoħci, aby zwolniè wiúkszæ iloħè pamiúci dla aplikacji. Z kolei w systemach wyposaľonych w wiele urzædzeē pamiúci masowej (na przykđad macierze) moľe byè potrzeba zwiúkszenia wartoħci maxpgio, aby dđugoħè kolejki stađa siú odpowiedniejsza dla dostúpnej pojemnoħci operacji wejħcia-wyjħcia.

7.6.2. Różnej wielkości strony Strony pamiúci o ogromnej wielkoħci mogæ poprawiè wydajnoħè operacji wejħcia-wyjħcia w pamiúci, poniewaľ zwiúkszajæ wspóđczynnik trafnoħci bufora TLB (zasiúg bufora jest po prostu wiúkszy). Wiúkszoħè nowoczesnych procesorów obsđuguje strony o róľnej wielkoħci, na przykđad domyħlnie 4 KB i ogromne — o wielkoħci 2 MB. W systemie Linux duľe strony (nazywane ogromnymi stronami) mogæ byè skonfigurowane na wiele róľnych sposobów. Dokđadne informacje na ten temat znajdziesz w pliku Documentation/vm/hugetlbpage.txt. Poniľej przedstawiono najczúħciej stosowany sposób tworzenia ogromnych stron: # echo 50 > /proc/sys/vm/nr_hugepages # grep Huge /proc/meminfo AnonHugePages: 0 kB HugePages_Total: 50 HugePages_Free: 50 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB

Jednym ze sposobów pozwalajæcych aplikacji na uľycie ogromnych stron jest zastosowanie segmentów pamiúci wspóđdzielonej i opcji SHM_HUGETLBS wywođania shmget(). Kolejnym sposobem utworzenia ogromnych stron na podstawie systemu plików jest mapowanie pamiúci: # mkdir /mnt/hugetlbfs # mount -t hugetlbfs none /mnt/hugetlbfs -o pagesize=2048K

Jeszcze inny sposób obejmuje uľycie opcji MAP_ANONYMOUS | MAP_HUGETLB wywođania mmap() oraz zastosowanie API libhugetlbfs (patrz odwođanie [4] na koēcu rozdziađu). Ostatnio opracowano moľliwoħè uľycia stron THP (ang. Transparent Huge Pages). Oznacza to moľliwoħè uľycia ogromnych stron, gdy zachodzi potrzeba, ale bez koniecznoħci podejmowania w tym celu kroków przez administratora systemu (patrz odwođanie [5] na koēcu rozdziađu). Wiúcej informacji na ten temat moľna znaleļè w pliku Documentation/vm/transhuge.txt. W systemie Solaris moľliwoħè obsđugi ogromnych stron daje skonfigurowanie ħrodowiska aplikacji do uľycia biblioteki libmpss.so.1, na przykđad: $ LD_PRELOAD=$LD_PRELOAD:mpss.so.1 $ MPSSHEAP=2M $ export LD_PRELOAD MPSSHEAP

364

Rozdział 7



Pamięć

Powyľsze polecenia moľna umieħciè w skrypcie startowym aplikacji. Duľe strony sæ tworzone dynamicznie przez jædro, a sama operacja koēczy siú powodzeniem, jeħli dostúpna jest wystarczajæca liczba stron potrzebnych do utworzenia duľych stron. W przeciwnym razie tworzone sæ mniejsze strony. Programy skompilowane za pomocæ Oracle Solaris Studio mogæ automatycznie uľywaè duľych stron i nie ma koniecznoħci przeprowadzania rúcznej konfiguracji biblioteki mpss.

7.6.3. Alokatory W systemie mogæ byè dostúpne róľne alokatory na poziomie uľytkownika, oferujæce poprawú wydajnoħci dziađania aplikacji wielowætkowych. Alokator moľna wybraè podczas kompilacji lub w trakcie dziađania aplikacji w wyniku ustawienia wartoħci zmiennej ħrodowiskowej LD_PRELOAD. Na przykđad w systemie Solaris wybór alokatora libumem nastúpuje za pomocæ poniľszego polecenia: export LD_PRELOAD=libumem.so

Wspomniane polecenie moľna umieħciè w skrypcie startowym.

7.6.4. Kontrola zasobów Podstawowe mechanizmy kontroli zasobów, miúdzy innymi ustawienie limitu dostúpnej pamiúci operacyjnej i wirtualnej, sæ oferowane w postaci polecenia ulimit. W systemie Linux kontener grup (cgroups) podsystemu pamiúci oferuje dodatkowe moľliwoħci w zakresie kontroli, na przykđad: 







memory.memsw.limit_in_bytes. Wyraľona w bajtach maksymalna dozwolona iloħè pamiúci i przestrzeni wymiany. memory.limit_in_bytes. Wyraľona w bajtach maksymalna dozwolona iloħè pamiúci uľytkownika, obejmuje bufor systemu plików. memory.swappiness. Podobnie jak omówiona wczeħniej opcja vm.swappiness, ale ta dotyczy cgroups. memory.oom_control. Ustawienie wartoħci 0 pozwala na uľycie mechanizmu OOM killer dla danej grupy cgroups, natomiast 1 wyđæcza moľliwoħè uľycia wymienionego mechanizmu.

W systemie Solaris ograniczenia dla poszczególnych stref lub projektów moľna zdefiniowaè za pomocæ mechanizmu kontroli zasobów i polecenia prctl. Wymuszajæ one przestrzeganie ustalonych limitów, co skutkuje przeprowadzaniem operacji stronicowania zamiast nieudanej alokacji. Takie rozwiæzanie moľe byè poľædane, w zaleľnoħci od aplikacji docelowej. Wiúcej informacji na ten temat zamieszczono w podrozdziale 11.2 w rozdziale 11. „Przetwarzanie w chmurze”.

7.7. Ćwiczenia

365

7.7. Ćwiczenia 1. Odpowiedz na nastúpujæce pytania dotyczæce terminologii: 

Co to jest strona pamiúci?



Co to jest pamiúè rezydentna?



Co to jest pamiúè wirtualna?





Jaka jest róľnica miúdzy stronicowaniem a wymianæ? Odpowiadajæc na pytanie, uľyj terminologii systemu UNIX. Jaka jest róľnica miúdzy stronicowaniem a wymianæ? Odpowiadajæc na pytanie, uľyj terminologii systemu Linux.

2. Odpowiedz na pytania dotyczæce koncepcji: 

Jaki jest cel stosowania stronicowania na ľædanie?



Jak mógđbyħ opisaè poziom wykorzystania i nasycenia pamiúci?



Jakie jest przeznaczenie jednostki MMU i bufora TLB?



Jaka jest rola demona operacji page-out?



Jaka jest rola mechanizmu OOM killer?

3. Odpowiedz na nastúpujæce, dokđadniejsze pytania: 





Co to jest stronicowanie anonimowe i dlaczego jest waľniejsze do przeanalizowania niľ stronicowanie systemu plików? Jakie kroki wykonuje jædro w celu zwolnienia pamiúci, gdy iloħè dostúpnej pamiúci w systemie Linux lub Solaris (wybierz dowolny) jest niewystarczajæca? Jakie korzyħci w zakresie wydajnoħci daje alokacja typu slab?

4. Zaimplementuj w uľywanym systemie operacyjnym wymienione procedury: 



Metoda USE w postaci listy rzeczy do zrobienia dotyczæcych zasobów pamiúci. Uwzglúdnij sposób pobrania poszczególnych metryk (podaj konkretne polecenia do wykonania) i wskaľ, jak moľna interpretowaè otrzymane wyniki. Przed instalacjæ lub uľyciem dodatkowego oprogramowania spróbuj wykorzystaè narzúdzia monitorowania oferowane przez uľywany system operacyjny. Przygotuj charakterystykú obciæľenia w postaci listy rzeczy do zrobienia dotyczæcych zasobów pamiúci. Uwzglúdnij sposób pobrania poszczególnych metryk — spróbuj w pierwszej kolejnoħci wykorzystaè narzúdzia monitorowania oferowane przez uľywany system operacyjny.

5. Wykonaj zadania: 





Wybierz aplikacjú, a nastúpnie przygotuj podsumowanie ħcieľek kodu prowadzæcych do alokacji pamiúci (malloc()). Wybierz aplikacjú, w której do pewnego stopnia wzrasta uľycie pamiúci (wywođanie brk()), a nastúpnie przygotuj podsumowanie ħcieľek kodu prowadzæcych do wspomnianego wzrostu. Opisz aktywnoħè pamiúci na podstawie przedstawionych danych wyjħciowych otrzymanych w systemie Linux:

366

Rozdział 7



Pamięć

# vmstat 1 procs -----------memory-------- ---swap-- -----io---- --system-- -----cpu----r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 413344 62284 72 6972 0 0 17 12 1 1 0 0 100 0 0 2 0 418036 68172 68 3808 0 4692 4520 4692 1060 1939 61 38 0 1 0 2 0 418232 71272 68 1696 0 196 23924 196 1288 2464 51 38 0 11 0 2 0 418308 68792 76 2456 0 76 3408 96 1028 1873 58 39 0 3 0 1 0 418308 67296 76 3936 0 0 1060 0 1020 1843 53 47 0 0 0 1 0 418308 64948 76 3936 0 0 0 0 1005 1808 36 64 0 0 0 1 0 418308 62724 76 6120 0 0 2208 0 1030 1870 62 38 0 0 0 1 0 422320 62772 76 6112 0 4012 0 4016 1052 1900 49 51 0 0 0 1 0 422320 62772 76 6144 0 0 0 0 1007 1826 62 38 0 0 0 1 0 422320 60796 76 6144 0 0 0 0 1008 1817 53 47 0 0 0 1 0 422320 60788 76 6144 0 0 0 0 1006 1812 49 51 0 0 0 3 0 430792 65584 64 5216 0 8472 4912 8472 1030 1846 54 40 0 6 0 1 0 430792 64220 72 6496 0 0 1124 16 1024 1857 62 38 0 0 0 2 0 434252 68188 64 3704 0 3460 5112 3460 1070 1964 60 40 0 0 0 2 0 434252 71540 64 1436 0 0 21856 0 1300 2478 55 41 0 4 0 1 0 434252 66072 64 3912 0 0 2020 0 1022 1817 60 40 0 0 0 [...]

6. (Opcjonalne, zaawansowane) Wyszukaj lub opracuj metryki pokazujæce, czy polityka lokalizacji pamiúci w systemie o architekturze NUMA jest przez jædro wystarczajæco dobrze stosowana w praktyce. Przygotuj „znane” obciæľenie, które charakteryzuje siú dobræ lub kiepskæ lokalizacjæ pamiúci, a nastúpnie wykorzystaj je do przetestowania metryki. 7. (Opcjonalne, zaawansowane) Opracuj narzúdzie przeznaczone do pomiaru lub oszacowania wielkoħci zbioru roboczego procesu. Twoje narzúdzie powinno byè bezpieczne w zastosowaniu w systemach produkcyjnych (wymaganie, którego speđnienie moľe okazaè siú niemoľliwe). Czúħciowym rozwiæzaniem moľe byè przygotowanie narzúdzia uwzglúdniajæcego jedynie strony systemu plików, a pomijajæcego stertú.

7.8. Odwołania [Corbató 68]

F.J. Corbató, A Paging Experiment with the Multics System, MIT Project MAC Report MAC-M-384, 1968.

[Denning 70]

P. Denning, Virtual Memory, „ACM Computing Surveys” (CSUR) 2, nr 3, 1970.

[Peterson 77]

J. Peterson, T. Norman, Buddy Systems, „Communications of the ACM”, 1977.

[Thompson 78]

K. Thompson, UNIX Implementation, Bell Laboratories, 1978.

[Babaoglu 79]

O. Babaoglu, W. Joy, J. Porcar, Design and Implementation of the Berkeley Virtual Memory Extensions to the UNIX Operating System, Computer Science Division, Department of Electrical Engineering and Computer Science, University of California, Berkeley, 1979.

7.8. Odwołania

367

[Bach 86]

M.J. Bach, The Design of the UNIX Operating System, Prentice Hall, 1986.

[Bonwick 94]

J. Bonwick, The Slab Allocator: An Object-Caching Kernel Memory Allocator, USENIX, 1994.

[Vahalia 96]

U. Vahalia, UNIX Internals: The New Frontiers, Prentice Hall, 1996.

[Bonwick 01]

J. Bonwick, J. Adams, Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources, USENIX, 2001.

[Gorman 04]

M. Gorman, Understanding the Linux Virtual Memory Manager, Prentice Hall, 2004.

[McDougall 06a] R. McDougall, J. Mauro, Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture, 2nd Edition, Prentice Hall, 2006. [McDougall 06b] R. McDougall, J. Mauro, B. Gregg, Solaris Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris, Prentice Hall, 2006. [Intel 12]

Intel 64 and IA-32 Architectures Software Developer’s Manual, pođæczone woluminy: 1, 2A, 2B, 2C, 3A, 3B i 3C, Intel, 2012.

[1]

http://lwn.net/Articles/83588/

[2]

http://lwn.net/Articles/229096/

[3]

http://valgrind.org/docs/manual/

[4]

http://lwn.net/Articles/375096/

[5]

http://lwn.net/Articles/423584/

368

Rozdział 7



Pamięć

8 Systemy plików

Podczas analizy wydajnoħci operacji wejħcia-wyjħcia aplikacji wydajnoħè systemu plików ma zdecydowanie wiúksze znaczenie niľ dysku. Systemy plików uľywajæ buforowania i asynchronicznych operacji wejħcia-wyjħcia, aby uniknæè opóļnienia zwiæzanego z odczytem przez aplikacjú danych z dysku bædļ zdalnego systemu. Pomimo to analiza wydajnoħci i dostúpne zestawy narzúdzi zwykle byđy skoncentrowane na wydajnoħci dziađania dysków. W erze monitorowania dynamicznego analiza systemu plików stađa siú đatwa i praktyczna. W tym rozdziale przekonasz siú, jak moľna szczegóđowo analizowaè ľædania systemu plików, a takľe jak wykorzystaè monitorowanie dynamiczne do pomiaru czasu wykonywania zadaē od poczætku do koēca w kontekħcie aplikacji. Dziúki temu systemy plików i tworzæce je dyski moľna bardzo szybko wykluczyè jako ļródđo kiepskiej wydajnoħci i zajæè siú sprawdzaniem innych komponentów systemu. W tym rozdziale moľna wyróľniè piúè czúħci. Pierwsze trzy zawierajæ informacje podstawowe dotyczæce analizy systemów plików, natomiast dwie kolejne pokazujæ jej praktyczne zastosowanie w systemach Linux i Solaris. Wspomnianymi czúħciami sæ: 





Wprowadzenie. Przedstawienie terminologii zwiæzanej z systemami plików, podstawowych modeli ilustrujæcych reguđy rzædzæce systemami plików oraz kluczowych koncepcji dotyczæcych wydajnoħci systemów plików. Architektura. Ogólne omówienie architektury sprzútowej i programowej systemów plików. Metodologia. Przedstawienie metodologii dotyczæcych analizy wydajnoħci, opartej zarówno na obserwacji, jak i eksperymentach. 369

370

Rozdział 8







Systemy plików

Analiza. Prezentacja narzúdzi analizy wydajnoħci systemów plików w systemach Linux i Solaris. Omówione búdzie miúdzy innymi monitorowanie statyczne i dynamiczne. Dostrajanie. Przykđady parametrów, które moľna dostrajaè w systemach plików.

8.1. Terminologia Wymieniono tutaj zwiæzanæ z systemami plików terminologiú, która búdzie uľywana w tym rozdziale: 



















System plików. Sposób organizacji danych w postaci plików i katalogów. Dostúp do danych odbywa siú za poħrednictwem interfejsu opartego na plikach, natomiast kontrola dostúpu jest realizowana za pomocæ uprawnieē plików. Dodatkowa zawartoħè moľe obejmowaè specjalnego typu pliki przeznaczone do urzædzeē, gniazd i potoków, a takľe metadane przechowujæce znaczniki czasu ostatniego dostúpu do pliku. Bufor systemu plików. Obszar w pamiúci operacyjnej uľywany do buforowania zawartoħci systemu plików. Moľe siú skđadaè z róľnych buforów przeznaczonych dla odmiennego rodzaju danych i metadanych. Operacje. To sæ operacje systemu plików wykonujæce ľædania kierowane do systemu plików, takie jak: read(), write(), open(), close(), stat(), mkdir(). Operacje wejħcia-wyjħcia. W przypadku systemu plików operacje wejħcia-wyjħcia moľna zdefiniowaè na wiele róľnych sposobów. W tym rozdziale pojúcie to oznacza jedynie operacje przeprowadzajæce bezpoħredni odczyt i zapis (wykonanie operacji wejħcia-wyjħcia), czyli miúdzy innymi: read(), write(), stat() (odczyt danych statystycznych) i mkdir() (zapis nowego katalogu). W takim ujúciu operacje wejħcia-wyjħcia nie obejmujæ wywođaē open() i close(). Logiczna operacja wejħcia-wyjħcia. Operacja wejħcia-wyjħcia, której ľædanie wykonania kierowane jest przez aplikacjú do systemu plików. Fizyczna operacja wejħcia-wyjħcia. Operacja wejħcia-wyjħcia, której ľædanie wykonania kierowane jest przez system plików do dysków. Przepustowoħè. Aktualny transfer danych miúdzy aplikacjami i systemem plików, mierzony w bajtach na sekundú. i-wúzeđ. Indeks wúzđa (ang. index node), czyli struktura danych zawierajæca metadane dla obiektu systemu plików, miúdzy innymi uprawnienia, znaczniki czasu i wskaļniki danych. VFS. Wirtualny system plików, stosowany przez jædro rodzaj abstrakcji pozwalajæcy na obsđugú róľnego typu systemów plików. W systemie Solaris i-wúzeđ VFS nosi nazwú vnode. Menedľer woluminów. Oprogramowanie przeznaczone do elastycznego zarzædzania fizycznymi urzædzeniami pamiúci masowej i tworzenia wirtualnych woluminów uľywanych przez system operacyjny.

8.2. Modele

371

Inne pojúcia búdæ wprowadzane na bieľæco w tekħcie. Sđowniczek znajdujæcy siú na koēcu ksiæľki zawiera wyjaħnienie pewnych podstawowych terminów, miúdzy innymi: fsck, IOPS i POSIX. Warto zapoznaè siú takľe z podrozdziađami poħwiúconymi terminologii zamieszczonymi w rozdziađach 2. i 3.

8.2. Modele Przedstawione w tym podrozdziale proste modele ilustrujæ podstawowe reguđy dotyczæce systemów plików i ich wydajnoħci.

8.2.1. Interfejsy systemów plików Podstawowy model systemu plików, w kategoriach interfejsu, zostađ pokazany na rysunku 8.1.

Rysunek 8.1. Interfejsy systemów plików

Na rysunku 8.1 przedstawiono równieľ miejsca, w których przeprowadzane sæ operacje logiczne i fizyczne. Wiúcej informacji na ich temat znajdziesz w punkcie 8.3.12 w dalszej czúħci rozdziađu. Jedno z podejħè podczas studiowania wydajnoħci systemu plików polega na potraktowaniu go jako zamkniútego pudeđka i skoncentrowaniu siú na opóļnieniu operacji przeprowadzanych na obiektach. Zostanie to dokđadnie wyjaħnione w punkcie 8.5.2 w dalszej czúħci rozdziađu.

8.2.2. Bufor systemu plików Ogólny bufor systemu plików znajduje siú w pamiúci operacyjnej, jak to zostađo pokazane na rysunku 8.2. Celem wspomnianego bufora jest obsđuga i poprawa wydajnoħci operacji odczytu.

372

Rozdział 8



Systemy plików

Rysunek 8.2. Umieszczony w pamięci operacyjnej bufor systemu plików

Operacja odczytu jest obsđugiwana za pomocæ bufora (trafienie bufora) lub dysku (nietrafienie bufora). Elementy nieznalezione pierwotnie w buforze zostajæ w nim umieszczane, co powoduje zapeđnianie bufora (tak zwane rozgrzewanie bufora). Bufor systemu plików moľe równieľ sđuľyè do przechowywania operacji zapisu, które zostanæ przeprowadzone nieco póļniej. Sposoby implementacji tego rodzaju rozwiæzania zaleľæ od systemu plików i búdæ omówione w podrozdziale 8.4 „Architektura”.

8.2.3. Bufory poziomu drugiego Bufor poziomu drugiego moľe byè dowolnym rodzajem pamiúci. Na rysunku 8.3 pokazano go jako pamiúè flash. Ten rodzaj bufora zostađ opracowany po raz pierwszy dla systemu plików ZFS.

Rysunek 8.3. Bufor poziomu drugiego dla systemu plików

8.3. Koncepcje W dalszej czúħci przedstawiono kilka najwaľniejszych koncepcji dotyczæcych systemu plików i jego wydajnoħci.

8.3. Koncepcje

373

8.3.1. Opóźnienie systemu plików Opóļnienie systemu plików to podstawowa metryka jego wydajnoħci, wyraľona jako czas, który musi upđynæè od wydania logicznego ľædania systemu plików do jego peđnego wykonania. Obejmuje czas spúdzony w systemie plików, dyskowym podsystemie operacji wejħcia-wyjħcia oraz oczekiwania na urzædzenia dyskowe — fizyczne operacje wejħciawyjħcia. Wætki aplikacji bardzo czústo sæ zablokowane podczas wykonywania ľædania, kiedy to system plików oczekuje na jego zakoēczenie. W takiej sytuacji opóļnienie systemu plików bezpoħrednio i proporcjonalnie wpđywa na wydajnoħè dziađania aplikacji. Sytuacje, w których wymienione opóļnienie moľe nie mieè bezpoħredniego wpđywu na aplikacje, dotyczæ uľycia nieblokujæcych operacji wejħcia-wyjħcia lub ich wykonywania przez asynchroniczny wætek (na przykđad dziađajæcy w tle wætek zapisujæcy dane na dysku). Istnieje moľliwoħè identyfikacji tego rodzaju sytuacji, jeħli aplikacja oferuje dokđadny opis metryk sposobu uľywania przez niæ systemu plików. Jeľeli brakuje dokđadnego opisu, to ogólne podejħcie polega na uľyciu narzúdzia monitorowania, które moľe pokazaè stos na poziomie uľytkownika prowadzæcy do logicznej operacji wejħcia-wyjħcia systemu plików. Wspomniany stos moľna nastúpnie przestudiowaè, aby przekonaè siú, jakie procedury aplikacji doprowadziđy do danej operacji wejħcia-wyjħcia. Systemy operacyjne nie oferujæ moľliwoħci đatwego monitorowania opóļnienia systemu plików i zamiast tego dostarczajæ metryk na poziomie urzædzenia dyskowego. Istnieje jednak wiele sytuacji, w których metryki te nie majæ bezpoħredniego wpđywu na aplikacjú. To utrudnia interpretacjú zebranych danych, a czasami nawet sprowadza jæ na niewđaħciwe tory. Przykđadem moľe byè nastúpujæca sytuacja: system plików przeprowadza w tle operacjú zapisywania danych bufora na dysku, co moľe objawiaè siú w postaci duľego opóļnienia dyskowych operacji wejħcia-wyjħcia. Gdy przypatrzymy siú metrykom na poziomie urzædzenia dyskowego, sytuacja moľe przedstawiaè siú alarmujæco. Jednak ľadna aplikacja nie oczekuje na zakoēczenie wykonywania wspomnianej operacji. Wiúcej przykđadów znajdziesz w punkcie 8.3.12.

8.3.2. Buforowanie Po uruchomieniu systemu operacyjnego system plików zwykle uľywa pamiúci operacyjnej (RAM) jako bufora poprawiajæcego wydajnoħè. Z perspektywy aplikacji uľycie bufora jest niewidoczne: opóļnienie ich logicznych operacji wejħcia-wyjħcia staje siú mniejsze, poniewaľ dane mogæ byè dostarczane z pamiúci operacyjnej zamiast ze znacznie wolniejszych urzædzeē dyskowych. Wraz z upđywem czasu bufor siú zwiúksza, podczas gdy iloħè wolnej pamiúci maleje. Taka sytuacja moľe martwiè poczætkujæcych uľytkowników, ale jest zupeđnie normalna. Reguđa brzmi: jeľeli w systemie znajduje siú wolna pamiúè, warto wykorzystaè jæ do czegoħ uľytecznego. Kiedy aplikacja búdzie potrzebowađa wiúkszej iloħci pamiúci, jædro systemu moľe bardzo szybko jæ dostarczyè, zwalniajæc odpowiedniæ iloħè z bufora systemu plików. System plików uľywa bufora w celu poprawy wydajnoħci operacji odczytu i zapisu. Dla systemu plików i podsystemu urzædzeē zwykle dostúpnych jest wiele rodzajów buforów, z których czúħè wymieniono w tabeli 8.1.

374

Rozdział 8



Systemy plików

Tabela 8.1. Przykładowe rodzaje buforów dostępnych dla systemów plików Bufor

Przykład

bufor stron

znajdujący się w systemie operacyjnym bufor stron

podstawowy bufor systemu plików

ZFS ARC

drugorzędny bufor systemu plików

ZFS L2ARC

bufor katalogów

DNLC

bufor i-węzłów

bufor i-węzłów

bufor urządzenia

ZFS vdev

bufor urządzenia blokowego

podręczna pamięć buforowa

Poszczególne rodzaje buforów omówiono w podrozdziale 8.4 „Architektura”, natomiast w rozdziale 3. „Systemy operacyjne” przedstawiono peđnæ listú buforów (znajdujæcych siú na poziomie zarówno aplikacji, jak i urzædzeē).

8.3.3. Losowe kontra sekwencyjne operacje wejścia-wyjścia Seria logicznych operacji wejħcia-wyjħcia moľe byè opisana jako losowa lub sekwencyjna, w zaleľnoħci od wartoħci przesuniúcia pliku poszczególnych operacji wejħciawyjħcia. W przypadku sekwencyjnej operacji wejħcia-wyjħcia kolejna rozpoczyna siú w miejscu zakoēczenia poprzedniej. Natomiast w losowych operacjach wejħciawyjħcia miejsca zakoēczenia poprzedniej i rozpoczúcia kolejnej sæ róľne, a odlegđoħè miúdzy nimi dowolnie siú zmienia. Obciæľenie w postaci losowego dostúpu do systemu plików moľe oznaczaè równieľ losowy dostúp do wielu róľnych plików. Na rysunku 8.4 pokazano oba rodzaje wzorca dostúpu jako uporzædkowanæ seriú operacji wejħcia-wyjħcia i przykđadowe wartoħci przesuniúcia pliku.

Rysunek 8.4. Losowe i sekwencyjne operacje wejścia-wyjścia

8.3. Koncepcje

375

Ze wzglúdu na charakterystykú wydajnoħci okreħlonych urzædzeē pamiúci masowej (omówiona w rozdziale 9. „Dyski”) systemy plików od zawsze próbujæ zmniejszyè iloħè losowych operacji wejħcia-wyjħcia na skutek umieszczania danych na dysku kolejno, w sposób przylegajæcy do siebie. Termin fragmentacja oznacza, ľe system plików sđabo radzi sobie z wymienionym zadaniem i powoduje rozrzucanie danych po cađym dysku. W takiej sytuacji iloħè losowych operacji wejħcia-wyjħcia búdzie znacznie przewyľszađa sekwencyjne. Systemy plików mogæ sprawdzaè wzorzec dostúpu logicznych operacji wejħcia-wyjħcia, aby zidentyfikowaè obciæľenie sekwencyjne, a nastúpnie poprawiè wydajnoħè za pomocæ mechanizmu prefetch lub odczytu z wyprzedzeniem. Wymienione zagadnienia zostanæ omówione w kolejnych punktach.

8.3.4. Mechanizm prefetch W bardzo czústo spotykanym obciæľeniu systemu plików nastúpuje sekwencyjny odczyt ogromnej iloħci danych, na przykđad podczas tworzenia kopii zapasowej systemu. Dane mogæ byè zbyt duľe, aby zmieħciđy siú w buforze bædļ teľ zostađy odczytane tylko jednokrotnie, dlatego istnieje znikome prawdopodobieēstwo ich umieszczenia w buforze (w zaleľnoħci od stosowanej polityki usuwania elementów bufora). Tego rodzaju obciæľenie charakteryzuje siú doħè sđabæ wydajnoħciæ ze wzglúdu na niski wspóđczynnik trafnoħci bufora. Prefetch to powszechnie stosowany przez system plików mechanizm pozwalajæcy rozwiæzaè opisany problem. Potrafi wykryè sekwencyjne operacje odczytu na podstawie wartoħci przesuniúcia bieľæcej i poprzedniej operacji wejħcia-wyjħcia pliku. Dlatego teľ przewiduje i wczeħniej odczytuje z dysku dane, których moľe zaľædaè aplikacja. Odczytane dane sæ umieszczane w buforze systemu plików i — jeħli aplikacja wyda ľædanie oczekiwanego odczytu — wynik búdzie pobrany z bufora (niezbúdne dane zostađy w nim wczeħniej umieszczone). Poniľej przedstawiono przykđad — przyjúto zađoľenie, ľe ľadne ľædane przez aplikacjú dane nie sæ buforowane: 1. Aplikacja wywođuje operacjú read() dla pliku i przekazuje jej wykonanie jædru systemu. 2. System plików przeprowadza operacjú odczytu danych z pliku. 3. Wartoħè przesuniúcia wskaļnika poprzedniego pliku jest porównywana z bieľæcym pođoľeniem. Jeľeli sæ one sekwencyjne, to system plików przeprowadza kolejne operacje odczytu. 4. Po zakoēczeniu pierwszego odczytu jædro przekazuje dane aplikacji, w której kontynuowane jest dziađanie. 5. Po zakoēczeniu kolejnych odczytów pobrane dane sæ umieszczane w buforze, który búdzie w ten sposób obsđugiwađ kolejne ľædania odczytu wydawane przez aplikacjú. Przedstawiony mechanizm zostađ zilustrowany na rysunku 8.5. Aplikacja odczytuje pliki o wartoħci przesuniúcia 1, nastúpnie 2, co powoduje odczytanie danych znajdujæcych siú w trzech kolejnych miejscach.

376

Rozdział 8



Systemy plików

Rysunek 8.5. Sposób działania mechanizmu prefetch w systemie plików

Jeľeli mechanizm prefetch trafnie przewiduje kolejne operacje odczytu, wydajnoħè sekwencyjnych operacji odczytu w aplikacji ulega znacznej poprawie, a dane sæ odczytywane z dysków, zanim aplikacja jeszcze ich zaľæda. Natomiast w przypadku kiepskiego przewidywania kolejnych operacji odczytu przez mechanizm prefetch wykonywane sæ dyskowe operacje wejħcia-wyjħcia w celu pobrania danych niepotrzebnych aplikacji, wypeđnienia nimi bufora, co powoduje marnowanie zasobów. Systemy plików najczúħciej zezwalajæ na dostrojenie parametrów mechanizmu prefetch.

8.3.5. Odczyt z wyprzedzeniem Wczeħniej mechanizm prefetch byđ znany jako odczyt z wyprzedzeniem. Ostatnio w systemie Linux zaadaptowano wymienione wyraľenie dla potrzeb wywođania systemowego readahead(), które pozwala aplikacji na wyraļne rozgrzanie bufora systemu plików.

8.3.6. Buforowanie operacji zapisu Buforowanie operacji zapisu danych jest powszechnie stosowane w systemach plików, aby poprawiè wydajnoħè tych operacji. Rozwiæzanie polega na uznaniu operacji zapisu za ukoēczonæ po przeniesieniu danych do pamiúci operacyjnej. Dane w rzeczywistoħci zostanæ zapisane na dysku nieco póļniej, w sposób asynchroniczny. Proces systemu plików odpowiedzialny za zapis takich „brudnych” danych na dysku nosi nazwú flushing. Przykđadowa sekwencja kroków przedstawia siú nastúpujæco: 1. Aplikacja wywođuje operacjú write() dla pliku i przekazuje jej wykonanie jædru systemu. 2. Dane z przestrzeni adresowej aplikacji sæ kopiowane do jædra. 3. Jædro traktuje wywođanie systemowe write() za ukoēczone, a kontrola nad przebiegiem dziađania wraca do aplikacji. 4. Nieco póļniej asynchroniczne zadanie jædra wyszukuje dane do zapisania, a nastúpnie rzeczywiħcie zapisuje je na dysku.

8.3. Koncepcje

377

Cenæ jest poħwiúcenie niezawodnoħci. Oparta na koħciach DRAM pamiúè operacyjna jest ulotna i niezapisane jeszcze dane mogæ zostaè utracone na skutek awarii zasilania. Utrata danych nastæpi, mimo ľe z punktu widzenia aplikacji dane zostađy zapisane na dysku. Ewentualnie mogæ zostaè zapisane niekompletnie, co powoduje, ľe sæ uznawane za uszkodzone. Jeľeli uszkodzone zostanæ metadane systemu plików, to nie búdzie mógđ byè on odczytany. Wówczas ratunkiem jest przywrócenie systemu plików z utworzonej wczeħniej kopii zapasowej, co oznacza pewien przestój podczas operacji przywracania danych. Co gorsza, jeľeli uszkodzona zostanie zawartoħè pliku odczytywanego i uľywanego przez aplikacjú, sama dziađalnoħè biznesowa moľe byè wówczas zagroľona. Zachowanie równowagi wymaga zarówno szybkoħci, jak i niezawodnoħci. System plików moľe zaoferowaè moľliwoħè domyħlnego buforowania operacji zapisu i jednoczeħnie opcjú zapisu synchronicznego, aby ominæè wspomniane buforowanie i przeprowadzaè zapis bezpoħrednio w urzædzeniach pamiúci masowej.

8.3.7. Synchroniczne operacje zapisu Synchroniczna operacja zapisu jest uznawana za zakoēczonæ tylko wtedy, gdy dane sæ w peđni zapisane w trwađej pamiúci masowej (na przykđad na dysku). Oznacza to równieľ zapis wszelkich metadanych systemu plików, o ile zachodzi potrzeba. To oczywiħcie rozwiæzanie znacznie wolniejsze niľ zapis asynchroniczny (z uľyciem bufora), poniewaľ wiæľe siú z wystæpieniem opóļnienia dyskowej operacji wejħcia-wyjħcia. Zapis synchroniczny jest uľywany przez aplikacje, w których ryzyko uszkodzenia danych na skutek zapisu asynchronicznego jest nie do zaakceptowania (na przykđad w bazie danych podczas zapisu dziennika zdarzeē). Istniejæ dwa rodzaje zapisu synchronicznego: synchroniczne wykonanie poszczególnych operacji wejħcia-wyjħcia oraz grupowanie operacji i ich synchroniczne przeprowadzenie.

Synchroniczne wykonanie poszczególnych operacji Synchroniczna operacja zapisu ma miejsce wtedy, gdy plik jest otwarty wraz z opcjæ O_SYNC lub jej wariantami: O_DSYNC bædļ O_RSYNC (poczæwszy od wersji 2.6.31 jædra systemu Linux sæ mapowane przez glib na O_SYNC). Niektóre systemy plików oferujæ opcje montowania pozwalajæce na wymuszenie tego, aby wszystkie operacje zapisu plików byđy przeprowadzane synchronicznie.

Synchroniczne zatwierdzenie wcześniej wydanych operacji Zamiast synchronicznie przeprowadzaè wszystkie operacje zapisu wejħcia-wyjħcia, na pewnym etapie aplikacja moľe synchronicznie zatwierdzaè wydane wczeħniej operacje, uľywajæc do tego wywođania systemowego fsync(). Umoľliwia to poprawú wydajnoħci dziúki grupowaniu synchronicznych operacji zapisu.

378

Rozdział 8



Systemy plików

Istniejæ takľe inne sytuacje wywođujæce zatwierdzenie wczeħniejszych operacji zapisu. Przykđadem moľe byè obsđuga zamykania pliku lub zbyt duľa liczba niezatwierdzonych danych dla okreħlonego pliku. Druga z wymienionych sytuacji czústo zdarza siú podczas rozpakowywania archiwum zawierajæcego wiele plików, zwđaszcza jeħli odbywa siú to przez NFS.

8.3.8. Niezmodyfikowane i bezpośrednie operacje wejścia-wyjścia Poza omówionymi wczeħniej mamy jeszcze inne rodzaje operacji wejħcia-wyjħcia, które mogæ byè wykonywane przez aplikacje. Niezmodyfikowane operacje wejħcia-wyjħcia. Tego rodzaju operacja jest przeprowadzana bezpoħrednio na dysku z pominiúciem systemu plików. Stosowana przez niektóre aplikacje, zwđaszcza bazy danych, umoľliwia znacznie lepsze zarzædzanie i buforowanie danych niľ w przypadku uľycia bufora systemu operacyjnego. Wadæ sæ trudnoħci zwiæzane z administracjæ: standardowe narzúdzia przeznaczone do obsđugi systemów plików nie mogæ byè wykorzystane do tworzenia i przywracania kopii zapasowej, a takľe do monitorowania. Bezpoħrednie operacje wejħcia-wyjħcia. Tego rodzaju operacja pozwala aplikacji na uľycie systemu plików, ale z pominiúciem jego bufora. Takie rozwiæzanie jest podobne do zapisu synchronicznego, ale bez gwarancji oferowanych w przypadku uľycia opcji O_SYNC; sprawdza siú równieľ w przypadku operacji odczytu. Nie przybiera tak bezpoħredniej postaci jak w niezmodyfikowanych operacjach wejħcia-wyjħcia, poniewaľ mapowanie kaľdego pliku na dysk nadal musi byè przeprowadzane przez kod systemu plików, a wielkoħè operacji wejħcia-wyjħcia moľe byè zmieniona w celu dostosowania do wielkoħci uľywanej przez system operacyjny w danym ukđadzie na dysku (wielkoħci rekordu). W zaleľnoħci od systemu plików wyđæczone moľe byè nie tylko buforowanie operacji odczytu i zapisu, ale równieľ mechanizm prefetch. Bezpoħrednie operacje wejħcia-wyjħcia mogæ byè uľywane przez aplikacje tworzæce kopie zapasowe systemu plików. Dziúki temu unika siú wypeđnienia bufora systemu plików jednorazowo odczytywanymi danymi. Zarówno niezmodyfikowane, jak i bezpoħrednie operacje wejħcia-wyjħcia moľna wykorzystaè w celu unikniúcia podwójnego buforowania w przypadku aplikacji, które implementujæ wđasne rozwiæzania buforowania w stercie procesu na poziomie aplikacji.

8.3.9. Nieblokujące operacje wejścia-wyjścia Standardowo operacje wejħcia-wyjħcia systemu plików búdæ koēczone natychmiast (obsđuľone przez bufor) lub po pewnym oczekiwaniu (na przykđad na zakoēczenie dyskowej operacji wejħcia-wyjħcia). Jeľeli konieczne búdzie oczekiwanie, aplikacja zablokuje wætek i opuħci procesor, pozwalajæc tym samym dziađaè innym wætkom w trakcie wspomnianego oczekiwania. Wprawdzie wætek zablokowany nie moľe wykonywaè zadaē, ale to z reguđy nie jest problem, poniewaľ aplikacje wielowætkowe mogæ tworzyè wætki dodatkowe przeznaczone do dziađania, gdy inne pozostajæ w tym czasie zablokowane. W pewnych sytuacjach, na przykđad w celu unikniúcia problemów zwiæzanych z wydajnoħciæ lub obciæľania zasobów podczas tworzenia wætku, sensownym rozwiæzaniem

8.3. Koncepcje

379

búdzie przeprowadzenie nieblokujæcych operacji wejħcia-wyjħcia. Operacje takie mogæ byè przeprowadzane dziúki uľyciu opcji O_NONBLOCK lub O_NDELAY wywođania systemowego open(). Powoduje to, ľe operacje odczytu i zapisu generujæ bđæd typu EAGAIN, zamiast blokowaè, co nakazuje aplikacji ponowiè próbú nieco póļniej. (Obsđuga takiego rozwiæzania zaleľy od systemu plików, który moľe honorowaè nieblokowanie jedynie dla zalecanych lub obowiæzkowych blokad pliku). Nieblokujæce operacje wejħcia-wyjħcia zostađy równieľ omówione w rozdziale 5., noszæcym tytuđ „Aplikacje”.

8.3.10. Mapowanie plików w pamięci W pewnych aplikacjach i rodzajach obciæľenia wydajnoħè operacji wejħcia-wyjħcia systemu plików moľna poprawiè dziúki mapowaniu plików na przestrzeē adresowæ pamiúci i bezpoħrednie uzyskiwanie dostúpu do pamiúci. W ten sposób unika siú obciæľenia zwiæzanego z wykonaniem wywođania systemowego i przeđæczenia kontekstu podczas uľycia wywođaē read() i write() w trakcie uzyskiwania dostúpu do danych. Moľna równieľ uniknæè dwukrotnego kopiowania danych, jeľeli jædro obsđuguje bezpoħrednie kopiowanie bufora pliku danych do przestrzeni adresowej procesu. Mapowanie w pamiúci jest tworzone za pomocæ wywođania systemowego mmap(), a usuwane za pomocæ munmap(). Dostrojenie mapowania do wđasnych potrzeb jest moľliwe dziúki uľyciu madvise(), co zostanie przedstawione w podrozdziale 8.8 „Dostrajanie”. Niektóre aplikacje oferujæ w opcjach konfiguracyjnych moľliwoħè uľycia wywođaē systemowych mmap() — moľe to nosiè nazwú na przykđad „mmap mode”. Przykđadem tego rodzaju aplikacji jest baza danych Riak, pozwalajæca na uľycie mapowaē mmap() dla danych przechowywanych w pamiúci operacyjnej. Zauwaľyđem tendencjú polegajæcæ na próbie uľycia mmap() do rozwiæzywania problemów zwiæzanych z wydajnoħciæ systemu plików bez ich wczeħniejszego przeanalizowania. Jeľeli problemem jest duľe opóļnienie operacji wejħcia-wyjħcia przeprowadzanych w urzædzeniach pamiúci masowej, to uľycie mmap() do unikniúcia wzglúdnie mađego obciæľenia zwiæzanego z wywođaniami systemowymi przyniesie niewielkæ korzyħè, a duľe opóļnienie dyskowych operacji wejħcia-wyjħcia nadal búdzie obecne i dominujæce. W systemie wieloprocesorowym wadæ stosowania mapowania jest obciæľenie zwiæzane z koniecznoħciæ synchronizacji jednostek MMU wszystkich procesorów, zwđaszcza wywođaē miúdzy procesorami w celu usuniúcia mapowaē (tzw. TLB shootdowns). W zaleľnoħci od uľywanego jædra i mapowania problem moľna ograniczyè wskutek opóļnienia uaktualnieē TLB (tzw. lazy shootdowns) — (patrz odwođanie [Vahalia 96] na koēcu rozdziađu).

8.3.11. Metadane Wprawdzie dane opisujæ zawartoħè plików i katalogów, ale to metadane zawierajæ informacje o nich. Metadane odnoszæ siú do informacji, które moľna odczytaè z interfejsu systemu plików (POSIX) lub niezbúdnych do implementacji ukđadu systemu plików na dysku. Wspomniane metadane sæ nazywane, odpowiednio, logicznymi i fizycznymi.

380

Rozdział 8



Systemy plików

Metadane logiczne Metadane logiczne to informacje odczytywane lub zapisywane w systemie plików przez konsumentów (aplikacje). Operacje odczytu i zapisu mogæ byè przeprowadzane nastúpujæco: 



wyraļnie — odczyt danych statystycznych pliku (stat()), tworzenie i usuwanie plików (create(), unlink()) oraz katalogów (mkdir(), rmdir()); niejawnie — uaktualnianie znaczników czasu dotyczæcych dostúpu do pliku w systemie plików, a takľe modyfikacje znaczników czasu dotyczæcych uaktualnieē katalogu.

Obciæľenie zwiæzane z „intensywnym uľyciem metadanych” najczúħciej odnosi siú do metadanych logicznych. Przykđadem moľe byè serwer WWW, który wywođuje stat() wzglúdem plików w celu sprawdzenia, czy nie ulegđy zmianie od chwili ich umieszczenia w buforze. Wspomniana operacja sprawdzenia jest przeprowadzana znacznie czúħciej niľ rzeczywisty odczyt danych znajdujæcych siú w pliku.

Metadane fizyczne Metadane fizyczne odnoszæ siú do informacji dotyczæcych ukđadu na dysku, niezbúdnych do zarejestrowania wszystkich danych systemu pliku. Rodzaj uľywanych metadanych zaleľy od typu systemu plików i moľe obejmowaè superbloki, i-wúzđy, bloki wskaļników danych (podstawowy, drugorzúdny, …) oraz listy wolnych stron pamiúci. Metadane logiczne i fizyczne to jeden z czynników wpđywajæcych na róľnice miúdzy logicznymi i fizycznymi operacjami wejħcia-wyjħcia.

8.3.12. Logiczne kontra fizyczne operacje wejścia-wyjścia Wprawdzie moľe siú to wydawaè dziwne, ale ľædania operacji wejħcia-wyjħcia kierowane przez aplikacje do systemu plików (logiczne operacje wejħcia-wyjħcia) nie odpowiadajæ dyskowym operacjom wejħcia-wyjħcia (fizycznym operacjom wejħcia-wyjħcia). Dzieje siú tak przynajmniej z kilku powodów. Systemy plików wykonujæ znacznie wiúkszæ pracú niľ jedynie przedstawianie trwađego magazynu danych (dysków) jako interfejsu opartego na plikach. Buforujæ operacje odczytu i zapisu, a takľe generujæ dodatkowe operacje wejħcia-wyjħcia w celu obsđugi metadanych fizycznego ukđadu na dysku, wymaganych do rejestracji informacji o miejscu pođoľenia poszczególnych danych. W ten sposób powstajæ dyskowe operacje wejħcia-wyjħcia, które sæ niepowiæzane, poħrednie, zmniejszone lub zwiúkszone w porównaniu do operacji wejħcia-wyjħcia generowanych przez aplikacje. Odpowiednie przykđady przedstawiono w kolejnych fragmentach ksiæľki.

Niezwiązane Tego rodzaju dyskowe operacje wejħcia-wyjħcia nie sæ powiæzane z aplikacjæ i mogđy zostaè wygenerowane z nastúpujæcych powodów:

8.3. Koncepcje







381

Inne aplikacje. Dyskowe operacje wejħcia-wyjħcia sæ przeprowadzane ze wzglúdu na dziađalnoħè innych aplikacji. Inne tenanty. Dyskowe operacje wejħcia-wyjħcia pochodzæ z innego tenantu (w przypadku niektórych technologii wirtualizacji sæ widoczne po uľyciu narzúdzi systemowych). Inne zadania jædra. Przykđadem moľe byè sytuacja, gdy jædro jest zajúte obsđugæ oprogramowania odbudowujæcego wolumin macierzy RAID lub przeprowadzaniem asynchronicznej weryfikacji sumy kontrolnej systemu plików (patrz podrozdziađ 8.4 „Architektura”).

Pośrednie To sæ operacje wejħcia-wyjħcia aplikacji i nie majæ bezpoħredniego przeđoľenia na dyskowe operacje wejħcia-wyjħcia. Mogđy zostaè wygenerowane z nastúpujæcych powodów: 



Dziađalnoħè mechanizmu prefetch systemu plików. To powoduje wygenerowanie dodatkowych operacji wejħcia-wyjħcia w celu pobrania danych, które mogæ, choè nie muszæ, byè uľywane przez aplikacje. Buforowanie w systemie plików. Powstaje na skutek buforowania operacji zapisu, które sæ zbierane i przeprowadzane nieco póļniej. Niektóre systemy mogæ buforowaè operacje zapisu przez dziesiætki sekund, zanim przeprowadzony búdzie ich rzeczywisty zapis na dysku. To moľe powodowaè wystúpowanie w systemie duľej iloħci operacji wejħcia-wyjħcia w nieregularnych odstúpach czasu.

Zmniejszone Tego rodzaju sytuacja ma miejsce wtedy, gdy dyskowe operacje wejħcia-wyjħcia sæ mniejsze niľ wykonywane przez aplikacje, a czasem nawet w ogóle nie istniejæ. Moľe to wynikaè z nastúpujæcych powodów: 









Buforowanie systemu plików. Operacja odczytu mogđa byè obsđuľona przez bufor znajdujæcy siú w pamiúci operacyjnej, nie byđ wymagany odczyt danych z dysku. Przerwanie operacji zapisu w systemie plików. Te same dane sæ modyfikowane wielokrotnie, a dopiero póļniej, po wprowadzeniu wszystkich zmian, zapisywane na dysku. Kompresja. Nastúpuje zmniejszenie wielkoħci danych miúdzy logicznymi i fizycznymi operacjami wejħcia-wyjħcia. Koalescencja. Pođæczenie sekwencyjnych operacji wejħcia-wyjħcia, a nastúpnie ich wykonanie. System plików w pamiúci. Dane mogæ nigdy nie byè zapisywane na dysku (na przykđad system plików tmpfs).

382

Rozdział 8



Systemy plików

Zwiększone Tego rodzaju sytuacja wystúpuje, gdy dyskowe operacje wejħcia-wyjħcia sæ wiúksze niľ wykonywane przez aplikacje. Moľe to wynikaè z powodów, takich jak: 





Metadane systemu plików. Oznacza to wykonanie dodatkowych operacji wejħcia-wyjħcia. Wielkoħè rekordu w systemie plików. To zaokræglenie w górú wielkoħci operacji wejħcia-wyjħcia (zwiúkszenie liczby bajtów) lub fragmentacja operacji wejħcia-wyjħcia (zwiúkszenie liczby operacji). Parzystoħè menedľera woluminu. Cykl odczyt-modyfikacja-zapis powoduje wygenerowanie dodatkowych operacji wejħcia-wyjħcia.

Przykład Aby pokazaè, jak wymienione wczeħniej czynniki mogæ wystæpiè razem, przedstawiono dokđadny przykđad zdarzeē zachodzæcych podczas wykonywania przez aplikacjú operacji zapisu o wielkoħci 1 B. 1. Aplikacja przeprowadza zapis danych o wielkoħci 1 B do istniejæcego pliku. 2. System plików identyfikuje pođoľenie nowych danych jako czúħè rekordu systemu plików o wielkoħci 128 KB, który nie jest buforowany (w przeciwieēstwie do jego metadanych). 3. System plików ľæda wczytania wspomnianego rekordu z dysku. 4. Warstwa urzædzenia dyskowego dzieli 128 KB na mniejsze jednostki, odpowiednie dla danego urzædzenia. 5. Dysk przeprowadza wiele mniejszych operacji odczytu w celu wczytania đæcznie 128 KB danych. 6. We wczytanych danych system plików zastúpuje jeden bajt nowym bajtem. 7. Po upđywie pewnego czasu system plików ľæda zapisania na dysku zmodyfikowanego wczeħniej rekordu o wielkoħci 128 KB. 8. Dysk zapisuje 128 KB, dzielæc je na mniejsze fragmenty, jeħli zachodzi potrzeba. 9. System plików zapisuje nowe metadane, na przykđad odniesienia (dla operacji kopiowania przy zapisie) i czas ostatniego dostúpu do pliku. 10. Dysk przeprowadza jeszcze wiúcej operacji zapisu. Jak siú przekonađeħ, wprawdzie aplikacja wykonađa ľædanie zapisu tylko 1 bajta, ale dysk przeprowadziđ wiele operacji odczytu (w sumie 128 KB) i zapisađ znacznie wiúcej danych (128 KB), niľ znalazđo siú w ľædaniu aplikacji.

8.3. Koncepcje

383

8.3.13. Operacje nie są jednakowe Na podstawie informacji przedstawionych w poprzednich punktach powinno byè jasne, ľe operacje systemu plików charakteryzujæ siú róľnæ wydajnoħciæ, zaleľnæ od rodzaju operacji. Stwierdzenie: „500 operacji na sekundú” niewiele mówi o danym obciæľeniu. Pewne operacje mogæ byè wykonywane bardzo szybko, poniewaľ pobierajæ dane z pamiúci, podczas gdy inne muszæ odczytaè dane z dysku i tym samym sæ znacznie wolniejsze. Kolejnym czynnikiem jest rodzaj operacji: losowa lub sekwencyjna, odczyt lub zapis, zapis synchroniczny lub asynchroniczny, wielkoħè operacji wejħcia-wyjħcia, uwzglúdnienie innego rodzaju operacji, a wreszcie koszt wykonania danej operacji przez procesor. Czústo spotykanæ praktykæ jest przeprowadzanie mikrotestów wydajnoħci róľnych operacji systemu plików i na tej podstawie okreħlanie ich charakterystyki wydajnoħci. Na przykđad wyniki przedstawione w tabeli 8.2 pochodzæ z systemu plików ZFS w komputerze wyposaľonym w wielordzeniowy procesor Intel Xeon o czústotliwoħci taktowania 2,4 GHz. Tabela 8.2. Przykładowe opóźnienia operacji w systemie plików Operacja

Średnie opóźnienie (μs)

open()

2,2

close()

0,7

read() — buforowane bloki o wielkości 4 KB

3,3

read() — buforowane bloki o wielkości 128 KB

13,9

write() — operacja asynchroniczna, bloki o wielkości 4 KB

9,3

write() — operacja asynchroniczna, bloki o wielkości 128 KB

55,2

Przeprowadzone testy nie wykorzystywađy urzædzeē pamiúci masowej, a miađy na celu przetestowanie systemu plików i szybkoħci procesora. Niektóre specjalne systemy plików nigdy nie uzyskujæ dostúpu do urzædzeē pamiúci masowej.

8.3.14. Specjalne systemy plików Przeznaczeniem systemu plików zwykle jest trwađe przechowywanie danych. Istniejæ jednak specjalne systemy plików przeznaczone do innych celów, na przykđad dla plików tymczasowych (/tmp), dla ħcieľek urzædzeē jædra (/dev) oraz dla danych statystycznych dotyczæcych systemu (/proc).

8.3.15. Znaczniki czasu dotyczące dostępu Wiele systemów plików obsđuguje znaczniki czasu dostúpu, które rejestrujæ czas ostatniego dostúpu (odczyt) danego pliku i katalogu. Takie rozwiæzanie powoduje uaktualnienie metadanych pliku w trakcie kaľdej operacji jego odczytu, co prowadzi do wygenerowania dyskowych operacji wejħcia-wyjħcia (zapis). W podrozdziale 8.8 „Dostrajanie” dowiesz siú, jak wyđæczyè wspomniane uaktualnianie metadanych.

384

Rozdział 8



Systemy plików

Nektóre systemy plików optymalizujæ znaczniki czasu dostúpu przez grupowanie i odroczenie ich zapisu — zmniejsza to obciæľenie zwiæzane z obsđugæ.

8.3.16. Pojemność Kiedy system plików siú zapeđnia, jego wydajnoħè moľe siú obniľyè z kilku powodów. Podczas zapisu nowych danych wyszukanie wolnych bloków na dysku moľe zajæè nieco wiúcej czasu, a sama operacja wyszukania oznacza dodatkowe operacje wejħcia-wyjħcia. Obszary wolnego miejsca na dysku búdæ prawdopodobnie mniejsze i rozrzucone na dysku, co zmniejsza wydajnoħè ze wzglúdu na koniecznoħè wykonywania mniejszych i losowych operacji wejħcia-wyjħcia. Skala pojawiajæcych siú problemów zaleľy od rodzaju systemu plików, jego ukđadu na dysku oraz zastosowanych urzædzeē pamiúci masowej. Wybrane rodzaje systemów plików zostađy omówione w nastúpnym podrozdziale.

8.4. Architektura W tym podrozdziale zostanie przedstawiona architektura systemu plików obejmujæca miúdzy innymi stos operacji wejħcia-wyjħcia, VFS, funkcje i bufory systemu plików, najczúħciej spotykane systemy plików, woluminy i pule. Tego rodzaju informacje sæ przydatne, gdy trzeba ustaliè, które komponenty systemu plików naleľy przeanalizowaè i dostroiè. Wiúcej informacji szczegóđowych oraz inne zagadnienia poħwiúcone systemom plików znajdziesz w kodzie ļródđowym (o ile jest dostúpny) oraz zewnútrznej dokumentacji. Niektóre ļródđa wymieniono na koēcu rozdziađu.

8.4.1. Stos operacji wejścia-wyjścia systemu plików Na rysunku 8.6 pokazano ogólny model stosu operacji wejħcia-wyjħcia systemu plików. Poszczególne komponenty i warstwy zaleľæ od rodzaju systemu operacyjnego, wersji i uľywanych systemów plików. Peđny wykres znajdziesz w rozdziale 3. „Systemy operacyjne”. Na rysunku przedstawiono ħcieľkú operacji wejħcia-wyjħcia uwzglúdniajæcæ jædro. Ħcieľka prowadzæca bezpoħrednio z wywođania systemowego do podsystemu urzædzenia dyskowego nosi nazwú niezmodyfikowanej operacji wejħcia-wyjħcia. Natomiast ħcieľka uwzglúdniajæca VFS i system plików to operacje wejħcia-wyjħcia systemu plików, obejmujæce bezpoħrednie operacje wejħcia-wyjħcia, które pomijajæ bufor systemu plików.

8.4.2. VFS Wirtualny system plików (ang. Virtual File System) dostarcza najczúħciej spotykanego interfejsu róľnym rodzajom systemów plików. Jego pođoľenie pokazano na rysunku 8.7.

8.4. Architektura

385

Rysunek 8.6. Ogólny stos operacji wejścia-wyjścia systemu plików

Rysunek 8.7. Interfejs wirtualnego systemu plików

Pewne systemy operacyjne (miúdzy innymi oryginalna implementacja SunOS) traktujæ VFS jako dwa interfejsy: VFS i wúzeđ, jak to zostađo logicznie podzielone we wczeħniejszym modelu systemu plików (patrz odwođanie [McDougall 06a] na koēcu rozdziađu). VFS obejmuje operacje o zasiúgu systemu plików, takie jak montowanie i odmontowanie. Z kolei interfejs vnode obejmuje operacje na plikach i-wúzđa VFS (vnode), takie jak: otwieranie, zamykanie, odczyt i zapis. Terminologia stosowana przez interfejs VFS w systemie Linux moľe byè nieco mylæca, poniewaľ pojúcia i-wúzeđ i superblok sæ ponownie uľywane w odniesieniu do obiektów VFS — wymienione pojúcia pochodzæ ze struktur danych znajdujæcych siú na dysku systemu plików UNIX. W systemie Linux wyraľenia dla struktur danych na dysku zwykle zawierajæ prefiks wskazujæcy rodzaj systemu plików, na przykđad: ext4_inode, ext4_super_block. Wymienione i-wúzđy i superbloki VFS znajdujæ siú jedynie w pamiúci.

386

Rozdział 8



Systemy plików

Interfejs VFS moľe równieľ dziađaè w charakterze najczúħciej uľywanego miejsca do przeprowadzania pomiarów wydajnoħci dowolnego systemu plików. Wspomnianæ wydajnoħè moľna sprawdzaè za pomocæ danych statystycznych dostarczanych przez system operacyjny oraz stosujæc monitorowanie statyczne bædļ dynamiczne.

8.4.3. Bufory systemu plików System UNIX byđ wyposaľony jedynie w bufor pozwalajæcy na poprawú wydajnoħci operacji dostúpu do urzædzeē blokowych. Obecnie w systemach Linux i Solaris znajduje siú wiele róľnego rodzaju buforów. W tym punkcie omawianie zaczniemy od systemu Solaris, aby przeanalizowaè ļródđa niektórych ze wspomnianych buforów.

Solaris Ogólny schemat buforów systemu plików w Solarisie znajdziesz na rysunku 8.8, na którym pokazano bufory zarówno dla UFS, jak i ZFS.

Rysunek 8.8. Bufory systemu plików w Solarisie

Trzy z pokazanych buforów to ogólne bufory systemu operacyjnego: stara podrúczna pamiúè buforowa, bufor stron oraz DNLC. Pozostađe to bufory charakterystyczne dla systemu plików i búdæ omówione w dalszej czúħci rozdziađu.

Stara podręczna pamięć buforowa Na poczætku istnienia system UNIX uľywađ podrúcznej pamiúci buforowej na poziomie interfejsu urzædzenia blokowego, co miađo na celu buforowanie bloków urzædzenia dyskowego. To byđa oddzielna pamiúè podrúczna o stađej wielkoħci, która wraz z buforem stron sprawiađa problemy podczas dostrajania, gdy trzeba byđo zrównowaľyè róľne obciæľenia miúdzy nimi. Dodatkowy problem stanowiđo podwójne buforowanie i obciæľenie zwiæzane z synchronizacjæ. Wspomniane problemy zostađy w wiúkszoħci wyeliminowane na skutek zastosowania bufora stron przeznaczonego do przechowywania podrúcznej pamiúci buforowej. To podejħcie, wprowadzone w systemie SunOS, nosiđo nazwú ujednoliconej podrúcznej pamiúci buforowej (patrz rysunek 8.9).

8.4. Architektura

387

Rysunek 8.9. Oryginalna i ujednolicona podręczna pamięć buforowa

W systemie Solaris oryginalna („stara”) podrúczna pamiúè buforowa nadal istnieje, jest uľywana jedynie dla i-wúzđów UFS i metadanych pliku, co odbywa siú na podstawie pođoľenia bloku, a nie pliku. Wielkoħè pamiúci buforowej jest dynamiczna, a wartoħci liczników dostúpu moľna sprawdziè w kstat. Bufor i-wúzđów równieľ wzrasta dynamicznie i przechowuje wszystkie i-wúzđy dla otwartych plików oraz dla mapowanych przez DNLC. Pewna liczba dodatkowych i-wúzđów jest buforowana w kolejce bezczynnoħci.

Bufor stron Bufor stron zostađ wprowadzony przy okazji tworzenia od nowa pamiúci wirtualnej dla systemu SunOS w 1985 roku i dodany do SVR4 (patrz odwođanie [Vahalia 96] na koēcu rozdziađu). Zawiera buforowane strony pamiúci wirtualnej, miúdzy innymi mapowane strony systemu plików. Charakteryzuje siú znacznie wiúkszæ efektywnoħciæ podczas dostúpu do pliku niľ podrúczna pamiúè buforowa, która przy kaľdej operacji dostúpu wymaga przeprowadzenia translacji wartoħci przesuniúcia pliku na wartoħè przesuniúcia dysku. Wiele rodzajów systemów plików uľywa bufora stron — zaliczamy do nich UFS i NFS, ale juľ nie ZFS. Wielkoħè bufora stron jest dynamiczna i búdzie zwiúkszana aľ do wykorzystania cađej dostúpnej pamiúci. Wspomnianæ pamiúè moľna szybko zwolniè, gdy búdzie potrzebna dla aplikacji. Zmodyfikowane strony pamiúci, uľywane przez system plików, búdæ zapisane na dysku przez wætek jædra nazywany file system flush daemon (fsflush), który w pewnych odstúpach czasu skanuje cađy bufor stron. Jeľeli búdzie deficyt wolnej pamiúci operacyjnej, inny wætek jædra — demon operacji page-out (pageout, nazywany takľe skanerem stron) — równieľ moľe wyszukiwaè i oznaczaè strony do zapisania na dysku, aby moľna byđo zwolniè pamiúè stron i wykorzystaè do innych celów (patrz rozdziađ 7. „Pamiúè”). Podczas monitorowania pageout i fsflush majæ identyfikatory, odpowiednio, 2 i 3 nawet pomimo faktu, ľe to sæ wætki jædra, a nie procesy. Istniejæ dwa podstawowe sterowniki jædra dla bufora stron: segvn (mapowanie plików na przestrzenie adresowe procesów) i segmap (buforowanie operacji odczytu i zapisu systemu plików). Wiúcej informacji na ten temat, jak równieľ dotyczæcych skanera stron znajdziesz w rozdziale 7. „Pamiúè”.

388

Rozdział 8



Systemy plików

DNLC Bufor DNLC (ang. Directory Name Lookup Cache) rejestruje mapowania katalogu na vnode — zostađ opracowany we wczesnych latach osiemdziesiætych przez Kevina Roberta Elza. Omawiany bufor poprawia wydajnoħè wyszukiwania nazw ħcieľek (na przykđad za pomocæ open()), poniewaľ w trakcie analizy nazwy ħcieľki kaľda operacja wyszukiwania nazwy moľe sprawdziè bufor DNLS pod kætem bezpoħredniego mapowania na vnode, zamiast przechodziè przez zawartoħè katalogu. Bufor DNLC zostađ zaprojektowany w celu zapewnienia wydajnoħci i skalowalnoħci, jego elementy sæ przechowywane w tabeli hash, która z kolei jest haszowana przez nadrzúdny vnode i nazwú katalogu. Na przestrzeni lat do bufora DNLC w systemie Solaris dodano róľne funkcje, miúdzy innymi poprawiajæce jego wydajnoħè dziađania. Poczætkowo w DNLC uľywane byđy wskaļniki prowadzæce do đaēcuchów hash oraz dodatkowe wskaļniki dla listy LRU. W systemie Solaris 2.4 zrezygnowano z obsđugi wskaļników LRU, poniewaľ powodowađy powstanie rywalizacji dotyczæcej blokad listy LRU. Zachowanie LRU zostađo zaimplementowane na skutek usuwania elementów z koēca tabeli hash. W systemie Solaris 8 dodano dwie nowe funkcje: buforowanie negatywne i buforowanie katalogu. Pierwsza z nich pamiúta wyszukiwania nieistniejæcych elementów, natomiast druga celowo buforuje katalogi. Funkcja buforowania negatywnego poprawia wydajnoħè w przypadku nieistniejæcych elementów w buforze, co najczúħciej wystúpuje w sytuacji wyszukiwania ħcieľki biblioteki. Z kolei buforowanie katalogu poprawia wydajnoħè podczas tworzenia pliku, poniewaľ zapobiega koniecznoħci przeprowadzania operacji skanowania katalogu w celu sprawdzenia, czy plik o podanej nazwie juľ istnieje. Wielkoħè bufora DNLC moľna dostosowaè, wartoħci wskazujæce trafienia i nietrafienia bufora sæ moľliwe do monitorowania za pomocæ kstat.

Linux Ogólny schemat buforów systemu plików w systemie Linux zaprezentowano na rysunku 8.10, na którym pokazano bufory dostúpne dla standardowych typów systemów plików.

Rysunek 8.10. Bufory systemu plików w systemie Linux

8.4. Architektura

389

Podręczna pamięć buforowa Podobnie jak UNIX, system Linux równieľ poczætkowo uľywađ podrúcznej pamiúci buforowej. Poczæwszy od jædra w wersji 2.4 podrúczna pamiúè buforowa jest przechowywana w buforze stron (stæd kropkowana linia uľyta na rysunku 8.10) i tym samym stosowana jest znana z systemu SunOS koncepcja ujednoliconego bufora. Pozwala to uniknæè podwójnego buforowania i obciæľenia zwiæzanego z synchronizacjæ. Funkcjonalnoħè podrúcznej pamiúci buforowej nadal istnieje i poprawia wydajnoħè operacji wejħcia-wyjħcia przeprowadzanych w urzædzeniach blokowych. Wielkoħè podrúcznej pamiúci buforowej jest dynamiczna i moľna jæ monitorowaè za pomocæ interfejsu /proc.

Bufor stron Bufor stron jest przeznaczony do buforowania stron pamiúci wirtualnej, miúdzy innymi stron systemu plików, co prowadzi do poprawy wydajnoħci operacji wejħcia-wyjħcia dotyczæcych plików i katalogów. Wielkoħè bufora stron jest dynamiczna, zwiúksza siú, zabierajæc cađæ dostúpnæ pamiúè, ale zwalnia jæ, gdy pamiúè jest potrzebna dla aplikacji (odbywa siú to za pomocæ stronicowania i wymiany, jak omówiono w rozdziale 7. „Pamiúè”). Zmodyfikowane strony pamiúci („brudne”), przeznaczone do uľycia przez system plików, sæ zapisywane na dysku przez wætki jædra. Przed wydaniem jædra w wersji 2.6.32 istniađa przeznaczona do zapisu brudnych stron pula wætków (pdflush) w liczbie od 2 do 8. Od wymienionej wersji pula zostađa zastæpiona przez wætki flusher (nazywane flush), które sæ tworzone dla poszczególnych urzædzeē. Takie rozwiæzanie umoľliwia lepsze zrównowaľenie obciæľenia miúdzy urzædzeniami i poprawia przepustowoħè. Strony sæ zapisywane na dysku z wielu róľnych powodów: 

po upđywie zdefiniowanego czasu (30 sekund),



na skutek wywođania systemowego sync(), fsync() i msync(),



ze wzglúdu na istnienie zbyt wielu brudnych stron (dirty_ratio),



z braku dostúpnych stron w buforze stron.

Jeľeli búdzie deficyt wolnej pamiúci operacyjnej, inny wætek jædra — demon operacji page-out (kswapd, nazywany takľe skanerem stron) — równieľ moľe wyszukiwaè i oznaczaè strony do zapisania na dysku, aby moľna byđo zwolniè pamiúè stron i wykorzystaè do innych celów (patrz rozdziađ 7. „Pamiúè”). Podczas monitorowania zarówno kswapd, jak i wætki flush sæ z poziomu narzúdzi wydajnoħci systemu operacyjnego widoczne jako zadania jædra. Wiúcej informacji dotyczæcych skanera stron przygotowano w rozdziale 7., zatytuđowanym „Pamiúè”.

Bufor Dcache Bufor obiektów dentry — Dcache (ang. Dentry Cache) pamiúta mapowania elementów katalogu (struct dentry) na i-wúzđy VFS, podobnie jak DNLC w systemie UNIX. Omawiany bufor poprawia wydajnoħè wyszukiwania nazw ħcieľek (na przykđad za pomocæ

390

Rozdział 8



Systemy plików

open()), poniewaľ w trakcie analizy nazwy ħcieľki kaľda operacja wyszukiwania nazwy moľe sprawdziè bufor Dcache pod kætem bezpoħredniego mapowania vnode, zamiast przechodziè przez zawartoħè katalogu. Elementy bufora Dcache sæ przechowywane w tabeli hash (która z kolei jest haszowana przez nadrzúdny vnode i nazwú katalogu), co ma zapewniè szybkie i skalowane operacje wyszukiwania. Na przestrzeni lat do bufora Dcache dodano róľne funkcje poprawiajæce jego wydajnoħè dziađania, miúdzy innymi obsđugú algorytmu RCU-walk (ang. Read-CopyUpdate-Walk) — patrz odwođanie [1] na koēcu rozdziađu. Rozwiæzanie to polega na próbie przejħcia przez nazwú ħcieľki bez uaktualniania liczników odniesieē obiektów dentry, co spowodowađoby problemy ze skalowalnoħciæ na skutek koherencji intensywnie uľywanego bufora w systemach wieloprocesorowych. Jeľeli zostanie napotkany obiekt dentry nieistniejæcy w buforze, algorytm RCU-walk powraca do wolniejszego mechanizmu zliczania odniesieē (ref-walk), poniewaľ wspomniane liczniki búdæ konieczne podczas operacji wyszukiwania i blokowania w systemie plików. W przypadku duľego obciæľenia moľna oczekiwaè, ľe obiekty dentry prawdopodobnie búdæ buforowane i moľliwe búdzie zastosowanie podejħcia z uľyciem algorytmu RCU-walk. Bufor Dcache obsđuguje równieľ buforowanie negatywne. Wymieniona funkcja pamiúta wyszukiwania nieistniejæcych elementów, a to poprawia wydajnoħè w przypadku nieistniejæcych elementów w buforze, co najczúħciej ma miejsce w sytuacji wyszukiwania ħcieľki biblioteki. Wielkoħè bufora Dcache zmienia siú dynamicznie, a gdy system potrzebuje wiúkszej iloħci pamiúci, wtedy zmniejsza siú za pomocæ LRU. Wielkoħè bufora moľna monitorowaè, uľywajæc interfejsu /proc.

Bufor i-węzłów Ten bufor zawiera i-wúzđy VFS (struct inode), z których kaľdy opisuje wđaħciwoħci obiektu systemu plików, a wiele jest zwracanych przez wywođanie systemowe stat(). Wspomniane wđaħciwoħci sæ bardzo czústo dostúpne dla róľnych operacji, na przykđad sprawdzania uprawnieē podczas otwierania plików lub uaktualniania znaczników czasu podczas modyfikacji pliku bædļ katalogu. I-wúzđy VFS sæ przechowywane w tabeli hash, co ma umoľliwiè przeprowadzanie szybkiej i skalowanej operacji wyszukiwania. (Wartoħciæ hash jest numer i-wúzđa i superblok systemu plików). Wiúkszoħè operacji wyszukiwania jednak moľna obsđuľyè za pomocæ bufora Dcache. Wielkoħè bufora i-wúzđów zmienia siú dynamicznie, bufor przechowuje wszystkie i-wúzđy mapowane przez Dcache. W sytuacji, gdy systemowi zaczyna brakowaè wolnej pamiúci, bufor i-wúzđów moľe zostaè zmniejszony wskutek usuniúcia i-wúzđów, z którymi nie sæ powiæzane ľadne obiekty dentry. Wielkoħè bufora moľna monitorowaè za pomocæ interfejsu /proc.

8.4.4. Funkcje systemu plików Oprócz buforowania zostanæ omówione w tym rozdziale takľe inne kluczowe funkcje systemu plików wpđywajæce na jego wydajnoħè.

8.4. Architektura

391

Blok kontra extent Systemy plików oparte na blokach przechowujæ dane w blokach o stađej wielkoħci, do których odnoszæ siú wskaļniki znajdujæce siú w metadanych. W przypadku ogromnych plików to moľe wymagaè uľycia w metadanych wielu wskaļników prowadzæcych do bloków, a same bloki mogæ byè porozrzucane na dysku, co skutkuje duľæ iloħciæ losowych operacji wejħcia-wyjħcia. Aby tego uniknæè, pewne systemy plików oparte na blokach próbujæ umieszczaè bloki obok siebie. Innym podejħciem jest zastosowanie bloków o zmiennej wielkoħci, aby wraz ze wzrostem pliku wzrastađa takľe wielkoħè bloku i tym samym zmniejszađo siú obciæľenie zwiæzane z obsđugæ metadanych. Systemy plików oparte na extentach alokujæ ciægđæ przestrzeē dla plików (extenty) i powiúkszajæ jæ, jeħli zachodzi potrzeba. Kosztem obciæľenia zwiæzanego z przestrzeniæ takie rozwiæzanie poprawia wydajnoħè strumieniowania, a takľe moľe poprawiè wydajnoħè losowych operacji wejħcia-wyjħcia, poniewaľ dane pliku znajdujæ siú obok siebie.

Księgowanie Ksiúgowanie (lub rejestrowanie) w systemie plików powoduje rejestracjú zachodzæcych w nim zmian na wypadek awarii systemu. W przypadku awarii zmiany mogæ byè wprowadzone cađkowicie lub mogæ w ogóle nie byè wprowadzone. Dziúki temu istnieje moľliwoħè znacznie szybszego przywrócenia systemu plików do spójnego stanu. Gdy nastæpi awaria systemu, wtedy pozbawiony ksiúgowania system plików zostaje uszkodzony — jeħli dane i metadane dotyczæce wprowadzanych zmian nie zostađy w peđni zapisane. Operacja odzyskiwania danych po tego rodzaju awarii oznacza koniecznoħè analizy wszystkich struktur systemu plików, co moľe zajæè dđugie godziny w przypadku ogromnych (o pojemnoħci podawanej w terabajtach) systemów plików. Ksiúgowanie na dysku odbywa siú synchronicznie, pewne systemy plików umoľliwiajæ nawet konfiguracjú oddzielnego urzædzenia przeznaczonego do tego celu. W niektórych rodzajach ksiúgowania rejestrowane sæ zarówno dane, jak i metadane, co powoduje zuľywanie zasobów operacji wejħcia-wyjħcia urzædzeē pamiúci masowej, poniewaľ wszystkie operacje sæ zapisywane dwukrotnie. W pozostađych rodzajach ksiúgowania zapisywane sæ jedynie metadane, a spójnoħè zapewniana jest dziúki technice kopiowania przy zapisie (ang. Copy-on-Write). Istniejæ systemy plików skđadajæce siú jedynie z ksiúgowania, na przykđad logstructured file system, w którym wszystkie uaktualnienia danych i metadanych sæ zapisywane do ciægđego i rotacyjnego dziennika zdarzeē. Takie rozwiæzanie powoduje optymalizacjú operacji zapisu, poniewaľ zawsze búdæ one sekwencyjne i mogæ byè đæczone w celu uľycia wiúkszych operacji wejħcia-wyjħcia.

Technika kopiowania przy zapisie System plików wykorzystujæcy technikú kopiowania przy zapisie nie nadpisuje istniejæcych bloków, a zamiast tego wykonuje wymienione poniľej kroki: 1. Zapis bloków w nowym pođoľeniu (nowa kopia). 2. Uaktualnienie odniesieē, aby prowadziđy do nowych bloków. 3. Dodanie starych bloków do listy wolnych.

392

Rozdział 8



Systemy plików

Tego rodzaju technika pomaga zachowaè spójnoħè systemu plików w przypadku wystæpienia awarii, a ponadto poprawia wydajnoħè dziúki zamianie losowych operacji zapisu na sekwencyjne.

Scrubbing To jest funkcja systemu plików, która asynchronicznie odczytuje wszystkie bloki danych i weryfikuje sumú kontrolnæ, aby jak najwczeħniej wykryè ryzyko awarii napúdu. Najlepiej jeħli awaria zostanie wykryta wtedy, gdy jeszcze istnieje moľliwoħè odzyskania danych. Jednak wspomniane operacje wejħcia-wyjħcia zwiæzane z odczytem bloków mogæ negatywnie wpđywaè na wydajnoħè i dlatego powinny byè przeprowadzane z niskim priorytetem.

8.4.5. Rodzaje systemów plików Wiúksza czúħè tego rozdziađu przedstawia ogólnæ charakterystykú, któræ moľna zastosowaè wzglúdem wszystkich rodzajów systemów plików. W kolejnych fragmentach zostanæ podsumowane pewne funkcje wydajnoħci dostúpne w najczúħciej uľywanych systemach plików. Ich analizæ i dostrajaniem zajmiemy siú w dalszej czúħci rozdziađu.

FFS Wiele systemów plików zostađo opartych na FFS, który zaprojektowano w celu rozwiæzania problemów zwiæzanych z oryginalnym systemem plików dla systemu UNIX1. Krótkie wprowadzenie moľe pomóc w wyjaħnieniu obecnego stanu systemów plików. Oryginalny system plików dla systemu UNIX miađ ukđad na dysku skđadajæcy siú z tabeli i-wúzđów, 512-bajtowych bloków danych i superbloku uľywanego podczas alokacji zasobów (patrz odwođania [Ritchie 74] i [Lions 77] na koēcu rozdziađu). Tabela i-wúzđów i bloki danych dzieliđy partycje dysku na dwa zakresy, co negatywnie wpđywađo na wydajnoħè podczas wyszukiwania danych miúdzy nimi. Kolejnym problemem byđo uľycie mađego bloku o stađej wielkoħci wynoszæcej 512 B, co ograniczađo przepustowoħè i zwiúkszađo iloħè metadanych (wskaļników) koniecznych do przechowywania ogromnych plików. W wyniku eksperymentu wielkoħè bloku zwiúkszono do 1024 B, ale wtedy ujawniđo siú wæskie gardđo, jak zostađo to opisane przez McKusicka (patrz odwođanie [McKusick 84] na koēcu rozdziađu): Wprawdzie przepustowoħè zostađa podwojona, ale stary system plików nadal uľywađ okođo 4% przepustowoħci dysku. Najwiúkszy problem polegađ na tym, ľe lista wolnych bloków zostađa poczætkowo przygotowana w sposób zapewniajæcy optymalny dostúp, ale niestety szybko ulegđa modyfikacji na skutek tworzenia i usuwania plików. Ostatecznie lista zawierađa cađkowicie losowo umieszczone bloki, a wiúc dane plików byđy umieszczane w tych wđaħnie blokach, rozrzuconych po cađym dysku. Kaľdy dostúp do bloku wymagađ wiúc przeprowadzenia operacji wyszukiwania. Choè stary system plików 1

Oryginalnego systemu plików dla systemu UNIX nie naleľy myliè z póļniejszym systemem plików UFS, który zbudowano na bazie FFS. Istniejæ takľe róľne wersje UFS — bez wætpienia ten skrót jest czústo stosowany!

8.4. Architektura

393

zapewniađ poczætkowo transfer siúgajæcy 175 KB/s po utworzeniu listy wolnych bloków, to po kilku tygodniach zwykđego uľytkowania systemu transfer spadađ do okođo 30 KB/s wđaħnie ze wzglúdu na losowe rozmieszczenie bloków danych.

Przedstawiony cytat opisuje fragmentacjú listy wolnych bloków, która prowadzi z czasem do zmniejszenia wydajnoħci dziađania, gdy system plików jest uľywany. Opracowany system plików FFS (ang. Fast File System) umoľliwiđ poprawú wydajnoħci dziúki podziađowi partycji na wiele grup cylindrów, jak pokazano na rysunku 8.11. Kaľda grupa ma wđasnæ tabelú i-wúzđów i bloki danych. System stara siú, aby i-wúzđy i dane pliku byđy przechowywane w jednej grupie cylindra, o ile moľliwe (patrz rysunek 8.12), poniewaľ to zmniejsza operacje wyszukiwania na dysku. Inne dane powiæzane z plikiem, miúdzy innymi i-wúzđy dotyczæce katalogu i jego elementów, równieľ sæ umieszczane w pobliľu. Projekt i-wúzđa pozostađ podobny do oryginalnego (patrz odwođanie [Bach 86] na koēcu rozdziađu). Na rysunku 8.12 nie pokazano potrójnie poħrednich bloków.

Rysunek 8.11. Grupy cylindra

Rysunek 8.12. Struktura danych i-węzła

Wielkoħè bloku zostađa zwiúkszona minimum do 4 KB, co poprawiđo przepustowoħè. Zmniejszyđa siú liczba bloków danych niezbúdnych do przechowywania pliku, a tym samym liczba bloków poħrednich wymagajæcych odniesienia do bloków danych.

394

Rozdział 8



Systemy plików

Liczba wymaganych wskaļników poħrednich zostađa jeszcze bardziej zmniejszona, poniewaľ bloki danych stađy siú wiúksze. W celu efektywnego wykorzystania miejsca podczas przechowywania mađych plików kaľdy blok danych mógđ byè podzielony na fragmenty o wielkoħci 1 KB. Inna wprowadzona w systemie plików FFS funkcja zwiæzana z wydajnoħciæ to block interleaving: umieszczanie na dysku sekwencyjnych bloków pliku z pozostawianiem miúdzy blokami miejsca co najmniej na jeden dodatkowy (patrz odwođanie [Doeppner 10] na koēcu rozdziađu). Wspomniane bloki dodatkowe dajæ jædru systemu i procesorowi czas na wydanie kolejnego sekwencyjnego polecenia odczytu, poniewaľ w danej chwili to jædro i procesor bezpoħrednio kierujæ dyskiem. Bez pozostawionych pustych miejsc na bloki gđowica dysku mogđaby minæè nastúpny blok, zanim uzyskađaby gotowoħè do jego odczytu. W takim przypadku nastæpiđoby opóļnienie zwiæzane z koniecznoħciæ wykonania praktycznie peđnego obrotu gđowicy.

UFS System plików FFS zostađ wprowadzony w SunOS 1.0 w 1984 roku, podobnie jak UFS (patrz odwođanie [McDougall 06a] na koēcu rozdziađu). W dwóch kolejnych dekadach do systemu plików SunOS UFS wprowadzono wiele nowych funkcji, miúdzy innymi klastrowanie operacji wejħcia-wyjħcia, zwiúkszenie systemu plików, obsđugú wielkoħci rzúdu terabajtów, rejestrowanie, bezpoħrednie operacje wejħcia-wyjħcia, migawki, listy kontroli dostúpu (ang. Access Control Lists, ACL) i rozbudowane atrybuty. Obecnie system Linux potrafi odczytywaè dane zapisane w systemie plików UFS, ale nie ma moľliwoħci zapisu w tym systemie. Zamiast tego obsđuguje inny system plików, podobny do UFS (ext3). To sæ kluczowe funkcje dotyczæce wydajnoħci, które zaimplementowano w UFS: 





Klastrowanie operacji wejħcia-wyjħcia. Ta funkcja grupuje bloki danych na dysku wskutek opóļnienia zapisu aľ do chwili, gdy klaster búdzie peđen. W ten sposób operacja zapisu stanie siú sekwencyjna. Po wykryciu sekwencyjnej operacji odczytu system plików UFS stosuje mechanizm prefetch (nazywany równieľ odczytem z wyprzedzeniem) i odczytuje klastry. Rejestrowanie (ksiúgowanie). Dotyczy jedynie metadanych. To poprawia wydajnoħè uruchamiania systemu po awarii, poniewaľ wykorzystanie informacji znajdujæcych siú w dzienniku zdarzeē zapobiega koniecznoħci uruchomienia narzúdzia przeznaczonego do sprawdzania systemu plików (fsck). Ponadto moľe siú poprawiè wydajnoħè pewnych operacji zapisu dziúki gromadzeniu zapisu metadanych. Bezpoħrednie operacje wejħcia-wyjħcia. Oznacza pominiúcie bufora stron i unikniúcie tym samym podwójnego buforowania w przypadku aplikacji, takich jak bazy danych.

Funkcje moľliwe do konfiguracji zostađy opisane na stronie podrúcznika man dla mkfs_ufs. Wiúcej informacji na temat systemu plików UFS i jego wewnútrznych komponentów znajdziesz w rozdziale 15. ksiæľki Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture, 2nd Edition (patrz odwođanie [McDougall 06a] na koēcu rozdziađu).

8.4. Architektura

395

ext3 System plików ext (ang. Extended File System) zostađ opracowany w 1992 roku jako pierwszy system plików dla systemu Linux i jego VFS. Oczywiħcie zostađ oparty na oryginalnym systemie plików systemu UNIX. Wersja druga (ext2), wydana w 1993 roku, zawierađa obsđugú wielu znaczników czasu, jak równieľ grupy cylindrów znane z FFS. Natomiast wersja trzecia (ext3) pojawiđa siú w 1999 roku i oferuje obsđugú zmiany wielkoħci systemu plików oraz ksiúgowanie. To sæ kluczowe funkcje dotyczæce wydajnoħci, które zaimplementowano od chwili wydania ext: 







Ksiúgowanie. Dostúpne w trybie ordered mode jedynie dla metadanych i journal mode dla metadanych i danych. Ksiúgowanie poprawia wydajnoħè uruchamiania systemu po awarii, poniewaľ wykorzystanie informacji znajdujæcych siú w dzienniku zdarzeē zapobiega koniecznoħci uruchomienia narzúdzia sđuľæcego do sprawdzania systemu plików (fsck). Poza tym moľe poprawiè siú wydajnoħè pewnych operacji zapisu wskutek gromadzenia zapisu metadanych. Urzædzenie ksiúgowania. Istnieje moľliwoħè uľycia zewnútrznego urzædzenia w celu ksiúgowania, aby obciæľenie zwiæzane z rejestrowaniem zmian nie wpđywađo negatywnie na operacje odczytu. Alokator bloków orlov. Pozwala na umieszczanie w wielu grupach cylindrów katalogów najwyľszego poziomu, aby podkatalogi i ich zawartoħè znajdowađy siú w pobliľu. W ten sposób zmniejsza siú iloħè losowych operacji wejħcia-wyjħcia. Indeksy katalogu. Oznacza dodanie do systemu plików haszowanych struktur typu B-tree, co umoľliwia szybsze wyszukiwanie katalogów.

Funkcje moľliwe do konfiguracji zostađy opisane na stronie podrúcznika man dla mke2fs.

ext4 System plików ext4 zostađ wydany w 2008 roku. W stosunku do ext3 dodano wiele róľnych funkcji oraz wprowadzono usprawnienia w zakresie wydajnoħci, takie jak: obsđuga extentów, ogromnej pojemnoħci, prealokacji za pomocæ fallocate() oraz opóļnionej alokacji, a ponadto sprawdzenie sumy kontrolnej ksiúgowania, szybsze dziađanie narzúdzia fsck, alokator multiblock, znaczniki czasu wyraľane w nanosekundach i migawki. Oto kluczowe funkcje dotyczæce wydajnoħci, zaimplementowane od chwili wydania ext: 



Extenty. Extenty poprawiajæ sekwencyjne umieszczanie danych, co oznacza zmniejszenie iloħci losowych operacji wejħcia-wyjħcia, zwiúkszenie wielkoħci operacji wejħcia-wyjħcia i liczby operacji sekwencyjnych. Prealokacja. Odbywa siú za pomocæ wywođania systemowego fallocate(). To pozwala aplikacjom na alokowanie przestrzeni, która prawdopodobnie búdzie ciægđa, co póļniej poprawia wydajnoħè operacji zapisu.

396

Rozdział 8







Systemy plików

Opóļniona alokacja. Alokacja bloku zostaje opóļniona aľ do chwili jego zapisu na dysku — pozwala to na zapis w grupie (za pomocæ alokatora multiblock) i zmniejsza fragmentacjú. Szybsze dziađanie fsck. Niezaalokowane bloki i i-wúzđy sæ oznaczane, co skraca czas dziađania narzúdzia fsck.

Funkcje moľliwe do konfiguracji zostađy opisane na stronie podrúcznika man dla mke2fs. Niektóre z wymienionych powyľej funkcji, na przykđad extenty, moľna zastosowaè takľe w systemie plików ext3.

ZFS System plików ZFS zostađ opracowany przez firmú Sun Microsystems i wydany w 2005 roku. Đæczy w sobie system plików z menedľerem woluminów, a ponadto obsđuguje wiele funkcji stosowanych w ħrodowiskach biznesowych, miúdzy innymi: pule pamiúci masowej, rejestrowanie, technikú kopiowania przy zapisie, bufor ARC, obsđugú ogromnej pojemnoħci, bloki o zmiennej wielkoħci, dynamicznæ zmianú wielkoħci, wiele strumieni mechanizmu prefetch, migawki, klonowanie, kompresjú, scrubbing i 128-bitowe sumy kontrolne. Kolejne funkcje byđy dodawane w uaktualnieniach i obejmujæ miúdzy innymi (czúħè z nich zostanie omówiona za chwilú): wymianú dysku w trakcie dziađania systemu, podwójnæ parzystoħè w macierzy RAID, kompresjú gzip, SLOG, bufor L2ARC, limity dla uľytkownika i grupy, potrójnæ parzystoħè w macierzy RAID, usuwanie powielonych danych, hybrydowæ alokacjú RAID oraz szyfrowanie. Wymienione funkcje powodujæ, ľe ZFS jest atrakcyjnym wyborem w zakresie systemu plików dla serwerów plików opracowanych przez Sun/Oracle i inne firmy (na podstawie ZFS wydanego jako open source). Oto kluczowe funkcje w zakresie wydajnoħci, zaimplementowane od chwili wydania ZFS: 







Pule pamiúci masowej. Wszystkie urzædzenia pamiúci masowej sæ umieszczone w puli, na podstawie której tworzony jest system plików. To pozwala jednoczeħnie wykorzystywaè wszystkie urzædzenia w celu osiægniúcia maksymalnej przepustowoħci i liczby operacji wejħcia-wyjħcia. Uľyte mogæ byè róľne rodzaje macierzy RAID: 0, 1, 10, Z (oparta na RAID-5), Z2 (podwójna parzystoħè) i Z3 (potrójna parzystoħè). Technika kopiowania przy zapisie. Grupowanie operacji zapisu i przeprowadzanie ich jako operacje sekwencyjne. Rejestrowanie. System plików ZFS zapisuje grupy transakcji (TXG) zmian, które sæ w cađoħci zatwierdzane lub odrzucane i tym samym zawsze zostaje zachowana spójnoħè dysku. Istnieje równieľ moľliwoħè przeprowadzania grupowych operacji zapisu, co poprawia asynchronicznæ przepustowoħè zapisu. Bufor ARC. Bufor ARC (ang. Adaptive Replacement Cache) umoľliwia osiægniúcie wysokiego wspóđczynnika trafnoħci dziúki jednoczesnemu uľyciu wielu algorytmów buforowania: MRU (ang. Most Recently Used) i MFU (ang. Most Frequently Used). Pamiúè operacyjna jest równowaľona miúdzy wymienionymi algorytmami na podstawie ich wydajnoħci, która jest znana dziúki obsđudze

8.4. Architektura

397

dodatkowych metadanych (ghost lists), w celu sprawdzenia, jak kaľdy z nich búdzie dziađađ, jeħli otrzyma cađæ dostúpnæ pamiúè. 

















Bloki o zmiennej wielkoħci. Kaľdy system plików ma konfigurowalnæ maksymalnæ wielkoħè bloku (rekordu), któræ moľna dobraè w zaleľnoħci od obciæľenia. Mniejsze wielkoħci sæ przeznaczone dla mniejszych plików. Dynamiczne zmniejszanie przepustowoħci. Zmniejszanie nastúpuje we wszystkich urzædzeniach pamiúci masowej, aby zachowaè maksymalnæ przepustowoħè. Obejmuje takľe dodatkowe urzædzenia w macierzy, jeħli zostanæ dodane. Inteligentny mechanizm prefetch. System plików ZFS stosuje róľne rodzaje mechanizmu prefetch zgodnie z wymaganiami: dla metadanych, dla znodes (zawartoħè plików) i dla vdev (urzædzenia wirtualne). Wiele strumieni mechanizmu prefetch. Wiele strumieni odczytujæcych jeden plik moľe doprowadziè do powstania losowych operacji wejħcia-wyjħcia, poniewaľ system plików przeprowadza operacje wyszukiwania miúdzy strumieniami (to stanowiđo problem w UFS). System plików ZFS monitoruje poszczególne strumienie mechanizmu prefetch, pozwala na dođæczanie nowych i efektywnie wykonuje operacje wejħcia-wyjħcia. Migawki. Ze wzglúdu na architekturú kopiowania przy zapisie migawki mogæ byè tworzone niemalľe natychmiast, w wyniku czego odkđadane jest kopiowanie nowych plików do chwili, aľ stanie siú to konieczne. Potok ZIO. Operacje wejħcia-wyjħcia urzædzenia sæ przetwarzane przez potok etapów, a kaľdy etap jest obsđugiwany przez pulú wætków, co poprawia wydajnoħè. Kompresja. Obsđugiwanych jest wiele algorytmów, które zwykle zmniejszajæ wydajnoħè ze wzglúdu na obciæľanie procesora. Opcja lzjb (Lemper-Ziv Jeff Bonwick) jest lekka i minimalnie poprawia wydajnoħè pamiúci masowej dziúki zmniejszeniu obciæľenia zwiæzanego z operacjami wejħcia-wyjħcia (skompresowane) kosztem pewnego zuľycia procesora. SLOG. Oddzielny dziennik zdarzeē w systemie ZFS umoľliwiajæcy synchroniczny zapis w oddzielnych urzædzeniach, co pozwala uniknæè rywalizacji w puli dysków. Zapisane zdarzenia w SLOG moľna jedynie odczytywaè, nie ma moľliwoħci ich modyfikacji — to na wypadek awarii systemu. W ten sposób moľna znacznie zwiúkszyè wydajnoħè synchronicznych operacji zapisu. Bufor L2ARC. To jest bufor poziomu drugiego przeznaczony do buforowania losowych operacji odczytu i dysków zbudowanych na bazie pamiúci flash (na przykđad SSD). Nie buforuje ľadnych operacji zapisu i zawiera jedynie czyste dane znajdujæce siú w puli dysków pamiúci masowej. Bufor L2ARC stanowi rozszerzenie moľliwoħci w zakresie buforowania systemu i pomaga uniknæè nagđego spadku wydajnoħci, gdy wykonywane zadania wykroczæ poza bufor pamiúci operacyjnej. Zapewnia równieľ histerezú, poniewaľ jego wypeđnianie przebiega wolniej niľ pamiúci operacyjnej i zawiera kopie dđugoterminowych danych. Jeľeli nastæpiæ perturbacje prowadzæce do zapeđnienia bufora w pamiúci operacyjnej, to bufor L2ARC búdzie mógđ szybko przywróciè go do stanu „rozgrzany”.

398

Rozdział 8







Systemy plików

Bufor vdev. Ten bufor peđni funkcjú podobnæ do oryginalnej podrúcznej pamiúci buforowej. System plików ZFS uľywa oddzielnych buforów vdev dla poszczególnych urzædzeē wirtualnych, które obsđugujæ LRU i odczyt z wyprzedzeniem. (Moľe to byè wyđæczone w niektórych systemach operacyjnych). Usuwanie powielonych danych. Funkcja na poziomie systemu operacyjnego pozwalajæca uniknæè zapisu wielu kopii tych samych danych. Omawiana funkcja implikuje wydajnoħè, zarówno w aspekcie dobrym (zmniejsza siú liczba operacji wejħcia-wyjħcia urzædzenia), jak i zđym (gdy tabela hash nie mieħci siú w pamiúci operacyjnej, wtedy mamy do czynienia ze zwiúkszeniem liczby operacji wejħcia-wyjħcia, najczúħciej znacznym). Poczætkowa wersja funkcji jest przeznaczona jedynie dla obciæľenia, gdy wiadomo, ľe tabela hash zawsze búdzie siú mieħciđa w pamiúci operacyjnej.

Bufor L2ARC i SLOG sæ czúħciæ modelu HSP (ang. ZFS Hybrid Storage Pool) stosowanego w celu inteligentnego uľycia w puli pamiúci masowej ZFS zoptymalizowanych pod kætem odczytu i zapisu napúdów SSD. Zoptymalizowany pod kætem odczytu napúd SSD charakteryzuje siú dobrym wspóđczynnikiem cena/wydajnoħè, plasujæcym siú miúdzy wartoħciami osiæganymi przez pamiúè operacyjnæ i dysk, co czyni go rozwiæzaniem odpowiednim do uľycia jako warstwa buforowania. Wprowadzono takľe inne, mniejsze funkcje dotyczæce wydajnoħci. Przykđadem moľe byè funkcja „nie przejmuje siú odstúpami”, powodujæca wykonywanie wiúkszych operacji odczytu, w sytuacji gdy mniejsze czúħci (odstúpy) nie sæ potrzebne. Kolejny przykđad to hybrydowa macierz RAID, umoľliwiajæca obsđugú róľnych typów macierzy w jednej puli dysków. Istnieje pewne zachowanie ZFS, które moľe zmniejszyè wydajnoħè w porównaniu z innymi systemami plików: domyħlnie ZFS wydaje urzædzeniom pamiúci masowej polecenia zapisu zawartoħci bufora, aby zagwarantowaè zapis danych na dysku — to na wypadek zaniku zasilania. Ta jedna z oferowanych przez ZFS funkcji zapewnienia spójnoħci danych wiæľe siú z pewnym kosztem: moľe wprowadziè opóļnienie do operacji ZFS, które muszæ poczekaè na zapis zawartoħci bufora na dysku. W niektórych rodzajach obciæľenia uľycie ZFS spowoduje mniejszæ wydajnoħè niľ uľycie innych systemów plików. Podobnie jak inne systemy plików, takľe ZFS moľe doprowadziè tylko do czúħciowego zapisu danych, a tym samym ich uszkodzenia w przypadku zaniku zasilania. To zaleľy jeszcze od uľytych urzædzeē pamiúci masowej. Przygotowano dwa projekty majæce na celu przeniesienie systemu plików ZFS do systemu Linux. Jeden z nich to ZFS on Linux, prowadzony przez Lawrence Livermore National Laboratory (patrz odwođanie [2] na koēcu rozdziađu). To jest rodzime rozwiæzanie przygotowane dla jædra systemu Linux. Drugi projekt to ZFS-FUSE — uruchamia ZFS w przestrzeni uľytkownika, ale charakteryzuje siú gorszæ wydajnoħciæ ze wzglúdu na obciæľenie zwiæzane z przeđæczaniem kontekstu.

btrfs Ten system plików zostađ oparty na technice kopiowania przy zapisie struktur typu B-tree. To jest nowoczesne rozwiæzanie đæczæce system plików i menedľera woluminów,

8.4. Architektura

399

podobnie jak ZFS. Oferowany zestaw funkcji jest równieľ porównywalny z ZFS. Aktualnie dostúpne funkcje to miúdzy innymi — pule pamiúci masowej, obsđuga ogromnych pojemnoħci, extenty, technika kopiowania przy zapisie, zmiana wielkoħci systemu plików, subwoluminy, dodawanie i odejmowanie urzædzeē blokowych, migawki, klonowanie, kompresja i sumy kontrolne CRC-32C. Prace nad tym systemem plików zostađy rozpoczúte w 2007 roku przez Oracle, nadal sæ intensywnie prowadzone, choè sam system plików jest jeszcze uznawany za niestabilny. To sæ kluczowe funkcje dotyczæce wydajnoħci: 





 

 

Pule pamiúci masowej. Urzædzenia pamiúci masowej sæ umieszczane w woluminie, na podstawie którego utworzony zostaje system plików. Umoľliwia to jednoczesne wykorzystywanie wszystkich urzædzeē w celu osiægniúcia maksymalnej przepustowoħci i liczby operacji wejħcia-wyjħcia. Uľyte mogæ byè róľne rodzaje macierzy RAID: 0, 1 i 10. Technika kopiowania przy zapisie. Grupowanie operacji zapisu i przeprowadzanie ich jako operacje sekwencyjne. Równowaľenie. Obiekty mogæ byè przenoszone miúdzy urzædzeniami pamiúci masowej, aby w ten sposób równowaľyè ich obciæľenie. Extenty. Poprawiajæ sekwencyjne uđoľenie danych i wydajnoħè. Migawki. Ze wzglúdu na architekturú kopiowania przy zapisie migawki mogæ byè tworzone niemalľe natychmiast, co odkđada kopiowanie nowych plików do chwili, aľ stanie siú to konieczne. Kompresja. Obsđugiwane sæ algorytmy zlib i LZO. Ksiúgowanie. Dla poszczególnych subwoluminów moľna utworzyè dziennik zdarzeē drzewa przeznaczony do ksiúgowania synchronicznego obciæľenia zwiæzanego ze stosowaniem techniki kopiowania przy zapisie.

Planowane funkcje dotyczæce wydajnoħci obejmujæ macierz RAID poziomu 5. i 6., macierz RAID na poziomie obiektu, przyrostowy zapis danych i unikanie powielania danych.

8.4.6. Woluminy i pule Dawniej systemy plików byđy budowane wokóđ pojedynczego dysku lub partycji. Woluminy i pule pozwalajæ na tworzenie systemów plików obejmujæcych wiele dysków i skonfigurowanych do stosowania róľnych strategii macierzy RAID (patrz rozdziađ 9. „Dyski”). Wolumin przedstawia wiele dysków jako jeden wirtualny dysk, na podstawie którego nastúpuje utworzenie systemu plików. Kiedy pliki sæ tworzone na bazie cađych dysków (nie partycji), woluminy izolujæ obciæľenie i zmniejszajæ problemy zwiæzane z rywalizacjæ o dostúp do zasobów. Oprogramowanie przeznaczone do zarzædzania woluminami obejmuje miúdzy innymi LVM (ang. Logical Volume Manager) dla systemu Linux oraz SVM (ang. Solaris Volume Manager) dla systemu Solaris. Woluminy, czyli dyski wirtualne, mogæ byè równieľ dostarczane przez sprzútowe kontrolery RAID.

400

Rozdział 8



Systemy plików

Pula pamiúci masowej skđada siú z wielu dysków — na jej podstawie moľna utworzyè wiele systemów plików. Takie rozwiæzanie zostađo pokazane na rysunku 8.13. Pula pamiúci masowej stanowi znacznie elastyczniejsze rozwiæzanie niľ wolumin pamiúci masowej, poniewaľ istnieje moľliwoħè zmiany wielkoħci systemów plików, niezaleľnie od urzædzeē tworzæcych pulú. Wspomniana moľliwoħè jest wykorzystywana przez nowoczesne systemy plików, takie jak ZFS i btrfs.

Rysunek 8.13. Woluminy i pule

Pula pamiúci moľe uľywaè wszystkich urzædzeē dyskowych do wszystkich systemów plików, a tym samym poprawiè ich wydajnoħè. Obciæľenia nie sæ izolowane. W pewnych sytuacjach na podstawie wielu pul moľna zastosowaè rozdzielenie obciæľenia, choè odbúdzie siú to kosztem elastycznoħci, poniewaľ poczætkowo urzædzenia dyskowe búdæ musiađy zostaè umieszczone w róľnych pulach. W tym miejscu wymieniono dodatkowe czynniki dotyczæce wydajnoħci, które naleľy wziæè pod uwagú podczas uľywania oprogramowania przeznaczonego do zarzædzania woluminami lub stosowania pul pamiúci masowej:  





Iloħè dysków. Naleľy dopasowaè do obciæľenia. Moľliwoħè monitorowania. Poziom wykorzystania urzædzenia wirtualnego moľe byè mylæcy, warto sprawdziè oddzielnie dla poszczególnych urzædzeē fizycznych. Obciæľenie procesora. To ma znaczenie w szczególnoħci podczas obliczania parzystoħci macierzy RAID. Trzeba jednak dodaè, ľe w przypadku nowoczesnych, szybkich procesorów ten czynnik ma coraz mniejsze znaczenie. Moľliwoħè odbudowy. Ten proces nosi równieľ nazwú resilvering. Z omawianym tutaj procesem mamy do czynienia, gdy do grupy dysków macierzy RAID zostaje dodany nowy, pusty dysk (na przykđad w celu wymiany uszkodzonego). Wówczas nowy dysk jest wypeđniany niezbúdnymi danymi, aby mógđ dođæczyè do grupy. Operacja ma zdecydowanie negatywny wpđyw na wydajnoħè, poniewaľ wiæľe siú z ogromnæ iloħciæ operacji wejħciawyjħcia i moľe trwaè wiele godzin, a nawet dni.

Odbudowa moľe w przyszđoħci staè siú jeszcze wiúkszym problemem, co jest zwiæzane z tym, ľe pojemnoħè urzædzeē pamiúci masowej wzrasta szybciej niľ ich przepustowoħè. Dlatego teľ czas odbudowy ulega wydđuľeniu.

8.5. Metodologia

401

8.5. Metodologia W tym podrozdziale zostanæ przedstawione róľne metodologie, jak równieľ èwiczenia dotyczæce analizy systemu plików i jego dostrajania. Poruszone tematy podsumowano w tabeli 8.5. Tabela 8.5. Podsumowanie metodologii dotyczących wydajności systemów plików Metodologia

Opis

Analiza dysku

Analiza oparta na obserwacji.

Analiza opóźnienia

Analiza oparta na obserwacji.

Charakterystyka obciążenia

Analiza oparta na obserwacji, planowanie pojemności.

Monitorowanie wydajności

Analiza oparta na obserwacji, planowanie pojemności.

Monitorowanie zdarzeń

Analiza oparta na obserwacji.

Statyczne dostosowanie wydajności

Analiza oparta na obserwacji, planowanie pojemności.

Dostrajanie bufora

Analiza oparta na obserwacji, dostrojenie.

Separacja obciążenia

Dostrojenie.

Systemy plików w pamięci

Dostrojenie.

Mikrotesty wydajności

Analiza oparta na eksperymentach.

W rozdziale 2., zatytuđowanym „Metodologia”, znajdziesz wiúcej strategii oraz wprowadzenie do wielu z nich. Strategii wymienionych w tabeli moľesz uľywaè pojedynczo lub w pođæczeniu z innymi. Sugerujú korzystanie ze strategii w nastúpujæcej kolejnoħci: analiza opóļnienia, monitorowanie wydajnoħci, charakterystyka obciæľenia, mikrotesty wydajnoħci, analiza statyczna i monitorowanie zdarzeē. Oczywiħcie moľesz zastosowaè inne pođæczenie i innæ kolejnoħè strategii; zastosuj rozwiæzanie, które najlepiej sprawdza siú w Twoim przypadku. W podrozdziale 8.6 „Analiza” przedstawiono informacje o znajdujæcych siú w systemach operacyjnych narzúdziach pozwalajæcych na uľycie omawianych strategii.

8.5.1. Analiza dysku Powszechnie stosowanæ strategiæ jest ignorowanie systemu plików i zamiast tego koncentrowanie siú na wydajnoħci dysku. Wynika to z faktu, ľe najgorszymi operacjami wejħcia-wejħcia sæ te wykonywane przez dysk. Ponadto, przystúpujæc do analizy dysku, koncentrujesz siú na oczekiwanym ļródle problemu. W przypadku prostszych systemów plików i mniejszej wielkoħci buforów takie podejħcie sprawdzađo siú. Obecnie jest ono niewđaħciwe, poniewaľ prowadzi do pominiúcia cađej klasy problemów (patrz punkt 8.3.12).

402

Rozdział 8



Systemy plików

8.5.2. Analiza opóźnienia Analizú opóļnienia naleľy rozpoczæè od zmierzenia opóļnienia operacji systemu plików. Podczas pomiaru trzeba uwzglúdniè wszystkie obiekty operacji, a nie tylko operacje wejħcia-wyjħcia (na przykđad sync()). opóěnienie operacji = godzina zakoñczenia operacji-godzina ĝÈdania operacji

Wartoħè opóļnienia moľna zmierzyè na jednej z czterech dostúpnych warstw, które wymieniono w tabeli 8.4. Wybór konkretnej warstwy do przeprowadzenia pomiaru moľe zaleľeè od dostúpnoħci narzúdzi. Sprawdļ wymienione poniľej: 





Dokumentacja aplikacji. Niektóre aplikacje zawierajæ wbudowane metryki opóļnienia systemu plików bædļ posiadajæ moľliwoħè zbierania danych dotyczæcych opóļnienia. Narzúdzia systemu operacyjnego. Systemy operacyjne równieľ mogæ dostarczaè metryk, w najlepszej sytuacji w postaci oddzielnych danych statystycznych dotyczæcych poszczególnych systemów plików lub aplikacji. Monitorowanie dynamiczne. Jeľeli system ma moľliwoħè prowadzenia monitorowania dynamicznego, to wszystkie warstwy moľna analizowaè za pomocæ wđasnych skryptów, bez koniecznoħci ponownego rozpoczynania czegokolwiek.

Opóļnienie moľe byè zaprezentowane w postaci: 





Ħredniej wartoħci w przedziale czasu. Na przykđad — ħrednia wartoħè opóļnienia odczytu w trakcie sekundy. Peđnego rozkđadu. Na przykđad — histogramy lub mapy cieplne, patrz punkt 8.6.18. Wartoħci dla poszczególnych operacji. Dane dla wszystkich operacji, patrz punkt 8.5.5.

W systemach plików charakteryzujæcych siú wysokim wspóđczynnikiem trafnoħci bufora (ponad 99%) na ħredniæ wartoħè opóļnienia w okreħlonym przedziale czasu dominujæcy wpđyw búdzie miađo opóļnienie trafnoħci bufora. Moľe to byè niefortunne, gdy istniejæ pojedyncze przypadki duľego opóļnienia (elementy odstajæce), które koniecznie trzeba zidentyfikowaè, choè jest to trudne na podstawie ħredniej wartoħci. Rozwiæzaniem jest wówczas przeanalizowanie peđnego rozkđadu lub opóļnienia poszczególnych operacji, dziúki czemu moľna wyszukaè elementy odstajæce oraz sprawdziè wpđyw róľnych warstw opóļnienia, miúdzy innymi trafnoħci i nietrafnoħci bufora systemu plików. Po wykryciu duľego opóļnienia naleľy prowadziè analizú dræľæcæ w systemie plików, aby wykryè ļródđo opóļnienia.

8.5. Metodologia

403

Tabela 8.4. Warstwy umożliwiające przeprowadzenie analizy opóźnienia systemu plików Warstwa

Zalety

Wady

Aplikacji

Ten pomiar jest przeprowadzany w miejscu najbliższym występowania efektu opóźnienia systemu plików w aplikacji. Za pomocą wspomnianego pomiaru można sprawdzić kontekst aplikacji i ustalić, czy opóźnienie powstaje w trakcie wykonywania podstawowych funkcji aplikacji, czyli — czy jest asynchroniczne.

Stosowane techniki zależą od aplikacji i wersji oprogramowania.

Interfejs wywołań systemowych

Doskonale udokumentowany interfejs. Najczęściej możliwy do monitorowania przy użyciu narzędzi systemu operacyjnego oraz przeznaczonych do monitorowania statycznego.

Wywołania systemowe obsługują wszystkie rodzaje systemów plików, w tym także nieprzeznaczone do przechowywania danych (na przykład systemy plików przeznaczone dla danych statystycznych, gniazd itd.), co może być mylące, o ile wspomniane systemy plików nie zostaną odfiltrowane. Kolejnym utrudnieniem może być istnienie wielu wywołań systemowych do tej samej funkcji systemu plików. Na przykład dla odczytu istnieją wywołania read(), pread(), read64() itd., a wszystkie należy uwzględnić podczas pomiarów.

VFS

Standardowy interfejs dla wszystkich systemów plików. Jedno wywołanie dla operacji systemu plików, na przykład vfs_write().

VFS monitoruje wszystkie rodzaje systemu plików, w tym te, które nie są przeznaczone do przechowywania danych (na przykład są przeznaczone dla danych statystycznych, gniazd itd.), co może być mylące, jeśli wspomniane systemy plików wcześniej nie zostaną odfiltrowane.

Na górze systemu plików

Monitorowanie jedynie wybranego rodzaju systemu plików w celu zebrania informacji szczegółowych o wewnętrznym kontekście systemu plików.

Specyficzna dla konkretnego systemu plików technika monitorowania, zależy od wersji oprogramowania systemu plików. (Jednak system plików może posiadać interfejs podobny do VFS, odpowiedzialny za mapowanie VFS, i wtedy nie ulega częstym zmianom).

Koszt transakcji Innym sposobem przedstawienia opóļnienia systemu plików jest podanie cađkowitego czasu oczekiwania na system plików podczas transakcji aplikacji (na przykđad zapytania bazy danych): procent czasu w systemie plików = 100*caïkowite opóěnienie blokujÈce system plików/ ´czas transakcji aplikacji

404

Rozdział 8



Systemy plików

Pozwala to na wyraľenie kosztu operacji systemu plików w kategoriach wydajnoħci aplikacji oraz na przewidywanie poprawy wydajnoħci. Metryka moľe byè przedstawiona jako wartoħè ħrednia wszystkich transakcji w przedziale czasu lub poszczególnych transakcji. Na rysunku 8.14 pokazano czas spúdzony przez wætek aplikacji podczas obsđugi transakcji. W omawianym przypadku transakcja oznacza pojedynczæ operacjú odczytu systemu plików, podczas której aplikacja jest zablokowana i czeka na zakoēczenie operacji, po czym nastúpuje przejħcie do stanu „poza procesorem”. W tej konkretnej sytuacji cađkowity czas zablokowania to jest czas trwania wspomnianej pojedynczej operacji odczytu systemu plików. Jeľeli wiele operacji wejħcia-wyjħcia blokuje dziađanie w trakcie transakcji aplikacji, to cađkowity czas blokady jest sumæ tych operacji.

Rysunek 8.14. Aplikacja i opóźnienie systemu plików

Spójrzmy na przykđad. Transakcja aplikacji trwa 200 ms, z których 180 ms to czas oczekiwania na wiele operacji wejħcia-wyjħcia w systemie plików. Czas blokowania aplikacji przez system plików wynosi wiúc 90% (100*180 ms/200 ms). Dlatego teľ usuniúcie opóļnienia systemu plików moľe poprawiè wydajnoħè dziađania aplikacji nawet dziesiúciokrotnie. Spójrzmy na inny przykđad. Transakcja aplikacji trwa 200 ms, z których jedynie 2 ms to czas spúdzony w systemie plików. W tej sytuacji system plików — i ogólnie cađy stos dyskowych operacji wejħcia-wyjħcia — stanowiæ jedynie 1% czasu trwania transakcji. Ten wynik jest niewiarygodnie uľyteczny, poniewaľ moľe skierowaè analizú wydajnoħci ku rzeczywistemu ļródđu opóļnienia, co zapobiegnie marnowaniu czasu na analizú komponentów, w których opóļnienie nie wystúpuje. Jeľeli aplikacja wykonuje nieblokujæce operacje wejħcia-wyjħcia, to moľe dziađaè w procesorze, podczas gdy system plików kontynuuje udzielanie odpowiedzi. W takiej sytuacji blokujæce opóļnienie systemu plików jest jedynie czasem, w którym aplikacja byđa zablokowana poza procesorem.

8.5.3. Charakterystyka obciążenia Charakterystyka obciæľenia to bardzo waľne zadanie podczas planowania pojemnoħci, przeprowadzania testów wydajnoħci i symulacji obciæľenia. Moľe prowadziè równieľ do uzyskania najwiúkszej poprawy wydajnoħci wskutek identyfikacji niepotrzebnych zadaē, które moľna wyeliminowaè. To sæ podstawowe atrybuty przeznaczone do scharakteryzowania obciæľenia systemu plików:

8.5. Metodologia



czústotliwoħè i rodzaj wykonywanych operacji,



przepustowoħè plikowych operacji wejħcia-wyjħcia,



wielkoħè plikowych operacji wejħcia-wyjħcia,



wspóđczynnik operacji odczytu/zapisu,



wspóđczynnik synchronicznych operacji zapisu,



rodzaj dostúpu do plików: losowy czy sekwencyjny.

405

Czústotliwoħè i rodzaj wykonywanych operacji zdefiniowano w podrozdziale 8.1 „Terminologia”, natomiast synchroniczne operacje zapisu oraz operacje losowe kontra sekwencyjne zostađy omówione w podrozdziale 8.3 „Koncepcje”. Charakterystyka moľe siú zmieniaè z sekundy na sekundú, zwđaszcza w przypadku zadaē wykonywanych przez aplikacjú w odstúpach czasu. Aby lepiej scharakteryzowaè obciæľenie, konieczne jest przechwycenie wartoħci maksymalnych oraz ħrednich. Najtrafniejsze búdzie przeanalizowanie peđnego rozkđadu wartoħci na przestrzeni czasu. Oto przykđadowy opis obciæľenia pokazujæcy, jak moľna razem wyraziè wymienione wczeħniej atrybuty: W bazie danych zawierajæcej dane finansowe system plików wykonuje losowe operacje odczytu. Ħrednia liczba operacji wynosi 18 000 na sekundú, a ħrednia wielkoħè odczytanych danych to 2 KB. Cađkowity wspóđczynnik operacji to 21 000 operacji na sekundú, obejmujæcy odczyt danych, wygenerowanie danych statystycznych, operacje otwarcia i zamkniúcia plików oraz okođo 200 synchronicznych operacji zapisu. Liczba operacji zapisu jest mniej wiúcej stađa, natomiast operacji odczytu zmienna i maksymalnie wynosi 39 000 operacji odczytu na sekundú.

Wspomniane cechy charakterystyczne mogæ byè opisane w kategoriach pojedynczego egzemplarza systemu plików lub wszystkich egzemplarzy systemu plików tego samego typu.

Zaawansowana charakterystyka obciążenia i lista rzeczy do sprawdzenia Podczas przygotowywania charakterystyki obciæľenia pod uwagú moľna wziæè informacje dodatkowe. Zostađy one wymienione w postaci pytaē, na które naleľy spróbowaè odpowiedzieè. Pytania te mogæ sđuľyè równieľ w charakterze listy rzeczy do zrobienia, gdy dokđadnie analizujesz problemy zwiæzane z systemem plików. 

Jakie sæ wartoħci wspóđczynników trafnoħci i nietrafnoħci bufora?



Jaka jest pojemnoħè bufora systemu plików i bieľæcy poziom jego uľycia?



Jakie inne bufory sæ dostúpne (katalogów, i-wúzđów) i jak przedstawiajæ siú wygenerowane dla nich dane statystyczne?



Jakie aplikacje lub jacy uľytkownicy uľywajæ systemu plików?



Jakie pliki i katalogi sæ uľywane, tworzone i usuwane?



Czy napotykane sæ jakiekolwiek bđúdy? Czy bđæd jest skutkiem nieprawidđowego ľædania, czy raczej skutkiem problemów zwiæzanych z systemem plików?

406

Rozdział 8









Systemy plików

Dlaczego wykonana zostađa operacja wejħcia-wyjħcia systemu plików? Jak wyglæda ħcieľka wywođania na poziomie uľytkownika? Do jakiego stopnia operacje wejħcia-wyjħcia wykonywane przez aplikacjú sæ synchroniczne? Jak przedstawia siú rozkđad czasu operacji wejħcia-wyjħcia?

Wiele z przedstawionych pytaē moľe dotyczyè aplikacji bædļ teľ poszczególnych plików. Kaľdæ z powyľszych wartoħci moľna sprawdzaè na przestrzeni czasu, wyszukujæc minimum, maksimum i wariancje oparte na czasie. Zapoznaj siú takľe z punktem 2.5.10 w rozdziale 2. „Metodologia”, w którym znajdziesz ogólne podsumowanie charakterystycznych cech wartych sprawdzenia (kto?, dlaczego?, co? i jak?).

Charakterystyka wydajności Na podstawie przedstawionych pytaē (porównaj je z poprzednimi, dotyczæcymi charakterystyki obciæľenia) moľna przygotowaè charakterystykú wydajnoħci systemu plików dziađajæcego pod danym obciæľeniem: 

Jakie jest ħrednie opóļnienie operacji systemu plików?



Czy istniejæ elementy odstajæce, o duľo wiúkszym opóļnieniu?



Jak przedstawia siú peđny rozkđad opóļnienia operacji?



Czy stosowane sæ jakiekolwiek mechanizmy kontroli zasobów systemu plików bædļ dyskowych operacji wejħcia-wyjħcia?

Pierwsze trzy pytania moľna zadawaè oddzielnie dla kaľdego rodzaju operacji.

8.5.4. Monitorowanie wydajności Monitorowanie wydajnoħci pozwala zidentyfikowaè problemy i wzorce zachowania na przestrzeni czasu. W przypadku systemu plików metrykami o znaczeniu krytycznym sæ: 

czústotliwoħè operacji,



opóļnienie operacji.

Czústotliwoħè operacji to najbardziej podstawowa cecha charakterystyczna obciæľenia, opóļnienie wynika z wydajnoħci koēcowej. Konkretne wartoħci normalnego lub zđego opóļnienia zaleľæ od danego obciæľenia, ħrodowiska i wymagaē dotyczæcych opóļnienia. Jeľeli nie jesteħ pewien, to moľna przeprowadziè mikrotesty wydajnoħci zarówno obciæľenia uznawanego za dobre, jak i nietypowego, sprawdzajæc tym samym opóļnienie (na przykđad w przypadku speđnienia ľædania zwykle z bufora systemu plików kontra sytuacja, gdy niemal na pewno bufor nie zostanie uľyty). Zapoznaj siú z podrozdziađem 8.7 „Eksperymenty”. Metryka, jakæ jest opóļnienie operacji, moľe byè monitorowana w postaci wartoħci ħredniej na sekundú i obejmowaè takľe inne wartoħci, takie jak maksimum i odchylenie standardowe. W idealnej sytuacji moľliwe búdzie przeanalizowanie peđnego rozkđadu

8.5. Metodologia

407

opóļnienia, na przykđad za pomocæ histogramu lub mapy cieplnej, aby wyszukaè elementy odstajæce oraz inne wzorce. Dla kaľdego rodzaju operacji (odczyt, zapis, generowanie danych statystycznych, otwieranie i zamykanie plików itd.) moľna zarejestrowaè zarówno czústotliwoħè, jak i opóļnienie. W ten sposób, dziúki identyfikacji róľnic w poszczególnych rodzajach operacji, bardzo uđatwiona búdzie analiza zmian wydajnoħci i obciæľenia. W systemach stosujæcych oparte na systemie plików mechanizmy kontroli zasobów (na przykđad przepustowoħè operacji wejħcia-wyjħcia w systemie plików ZFS) uwzglúdniè moľna takľe dane statystyczne, aby przekonaè siú, jak i kiedy zastosowane zostađo ograniczenie.

8.5.5. Monitorowanie zdarzeń Monitorowanie zdarzeē przechwytuje informacje szczegóđowe o kaľdej operacji systemu plików. W analizie opartej na obserwacji to jest wyjħcie ostateczne. Negatywnie wpđywa na wydajnoħè ze wzglúdu na koniecznoħè przechwycenia i zapisania wspomnianych informacji, które zwykle sæ umieszczane w plikach dzienników zdarzeē w celu dalszej analizy. Pliki dzienników zdarzeē mogæ zawieraè nastúpujæce informacje szczegóđowe o poszczególnych operacjach: 

rodzaj systemu plików,



punkt montowania systemu plików,



 



rodzaj operacji: odczyt, zapis, generowanie danych statystycznych, otwieranie i zamykanie plików, mkdir, …, wyraľona w bajtach wielkoħè operacji (o ile wystúpuje), poczætkowy znacznik czasu operacji: godzina rozpoczúcia wykonywania operacji przez system plików, koēcowy znacznik czasu operacji: godzina, w której system plików zakoēczyđ operacjú,



stan zakoēczenia operacji: bđúdy,



nazwa ħcieľki (o ile jest dostúpna),



identyfikator procesu,



nazwa aplikacji.

Na podstawie poczætkowego i koēcowego znacznika czasu moľna obliczyè opóļnienie operacji. Wiele frameworków monitorowania pozwala na obliczenia w trakcie monitorowania i umieszczanie wartoħci opóļnienia w dzienniku zdarzeē. Umoľliwiajæ takľe filtrowanie danych wyjħciowych i tym samym na przykđad rejestrowanie jedynie tych operacji, których wykonanie trwa dđuľej niľ zdefiniowany przedziađ czasu. Czústotliwoħè operacji wykonywanych przez system plików moľe byè wyraľona w milionach na sekundú i dlatego ich filtrowanie jest dobrym rozwiæzaniem, o ile moľna je zastosowaè. Monitorowanie zdarzeē moľna prowadziè na dowolnym z czterech poziomów wymienionych w punkcie 8.5.2. Przykđady znajdziesz w podrozdziale 8.6, noszæcym tytuđ „Analiza”.

408

Rozdział 8



Systemy plików

8.5.6. Statyczne dostosowanie wydajności Statyczne dostosowanie wydajnoħci jest skoncentrowane na zagadnieniach dotyczæcych skonfigurowanego ħrodowiska. W przypadku analizy wydajnoħci systemu plików konieczne jest przeanalizowanie nastúpujæcych aspektów konfiguracji statycznej (przedstawione zostađy w formie pytaē): 

Ile jest zamontowanych systemów plików i ile z nich jest uľywanych?



Jaka jest wielkoħè rekordu systemu plików?



 

Czy wđæczone jest uaktualnianie znaczników czasu dostúpu do plików i katalogów? Jakie inne opcje systemu plików zostađy wđæczone (kompresja, szyfrowanie, …)? W jaki sposób zostađ skonfigurowany bufor systemu plików? Jaka jest jego wielkoħè maksymalna?



Czy zostađy skonfigurowane jeszcze inne bufory (katalogów, i-wúzđów)?



Czy istnieje i jest uľywany bufor poziomu drugiego?



Ile urzædzeē pamiúci masowej jest w systemie i ile z nich jest uľywanych?



Jaka jest konfiguracja urzædzeē pamiúci masowej? Czy uľywana jest macierz RAID?



Jakie rodzaje systemów plików sæ uľywane?



Jaka jest wersja systemu plików (lub jædra)?





Czy istniejæ jakiekolwiek bđúdy systemu plików lub poprawki do tego systemu, które naleľy wziæè pod uwagú? Czy stosowane sæ jakiekolwiek mechanizmy kontroli zasobów dla operacji wejħcia-wyjħcia systemu plików?

Udzielenie odpowiedzi na postawione pytania moľe ujawniè przeoczone wczeħniej opcje konfiguracyjne. Czasami zdarza siú, ľe system jest skonfigurowany pod kætem pewnego obciæľenia, a nastúpnie wykorzystywany do innych celów. Dziúki omawianej metodzie búdzie moľna wprowadziè odpowiednie korekty.

8.5.7. Dostrajanie bufora Jædro i system plików mogæ uľywaè wielu róľnych buforów, miúdzy innymi podrúcznej pamiúci buforowej, bufora katalogów, bufora i-wúzđów i bufora systemu plików (stron). Poszczególne bufory zostađy omówione w podrozdziale 8.4 „Architektura” i mogæ byè dostrojone zgodnie z informacjami przedstawionymi w punkcie 2.5.17 w rozdziale 2. „Metodologia”. Podsumowujæc — warto ustaliè, jakie istniejæ bufory, przekonaè siú, czy w ogóle dziađajæ, sprawdziè, czy dziađajæ zgodnie z oczekiwaniami, okreħliè ich wielkoħè, a nastúpnie dostosowaè obciæľenie do bufora i bufor do obciæľenia.

8.5. Metodologia

409

8.5.8. Separacja obciążenia W pewnych rodzajach obciæľenia moľna osiægnæè lepszæ wydajnoħè po skonfigurowaniu dla nich oddzielnych systemów plików i urzædzeē dyskowych. Tego rodzaju podejħcie jest okreħlane jako uľycie „oddzielnych napúdów”, poniewaľ w przypadku dysków mechanicznych dwie losowe operacje wejħcia-wyjħcia wyszukujæce dane dla dwóch róľnych zadaē charakteryzujæ siú szczególnie kiepskæ wydajnoħciæ (patrz rozdziađ 9. „Dyski”). Na przykđad baza danych odniesie duľe korzyħci z posiadania oddzielnych systemów plików i dysków dla plików dzienników zdarzeē i plików samej bazy danych.

8.5.9. Systemy plików w pamięci Innym podejħciem konfiguracyjnym majæcym na celu poprawú wydajnoħci jest zastosowanie systemów plików tworzonych w pamiúci. Poniewaľ znajdujæ siú w pamiúci, udostúpniajæ swojæ zawartoħè z maksymalnæ szybkoħciæ. Z reguđy sæ implementowane jedynie jako dodatkowe — wiele aplikacji ma wđasne (konfigurowalne) i charakterystyczne dla aplikacji bufory w pamiúci procesu, co zapewnia znacznie wiúkszæ efektywnoħè podczas uzyskiwania dostúpu niľ za pomocæ pliku i interfejsu wywođaē systemowych. Tworzone w pamiúci systemy plików nie sæ najlepszym rozwiæzaniem w nowoczesnych systemach wykorzystujæcych ogromne bufory dla systemów plików.

/tmp Standardowy system plików /tmp jest uľywany do przechowywania plików tymczasowych, bardzo czústo jest zakđadany w pamiúci. Na przykđad dla /tmp Solaris uľywa tmpfs, który jest systemem plików tworzonym w pamiúci. Wymieniony system plików istnieje równieľ dla systemu Linux — jest uľywany dla kilku specjalnych rodzajów systemów plików.

8.5.10. Mikrotesty wydajności Narzúdzia testów wydajnoħci przeznaczonych do testowania systemu plików i dysku moľna wykorzystaè do sprawdzenia wydajnoħci róľnego rodzaju systemów plików (lub ich ustawieē) dla danego obciæľenia. Oto typowe czynniki, które sæ uwzglúdniane w testach wydajnoħci: 

Rodzaje operacji. Czústotliwoħè operacji odczytu, zapisu oraz innych przeprowadzanych przez system plików.



Wielkoħè operacji wejħcia-wyjħcia. Od 1 B do 1 MB, a nawet wiúksze.



Wzorzec przesuniúcia pliku. Operacje losowe lub sekwencyjne.



Wzorzec losowego dostúpu do pliku. Ujednolicone operacje losowe lub rozkđad Pareto.



Rodzaj zapisu. Operacje asynchroniczne lub synchroniczne (uľycie opcji O_SYNC).



Wielkoħè zbioru roboczego. Czy mieħci siú w buforze systemu plików?

410

Rozdział 8











Systemy plików

Wspóđbieľnoħè. Liczba operacji wejħcia-wyjħcia lub liczba wætków przeprowadzajæcych operacje wejħcia-wyjħcia. Mapowanie pamiúci. Dostúp do plików za pomocæ mmap() zamiast read() i write(). Stan bufora. Czy bufor systemu plików jest „nierozgrzany” (niewypeđniony) czy „rozgrzany”? Dostrajanie systemu plików. Moľe obejmowaè kompresjú, ochronú przed powielaniem danych itd.

Najczúħciej stosowane pođæczenie obejmuje losowe operacje odczytu, sekwencyjne operacje odczytu, losowe operacje zapisu i sekwencyjne operacje zapisu. Czynnikiem, który najczúħciej ma znaczenie krytyczne, jest wielkoħè zbioru roboczego, czyli iloħè danych, do których nastúpuje dostúp podczas testu wydajnoħci. W zaleľnoħci od testu wydajnoħci moľe to byè cađkowita wielkoħè uľywanych plików. Mađy zbiór roboczy moľe cađkowicie zmieħciè siú w znajdujæcym siú w pamiúci operacyjnej buforze systemu plików. Z kolei w przypadku ogromnego zbioru roboczego wiúkszoħè ľædaē búdzie speđniana przez urzædzenia pamiúci masowej (dyski). Róľnica miúdzy wydajnoħciæ ľædania speđnianego przez bufor a speđnianego przez dyski moľe byè kolosalna. Spójrz na wymienione w tabeli 8.5 ogólne oczekiwania dotyczæce róľnych testów wydajnoħci. Oczekiwania te uwzglúdniajæ cađkowitæ wielkoħè plików (zbioru roboczego). Tabela 8.5. Oczekiwania od testów wydajności systemów plików Pamięć operacyjna

Całkowita wielkość plików

Test wydajności

Oczekiwania

128 GB

10 GB

odczyt losowy

trafność bufora na poziomie 100%

128 GB

1000 GB

odczyt losowy

w większości odczyt danych z dysku, trafność bufora na poziomie około 12%

128 GB

10 GB

odczyt sekwencyjny

trafność bufora na poziomie 100%

128 GB

1000 GB

odczyt sekwencyjny

połączenie trafności bufora (w większości na skutek działania mechanizmu prefetch) i odczytu danych z dysku

128 GB

10 GB

zapis

w większości przypadków trafność bufora (buforowanie) oraz pewne blokowanie w trakcie zapisu, w zależności od zachowania systemu plików

128 GB

10 GB

zapis synchroniczny

100% operacji zapisu na dysku

W przypadku niektórych narzúdzi przeznaczonych do przeprowadzania testów wydajnoħci systemów plików nie ma pewnoħci, co tak naprawdú jest testowane. Narzúdzie wskazuje na test wydajnoħci dysku, podczas gdy cađkowita wielkoħè zbioru roboczego jest mađa i operacje sæ obsđugiwane przez bufor, a nie dysk. Zapoznaj siú z punktem 8.3.12, w którym wyjaħniono róľnice miúdzy testowaniem systemu plików (logiczne operacje wejħcia-wyjħcia) i dysków (fizyczne operacje wejħcia-wyjħcia).

8.6. Analiza

411

Niektóre narzúdzia testów wydajnoħci dysków przeprowadzajæ operacje za pomocæ systemu plików i uľywajæ bezpoħrednich operacji wejħcia-wyjħcia, aby uniknæè buforowania. System plików nadal odgrywa mniejszæ rolú i dodaje obciæľenie zwiæzane ze ħcieľkæ kodu i mapowaniem róľnic miúdzy plikiem a jego pođoľeniem na dysku. Czasami jest to zamierzona strategia testowania systemu plików: przeanalizowanie sytuacji najgorszej z moľliwych pod wzglúdem wydajnoħci (trafnoħè bufora na poziomie 0%). Tego rodzaju strategia przedstawia sytuacjú oderwanæ od rzeczywistoħci, poniewaľ twórcy aplikacji spodziewajæ siú raczej wysokiego wspóđczynnika trafnoħci bufora ze wzglúdu na coraz wiúkszæ iloħè pamiúci instalowanej w komputerach. Wiúcej informacji na ten temat moľesz znaleļè w rozdziale 12. „Testy wydajnoħci”.

8.6. Analiza W tym podrozdziale zostanæ przedstawione narzúdzia analizy wydajnoħci systemu plików w systemach operacyjnych Linux i Solaris. Strategie uľycia omawianych tutaj narzúdzi przedstawiono w poprzednim podrozdziale. W tabeli 8.6 wymieniono narzúdzia, które búdæ stosowane w niniejszym podrozdziale. Tabela 8.6. Polecenia służące do analizy wydajności systemu plików Linux

Solaris

Opis

-

vfsstat

Dane statystyczne systemu plików, między innymi średnie opóźnienie.

-

fsstat

Dane statystyczne systemu plików.

strace

truss

Debugery wywołań systemowych.

dtrace

dtrace

Monitorowanie dynamiczne operacji systemu plików, między innymi opóźnienia.

free

-

Dane statystyczne o pojemności bufora.

top

top

Różne dane, między innymi podsumowanie poziomu użycia pamięci.

vmstat

vmstat

Dane statystyczne dotyczące pamięci wirtualnej.

sar

sar

Różne dane statystyczne, w tym również historyczne.

slabtop

mdb ::kmastat

Dane statystyczne dotyczące alokatora jądra slab.

-

fcachestat

Różne dane, między innymi współczynniki trafności buforów i ich wielkości.

/proc/meminfo

mdb ::memstat

Informacje o użyciu pamięci przez jądro.

-

kstat

Różne dane o systemie plików oraz dane statystyczne dotyczące bufora.

Wymienione narzúdzia zostađy wybrane pod kætem moľliwoħci obsđugi metodologii przedstawionych w podrozdziale 8.5. Na poczætku listy znajdujæ siú narzúdzia monitorowania na poziomie cađego systemu i dla poszczególnych systemów plików. Nastúpnie mamy narzúdzia przeznaczone do analizy operacji i opóļnienia, a na koēcu dostarczajæce

412

Rozdział 8



Systemy plików

danych statystycznych dotyczæcych bufora. Omówienie funkcji poszczególnych narzúdzi znajdziesz w dokumentacji, miúdzy innymi na stronach podrúcznika man. Nawet jeħli jesteħ zainteresowany jedynie narzúdziami dla systemu Linux lub Solaris, warto i tak spojrzeè na narzúdzia dostúpne dla innych systemów operacyjnych, poniewaľ zwykle dajæ one moľliwoħè dostrzeľenia problemu z innej perspektywy.

8.6.1. vfsstat Polecenie vfsstat jest podobne do iostat, z tym ľe przeznaczone do pracy z systemem plików VFS. Zostađo opracowane przez Billa Pijewskiego dla systemu SmartOS. Dla ustalonych odstúpów czasu wyħwietla podsumowanie operacji systemu plików (logicznych operacji wejħcia-wyjħcia), miúdzy innymi ħrednie opóļnienie w aplikacjach na poziomie uľytkownika. Tego rodzaju informacje sæ znacznie bardziej powiæzane z wydajnoħciæ aplikacji niľ dane statystyczne generowane przez iostat, które pokazujæ dyskowe (fizyczne) operacje wejħcia-wyjħcia, miúdzy innymi asynchroniczne. $ vfsstat 1 r/s w/s kr/s kw/s ractv wactv read_t writ_t 2.5 0.1 1.5 0.0 0.0 0.0 0.0 2.6 1540.4 0.0 95014.9 0.0 0.0 0.0 0.0 0.0 1991.7 0.0 74931.5 0.0 0.0 0.0 0.0 0.0 1989.8 0.0 84697.0 0.0 0.0 0.0 0.0 0.0 [...]

%r 0 3 4 4

%w 0 0 0 0

d/s 0.0 0.0 0.0 0.0

del_t 8.0 0.0 0.0 0.0

zone dev (5) dev (5) dev (5) dev (5)

Pierwszy wiersz danych wyjħciowych zawiera podsumowanie od chwili uruchomienia systemu, a nastúpnie umieszczone sæ podsumowania dla kolejnych przedziađów czasu. Kolumny w danych wyjħciowych majæ nastúpujæce znaczenie: 



 





r/s, w/s — liczba operacji odczytu i zapisu wykonywanych w trakcie sekundy w systemie plików, kr/s, kw/s — liczba kilobajtów odczytanych i zapisanych w trakcie sekundy w systemie plików, ractv, wactv — ħrednia liczba operacji odczytu i zapisu, read_t, writ_t — wyraľone w milisekundach ħrednie opóļnienie odczytu i zapisu w systemie VFS, %r, %w — procent czasu, przez który operacja odczytu lub zapisu VFS musiađa oczekiwaè, d/s, del_t — wielkoħè opóļnieē operacji wejħcia-wyjħcia w ciægu sekundy, a takľe wyraľone w mikrosekundach ħrednie opóļnienie.

Polecenie vfsstat dostarcza informacji pozwalajæcych scharakteryzowaè obciæľenie, a takľe uzyskanæ wydajnoħè. Obejmuje takľe dane dotyczæce ograniczeē w operacjach wejħcia-wyjħcia ZFS, które przez system SmartOS sæ stosowane w ħrodowisku przetwarzania w chmurze do zrównowaľenia tenantów.

8.6. Analiza

413

W pokazanym przykđadzie obciæľenie stanowiđy operacje odczytu o wielkoħci od 1,5 KB/s do 2 KB/s, a przepustowoħè wyniosđa od 73 MB/s do 92 MB/s. Ħrednie opóļnienie jest na tyle mađe, ľe zostađo zaokræglone do 0,0 ms. Operacje byđy wiúc prawdopodobnie obsđugiwane przez bufor systemu plików, a obciæľenie systemu plików zwiæzane z obsđugæ operacji wyniosđo od 3% do 4% czasu.

8.6.2. fsstat Polecenie fsstat w systemie Solaris generuje róľne dane statystyczne o systemie plików: $ fsstat /var 1 new name name attr attr lookup rddir read read write write file remov chng get set ops ops ops bytes ops bytes 8.98K 520 177 1.61M 2.26K 3.57M 18.2K 3.78M 6.85G 2.98M 9.10G /var 0 0 0 0 0 0 0 0 0 1 152 /var 0 0 0 1 0 3 0 2 24 1 109 /var 0 0 0 51 0 35 0 0 0 1 14 /var [...]

Moľna je wykorzystaè do przygotowania charakterystyki obciæľenia oraz analizy poszczególnych systemów plików. Zwróè uwagú, ľe polecenie fsstat nie zawiera danych dotyczæcych opóļnienia.

8.6.3. strace, truss Inne narzúdzia systemu operacyjnego przeznaczone do szczegóđowego pomiaru opóļnienia systemu plików zawierajæ debugery dla interfejsu wywođaē systemowych. Przykđadem takich poleceē sæ: strace dla systemu Linux i truss dla systemu Solaris. Tego rodzaju debugery mogæ jednak negatywnie wpđywaè na wydajnoħè i dlatego ich uľycie zaleca siú jedynie w sytuacjach, w których wspomniany wpđyw jest akceptowany i nie ma moľliwoħci uľycia innych metod analizy opóļnienia. Poniľej przedstawiono przykđad uľycia polecenia strace do pomiaru czasu operacji odczytu w systemie plików ext4: $ strace -ttT -p 845 [...] 18:41:01.513110 read(9, 18:41:01.531646 read(9, 18:41:01.531984 read(9, 18:41:01.538151 read(9, 18:41:01.538549 read(9, 18:41:01.540923 read(9,

"\334\260/\224\356k..."..., "\371X\265|\244\317..."..., "\357\311\347\1\241..."..., "*\263\264\204|\370..."..., "\205q\327\304f\370..."..., "\6\2738>zw\321\353..."...,

65536) 65536) 65536) 65536) 65536) 65536)

= = = = = =

65536 65536 65536 65536 65536 65536





Opcja -tt powoduje wyħwietlenie wzglúdnych znaczników czasu po lewej stronie, natomiast -T wyħwietlenie czasu wywođaē systemowych po prawej stronie. Kaľda operacja odczytu miađa wielkoħè 64 KB, wykonanie pierwszej zabrađo 18 ms, kolejnej 56 μs (prawdopodobnie buforowana), a nastúpnej 5 ms. Operacje odczytu dotyczyđy deskryptora

414

Rozdział 8



Systemy plików

pliku 9. Aby przekonaè siú, ľe operacja dotyczy systemu plików (a nie gniazda), naleľy sprawdziè obecnoħè wywođania systemowego open() we wczeħniejszym fragmencie danych wyjħciowych strace lub uľyè innego polecenia, na przykđad lsof.

8.6.4. DTrace Narzúdzie DTrace moľna wykorzystaè do przeanalizowania zachowania systemu plików za pomocæ interfejsu wywođaē systemowych, interfejsu VFS oraz z wewnætrz samego systemu plików. Wymienione moľliwoħci pozwalajæ przygotowaè charakterystykú obciæľenia i analizú opóļnienia. W przedstawionych dalej fragmentach znajdziesz wprowadzenie do uľycia narzúdzia DTrace w celu analizy systemu plików w systemach Linux i Solaris. O ile nie zostanie to wyraļnie okreħlone, polecenia DTrace sæ przeznaczone do wydawania w obu wymienionych systemach operacyjnych. Krótkie, ogólne wprowadzenie do DTrace zaprezentowano w rozdziale 4., zatytuđowanym „Narzúdzia monitorowania”.

Liczniki operacji Podsumowanie operacji systemu plików dla poszczególnych aplikacji i wedđug rodzaju systemów plików dostarcza uľytecznych informacji, które búdæ przydatne podczas przygotowywania charakterystyki obciæľenia. Przedstawione jednowierszowe wywođanie DTrace dla systemu Solaris zlicza operacje systemu plików dla aplikacji o podanej nazwie, uľywajæc do tego dostawcy fsinfo (ang. file system info): # dtrace -n 'fsinfo::: { @[execname] = count(); }' dtrace: description 'fsinfo::: ' matched 46 probes ^C [...] fsflush splunkd nginx node

970 2147 7338 25340

Dane wyjħciowe pokazujæ, ľe proces o nazwie node przeprowadziđ 25 340 operacji systemu plików w trakcie danej sesji monitorowania. Sonda tick-ls moľe byè uľyta, aby otrzymaè podsumowanie sekundowe, co umoľliwi obserwacjú czústotliwoħci. Ten rodzaj operacji moľna zgđaszaè przez agregacjú probename zamiast execname, na przykđad: # dtrace -n 'fsinfo::: /execname == "splunkd"/ { @[probename] = count(); }' dtrace: description 'fsinfo::: ' matched 46 probes ^C [...] read 13 write 16 seek 22 rwlock 29

8.6. Analiza

415

rwunlock getattr lookup

29 131 565

Przedstawione polecenie pokazuje, jak moľna przeanalizowaè dane dotyczæce konkretnej aplikacji. W tym przypadku to byđ proces splunkd. W systemie Linux operacje systemu plików moľna monitorowaè za pomocæ dostawców syscall i fbt, chyba ľe dostúpny búdzie dostawca fsinfo. Poniľej przedstawiono sposób monitorowania funkcji vfs jædra za pomocæ dostawcy fbt: # dtrace -n 'fbt::vfs_*:entry { @[execname] = count(); }' dtrace: description 'fbt::vfs_*:entry ' matched 39 probes ^C [...] sshd ls bash sysbench

913 1367 1462 10295

W trakcie danej sesji monitorowania najwiúksza liczba operacji systemu plików zostađa wywođana przez aplikacjú o nazwie sysbench — to narzúdzie przeznaczone do wykonywania testów wydajnoħci (patrz odwođanie [3] na koēcu rozdziađu). Poniľszy przykđad pokazuje zliczanie operacji wedđug typu, co odbywa siú przez agregacjú w probefunc: # dtrace -n 'fbt::vfs_*:entry /execname == "sysbench"/ { @[probefunc] = count(); }' dtrace: description 'fbt::vfs_*:entry ' matched 39 probes ^C vfs_write 4001 vfs_read 5999

Dane odpowiadajæ procesowi sysbench, gdy przeprowadza on losowe operacje odczytu i zapisu podczas testu wydajnoħci oraz pokazuje wspóđczynnik operacji. W celu usuniúcia vfs_ z danych wyjħciowych naleľy zamiast @[probefunc] uľyè @[probefunc + 4] (wskaļnik plus wartoħè przesuniúcia).

Otwarcie pliku Poprzednie jednowierszowe wywođania DTrace byđy uľywane w celu wygenerowania podsumowania po zliczeniu zdarzeē. Poniľsze pokazuje oddzielne wyħwietlenie wszystkich danych zdarzenia, w tym przypadku to informacje szczegóđowe dla wywođania systemowego open(). Dane dotyczæ cađego systemu: # opensnoop STRTIME 2012 Sep 13 2012 Sep 13 2012 Sep 13 2012 Sep 13

-ve UID 23:30:55 45821 23:30:55 45821 23:30:55 80 23:30:56 80

PID 24218 24218 3505 25308

COMM ruby ruby nginx php-fpm

FD ERR PATH 23 0 /var/run/name_service_door 23 0 /etc/inet/ipnodes -1 2 /public/dev-3/vendor/ 5 0 /public/etc/config.xml

416

2012 Sep 13 23:30:56 2012 Sep 13 23:30:56 [...]

Rozdział 8

80 80

25308 php-fpm 25308 php-fpm

5 5



Systemy plików

0 /public/etc/local.xml 0 /public/etc/local.xml

Narzúdzie opensnoop zostađo utworzone na podstawie DTrace i znajduje siú w pakiecie DTraceToolkit. Domyħlnie jest dostúpne takľe w systemach Oracle Solaris 11 i OS X, a takľe dla innych systemów operacyjnych. Omawiane narzúdzie dostarcza informacji o obciæľeniu systemu plików, pokazuje procesy, nazwy ħcieľek i wygenerowane bđúdy w zakresie wywođania systemowego open(). Tego rodzaju dane sæ uľyteczne podczas analizy wydajnoħci oraz rozwiæzywania problemów. W omawianym przykđadzie operacja otwarcia pliku przez proces nginx zakoēczyđa siú niepowodzeniem (liczba 2 w kolumnie ERR oznacza, ľe nie znaleziono pliku). Inne popularne skrypty w DTraceToolkit to rwsnoop i rwtop, które pozwalajæ na monitorowanie i wygenerowanie podsumowania logicznych operacji wejħcia-wyjħcia. Skrypt rwsnoop monitoruje wywođania systemowe read() i write(), natomiast rwtop uľywa dostawcy sysinfo w celu przygotowania podsumowania dotyczæcego przepustowoħci (wyraľonej w bajtach).

Opóźnienie wywołania systemowego Prezentowany przykđad wywođania narzúdzia DTrace umoľliwia przeprowadzenie pomiaru opóļnienia na poziomie interfejsu wywođaē systemowych i podsumowanie go w postaci histogramu uľywajæcego nanosekund jako jednostki: # dtrace -n 'syscall::read:entry /fds[arg0].fi_fs == "zfs"/ { self->start = timestamp; } syscall::read:return /self->start/ { @["ns"] = quantize(timestamp - self->start); self->start = 0; }' dtrace: description 'syscall::read:entry ' matched 2 probes ^C ns value ------------- Distribution ------------- count 1024 | 0 2048 | 2 4096 |@@@@@@ 103 8192 |@@@@@@@@@@ 162 16384 | 3 32768 | 0 65536 | 0 131072 | 1 262144 | 0 524288 | 1 1048576 | 3 2097152 |@@@ 48 4194304 |@@@@@@@@@@@@@@@@@@@@@ 345 8388608 | 0

Rozkđad pokazuje dwukrotny skok wartoħci, pierwszy miúdzy 4 μ i 16 μ (trafienie bufora) i drugi miúdzy 2 ms i 8 ms (odczyt dysku). Zamiast quantize() moľna uľyè

8.6. Analiza

417

funkcji avg() i wyħwietliè wartoħè ħredniæ. Niemniej wartoħè ħrednia uwzglúdniajæca dwa wspomniane skoki moľe byè mylæca. Tego rodzaju podejħcie umoľliwia monitorowanie pojedynczych wywođaē systemowych, w omawianym przypadku to read(). Aby przechwyciè wszystkie operacje systemu plików, konieczne jest ħledzenie wszystkich wywođaē systemowych, w tym takľe ich poszczególnych odmian (na przykđad pread(), pread64()). Moľna w tym celu przygotowaè skrypt przechwytujæcy wszystkie wywođania systemowe lub dla danej aplikacji sprawdziè (za pomocæ DTrace) uľywane przez niæ wywođania systemowe i tylko je monitorowaè. Przedstawione podejħcie spowoduje przechwycenie aktywnoħci wszystkich systemów plików, miúdzy innymi nieprzeznaczonych do przechowywania danych, na przykđad sockfs. W pokazanym przykđadzie rodzaj systemu plików byđ filtrowany na skutek sprawdzenia wartoħci fds[arg0].fi_fs, która przekđada deskryptor pliku (arg0 dla read()) na rodzaj systemu plików (fds[].fi_fs). W tym kontekħcie moľna zastosowaè inne uľyteczne filtry, na przykđad nazwú aplikacji, identyfikator procesu, punkt montowania lub komponenty nazwy ħcieľki. Zwróè uwagú, ľe opóļnienie nie musi mieè bezpoħredniego wpđywu na wydajnoħci aplikacji, o czym juľ wspomniano w punkcie 8.3.1. Wszystko zaleľy od tego, czy opóļnienie nastúpuje w trakcie ľædania wykonywanego przez aplikacjú, czy w trakcie asynchronicznego zadania wykonywanego w tle. Narzúdzie DTrace moľna wykorzystaè do udzielenia odpowiedzi na tego rodzaju pytania. Wystarczy dla stosu na poziomie uľytkownika przechwyciè dane dotyczæce operacji wejħcia-wyjħcia wywođaē systemowych, co moľe pomóc w wyjaħnieniu powodu ich wykonywania (na przykđad agregacja za pomocæ @[ustack(), "ns"]). W zaleľnoħci od skomplikowania aplikacji i jej kodu ļródđowego moľe to byè doħè zđoľona czynnoħè.

Opóźnienie VFS Opóļnienie interfejsu VFS równieľ moľna monitorowaè za pomocæ dostawcy statycznego (o ile taki istnieje) lub stosujæc monitorowanie dynamiczne (dostawca fbt). W systemie Solaris VFS moľna monitorowaè, korzystajæc z funkcji fop_*(), na przykđad: # dtrace -n 'fbt::fop_read:entry /stringof(args[0]->v_op->vnop_name) == "zfs"/ { self->start = timestamp; } fbt::fop_read:return /self->start/ { @["ns"] = quantize(timestamp - self->start); self->start = 0; }' dtrace: description 'fbt::fop_read:entry ' matched 2 probes ^C ns value ------------- Distribution ------------- count 512 | 0 1024 | 12 2048 |@@@@@@@@@@@@@@@@@@@@@@ 2127 4096 |@@@@@@@@@@@@@@@@@@ 1732 8192 | 10 16384 | 0

418

Rozdział 8



Systemy plików

W przeciwieēstwie do poprzednich przykđadów wykorzystujæcych wywođania systemowe ten pokazuje w peđni buforowane obciæľenie. Przedstawione wywođanie DTrace ma szeroki zasiúg i dopasowuje wszystkie warianty operacji odczytu. Inne operacje VFS moľna monitorowaè w podobny sposób. Poniľsze polecenie wyħwietla listú dostúpnych sond: # dtrace -ln 'fbt::fop_*:entry' ID PROVIDER MODULE 15164 fbt genunix 16462 fbt genunix 16466 fbt genunix 16599 fbt genunix 16611 fbt genunix 16763 fbt genunix 16990 fbt genunix 17100 fbt genunix [...39 kolejnych wierszy zostaïo usuniÚtych...]

FUNCTION fop_inactive fop_addmap fop_access fop_create fop_delmap fop_frlock fop_lookup fop_close

NAME entry entry entry entry entry entry entry entry

Zwróè uwagú, ľe dostawca fbt jest uznawany za interfejs niestabilny. Dlatego teľ wszystkie polecenia lub skrypty oparte na fbt mogæ wymagaè uaktualnienia, aby dopasowaè je do zmieniajæcego siú jædra (to jednak wydaje siú mađo prawdopodobne, poniewaľ implementacja VFS nie ulega zbyt czústym zmianom). W systemie Linux narzúdzia DTrace moľna uľyè do prototypowania: # dtrace -n 'fbt::vfs_read:entry /stringof(((struct file *)arg0)-> f_path.dentry->d_sb->s_type->name) == "ext4"/ { self->start = timestamp; } fbt::vfs_read:return /self->start/ { @["ns"] = quantize(timestamp - self->start); self->start = 0; }' dtrace: description 'fbt::vfs_read:entry ' matched 2 probes ^C ns value ------------- Distribution ------------- count 1024 | 0 2048 |@ 13 4096 |@@@@@@@@@@@@ 114 8192 |@@@ 26 16384 |@@@ 32 32768 |@@@ 29 65536 |@@ 23 131072 |@ 9 262144 |@ 5 524288 |@@ 14 1048576 |@ 6 2097152 |@@@ 31 4194304 |@@@@@@ 55 8388608 |@@ 14 16777216 | 0

Tym razem predykat powoduje dopasowanie systemu plików ext4. Zauwaľalne sæ skoki zarówno trafienia, jak i nietrafienia bufora oraz oczekiwane opóļnienie.

8.6. Analiza

419

Poniľsze polecenie wyħwietla listú dostúpnych sond: # dtrace -ln 'fbt::vfs_*:entry' ID PROVIDER MODULE 15518 fbt kernel 15552 fbt kernel 15554 fbt kernel 15572 fbt kernel 15574 fbt kernel 15678 fbt kernel 15776 fbt kernel 15778 fbt kernel [...31 kolejnych wierszy zostaïo usuniÚtych...]

FUNCTION vfs_llseek vfs_write vfs_read vfs_writev vfs_readv vfs_kern_mount vfs_getattr vfs_fstatat

NAME entry entry entry entry entry entry entry entry

Stosy wejścia-wyjścia urządzeń blokowych Przeanalizowanie stosu jædra pod kætem operacji wejħcia-wyjħcia urzædzeē blokowych to doskonađy sposób na to, aby przekonaè siú, jak wewnútrznie dziađa system plików oraz jaka ħcieľka kodu prowadzi do danych dyskowych operacji wejħcia-wyjħcia. Uzyskane dane mogæ równieľ pomóc w wyjaħnieniu przyczyn wykonywania dodatkowych dyskowych operacji wejħcia-wyjħcia (asynchroniczne, metadane) poza oczekiwanymi dla danego obciæľenia. Zaprezentowany przykđad pozwala na monitorowanie wewnútrznego dziađania systemu plików ZFS podczas wykonywania blokujæcej operacji wejħcia-wyjħcia: # dtrace -n 'io:::start { @[stack()] = count(); }' dtrace: description 'io:::start ' matched 6 probes ^C [...] genunix`ldi_strategy+0x53 zfs`vdev_disk_io_start+0xcc zfs`zio_vdev_io_start+0xab zfs`zio_execute+0x88 zfs`vdev_queue_io_done+0x70 zfs`zio_vdev_io_done+0x80 zfs`zio_execute+0x88 genunix`taskq_thread+0x2d0 unix`thread_start+0x8 1070 genunix`ldi_strategy+0x53 zfs`vdev_disk_io_start+0xcc zfs`zio_vdev_io_start+0xab zfs`zio_execute+0x88 zfs`zio_nowait+0x21 zfs`vdev_mirror_io_start+0xcd zfs`zio_vdev_io_start+0x250 zfs`zio_execute+0x88 zfs`zio_nowait+0x21 zfs`arc_read_nolock+0x4f9

420

Rozdział 8



Systemy plików

zfs`arc_read+0x96 zfs`dsl_read+0x44 zfs`dbuf_read_impl+0x166 zfs`dbuf_read+0xab zfs`dmu_buf_hold_array_by_dnode+0x189 zfs`dmu_buf_hold_array+0x78 zfs`dmu_read_uio+0x5c zfs`zfs_read+0x1a3 genunix`fop_read+0x8b genunix`read+0x2a7 2690

Dane wyjħciowe pokazujæ stosy oraz liczbú wystæpieē podczas monitorowania. Stosy wyħwietlone na poczætku to asynchroniczne operacje wejħcia-wyjħcia systemu plików ZFS (w wætku taskq dziađajæcym w potoku ZIO) synchronicznie wygenerowane przez wywođanie systemowe. Aby zebraè wiúcej informacji szczegóđowych, kaľdy wiersz stosu moľna przestudiowaè indywidualnie, wykorzystujæc do tego monitorowanie dynamiczne za pomocæ DTrace i dostawcy fbt. To jest przykđad takiego samego monitorowania jak poprzednio, ale tym razem systemu plików ext4: # dtrace -n 'io:::start { @[stack()] = count(); }' dtrace: description 'io:::start ' matched 6 probes ^C [...] kernel`generic_make_request+0x68 kernel`submit_bio+0x87 kernel`do_mpage_readpage+0x436 kernel`mpage_readpages+0xd7 kernel`ext4_readpages+0x1d kernel`__do_page_cache_readahead+0x1c7 kernel`ra_submit+0x21 kernel`ondemand_readahead+0x115 kernel`page_cache_async_readahead+0x80 kernel`generic_file_aio_read+0x48b kernel`do_sync_read+0xd2 kernel`vfs_read+0xb0 kernel`sys_read+0x4a kernel`system_call_fastpath+0x16 109

Ta ħcieľka pokazuje, ľe wywođanie systemowe read() spowodowađo wywođanie operacji odczytu z wyprzedzeniem bufora stron.

Wnętrze systemu plików Kiedy zachodzi potrzeba, opóļnienie w systemie plików moľna okreħliè z duľæ dokđadnoħciæ dziúki monitorowaniu implementacji systemu plików.

8.6. Analiza

421

Poniľsze polecenie wyħwietla listú dostúpnych sond dotyczæcych funkcji systemu plików ZFS w systemie Solaris: # dtrace -ln 'fbt:zfs::entry' ID PROVIDER MODULE FUNCTION 47553 fbt zfs buf_hash 47555 fbt zfs buf_discard_identity 47557 fbt zfs buf_hash_find 47559 fbt zfs buf_hash_insert 47561 fbt zfs buf_hash_remove 47563 fbt zfs buf_fini 47565 fbt zfs hdr_cons 47567 fbt zfs buf_cons [...2328 kolejnych wierszy zostaïo usuniÚtych...]

NAME entry entry entry entry entry entry entry entry

System plików ZFS stosuje cađkiem proste mapowanie na VFS, co niezwykle uđatwia monitorowanie. Na przykđad przedstawione teraz polecenie pokazuje, jak monitorowaè opóļnienie odczytu w ZFS: # dtrace -n 'fbt::zfs_read:entry { self->start = timestamp; } fbt::zfs_read:return /self->start/ { @["ns"] = quantize(timestamp - self->start); self->start = 0; }' dtrace: description 'fbt::zfs_read:entry ' matched 2 probes ^C ns value ------------- Distribution ------------- count 512 | 0 1024 |@ 6 2048 |@@ 18 4096 |@@@@@@@ 79 8192 |@@@@@@@@@@@@@@@@@ 191 16384 |@@@@@@@@@@ 112 32768 |@ 14 65536 | 1 131072 | 1 262144 | 0 524288 | 0 1048576 | 0 2097152 | 0 4194304 |@@@ 31 8388608 |@ 9 16777216 | 0

Z danych wyjħciowych wynika, ľe najwiúksza liczba operacji wejħcia-wyjħcia jest wykonywana w trakcie okođo 8 μs (trafienie bufora), a nastúpnie w okolicach 4 ms (nietrafienie bufora). Takie rozwiæzanie siú sprawdza, poniewaľ zfs_read() synchronicznie blokuje wywođanie systemowe. Zagđúbiajæc siú we wnútrze systemu plików ZFS, moľna odkryè, ľe funkcje wykonujæ operacjú wejħcia-wyjħcia, ale nie zostajæ zablokowane wskutek oczekiwania na jej zakoēczenie, wiúc zmierzony czas operacji wejħcia-wyjħcia jest nieco dđuľszy.

422

Rozdział 8



Systemy plików

Wnútrze systemu plików ext4 w systemie Linux moľna monitorowaè w podobny sposób: # dtrace -ln 'fbt::ext4_*:entry' ID PROVIDER MODULE FUNCTION 20430 fbt kernel ext4_lock_group.clone.14 20432 fbt kernel ext4_get_group_no_and_offset 20434 fbt kernel ext4_block_in_group 20436 fbt kernel ext4_get_group_desc 20438 fbt kernel ext4_has_free_blocks 20440 fbt kernel ext4_claim_free_blocks 20442 fbt kernel ext4_should_retry_alloc 20444 fbt kernel ext4_new_meta_blocks [...347 kolejnych wierszy zostaïo usuniÚtych...]

NAME entry entry entry entry entry entry entry entry

Pewne funkcje sæ synchroniczne, na przykđad ext4_readdir(), której opóļnienie moľna zmierzyè w taki sam sposób jak we wczeħniejszym przykđadzie z uľyciem zfs_read(). Z kolei inne funkcje nie sæ synchroniczne, miúdzy innymi ext4_readpage() i ext4_readpages(). Aby zmierzyè ich opóļnienie, konieczne jest okreħlenie czasu, jaki upđynæđ miúdzy rozpoczúciem operacji wejħcia-wyjħcia a jej zakoēczeniem, i porównanie obu wartoħci. Ewentualnie moľna posđuľyè siú monitorowaniem stosu, jak zademonstrowano to we wczeħniejszym przykđadzie z VFS.

Monitorowanie wolnego zdarzenia Za pomocæ narzúdzia DTrace moľna wyħwietliè szczegóđowe informacje o kaľdej operacji systemu plików. Podobnie jak omówione w rozdziale 9. „Dyski” polecenie iosnoop, narzúdzie to wyħwietla kaľdæ dyskowæ operacjú wejħcia-wyjħcia. Jednak monitorowanie na poziomie systemu operacyjnego moľe doprowadziè do wygenerowania ogromnej iloħci danych wyjħciowych, poniewaľ obejmuje równieľ trafienia bufora systemu plików. Rozwiæzaniem búdzie wyħwietlanie tylko wolno wykonywanych operacji, co pomoľe w analizie tej okreħlonej klasy problemów: elementów odstajæcych pod wzglúdem opóļnienia. Skrypt zfsslower.d (patrz odwođanie [4] na koēcu rozdziađu) wyħwietla operacje na poziomie ZFS, których wykonanie trwađo dđuľej niľ podana liczba milisekund: # ./zfsslower.d 10 TIME 2011 May 17 01:23:12 2011 May 17 01:23:13 2011 May 17 01:23:33 2011 May 17 01:23:33 2011 May 17 01:23:51 ^C

PROCESS mysqld mysqld mysqld mysqld httpd

D R W W W R

KB 16 16 16 16 56

ms 19 10 11 10 14

FILE /z01/opt/mysql5-64/data/xxxxx.ibd /z01/var/mysql/xxxxx.ibd /z01/var/mysql/xxxxx.ibd /z01/var/mysql/xxxxx.ibd /z01/home/xxxxx/xxxxx/xxxxx

Te ograniczone dane wyjħciowe pokazujæ wyđæcznie operacje w systemie plików, które trwađy dđuľej niľ 10 ms.

8.6. Analiza

423

Zaawansowane monitorowanie Monitorowanie dynamiczne moľe dostarczyè wielu znacznie dokđadniejszych informacji o systemie plików, jeħli sæ one niezbúdne do bardziej zaawansowanej analizy. Aby zademonstrowaè próbkú moľliwoħci w tym zakresie, w tabeli 8.7 wymieniono skrypty z rozdziađu ksiæľki poħwiúconej narzúdziu DTrace (patrz odwođanie [Gregg 11] na koēcu rozdziađu). Skrypty te sæ dostúpne w internecie (patrz odwođanie [4] na koēcu rozdziađu). Tabela 8.7. Skrypty przeznaczone do zaawansowanego monitorowania systemu plików Skrypt

Warstwa

Opis

sysfs.d

wywołania systemowe

Wyświetla odczyty i zapisy według procesów i punktów montowania.

fsrwcount.d

wywołania systemowe

Zlicza wywołania systemowe odczytu i zapisu według systemu plików i rodzaju.

fsrwtime.d

wywołania systemowe

Mierzy czas w wywołaniach systemowych odczytu i zapisu według systemu plików.

fsrtpk.d

wywołania systemowe

Mierzy czas odczytu kilobajta z systemu plików.

rwsnoop

wywołania systemowe

Monitoruje wywołania systemowe odczytu i zapisu, podaje przy tym informacje szczegółowe z systemu plików.

mmap.d

wywołania systemowe

Monitoruje wywołania mmap() dla plików i podaje informacje szczegółowe.

fserrors.d

wywołania systemowe

Pokazuje błędy wywołań systemowych dotyczących systemu plików.

fswho.d

VFS

Podsumowuje procesy i operacje odczytu oraz zapisu.

readtype.d

VFS

Porównuje logiczne operacje odczytu systemu plików z fizycznymi.

writetype.d

VFS

Porównuje logiczne operacje zapisu systemu plików z fizycznymi.

fssnoop.d

VFS

Za pomocą fsinfo monitoruje wywołania systemu plików.

solvfssnoop.d

VFS

Za pomocą fbt w systemie Solaris monitoruje wywołania systemu plików.

sollife.d

VFS

Pokazuje operacje tworzenia i usuwania plików w systemie Solaris.

fsflush_cpu.d

VFS

Pokazuje czas procesora poświęcony na operacje flush w systemie plików.

fsflush.d

VFS

Pokazuje dane statystyczne dotyczące operacji flush w systemie plików.

dnlcps.d

DNLC

Pokazuje trafienia bufora DNLC według procesów.

ufssnoop.d

UFS

Monitoruje bezpośrednie wywołania UFS, używając dostawcy fbt.

ufsreadahead.d

UFS

Pokazuje współczynnik operacji odczytu z wyprzedzeniem UFS dla sekwencyjnych operacji wejścia-wyjścia.

ufsimiss.d

UFS

Monitoruje nietrawienia bufora i-węzłów oraz podaje informacje szczegółowe na ten temat.

424

Rozdział 8



Systemy plików

Tabela 8.7. Skrypty przeznaczone do zaawansowanego monitorowania systemu plików — ciąg dalszy Skrypt

Warstwa

Opis

zfssnoop.d

ZFS

Monitoruje bezpośrednie wywołania ZFS, używając dostawcy fbt.

zfslower.d

ZFS

Monitoruje wolne operacje odczytu i zapisu w ZFS.

zioprint.d

ZFS

Pokazuje dane zdarzenia ZIO.

ziosnoop.d

ZFS

Pokazuje szczegółowe dane monitorowania zdarzenia ZIO.

ziotype.d

ZFS

Pokazuje podsumowanie typu ZIO według pul.

perturbation.d

ZFS

Pokazuje czas odczytu i zapisu ZFS w trakcie danego zakłócenia.

spasync.d

ZFS

Pokazuje szczegółowe dane monitorowania SPA (ang. Storage Pool Allocator).

nfswizard.d

NFS

Podsumowuje wydajność NFS klient-serwer.

nfs3sizes.d

NFS

Pokazuje logiczne kontra fizyczne wielkości operacji odczytu NFSv3.

nfs3fileread.d

NFS

Pokazuje logiczne kontra fizyczne operacje odczytu NFSv3 według pliku.

tmpusers.d

TMP

Pokazuje użytkowników /tmp i tmpfs przez monitorowanie wywołań open().

tmpgetpage.d

TMP

Sprawdza, kiedy następuje stronicowanie tmpfs, podaje czas operacji wejścia-wyjścia.

Wprawdzie moľliwy stopieē monitorowania jest wrúcz niewiarygodny, ale wiele z wymienionych skryptów monitorowania dynamicznego jest powiæzanych z konkretnymi komponentami jædra i búdzie wymagađo uaktualnieē, aby dopasowaè je do zmian wprowadzanych w nowszych wersjach jædra. Oto przykđad zaawansowanego monitorowania. Przedstawiony skrypt DTraceToolkit powoduje monitorowanie zdarzeē z wielu warstw podczas odczytu 50 KB pliku z UFS: # ./fsrw.d Event sc-read fop_read disk_io disk_ra sc-read fop_read disk_ra sc-read fop_read sc-read fop_read sc-read fop_read sc-read fop_read sc-read fop_read

Device RW . R . R cmdk0 R cmdk0 R . R . R cmdk0 R . R . R . R . R . R . R . R . R . R . R

Size Offset Path 8192 0 /extra1/50k 8192 0 /extra1/50k 8192 0 /extra1/50k 8192 8 /extra1/50k 8192 8 /extra1/50k 8192 8 /extra1/50k 34816 16 /extra1/50k 8192 16 /extra1/50k 8192 16 /extra1/50k 8192 24 /extra1/50k 8192 24 /extra1/50k 8192 32 /extra1/50k 8192 32 /extra1/50k 8192 40 /extra1/50k 8192 40 /extra1/50k 8192 48 /extra1/50k 8192 48 /extra1/50k

8.6. Analiza

sc-read fop_read ^C

425

. .

R R

8192 8192

50 /extra1/50k 50 /extra1/50k

Pierwsze zdarzenie to wywođanie systemowe operacji odczytu (sc-read) dotyczæce 8 KB, przetworzone jako odczyt VFS (fop_read). Dalej mamy odczyt z dysku (disk_io) i odczyt z wyprzedzeniem kolejnych 8 KB (disk_ra). Nastúpne wywođanie systemowe operacji odczytu w pozycji 8 KB nie powoduje odczytu danych z dysku, poniewaľ sæ one buforowane. Wywođuje jednak odczyt z wyprzedzeniem danych w pozycji 16 KB dla kolejnych 34 KB, czyli pozostađej czúħci 50-kilobajtowego pliku. Dalsze wywođania systemowe sæ obsđugiwane przez bufor i dlatego moľna dostrzec jedynie zdarzenia VFS.

8.6.5. SystemTap W systemie Linux do monitorowania dynamicznego zdarzeē systemu plików moľna wykorzystaè takľe SystemTap. Zapoznaj siú z podrozdziađem 4.4 w rozdziale 4. „Narzúdzia monitorowania” oraz z dodatkiem E. Znajdziesz tam informacje pomocne w konwersji wczeħniej przedstawionych skryptów DTrace.

8.6.6. LatencyTOP LatencyTOP jest narzúdziem przeznaczonym do wskazywania ļródeđ opóļnieē, zagregowanych dla cađego systemu, a takľe dla poszczególnych procesów (patrz odwođanie [5] na koēcu rozdziađu). Zostađo opracowane dla systemu Linux, a nastúpnie przeniesione do systemu Solaris. Oto przykđad zgđaszania przez LatencyTOP opóļnienia systemu plików: Cause Reading from file synchronous write Marking inode dirty Waiting for a process to die Waiting for event (select) Page fault Process gzip (10969) Reading from file synchronous write Marking inode dirty

Maximum 209.6 msec 82.6 msec 7.9 msec 4.6 msec 3.6 msec 0.2 msec Total: 442.4 209.6 82.6 7.9

msec msec msec msec

Percentage 61.9 % 24.0 % 2.2 % 1.5 % 10.1 % 0.2 % 70.2 % 27.2 % 2.5 %

Górna sekcja zawiera podsumowanie dotyczæce cađego systemu, natomiast dolna jest poħwiúcona procesowi gzip zajmujæcemu siú kompresjæ pliku. Wiúksza czúħè opóļnienia gzip wynika z Reading from file — to aľ 70,2% cađego opóļnienia. Nastúpna z kolei przyczyna to synchronous write — 27,2% cađego opóļnienia. Druga z wymienionych przyczyn jest zwiæzana z zapisem nowo kompresowanego pliku. Narzúdzie LatencyTOP wymaga nastúpujæcych opcji jædra: CONFIG_LATENCYTOP i CONFIG_HAVE_LATENCYTOP_SUPPORT.

426

Rozdział 8



Systemy plików

8.6.7. free W systemie Linux polecenie free wyħwietla dane statystyczne dotyczæce pamiúci operacyjnej i przestrzeni wymiany: $ free -m total Mem: 868 -/+ buffers/cache: Swap: 0

used 799 60 0

free 68 808 0

shared 0

buffers 130

cached 608

Kolumna buffers pokazuje wielkoħè podrúcznej pamiúci buforowej, natomiast kolumna cached — wielkoħè bufora stron. Opcja -m zostađa uľyta w celu wyħwietlania danych wyjħciowych w megabajtach.

8.6.8. top Niektóre wersje polecenia top wyħwietlajæ informacje szczegóđowe o buforze systemu plików. Poniľszy wiersz pochodzi z systemu Linux i zawiera informacje o wielkoħci bufora, które sæ podawane takľe przez polecenie free. Mem:

889484k total,

819056k used,

70428k free,

134024k buffers

Wiúcej informacji na temat polecenia top zamieszczono w rozdziale 6. „Procesory”.

8.6.9. vmstat Polecenie vmstat, podobnie jak top, moľe zawieraè informacje szczegóđowe o buforze systemu plików. Wiúcej informacji na temat polecenia vmstat znajdziesz w rozdziale 7. „Pamiúè”.

Linux Przedstawione poniľej polecenie powoduje uruchomienie vmstat i uaktualnianie informacji co sekundú: $ vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 70296 134024 623100 0 0 1 1 7 6 0 0 100 0 0 0 0 0 68900 134024 623100 0 0 0 0 46 96 1 2 97 0 0 [...]

Kolumna buff pokazuje wielkoħè podrúcznej pamiúci buforowej, natomiast kolumna cache — wielkoħè bufora stron. Obie wartoħci sæ podawane w kilobajtach.

8.6. Analiza

427

Solaris Domyħlne dane wyjħciowe polecenia vmstat w systemie Solaris nie zawierajæ informacji o wielkoħci bufora, ale i tak warto je tutaj przedstawiè: $ vmstat 1 kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr rm s0 s1 -in sy cs us sy id 0 0 36 88812996 3883956 324 3099 5 1 1 0 6 -1546 -0 92 0 28521 79147 37128 5 5 90 1 0 317 86830644 2981520 23 137 43 2 2 0 0 0 0 1 0 23063 59809 31454 1 3 96 0 0 317 86826504 2977588 1876 40670 0 0 0 0 0 0 0 0 0 44264 110777 32383 15 10 76 [...]

Wartoħè kolumny free jest podawana w kilobajtach. Od systemu Solaris w wersji 9 bufor stron jest traktowany jako wolna pamiúè, a wiúc jego wielkoħè jest uwzglúdniania w omawianej kolumnie. Opcja -p powoduje wyħwietlenie informacji podzielonych na operacje page-in i page-out wedđug typu: $ vmstat -p 1 5 memory page swap free re mf fr de 8740292 1290896 75 168 0 0 10828352 3214300 155 42 0 0 10828352 3221976 483 62 0 0 [...]

sr 12 0 0

executable epi epo epf 0 0 0 0 0 0 0 0 0

anonymous filesystem api apo apf fpi fpo fpf 11 0 0 0 0 0 0 0 0 12931 0 0 0 0 0 15568 0 0

Dziúki temu moľna odróľniè stronicowanie systemu plików od stronicowania anonimowego, które wynika z niewielkiej iloħci wolnej pamiúci. Niestety kolumny systemu plików obecnie nie obejmujæ zdarzeē systemu plików ZFS.

8.6.10. sar Polecenie sar moľna wykorzystaè do sprawdzenia bieľæcej aktywnoħci systemu i miúdzy innymi do wyħwietlenia danych statystycznych o systemie plików. Istnieje moľliwoħè skonfigurowania narzúdzia w taki sposób, aby archiwizowađo i podawađo takľe historyczne dane statystyczne. To polecenie jest stosowane równieľ w innych rozdziađach, gdy zajdzie potrzeba.

Linux To jest przykđad uruchomienia sar podajæcego dane w pewnym odstúpie czasu — zadaniem polecenia jest informowanie o bieľæcej aktywnoħci systemu. # sar -v 1 Linux 2.6.35.14-103.fc14.x86_64 (fedora0) 12:07:32 AM dentunusd file-nr inode-nr 12:07:33 AM 11498 384 14029 12:07:34 AM 11498 384 14029 [...]

07/13/2012 pty-nr 6 6

_x86_64_

(1 CPU)

428

Rozdział 8



Systemy plików

Uľycie opcji -v powoduje wyħwietlenie nastúpujæcych kolumn: 

dentunusd — liczba nieuľytych (dostúpnych do wypeđnienia) miejsc w buforze katalogów,



file-nr — liczba aktualnie uľywanych uchwytów plików,



inode-nr — liczba aktualnie uľywanych i-wúzđów.

Istnieje równieľ opcja -r, która powoduje wyħwietlenie kolumn kbbuffers i kbcached, w których znajdujæ siú wyraľone w kilobajtach wielkoħci podrúcznej pamiúci buforowej i bufora stron.

Solaris Oto przykđad uruchomienia sar w pewnym odstúpie czasu — zadaniem polecenia jest informowanie o bieľæcej aktywnoħci systemu. $ sar -v 1 1 [...] 03:16:47 proc-sz 03:16:48 95/16346

ov

inod-sz ov file-sz 0 7895/70485 0 882/882

ov 0

lock-sz 0/0

Opcja -v powoduje wyħwietlenie kolumny inod-sz zawierajæcej informacje o wielkoħci bufora i-wúzđów i jego maksimum. Dostúpna jest równieľ opcja -b odpowiedzialna za wyħwietlanie danych statystycznych dotyczæcych podrúcznej pamiúci buforowej.

8.6.11. slabtop W systemie Linux polecenie slabtop powoduje wyħwietlenie informacji o poziomie uľycia bufora slab jædra; niektóre z nich dotyczæ bufora systemu plików: # slabtop -o Active / Total Objects (% used) Active / Total Slabs (% used) Active / Total Caches (% used) Active / Total Size (% used) Minimum / Average / Maximum Object OBJS ACTIVE USE OBJ SIZE 35802 27164 75% 0.10K 26607 26515 99% 0.19K 26046 25948 99% 0.86K 12240 10095 82% 0.05K 11228 11228 100% 0.14K 9968 9616 96% 0.07K 6846 6846 100% 0.55K 5632 5632 100% 0.01K [...]

: : : : :

151827 / 165106 (92.0%) 7599 / 7599 (100.0%) 68 / 101 (67.3%) 44974.72K / 47255.53K (95.2%) 0.01K / 0.29K / 8.00K

SLABS OBJ/SLAB CACHE SIZE NAME 918 39 3672K buffer_head 1267 21 5068K dentry 2894 9 23152K ext4_inode_cache 144 85 576K shared_policy_node 401 28 1604K sysfs_dir_cache 178 56 712K selinux_inode_security 489 14 3912K inode_cache 11 512 44K kmalloc-8

8.6. Analiza

429

Bez uľycia opcji -o, ustawiajæcej tryb danych wyjħciowych, polecenie slabtop búdzie odħwieľađo i uaktualniađo dane na ekranie. Dane wyjħciowe mogæ obejmowaè: 

dentry — bufor obiektów dentry,



inode_cache — bufor i-wúzđów,



ext3_inode_cache — bufor i-wúzđów dla ext3,



ext4_inode_cache — bufor i-wúzđów dla ext4.

Dane statystyczne o buforze slab pochodzæ z interfejsu /proc/slabinfo, który istnieje, jeħli wđæczono opcjú CONFIG_SLAB.

8.6.12. mdb ::kmastat Szczegóđowe dane statystyczne o alokatorze pamiúci w systemie Solaris moľna wyħwietliè za pomocæ ::kmastat w debugerze mdb -k. Wspomniane dane zawierajæ informacje o róľnych buforach uľywanych przez system plików: > ::kmastat cache buf buf buf memory alloc alloc name size in use total in use succeed fail ------------------------------ ----- --------- --------- ------ ---------- ----kmem_magazine_1 16 7438 18323 292K 90621 0 [...] zfs_file_data_4096 4K 223 1024 4M 1011 0 zfs_file_data_8192 8K 2964824 3079872 23.5G 8487977 0 zfs_file_data_12288 12K 137 440 5.50M 435 0 zfs_file_data_16384 16K 26 176 2.75M 185 0 [...] ufs_inode_cache 368 27061 27070 10.6M 27062 0 [...]

Dane wyjħciowe mogæ byè naprawdú obszerne i zawieraè informacje o buforach wszystkich alokatorów jædra. Wartoħci wyħwietlane w kolumnie memory in use moľna przeanalizowaè w celu ustalenia, które bufory przechowujæ wiúkszoħè danych. Dziúki temu uzyskujemy wglæd w sposób wykorzystania pamiúci przez jædro. W omawianym przykđadzie 23,5 GB pamiúci zostađo uľyte przez bufor systemu plików ZFS i zapisane w plikach o wielkoħci 8 KB. Jeľeli zachodzi potrzeba, alokacje okreħlonych buforów moľna monitorowaè dynamicznie, aby identyfikowaè ħcieľki kodu i konsumenta.

8.6.13. fcachestat To jest narzúdzie typu open source dla systemu Solaris — uľywa biblioteki Perl Sun::Solaris::Kstat i wyħwietla podsumowanie przydatne podczas analizy aktywnoħci bufora w systemie plików UFS:

430

Rozdział 8

~/Dev/CacheKit/CacheKit-0.96> ./fcachestat 1 5 --- dnlc ---- inode ---- ufsbuf -%hit total %hit total %hit total 99.45 476.6M 15.35 914326 99.78 7.4M 70.99 2754 17.52 799 98.71 696 72.64 1356 0.00 371 98.94 377 71.32 1231 0.00 353 96.49 427 84.90 1517 0.00 229 97.27 330

-- segmap -%hit total 93.41 10.7M 52.51 2510 51.10 1779 47.23 2581 48.57 1748



Systemy plików

-- segvn --%hit total 99.89 413.7M 35.94 2799 35.32 2421 42.37 4406 47.85 3162

Pierwszy wiersz zawiera podsumowanie od chwili uruchomienia systemu. Istnieje piúè grup kolumn dla róľnych buforów i napúdów. Kolumna ufsbuf wyħwietla informacje o podrúcznej pamiúci buforowej, natomiast segmap i segvn — o napúdach dla bufora stron. Kolumny pokazujæ wspóđczynnik trafnoħci/nietrafnoħci jako wartoħè procentowæ (%hit) i cađkowitæ liczbú operacji dostúpu (total). Prawidđowe dziađanie narzúdzia fcachestat moľe wymagaè jego uaktualnienia. Wspomniane narzúdzie zostađo przedstawione w niniejszej ksiæľce, aby pokazaè, jakie informacje moľna uzyskaè za jego pomocæ2.

8.6.14. /proc/meminfo W systemie Linux plik /proc/meminfo zawiera podsumowanie dotyczæce pamiúci, jest odczytywany przez polecenia, takie jak free: $ cat /proc/meminfo MemTotal: 49548744 MemFree: 46704484 Buffers: 279280 Cached: 1400792 [...]

kB kB kB kB

Wyħwietlane dane zawierajæ informacje miúdzy innymi o podrúcznej pamiúci buforowej (Buffers) i buforze stron (Cached), a takľe ogólne dane o uľyciu pamiúci w systemie. Wiúcej na ten temat dowiesz siú z rozdziađu 7., zatytuđowanego „Pamiúè”.

8.6.15. mdb ::memstat Polecenie ::memstat dla debugera mdb -k powoduje wyħwietlenie w systemie Solaris ogólnych informacji o uľyciu pamiúci: > ::memstat Page Summary -----------Kernel ZFS File Data 2

Pages ---------------3745224 6082651

MB ---------------14629 23760

%Tot ---30% 48%

Narzúdzie fcachestat jest czúħciæ zestawu CacheKit, czyli eksperymentalnej kolekcji narzúdzi przeznaczonych do analizy buforów. Tú kolekcjú utworzyđem dla systemu Solaris.

8.6. Analiza

431

Anon Exec and libs Page cache Free (cachelist) Free (freelist) Total Physical

2187140 13085 71065 16778 461617 12577560 12577559

8543 51 277 65 1803 49131 49131

17% 0% 1% 0% 4%

Wyħwietlone dane zawierajæ miúdzy innymi informacje o wielkoħci danych buforowanych przez ARC (ZFS File Data) i wielkoħci bufora stron (Page cache), obejmujæcego takľe buforowane dane UFS.

8.6.16. kstat Niezmodyfikowane dane statystyczne wyħwietlane przez poprzednio omówione polecenia moľna uzyskaè z poziomu narzúdzia kstat, do którego dostúp jest moľliwy przez bibliotekú Perl Sun::Solaris::Kstat, bibliotekú C libkstat lub polecenie kstat. Polecenia wymienione w tabeli 8.8 wyħwietlajæ grupy danych statystycznych dotyczæcych systemu plików oraz liczbú dostúpnych grup (w najnowszych wersjach jædra). Tabela 8.8. Polecenia kstat generujące dane statystyczne dla systemu plików Polecenie kstat

Opis

Dane statystyczne

kstat -n segmap

Dane statystyczne operacji odczytu i zapisu dla bufora stron.

23

kstat cpu_stat

Między innymi dane statystyczne bufora stron dla apowanych plików.

90 na procesor

kstat -n dnlcstats

Dane statystyczne bufora DNLC.

31

kstat -n biostats

Dane statystyczne podręcznej pamięci buforowej.

9

kstat -n inode_cache

Dane statystyczne bufora i-węzłów.

20

kstat -n arcstats

Dane statystyczne dotyczące buforów ZFS ARC i L2ARC.

56

kstat zone_vfs

Liczniki VFS dla poszczególnych stref.

18 na strefę

Oto przykđad uľycia jednego z poleceē wymienionych w tabeli 8.8: $ kstat -n inode_cache module: ufs name: inode_cache cache allocs cache frees crtime hits kmem allocs kmem frees lookup idles maxsize

instance: 0 class: ufs 772825 973443 36.947583642 139468 214347 206439 0 70485

432

Rozdział 8

maxsize reached misses pushes at close puts at backlist puts at frontlist queues to free scans size snaptime thread idles vget idles



Systemy plików

90170 772825 0 65379 766776 3148 485005142 7895 5506613.86119402 722525 0

Wprawdzie narzúdzie kstat dostarczyđo uľytecznych informacji, ale nie zostađy one udokumentowane. Czasami nazwa danych statystycznych jest jasna, a ich przeznaczenie đatwe do odgadniúcia, natomiast w innych przypadkach konieczne jest sprawdzenie kodu ļródđowego jædra (o ile jest dostúpny) w celu ustalenia przeznaczenia konkretnych danych statystycznych. Dostúpne dane statystyczne zaleľæ równieľ od wersji jædra. W najnowszych wersjach jædra systemu SmartOS/illumos dodane zostađy zaznaczone poniľej liczniki: $ kstat zone_vfs module: zone_vfs name: 961ebd45-7fcc-4f18-8f90-ba1353 100ms_ops 10ms_ops 10s_ops 1s_ops [...]

instance: 3 class: zone_vfs 5 73 0 1

Wspomniane liczniki zliczajæ operacje systemu plików, których wykonanie trwa dđuľej niľ wskazany przedziađ czasu, i rejestrujæ te operacje. Dane zebrane w ten sposób majæ nieocenionæ wartoħè podczas wyszukiwania opóļnienia systemu plików w ħrodowiskach przetwarzania w chmurze.

8.6.17. Inne narzędzia Istniejæ jeszcze inne narzúdzia i frameworki monitorowania, które moľna wykorzystaè do analizy wydajnoħci systemu plików i przygotowywania charakterystyki jego sposobu uľycia. Do wspomnianych narzúdzi zaliczamy: 





df. Polecenie wyħwietla informacje o uľyciu systemu plików i dane statystyczne dotyczæce jego pojemnoħci. mount. Polecenie moľe wyħwietliè opcje zamontowanych systemów pliku (statyczne dostrajanie wydajnoħci). inotify. To jest framework dla systemu Linux przeznaczony do monitorowania zdarzeē systemu plików.

8.6. Analiza

433

Niektóre rodzaje systemów plików majæ wđasne, specyficzne narzúdzia wydajnoħci poza dostarczanymi przez system operacyjny. Do takich systemów plików zaliczamy ZFS.

ZFS System plików ZFS jest dostarczany wraz z poleceniem zpool posiadajæcym opcjú iostat przeznaczonæ do monitorowania danych statystycznych puli ZFS. Polecenie podaje informacje o czústotliwoħci wykonywania operacji (odczytu i zapisu) oraz przepustowoħci. Popularnym dodatkiem jest narzúdzie arcstat.pl, które podaje informacje o wielkoħci buforów ARC i L2ARC, a takľe wspóđczynniki ich trafnoħci i nietrafnoħci, na przykđad: $ arcstat 1 time read 04:45:47 0 04:45:49 15K 04:45:50 23K 04:45:51 65K [...]

miss 0 10 81 25

miss% 0 0 0 0

dmis 0 10 81 25

dm% 0 0 0 0

pmis 0 0 0 0

pm% 0 0 0 0

mmis 0 1 1 4

mm% 0 0 0 0

arcsz 14G 14G 14G 14G

c 14G 14G 14G 14G

Dane statystyczne dotyczæ wskazanego przedziađu czasu i oznaczajæ: 



read, miss — informacje o cađkowitym dostúpie do bufora ARC i o jego nietrafieniach, miss%, dm%, pm%, mm% — procentowa, cađkowita iloħè nietrafieē bufora ARC, ľædaē, operacji mechanizmu prefetch i metadanych,



dmis, pmis, mmis — nietrafienia ľædaē, prefetch i metadanych,



arcsz, c — wielkoħè bufora ARC i jego wielkoħè docelowa.

Narzúdzie arcstat.pl to po prostu skrypt Perla odczytujæcy dane statystyczne z kstat.

8.6.18. Wizualizacje Obciæľenie systemu plików na przestrzeni czasu moľna przestawiè w postaci wykresu liniowego, co pomaga w identyfikacji wzorców uľycia opartych na czasie. Uľytecznym rozwiæzaniem moľe byè wygenerowanie oddzielnych wykresów dla odczytu, zapisu i innych operacji systemu plików. Oczekiwany rozkđad opóļnienia systemu plików jest bimodalny: jeden tryb niskiego opóļnienia systemu plików dziúki trafieniu bufora i drugi tryb wysokiego opóļnienia ze wzglúdu na nietrafienie bufora (a tym samym wykonanie dyskowych operacji wejħcia-wyjħcia). Z tego powodu przedstawienie rozkđadu w postaci pojedynczej wartoħci, takiej jak ħrednia, dominanta lub mediana, jest po prostu mylæce. Jednym z rozsædnych rozwiæzaē wspomnianego problemu jest zastosowanie wizualizacji, która pokazuje peđny rozkđad. Przykđadem moľe byè mapa cieplna (mapy te zostađy wprowadzone w rozdziale 2., zatytuđowanym „Metodologia”). Tego rodzaju mapú cieplnæ przedstawiono na rysunku 8.15 — na osi X znajdujæ siú wartoħci czasu, natomiast na osi Y wartoħci opóļnienia operacji wejħcia-wyjħcia.

434

Rozdział 8



Systemy plików

Rysunek 8.15. Mapa cieplna pokazująca opóźnienie systemu plików

Wspomniana mapa cieplna pokazuje system plików podczas operacji losowego odczytu pliku o wielkoħci 1 GB. W pierwszej pođowie mapy cieplnej opóļnienie zawiera siú w przedziale od 3 ms do 10 ms, co prawdopodobnie odzwierciedla dyskowe operacje wejħcia-wyjħcia. Linia umieszczona na dole wykresu pokazuje trafienia znajdujæcego siú w pamiúci operacyjnej bufora systemu plików. Po przekroczeniu pođowy wykresu moľna zobaczyè, ľe plik byđ w peđni buforowany w pamiúci operacyjnej i dyskowe operacje wejħcia-wyjħcia zanikđy. Omówiony przykđad pochodzi z pakietu Joyent Cloud Analytics, który pozwala na wybór i izolacjú rodzajów operacji systemu plików.

8.7. Eksperymenty W tym podrozdziale zostanæ przedstawione narzúdzia przeznaczone do aktywnego testowania wydajnoħci systemu plików. Informacje o sugerowanej strategii, któræ warto zastosowaè, znajdziesz w punkcie 8.5.10. Podczas uľywania omawianych tutaj narzúdzi dobrym rozwiæzaniem jest pozostawienie nieustannie dziađajæcego polecenia iostat, aby potwierdziè, ľe obciæľenie rzeczywiħcie powoduje odczyt z dysku. Przykđadowo w trakcie testowania zbioru roboczego mieszczæcego siú bez problemów w buforze systemu plików oczekuje siú 100procentowej trafnoħci bufora dla operacji odczytu. W takim przypadku polecenie iostat nie powinno wskazywaè, ľe przeprowadzane sæ jakiekolwiek dyskowe operacje wejħciawyjħcia. Wiúcej informacji o poleceniu iostat znajdziesz w rozdziale 9., noszæcym tytuđ „Dyski”.

8.7. Eksperymenty

435

8.7.1. Ad hoc Polecenie dd (przeznaczone do kopiowania danych miúdzy urzædzeniami) moľna wykorzystaè do przeprowadzenia testów ad hoc sekwencyjnej wydajnoħci systemu plików. Pierwsze z przedstawionych poniľej poleceē zapisuje, a drugie odczytuje plik o wielkoħci 1 GB i nazwie file1. Wielkoħè operacji wejħcia-wyjħcia wynosi 1 MB: zapis: dd if=/dev/zero of=file1 bs=1024k count=1k odczyt: dd if=file1 of=/dev/null bs=1024k

W systemie Linux polecenie dd wyħwietla dane statystyczne po zakoēczeniu operacji.

8.7.2. Narzędzia mikrotestów wydajności Dostúpnych jest wiele narzúdzi przeznaczonych do przeprowadzania testów wydajnoħci systemów plików, miúdzy innymi: Bonnie, Bonnie++, iozone, tiobench, SysBench, fio i FileBench. Niektóre z nich zostanæ teraz omówione — narzúdzia búdæ prezentowane w kolejnoħci rosnæcego poziomu ich skomplikowania. Zapoznaj siú takľe z rozdziađem 12., zatytuđowanym „Testy wydajnoħci”.

Bonnie, Bonnie++ Narzúdzie Bonnie to prosty program utworzony w júzyku C, przeznaczony do przetestowania wielu obciæľeē za pomocæ jednego pliku i wætku. Pierwsza wersja zostađa opracowana przez Tima Braya w 1989 roku (patrz odwođanie [6] na koēcu rozdziađu). Sposób uľycia narzúdzia Bonnie jest bardzo prosty: # ./Bonnie -h usage: Bonnie [-d scratch-dir] [-s size-in-Mb] [-html] [-m machine-label]

Opcja -s umoľliwia ustawienie wielkoħci pliku do przetestowania. Domyħlnie Bonnie uľywa pliku o wielkoħci 100 MB, który w cađoħci jest buforowany w analizowanym systemie: $ ./Bonnie File './Bonnie.9598', size: 104857600 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 1...Seeker 3...Seeker 2...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random--Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 123396 100.0 1258402 100.0 996583 100.0 126781 100.0 2187052 100.0 164190.1 299.0

436

Rozdział 8



Systemy plików

Dane wyjħciowe zawierajæ informacje o czasie procesora podczas kaľdego testu. Wartoħè 100% oznacza, ľe narzúdzie Bonnie nigdy nie zostađo zablokowane przez dyskowe operacje wejħcia-wyjħcia, które zamiast tego ľædania byđy obsđugiwane przez bufor, wiúc narzúdzie mogđo pozostaè w procesorze i tam dziađaè. Istnieje równieľ 64-bitowa wersja narzúdzia o nazwie „Bonnie-64”, która pozwala na przetestowanie wiúkszych plików. Przygotowano takľe wersjú w júzyku C++, o nazwie „Bonnie++” — jej autorem jest Russell Coker (patrz odwođanie [7] na koēcu rozdziađu). Niestety narzúdzia takie jak Bonnie, przeznaczone do przeprowadzania testów wydajnoħci systemu plików, mogæ generowaè dane wprowadzajæce w bđæd, o ile nie orientujesz siú doskonale, co tak naprawdú zostađo przetestowane. Wynik pierwszego testu, czyli uľycia putc(), zaleľy od implementacji biblioteki systemowej, która jest celem testu, a nie system plików. Zapoznaj siú z przykđadem w punkcie 12.3.2 w rozdziale 12. „Testy wydajnoħci”.

fio Opracowane przez Jensa Axboe’a narzúdzie fio (ang. The Flexible IO Tester) jest przeznaczone do przeprowadzania testów wydajnoħci systemów plików. Oferuje ono duľe moľliwoħci w zakresie konfiguracji oraz wiele zaawansowanych funkcji (patrz odwođanie [8] na koēcu rozdziađu). Poniľej wymieniđem dwie funkcje, które skđaniajæ mnie do uľywania tego narzúdzia zamiast innych przeznaczonych do przeprowadzania testów wydajnoħci: 



niejednostajny rozkđad losowy — umoľliwia znacznie bardziej rzeczywiste symulowanie wzorca dostúpu (na przykđad -random_distribution=pareto:0.9), informacje o percentylach opóļnienia — miúdzy innymi: 99.00, 99.50, 99.90, 99.95, 99.99.

W dalszej czúħci pokazano przykđadowe dane wyjħciowe wygenerowane przez omawiane narzúdzie. Dane wskazujæ na obciæľenie w postaci losowych operacji odczytu — wielkoħè operacji wejħcia-wyjħcia wynosi 8 KB, zbiór roboczy ma wielkoħè 5 GB i niejednostajny wzorzec dostúpu (pareto:0.9): # ./fio --runtime=60 --time_based --clocksource=clock_gettime --name=randread -numjobs=1 --rw=randread --random_distribution=pareto:0.9 --bs=8k --size=5g -filename=fio.tmp randread: (g=0): rw=randread, bs=8K-8K/8K-8K/8K-8K, ioengine=sync, iodepth=1 fio-2.0.13-97-gdd8d Starting 1 process Jobs: 1 (f=1): [r] [100.0% done] [3208K/0K/0K /s] [401 /0 /0 iops] [eta 00m:00s] randread: (groupid=0, jobs=1): err= 0: pid=2864: Tue Feb 5 00:13:17 2013 read : io=247408KB, bw=4122.2KB/s, iops=515 , runt= 60007msec clat (usec): min=3 , max=67928 , avg=1933.15, stdev=4383.30 lat (usec): min=4 , max=67929 , avg=1934.40, stdev=4383.31 clat percentiles (usec): | 1.00th=[ 5], 5.00th=[ 5], 10.00th=[ 5], 20.00th=[ 6], | 30.00th=[ 6], 40.00th=[ 6], 50.00th=[ 7], 60.00th=[ 620],

8.7. Eksperymenty

437

| 70.00th=[ 692], 80.00th=[ 1688], 90.00th=[ 7648], 95.00th=[10304], | 99.00th=[19584], 99.50th=[24960], 99.90th=[39680], 99.95th=[51456], | 99.99th=[63744] bw (KB/s) : min= 1663, max=71232, per=99.87%, avg=4116.58, stdev=6504.45 lat (usec) : 4=0.01%, 10=55.62%, 20=1.27%, 50=0.28%, 100=0.13% lat (usec) : 500=0.01%, 750=15.21%, 1000=4.15% lat (msec) : 2=3.72%, 4=2.57%, 10=11.50%, 20=4.57%, 50=0.92% lat (msec) : 100=0.05% cpu : usr=0.18%, sys=1.39%, ctx=13260, majf=0, minf=42 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued : total=r=30926/w=0/d=0, short=r=0/w=0/d=0

Percentyle opóļnienia (clat) wyraļnie okreħlajæ zakres trafnoħci bufora — w omawianym przykđadzie do 50. percentyla ze wzglúdu na mađe opóļnienie. Pozostađe percentyle pokazujæ efekt nietrafnoħci bufora, miúdzy innymi na koēcu kolejki. W omawianym przykđadzie percentyl 99,99 pokazuje opóļnienie na poziomie 63 ms. Wprawdzie wspomniane percentyle nie dostarczajæ informacji pozwalajæcych tak naprawdú poznaè prawdopodobieēstwo otrzymania rozkđadu multimodalnego, ale za to koncentrujæ siú na najbardziej interesujæcym aspekcie, jakim jest koniec najwolniejszej dominanty (dyskowe operacje wejħcia-wyjħcia). Podobnym, choè prostszym narzúdziem jest SysBench. Z drugiej strony, jeħli chcesz mieè jeszcze wiúkszæ kontrolú, wypróbuj narzúdzie FileBench.

FileBench FileBench to przeznaczone do przeprowadzania testów wydajnoħci systemu plików programowalne narzúdzie, w którym obciæľenie aplikacji moľe byè symulowane przez jego opisanie w júzyku WML (ang. Workload Model Language). To umoľliwia zasymulowanie wætków z róľnymi obciæľeniami oraz wskazanie zachowania wætku synchronicznego. Narzúdzie jest standardowo dostarczane z róľnymi konfiguracjami nazywanymi personalities, miúdzy innymi symulujæcymi model operacji wejħcia-wyjħcia Oracle 9i. Niestety narzúdzie FileBench nie jest đatwe do nauki i uľycia, moľe raczej zainteresowaè jedynie te osoby, które codziennie zajmujæ siú pracæ z systemami plików.

8.7.3. Opróżnienie bufora systemu plików System Linux zapewnia moľliwoħè opróľnienia (usuniúcia zawartoħci) buforów systemów plików, co moľe byè uľyteczne podczas przeprowadzania testów wydajnoħci dla spójnego i „zimnego” bufora, na przykđad takiego jak po uruchomieniu systemu. Ten mechanizm jest bardzo jasno opisany w dokumentacji kodu ļródđowego jædra (a dokđadnie w pliku Documentation/sysctl/vm.txt) jako: Opróĝnienie bufora stron: echo 1 > /proc/sys/vm/drop_caches Opróĝnienie bufora obiektów dentries i i-wÚzïów: echo 2 > /proc/sys/vm/drop_caches

438

Rozdział 8



Systemy plików

Opróĝnienie bufora stron, bufora obiektów dentries i i-wÚzïów: echo 3 > /proc/sys/vm/drop_caches

Obecnie nie ma odpowiadajæcych im poleceē dla systemu Solaris.

8.8. Dostrajanie Wiele podejħè z zakresu dostrajania zostađo juľ przedstawionych w podrozdziale 8.5 „Metodologia”, miúdzy innymi dostrajanie bufora i przygotowywanie charakterystyki obciæľenia. Drugie z wymienionych podejħè moľe przynieħè najwiúksze korzyħci, poniewaľ pozwala zidentyfikowaè i wyeliminowaè niepotrzebnie wykonywane zadania. W tym podrozdziale zostanæ pokazane przykđady konkretnych parametrów, które moľna zmodyfikowaè. Specyfika dostrajania — dostúpne opcje i przypisywane im wartoħci — zaleľy od rodzaju systemu plików, wersji uľywanego systemu operacyjnego oraz planowanego obciæľenia. W dalszej czúħci przedstawiono przykđady opcji, które mogæ byè dostúpne, i sposoby ich dostrajania. Omówione zostanæ wywođania aplikacji i dwa przykđadowe rodzaje systemu plików: ext3 i ZFS. Informacje dotyczæce dostrajania bufora stron znajdziesz w rozdziale 7., zatytuđowanym „Pamiúè”.

8.8.1. Wywołania aplikacji W punkcie 8.3.7 wspomniano, ľe wydajnoħè synchronicznych operacji zapisu moľna poprawiè dziúki uľyciu wywođania fsync() sđuľæcego do przeprowadzania logicznej grupy operacji zapisu zamiast przeprowadzaè pojedyncze operacje z uľyciem opcji O_DSYNC/O_RSYNC wywođania open(). Inne wywođania, które mogæ poprawiè wydajnoħè, to miúdzy innymi: posix_fadvise() i madvise(), dostarczajæce wskazówek o dostúpnoħci bufora.

posix_fadvise() To wywođanie biblioteki operuje na pewnym fragmencie pliku. Prototyp wywođania przedstawia siú nastúpujæco: int posix_fadvise(int fd, off_t offset, off_t len, int advice);

Argument advice moľe przyjæè dowolnæ wartoħè z wymienionych w tabeli 8.9. Jædro wykorzystuje wartoħè argumentu advice do poprawy wydajnoħci podczas podejmowania decyzji o najlepszym momencie na wczeħniejsze pobranie lub buforowanie danych. Tego rodzaju rozwiæzanie moľe poprawiè wspóđczynnik trafnoħci bufora dla danych o wyľszym priorytecie, jeħli jest zalecane przez aplikacjú. Peđnæ listú obsđugiwanych wartoħci argumentu znajdziesz w podrúczniku man wykorzystywanego systemu operacyjnego. Wywođanie posix_fadvise() zostađo uľyte jako przykđad w punkcie 3.3.4 w rozdziale 3. „Systemy operacyjne”. Jego obsđuga zaleľy od konkretnej wersji jædra.

8.8. Dostrajanie

439

Tabela 8.9. Dostępne wartości argumentu advice w wywołaniu posix_fadvise() Wartość argumentu

Opis

POSIX_FADV_SEQUENTIAL

Dostęp do wskazanego zakresu danych będzie odbywał się sekwencyjnie.

POSIX_FADV_RANDOM

Dostęp do wskazanego zakresu danych będzie odbywał się losowo.

POSIX_FADV_NOREUSE

Wskazane dane nie będą ponownie używane.

POSIX_FADV_WILLNEED

Wskazane dane będą ponownie używane w niedalekiej przyszłości.

POSIX_FADV_DONTNEED

Wskazane dane nie będą ponownie używane w niedalekiej przyszłości.

madvise() To wywođanie biblioteki operuje na mapowaniach pamiúci, a jego prototyp przedstawia siú nastúpujæco: int madvise(void *addr, size_t length, int advice);

Argument advice moľe przyjæè dowolnæ wartoħè z wymienionych w tabeli 8.10. Tabela 8.10. Dostępne wartości argumentu advice w wywołaniu madvise() Wartość argumentu

Opis

MADV_RANDOM

Dostęp do wskazanego położenia będzie odbywał się w kolejności losowej.

MADV_SEQUENTIAL

Dostęp do wskazanego położenia będzie odbywał się w kolejności sekwencyjnej.

MADV_WILLNEED

Wskazane dane będą ponownie potrzebne (proszę je buforować).

MADV_DONTNEED

Wskazane dane nie będą ponownie potrzebne (proszę ich nie buforować).

Podobnie jak w przypadku posix_fadvise(), jædro wykorzystuje wartoħè argumentu advice do poprawy wydajnoħci, miúdzy innymi do podejmowania lepszych decyzji dotyczæcych buforowania danych.

8.8.2. ext3 W systemie Linux systemy plików ext2, ext3 i ext4 moľna dostroiè za pomocæ polecenia tune2fs. Istnieje moľliwoħè podania róľnych opcji takľe podczas montowania, przeprowadzanego zarówno rúcznie za pomocæ polecenia mount, jak i w trakcie uruchamiania systemu (odczyt danych z /boot/grub/menu.lst i /etc/fstab). Dostúpne opcje sæ omówione na stronach podrúcznika systemowego man dla tune2fs i mount. Ponadto ustawienia bieľæce moľna wyħwietliè za pomocæ poleceē tunefs -l urzÈdzenie i mount (bez ľadnych opcji). Opcja noatime moľe byè uľyta wraz z poleceniem mount, powoduje ona wyđæczenie uaktualniania znaczników czasu dostúpu do plików. Jeľeli uaktualnienia nie sæ niezbúdne dla uľytkowników systemu plików, ich wyđæczenie spowoduje zmniejszenie iloħci dyskowych operacji wejħcia-wyjħcia, a tym samym ogólnæ poprawú wydajnoħci.

440

Rozdział 8



Systemy plików

Kluczowæ opcjæ dla poprawy wydajnoħci w tune2fs jest: tune2fs -O dir_index /dev/hdX

Opcja ta powoduje uľycie haszowanych struktur B-tree, co przyħpiesza operacje wyszukiwania w ogromnych katalogach. Polecenie e2fsck moľe byè uľyte do ponownego zindeksowania katalogów w systemie plików, na przykđad: e2fsck -D -f /dev/hdX

Inne opcje polecenia e2fsck sæ powiæzane z operacjami sprawdzania i naprawy systemu plików.

8.8.3. ZFS System plików ZFS obsđuguje ogromnæ liczbú parametrów moľliwych do modyfikacji (nazywanych wđaħciwoħciami), dostúpnych dla poszczególnych systemów plików. Niewielka czúħè wspomnianych wđaħciwoħci moľe byè ustawiona dla cađego systemu (/etc/system). Dostúpne wđaħciwoħci systemu plików sæ wyħwietlane za pomocæ polecenia zfs, na przykđad: # zfs get all zones/var NAME PROPERTY zones/var type zones/var creation zones/var used zones/var available zones/var referenced zones/var compressratio zones/var mounted zones/var quota zones/var reservation zones/var recordsize zones/var mountpoint zones/var sharenfs zones/var checksum zones/var compression zones/var atime [...]

VALUE filesystem Sat Nov 19 60.2G 1.38T 60.2G 1.00x yes none none 128K legacy off on off off

0:37 2011

SOURCE default default default local default default inherited from zones inherited from zones

Przedstawione (skrócone) dane wyjħciowe zawierajæ kolumny dla nazwy wđaħciwoħci, jej wartoħci bieľæcej i ļródđa. Wspomniane ļródđo wskazuje na sposób ustawienia wđaħciwoħci: dziedziczona ze zbioru danych na wyľszym poziomie ZFS, domyħlna lub ustawiona lokalnie dla danego systemu plików.

8.8. Dostrajanie

441

Za pomocæ polecenia zfs mogæ byè równieľ ustawiane parametry, jak to zostađo omówione na stronie podrúcznika man poħwiúconej poleceniu zfs. W tabeli 8.11 wymieniono parametry, które majæ znaczenie kluczowe dla wydajnoħci. Tabela 8.11. Kluczowe dla wydajności parametry zbioru danych ZFS Parametr

Opcje

Opis

recordsize

od 512 B do 128 KB

Sugerowana wielkość bloku dla plików.

copression

on | off | lzjb | gzip | gzip-[1–9] | zle | lz4

Lżejsze algorytmy (na przykład lzjb) mogą poprawić wydajność w pewnych sytuacjach, ponieważ pozwalają zmniejszyć ilość operacji wejścia-wyjścia.

atime

on | off

Uaktualnienie znaczników czasu dostępu do plików (powoduje powstanie operacji zapisu po operacjach odczytu).

primarycache

all | none | metadata

Polityka bufora ARC, zanieczyszczenie bufora ze względu na to, że systemy plików o mniejszym priorytecie (na przykład archiwa) można ograniczyć dzięki użyciu opcji (tylko) none lub metadata.

secondarycache

all | none | metadata

Polityka bufora L2ARC.

logbias

latency | throughput

Wskazówka dla synchronicznej operacji zapisu. Opcja latency oznacza użycie urządzenia przeznaczonego dla dzienników zdarzeń, natomiast throughput oznacza użycie puli urządzeń.

sync

standard | always | disabled

Zachowanie synchronicznej operacji zapisu.

Najwaľniejszym parametrem moľliwym do modyfikacji jest z reguđy wielkoħè rekordu, dopasowywana do wielkoħci operacji wejħcia-wyjħcia wykonywanych przez aplikacjú. Wartoħè domyħlna najczúħciej wynosi 128 KB i moľe byè nieefektywna w przypadku mađych, losowych operacji wejħcia-wyjħcia. Zwróè uwagú, ľe nie dotyczy to plików mniejszych niľ wielkoħè rekordów — pliki takie sæ zapisywane za pomocæ rekordu o wielkoħci dynamicznie dopasowywanej do wielkoħci pliku. Wyđæczenie uaktualniania czasu dostúpu do plików równieľ moľe poprawiè wydajnoħè (choè to zachowanie i tak zostađo juľ zoptymalizowane), jeħli wspomniane znaczniki czasu rzeczywiħcie sæ niepotrzebne. W tabeli 8.12 przedstawiono parametry ZFS, które moľna ustawiè dla cađego systemu. (Parametry, które majæ najwiúkszy zwiæzek z wydajnoħciæ, ulegajæ zmianie na przestrzeni czasu, w zaleľnoħci od wersji ZFS. Trzy parametry wymienione w tabeli równieľ mogđy siú zmieniè do chwili, w której czytasz te sđowa). Na przestrzeni lat wartoħci domyħlne parametrów zfs_txg_synctime_ms i zfs_txg_ ´timeout byđy systematycznie zmniejszane, aby grupy transakcji stawađy siú mniejsze i tym samym stwarzađy mniejsze prawdopodobieēstwo rywalizacji z innymi operacjami wejħcia-wyjħcia ze wzglúdu na kolejkowanie. Podobnie jak w przypadku innych

442

Rozdział 8



Systemy plików

Tabela 8.12. Przykłady parametrów ZFS możliwych do ustawienia dla całego systemu Parametr

Opis

zfs_txg_synctime_ms

Wyrażony w milisekundach czas synchronizacji docelowej grupy transakcji (TXG).

zfs_txg_timeout

Wyrażony w sekundach czas utraty ważności grupy transakcji. Powoduje ustawienie niższej wartości niż częstotliwość ich występowania.

metaslab_df_free_pct

Wartość procentowa dla elementów metaslabs, wskazująca na zmianę zachowania i przeprowadzanie optymalizacji pod kątem przestrzeni zamiast czasu.

parametrów jædra, których wartoħè moľna modyfikowaè, sprawdļ dokumentacjú dostarczanæ przez producenta — znajdziesz tam peđnæ listú parametrów, ich opisy oraz ostrzeľenia. Ustawienie wspomnianych parametrów moľe byè niedozwolone ze wzglúdu na stosowanæ politykú firmy lub producenta. Wiúcej informacji na temat dostrajania ZFS znajdziesz w artykule zatytuđowanym ZFS Evil Tuning Guide (patrz odwođanie [9] na koēcu rozdziađu).

8.9. Ćwiczenia 1. Odpowiedz na nastúpujæce pytania na temat terminologii: 

Jaka jest róľnica miúdzy logicznymi i fizycznymi operacjami wejħcia-wyjħcia?



Jaka jest róľnica miúdzy losowymi i sekwencyjnymi operacjami wejħcia-wyjħcia?



Co to jest bezpoħrednia operacja wejħcia-wyjħcia?



Co to jest nieblokujæca operacja wejħcia-wyjħcia?



Czym jest wielkoħè zbioru roboczego?

2. Odpowiedz na poniľsze pytania dotyczæce koncepcji:  

Jaka jest rola VFS? Jak mógđbyħ opisaè rolú opóļnienia systemu plików, zwđaszcza w miejscu, gdzie moľna je zmierzyè?



Jakie jest przeznaczenie mechanizmu prefetch (odczytu z wyprzedzeniem)?



Jakie jest przeznaczenie bezpoħrednich operacji wejħcia-wyjħcia?

3. Odpowiedz na nastúpujæce, dokđadniejsze pytania: 

Jakie sæ zalety uľycia fsync() zamiast opcji O_SYNC?



Jakie sæ wady i zalety uľycia mmap() zamiast operacji read() i write()?







Jakie mógđbyħ wymieniè powody, dla których logiczne operacje wejħcia-wyjħcia powiúkszajæ siú, gdy zostanæ fizycznymi operacjami wejħcia-wyjħcia? Jakie mógđbyħ wymieniè powody, dla których logiczne operacje wejħcia-wyjħcia zmniejszajæ siú, gdy zostanæ fizycznymi operacjami wejħcia-wyjħcia? Jak moľesz wyjaħniè poprawú wydajnoħci powodowanæ przez technikú kopiowania przy zapisie?

4. Zaimplementuj w uľywanym systemie operacyjnym wymienione procedury:

8.10. Odwołania





443

Lista rzeczy do zrobienia dotyczæcych systemu plików. Uwzglúdnij istniejæce bufory systemu plików, sposoby sprawdzania ich bieľæcej wielkoħci i poziomu uľycia, a takľe wspóđczynnik trafnoħci. Przygotuj charakterystykú obciæľenia w postaci listy rzeczy do zrobienia dotyczæcych operacji systemu plików. Uwzglúdnij sposób pobrania informacji szczegóđowych. Spróbuj w pierwszej kolejnoħci wykorzystaè narzúdzia monitorowania oferowane przez uľywany system operacyjny.

5. Wykonaj poniľsze zadania: 

Wybierz aplikacjú, a nastúpnie wykonaj pomiar operacji i opóļnienia systemu plików. Uwzglúdnij: 





peđny rozkđad opóļnienia operacji systemu plików, a nie tylko wartoħè ħredniæ, czúħè kaľdej sekundy, jakæ wætkom poszczególnych aplikacji zajmuje wykonywanie operacji systemu plików.

Za pomocæ narzúdzia przeznaczonego do mikrotestów wydajnoħci eksperymentalnie okreħl wielkoħè bufora systemu plików. Wyjaħnij dokonywane wybory podczas uľycia narzúdzia. Ponadto pokaľ degradacjú wydajnoħci (uľyj do tego dowolnej metryki), gdy zbiór roboczy nie mieħci siú w buforze.

6. (Opcjonalne, zaawansowane) Opracuj narzúdzie monitorowania dostarczajæce metryk dla synchronicznych kontra asynchronicznych operacji zapisu w systemie plików. Tego rodzaju narzúdzie powinno podawaè informacje o czústotliwoħci i opóļnieniu, a takľe mieè moľliwoħè wykrycia identyfikatora procesu wywođujæcego narzúdzie. Dziúki temu narzúdzie stanie siú odpowiednie do przygotowywania charakterystyki obciæľenia. 7. (Opcjonalne, zaawansowane) Opracuj narzúdzie dostarczajæce danych statystycznych o poħrednich i zmniejszonych operacjach wejħcia-wyjħcia systemu plików: dotyczæcych dodatkowych bajtów i operacji wejħcia-wyjħcia, których ľædanie wykonania nie zostađo bezpoħrednio wydane przez aplikacje. Wspomniane dodatkowe operacje wejħcia-wyjħcia powinny byè podzielone na róľne rodzaje w celu wyjaħnienia powodów ich powstania.

8.10. Odwołania [Ritchie 74]

D.M. Ritchie, K. Thompson, The UNIX Time-Sharing System, „Communications of the ACM” 17, nr 7 (lipiec 1974), s. 365 – 375.

[Lions 77]

J. Lions, A Commentary on the Sixth Edition UNIX Operating System, University of New South Wales, 1977.

[McKusick 84]

M. McKusick i in., A Fast File System for UNIX, „ACM Transactions on Computer Systems” (TOC) 2, nr 3 (sierpieē 1984).

[Bach 86]

M. Bach, The Design of the UNIX Operating System, Prentice Hall, 1986.

444

[Vahalia 96]

Rozdział 8



Systemy plików

U. Vahalia, UNIX Internals: The New Frontiers, Prentice Hall, 1996.

[McDougall 06a] R. McDougall, J. Mauro, Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture, 2nd Edition, Prentice Hall, 2006. [Doeppner 10]

T. Doeppner, Operating Systems in Depth: Design and Programming, Wiley, 2010.

[Gregg 11]

B. Gregg, J. Mauro, DTrace: Dynamic Tracing in Oracle Solaris, Mac OS X and FreeBSD, Prentice Hall, 2011.

[1]

http://lwn.net/Articles/419811/

[2]

http://zfsonlinux.org/

[3]

http://sysbench.sourceforge.net/docs/

[4]

http://www.dtracebook.com/

[5]

https://latencytop.org/

[6]

http://www.textuality.com/bonnie/

[7]

http://www.coker.com.au/bonnie++/

[8]

https://github.com/axboe/fio

[9]

http://www.solarisinternals.com/wiki/index.php/ ZFS_Evil_Tuning_Guide

9 Dyski

Dyskowe operacje wejħcia-wyjħcia mogæ powodowaè powstawanie znacznego opóļnienia w aplikacji i dlatego sæ waľnym przedmiotem analizy wydajnoħci systemu. Przy duľym obciæľeniu dysk staje siú wæskim gardđem, a procesor pozostaje bezczynny, poniewaľ system oczekuje na zakoēczenie dyskowej operacji wejħcia-wyjħcia. Identyfikacja i eliminacja wæskich gardeđ moľe poprawiè wydajnoħè i przepustowoħè aplikacji o kilka rzúdów wielkoħci. Pojúcie dysków odnosi siú do podstawowych urzædzeē pamiúci masowej w systemie. Obejmuje tradycyjne dyski mechaniczne oraz nowe, zbudowane na bazie pamiúci flash napúdy SSD (ang. Solid State Drive). Drugie z wymienionych zostađy opracowane przede wszystkim w celu poprawy wydajnoħci dyskowych operacji wejħcia-wyjħcia, co niewætpliwie siú udađo. Niemniej zwiúkszajæ siú równieľ wymagania w zakresie pojemnoħci i liczby operacji wejħcia-wyjħcia, a same urzædzenia SSD nie sæ w peđni odporne na problemy zwiæzane z wydajnoħciæ. W tym rozdziale moľna wyróľniè piúè czúħci. W pierwszych trzech zebrano informacje podstawowe dotyczæce analizy dyskowych operacji wejħcia-wyjħcia, natomiast w dwóch kolejnych pokazano jej praktyczne zastosowanie w systemach Linux i Solaris. Oto poszczególne czúħci omawianego rozdziađu: 



Wprowadzenie. Prezentacja terminologii zwiæzanej z pamiúciæ masowæ, podstawowych modeli ilustrujæcych reguđy rzædzæce urzædzeniami dyskowymi oraz kluczowych koncepcji dotyczæcych wydajnoħci systemów plików. Architektura. Ogólne omówienie architektury sprzútowej i programowej urzædzeē pamiúci masowej. 445

446

Rozdział 9









Dyski

Metodologia. Przedstawienie metodologii w zakresie analizy wydajnoħci, opartej na obserwacji i eksperymentach. Analiza. Prezentacja narzúdzi analizy wydajnoħci dysków, eksperymenty w systemach Linux i Solaris. Omówione zostanæ miúdzy innymi monitorowanie i wizualizacje. Dostrajanie. Przykđady parametrów, które moľna dostrajaè dla dysków.

W poprzednim rozdziale zajmowaliħmy siú wydajnoħciæ systemów plików tworzonych na dyskach.

9.1. Terminologia Wymieniono w tym miejscu zwiæzanæ z dyskami terminologiú, która búdzie uľywana w niniejszym rozdziale: 



 











Dysk wirtualny. Emulacja urzædzenia pamiúci masowej. W systemie pojawia siú jako pojedynczy dysk fizyczny, choè moľe skđadaè siú z wielu dysków. Transport. Fizyczna szyna stosowana do komunikacji, miúdzy innymi transferu danych (operacje wejħcia-wyjħcia) i innych poleceē dyskowych. Sektor. Blok pamiúci masowej na dysku, tradycyjnie o wielkoħci 512 bajtów. Operacja wejħcia-wyjħcia. W przypadku dysków to sæ jedynie operacje odczytu i zapisu; nie obejmuje innych poleceē dyskowych. Operacja wejħcia-wyjħcia skđada siú co najmniej z kierunku (odczytu lub zapisu), adresu dyskowego (pođoľenia) i wielkoħci (wyraľonej w bajtach). Polecenia dyskowe. Poza poleceniami wykonania operacji odczytu i zapisu dyskom moľna wydaè polecenia przeznaczone do wykonywania zadaē innych niľ transfer danych, na przykđad opróľnienie bufora. Transfer. Dla dysku oznacza to bieľæcæ wielkoħè transferu danych, wyraľanæ w bajtach na sekundú. Przepustowoħè. Maksymalny moľliwy transfer danych dla kontrolera warstwy transportowej pamiúci masowej. Opóļnienie wejħcia-wyjħcia. Czas przeprowadzania operacji wejħcia-wyjħcia. Pojúcie uľywane powszechnie na poziomie stosu systemu operacyjnego, a nie na poziomie urzædzenia dyskowego. Pamiútaj, ľe w przypadku sieci omawiane wyraľenie jest uľywane w innym kontekħcie — opóļnienie odnosi siú tam do czasu inicjacji operacji wejħcia-wyjħcia, nastúpnie mamy czas transferu danych. Elementy odstajæce opóļnienia. Dyskowa operacja wejħcia-wyjħcia charakteryzujæca siú duľym opóļnieniem.

Inne pojúcia búdæ wprowadzane na bieľæco w tekħcie. Sđowniczek znajdujæcy siú na koēcu ksiæľki zawiera wyjaħnienie pewnych podstawowych terminów, miúdzy innymi: dysk, kontroler dysku, macierz pamiúci masowej, dyski lokalne, dyski zdalne i IOPS.

9.2. Modele

447

Warto zapoznaè siú takľe z podrozdziađami dotyczæcymi terminologii, przedstawionymi w rozdziađach 2. i 3.

9.2. Modele Przedstawione w tym podrozdziale proste modele ilustrujæ podstawowe reguđy dotyczæce wydajnoħci dyskowych operacji wejħcia-wyjħcia.

9.2.1. Prosty dysk Nowoczesne modele dysków zawierajæ wbudowanæ kolejkú dla ľædaē operacji wejħcia-wyjħcia, jak pokazano na rysunku 9.1.

Rysunek 9.1. Prosty dysk wraz z kolejką

Operacje wejħcia-wyjħcia akceptowane przez dysk mogæ oczekiwaè w kolejce lub byè wđaħnie realizowane. Pokazany prosty model jest podobny do kolejki do kasy (na przykđad w sklepie spoľywczym), gdzie obsđugiwani sæ klienci. Ponadto model ten doskonale nadaje siú do analizy za pomocæ teorii kolejek. Wprawdzie sugerowana jest kolejka typu „pierwszy na wejħciu, pierwszy obsđuľony”, ale kontroler znajdujæcy siú w dysku moľe zastosowaè inne algorytmy w celu optymalizacji wydajnoħci. Wspomniane algorytmy mogæ obejmowaè przeszukiwanie dysków (patrz punkt 9.4.1) lub oddzielne kolejki dla operacji odczytu i zapisu (zwđaszcza w dyskach zbudowanych na bazie pamiúci flash).

9.2.2. Pamięć podręczna dysku Pamiúè podrúczna dysku pozwala na obsđugú pewnych ľædaē za pomocæ szybkiej pamiúci — przedstawiono to na rysunku 9.2. Rozwiæzanie moľe byè zaimplementowane w postaci niewielkiej iloħci pamiúci DRAM, umieszczonej fizycznie w urzædzeniu dyskowym. Ľædania obsđugiwane przez pamiúè podrúcznæ charakteryzujæ siú mađym opóļnieniem. Z reguđy nadal búdæ wystúpowađy nietrafienia pamiúci podrúcznej, a wtedy tego rodzaju ľædanie oznacza duľe opóļnienie dyskowe.

448

Rozdział 9



Dyski

Rysunek 9.2. Prosty dysk wraz z pamięcią podręczną

Pamiúè podrúczna dysku moľe byè wykorzystana równieľ do poprawy wydajnoħci zapisu przez uľycie jej w charakterze pamiúci podrúcznej z buforowaniem zapisu. W takim przypadku po umieszczeniu w pamiúci podrúcznej danych przeznaczonych do zapisania operacja zapisu jest uznawana za zakoēczonæ, choè dane w rzeczywistoħci nie zostađy jeszcze trwale zapisane na dysku twardym. Pojúciem o przeciwnym znaczeniu jest pamiúè podrúczna bez buforowania zapisu — tutaj operacja zapisu jest uznawana za zakoēczonæ dopiero po peđnym przeniesieniu danych na nastúpny poziom.

9.2.3. Kontroler Na rysunku 9.3 pokazano prosty kontroler dysku đæczæcy szynú operacji wejħcia-wyjħcia z szynæ pamiúci masowej dla urzædzeē dyskowych. Kontroler pozwalajæcy na komunikacjú miúdzy wymienionymi szynami nosi nazwú HBA (ang. Host Bus Adapter).

Rysunek 9.3. Prosty kontroler dysku i łączone przez niego szyny

Wydajnoħè moľe byè ograniczona przez dowolnæ z wymienionych szyn, kontroler dysku lub same dyski. Wiúcej informacji dotyczæcych kontrolerów dysków znajdziesz w podrozdziale 9.4, zatytuđowanym „Architektura”.

9.3. Koncepcje

449

9.3. Koncepcje W niniejszym podrozdziale przedstawiono kilka najwaľniejszych koncepcji dotyczæcych wydajnoħci dysków.

9.3.1. Pomiar czasu W przypadku urzædzeē pamiúci masowej czas udzielenia odpowiedzi (nazywany równieľ opóļnieniem dyskowych operacji wejħcia-wyjħcia) to czas upđywajæcy od ropoczúcia do zakoēczenia operacji. Skđada siú z czasu obsđugi i czasu oczekiwania: 



Czas obsđugi. Czas, w którym operacja wejħcia-wyjħcia jest aktywnie przetwarzana (obsđugiwana). Nie zalicza siú do niego czasu oczekiwania w kolejce. Czas oczekiwania. Czas, przez który operacja wejħcia-wyjħcia czeka w kolejce na przetworzenie (obsđugú).

Cađoħè wraz z pozostađæ terminologiæ pokazano na rysunku 9.4.

Rysunek 9.4. Terminologia stosowana w dyskowych operacjach wejścia-wyjścia

Czasy udzielania odpowiedzi, obsđugi i oczekiwania zaleľæ od miejsca, od którego sæ mierzone. Poniľej znajdziesz objaħnienie czasu obsđugi w kontekħcie zarówno systemu operacyjnego, jak i dysku (definicje te sæ w pewnym stopniu uproszczone): 



W kontekħcie systemu operacyjnego (interfejs urzædzenia blokowego) czas obsđugi moľe byè zmierzony jako czas od chwili wydania urzædzeniu dyskowemu ľædania wykonania operacji wejħcia-wyjħcia do chwili wystæpienia przerwania wskazujæcego na zakoēczenie operacji. Do tego czasu nie zalicza siú czasu oczekiwania w kolejkach systemu operacyjnego — odzwierciedlana jest tylko ogólna wydajnoħè urzædzenia dyskowego dla ľædanej operacji. W kontekħcie dysków czas obsđugi to czas, przez który dysk aktywnie obsđugiwađ danæ operacjú wejħcia-wyjħcia. Do tego czasu nie zalicza siú czasu spúdzonego w kolejce znajdujæcej siú w dysku.

Wyraľenie czas obsđugi ma korzenie w przeszđoħci, gdy dyski byđy prostymi urzædzeniami zarzædzanymi bezpoħrednio przez system operacyjny, który doskonale wiedziađ, kiedy dysk aktywnie obsđugiwađ operacjú wejħcia-wyjħcia. Obecnie dyski sæ wyposaľone we wđasne kolejki, a liczony przez system operacyjny czas obsđugi obejmuje

450

Rozdział 9



Dyski

takľe czas spúdzony w kolejce znajdujæcej siú w urzædzeniu. Dlatego teľ metrykú systemu operacyjnego moľna trafniej opisaè jako „czas udzielania odpowiedzi przez dysk”. Wyraľenie czas udzielania odpowiedzi moľe byè stosowane z róľnych perspektyw. Na przykđad „czas udzielania odpowiedzi przez dysk” moľe oznaczaè czas obsđugi zarejestrowany z poziomu systemu operacyjnego, podczas gdy „czas udzielania odpowiedzi operacji wejħcia-wyjħcia” z perspektywy aplikacji moľe odwođywaè siú do wszystkiego, co znajduje siú poniľej warstwy wywođania systemowego (czasu obsđugi, wszystkich czasów oczekiwania i czasu wykonywania ħcieľki kodu). Czas obsđugi z perspektywy interfejsu urzædzenia blokowego jest, ogólnie rzecz bioræc, traktowany jako pomiar wydajnoħci dysku (i to wđaħnie pokazujæ dane wyjħciowe polecenia iostat). Trzeba mieè jednak ħwiadomoħè, ľe jest to pewne uproszczenie. Na rysunku 9.6 w dalszej czúħci rozdziađu pokazano ogólny stos operacji wejħcia-wyjħcia. Widzimy tam trzy moľliwe warstwy sterownika poniľej interfejsu urzædzenia blokowego. Kaľda z nich moľe implementowaè wđasnæ kolejkú, nakđadaè blokady muteksu i zwiúkszaè opóļnienie cađej operacji wejħcia-wyjħcia. Wspomniane opóļnienie jest zaliczane do czasu obsđugi mierzonego w interfejsie urzædzenia blokowego.

Obliczanie czasu System operacyjny zwykle nie ma moľliwoħci bezpoħredniego monitorowania czasu obsđugi dysku. Jednak ħredni czas obsđugi dysku moľna sprawdziè za pomocæ wartoħci IOPS i poziomu wykorzystania: czas obsïugi dysku = poziom wykorzystania/IOPS

Na przykđad jeľeli poziom wykorzystania wynosi 60%, a wartoħè IOPS 300, wówczas ħredni czas obsđugi to 2 ms (600 ms/300 IOPS). Przyjúto zađoľenie, ľe poziom wykorzystania odzwierciedla pojedyncze urzædzenie (lub centrum obsđugi), które moľe przetwarzaè jednoczeħnie tylko jednæ operacjú wejħcia-wyjħcia. Dyski z reguđy majæ moľliwoħè jednoczesnego przetwarzania wielu operacji wejħcia-wyjħcia.

9.3.2. Skale czasu Skala czasu dla dyskowych operacji wejħcia-wyjħcia moľe siú zmieniaè o rzúdy wielkoħci — od dziesiætych czúħci mikrosekund do tysiúcznych milisekund. Na najwolniejszym koēcu skali kiepski czas udzielania odpowiedzi przez aplikacjú moľe byè spowodowany przez pojedynczæ, wolnæ dyskowæ operacjú wejħcia-wyjħcia. Z kolei na najszybszym koēcu skali dyskowe operacje wejħcia-wyjħcia mogæ byè wykonywane jedynie w ogromnych iloħciach (suma wielu szybkich operacji wejħcia-wyjħcia jest równa powolnej operacji wejħcia-wyjħcia). W tabeli 9.1 w celu zapewnienia odpowiedniego kontekstu wymieniono ogólne, moľliwe zakresy opóļnienia dyskowych operacji wejħcia-wyjħcia. Jeľeli chcesz poznaè dokđadniejsze i bieľæce wartoħci, sprawdļ dokumentacjú dostarczanæ przez producenta urzædzenia oraz samodzielnie przeprowadļ mikrotesty wydajnoħci. Warto równieľ zajrzeè do rozdziađu 2. „Metodologia”, aby poznaè skale czasu inne niľ dyskowych operacji wejħcia-wyjħcia.

9.3. Koncepcje

451

Tabela 9.1. Przykłady skali czasu dla opóźnień dyskowych operacji wejścia-wyjścia Zdarzenie

Opóźnienie

Wartość przeskalowana

Trafienie pamięci podręcznej w dysku.

< 100 μs

1s

Odczyt z pamięci flash.

od ~100 μs do 1000 μs (od małej do dużej operacji wejścia-wyjścia)

od 1 s do 10 s

Sekwencyjny odczyt z dysku mechanicznego.

~1 ms

10 s

Losowy odczyt z dysku mechanicznego (7200 obr./min).

~8 ms

1,3 min

Losowy odczyt z dysku mechanicznego (wolny, kolejkowanie).

> 10 ms

1,7 min

Losowy odczyt z dysku mechanicznego (dziesiątki operacji w kolejce).

> 100 ms

17 min

Najgorsza sytuacja w przypadku operacji wejścia-wyjścia dla dysku wirtualnego (kontroler sprzętowy, RAID-5, kolejkowanie, losowe operacje wejścia-wyjścia).

> 1000 ms

2,8 godz.

Kolumna Wartoħè przeskalowana zawiera wartoħci w porównaniu do wynoszæcego 1 s wyimaginowanego opóļnienia trafnoħci pamiúci podrúcznej w dysku. Wymienione w tabeli 9.1 wartoħci opóļnienia moľna interpretowaè odmiennie, w zaleľnoħci od wymagaē ħrodowiska. W przypadku ħrodowiska biznesowego wszelkie dyskowe operacje wejħcia-wyjħcia trwajæce powyľej 10 ms uznajú za wolne, a przy tym za potencjalne ļródđo problemów zwiæzanych z wydajnoħciæ. Z kolei w ħrodowisku przetwarzania w chmurze istnieje nieco wiúksza tolerancja dla wyľszych wartoħci opóļnienia, zwđaszcza w przypadku aplikacji sieciowych, w których moľna siú spodziewaè wysokiego opóļnienia miúdzy sieciæ i przeglædarkæ internetowæ klienta. W tego rodzaju ħrodowiskach dyskowe operacje wejħcia-wyjħcia mogæ staè siú problemem, gdy búdæ trwađy dđuľej niľ 100 ms (indywidualny lub cađkowity czas w trakcie obsđugi ľædania aplikacji). Tabela pokazuje równieľ, ľe dysku mogæ dotyczyè dwa rodzaje opóļnienia: jedno w sytuacji trafienia pamiúci podrúcznej (wtedy jest mniejsze niľ 100 μs), a drugie w sytuacji nietrafienia pamiúci podrúcznej (1 – 8 ms i wiúcej, w zaleľnoħci od wzorca dostúpu i rodzaju urzædzenia). Poniewaľ podczas pracy z dyskiem mamy do czynienia z pođæczeniem obu rodzajów opóļnienia, ich đæczenie w postaci ħredniego opóļnienia (jak to robi polecenie iostat) moľe byè mylæce, poniewaľ rozkđad opóļnienia jest bimodalny. Na rysunku 2.22 w rozdziale 2. „Metodologia” pokazano przykđad rozkđadu opóļnienia dyskowych operacji wejħcia-wyjħcia — to histogram, wartoħci zostađy zmierzone za pomocæ narzúdzia DTrace.

452

Rozdział 9



Dyski

9.3.3. Buforowanie Najlepsza wydajnoħè dyskowej operacji wejħcia-wyjħcia jest wtedy, gdy w ogóle uda siú wyeliminowaè operacjú. Wiele warstw stosu oprogramowania próbuje zlikwidowaè koniecznoħè przeprowadzania operacji wejħcia-wyjħcia wskutek buforowania odczytów i zapisów w samym dysku. Peđnæ listú buforów znajdziesz w tabeli 3.2 w rozdziale 3. „Systemy operacyjne”. Wspomniana lista obejmuje bufory na poziomie aplikacji i systemu plików. Bufory dostúpne na poziomie sterownika urzædzenia dyskowego i na niľszych poziomach zostađy wymienione w tabeli 9.2. Tabela 9.2. Bufory dyskowych operacji wejścia-wyjścia Bufor

Przykład

bufor urządzenia

ZFS vdev

bufor bloku

podręczna pamięć buforowa

bufor kontrolera dysku

bufor karty RAID

bufor macierzy pamięci masowej

bufor macierzy

bufor w dysku

pamięć DRAM w dysku

Oparta na bloku podrúczna pamiúè buforowa zostađa omówiona w rozdziale 8. „Systemy plików”. Wymienione w tabeli bufory dyskowych operacji wejħcia-wyjħcia sæ szczególnie waľne, poniewaľ poprawiajæ wydajnoħè w trakcie losowych operacji wejħcia-wyjħcia.

9.3.4. Losowe kontra sekwencyjne operacje wejścia-wyjścia Obciæľenie w postaci dyskowych operacji wejħcia-wyjħcia moľna opisaè za pomocæ terminów losowe i sekwencyjne, w zaleľnoħci od wzglúdnego pođoľenia operacji wejħcia-wyjħcia na dysku (przesuniúcie). Wymienione terminy zostađy omówione w rozdziale 8., zatytuđowanym „Systemy plików”, przy okazji przedstawiania wzorców dostúpu do pliku. Obciæľenie sekwencyjne jest znane równieľ pod nazwæ obciæľenie strumieniowe. Pojúcie strumieniowe jest zwykle uľywane na poziomie aplikacji w celu opisania strumieniowania odczytu lub zapisu „na dysk” (system plików). Wzorce losowych kontra sekwencyjnych operacji wejħcia-wyjħcia byđy bardzo waľne do analizy w erze tradycyjnych mechanicznych dysków twardych. W ich przypadku losowa operacja wejħcia-wyjħcia jeszcze dodatkowo zwiúkszađa opóļnienie, poniewaľ gđowica dysku musiađa siú poruszaè, szukajæc miejsca pođoľenia danych, a talerz obracađ siú miúdzy kolejnymi operacjami wejħcia-wyjħcia. Takie rozwiæzanie pokazano na rysunku 9.5 — wyszukiwanie i obrót sæ niezbúdne, aby gđowica mogđa przechodziè miúdzy sektorami 1. i 2. (rzeczywista ħcieľka jest maksymalnie bezpoħrednia). W tym przypadku dostrajanie wydajnoħci polega na identyfikacji losowych operacji wejħcia-wyjħcia i podjúciu próby wyeliminowania ich na wiele róľnych sposobów, miúdzy innymi przez buforowanie, rozđoľenie losowych operacji wejħcia-wyjħcia na oddzielne dyski oraz zmianú uđoľenia danych na dysku, aby zmniejszyè odlegđoħci pokonywane przez gđowicú.

9.3. Koncepcje

453

Rysunek 9.5. Dysk z obracającym się talerzem

Inne rodzaje dysków, miúdzy innymi SSD, najczúħciej dziađajæ podobnie podczas wykonywania losowych i sekwencyjnych operacji wejħcia-wyjħcia. W zaleľnoħci od dysku mogæ wystúpowaè niewielkie róľnice ze wzglúdu na inne czynniki, na przykđad przeszukiwanie bufora adresów, który moľe zapewniaè dostúp sekwencyjny, ale nie losowy. Zwróè uwagú, ľe wartoħè przesuniúcia obserwowana przez system operacyjny nie musi odpowiadaè wartoħci na fizycznym dysku. Na przykđad sprzútowy dysk wirtualny moľe mapowaè na wielu dyskach ciægđy zakres przesuniúè. Dyski mogæ ponownie mapowaè przesuniúcia we wđasny sposób (za pomocæ kontrolera dysku). Czasami losowa operacja wejħcia-wyjħcia nie jest identyfikowana na skutek analizy wartoħci przesuniúcia, ale jej wystúpowanie moľna stwierdziè na podstawie zwiúkszonego czasu obsđugi.

9.3.5. Współczynnik odczyt/zapis Poza identyfikacjæ rodzaju operacji (losowa lub sekwencyjna) cechæ charakterystycznæ obciæľenia jest wspóđczynnik wyraľajæcy stosunek liczby operacji odczytu do liczby operacji zapisu, okreħlany mianem IOPS lub przepustowoħci. Wartoħè tú moľna wyraziè jako wartoħè procentowæ na przestrzeni czasu, na przykđad „od chwili uruchomienia odczyt stanowi 80% wykonanych operacji dyskowych”. Dokđadne poznanie omawianego wspóđczynnika okazuje siú pomocne podczas projektowania i konfigurowania systemów. System, w którym ogromna wiúkszoħè operacji dyskowych to odczyty, moľe dziađaè jeszcze wydajniej po dodaniu bufora. Z kolei jeľeli w systemie dominujæ operacje zapisu, lepszym rozwiæzaniem búdzie dodanie kolejnych dysków, poniewaľ to zwiúksza maksymalnæ dostúpnæ przepustowoħè i wartoħè IOPS. Operacje odczytu i zapisu mogæ mieè zupeđnie odmiennæ charakterystykú, na przykđad odczyty losowe, a zapisy sekwencyjne (zwđaszcza w systemach plików stosujæcych technikú kopiowania przy zapisie). Poza tym operacje wejħcia-wyjħcia dla odczytu i zapisu mogæ mieè róľne wielkoħci.

454

Rozdział 9



Dyski

9.3.6. Wielkość operacji wejścia-wyjścia Wyraľona w bajtach ħrednia wielkoħè operacji wejħcia-wyjħcia lub rozkđad wielkoħci operacji wejħcia-wyjħcia to inne cechy charakterystyczne obciæľenia. Wiúksze operacje wejħcia-wyjħcia z reguđy zapewniajæ wiúkszæ przepustowoħè, choè kosztem wiúkszego opóļnienia pojedynczej operacji wejħcia-wyjħcia. Wielkoħè operacji wejħcia-wyjħcia moľe byè zmieniona przez podsystem urzædzenia dyskowego (na przykđad dla 512-bajtowych bloków). Ponadto moľe ona ulec zmianie ze wzglúdu na fakt, ľe polecenie wykonania operacji wejħcia-wyjħcia zostađo wydane na poziomie aplikacji przez komponenty jædra, takie jak: system plików, menedľer woluminów i sterownik urzædzenia. Zapoznaj siú z punktem 8.3.12 w rozdziale 8., noszæcym tytuđ „Systemy plików”. Pewne urzædzenia dyskowe, zwđaszcza zbudowane na bazie pamiúci flash, charakteryzujæ siú róľnæ wydajnoħciæ dla poszczególnych wielkoħci operacji odczytu i zapisu. Tego rodzaju napúd moľe dziađaè optymalnie z operacjami odczytu o wielkoħci 4 KB i zapisu o wielkoħci 1 MB. Informacje o idealnej wielkoħci operacji wejħcia-wyjħcia moľna z reguđy znaleļè w dokumentacji dostarczanej przez producenta lub ustaliè dziúki przeprowadzeniu mikrotestów wydajnoħci. Aktualnæ wielkoħè operacji wejħcia-wyjħcia moľna okreħliè za pomocæ narzúdzi monitorowania (patrz podrozdziađ 9.6 „Analiza”).

9.3.7. Wartości IOPS nie są równe Wartoħci IOPS z powodu trzech ostatnio omówionych cech charakterystycznych nie sæ obliczane w taki sam sposób, a wiúc nie moľna ich bezpoħrednio porównywaè miúdzy róľnymi urzædzeniami i obciæľeniami. Sama wartoħè IOPS niewiele znaczy i nie moľe byè uľyta do wiarygodnego porównania obciæľenia. Na przykđad w mechanicznych dyskach twardych obciæľenie w postaci 5000 sekwencyjnych operacji wejħcia-wyjħcia na sekundú moľe byè znacznie szybsze niľ 1000 losowych IOPS. W przypadku napúdów zbudowanych na bazie pamiúci flash porównanie jest jeszcze trudniejsze, poniewaľ wydajnoħè zwykle jest powiæzana z kierunkiem (odczytem lub zapisem) i wielkoħciæ operacji wejħcia-wyjħcia. Aby porównanie wartoħci IOPS miađo sens, konieczne jest dođæczenie innych danych szczegóđowych: rodzaju operacji (losowe lub sekwencyjne), wielkoħci i kierunku. Warto takľe rozwaľyè uľycie metryk opartych na czasie, na przykđad poziomu wykorzystania i czasu usđugi, poniewaľ odzwierciedlajæ one rzeczywistæ wydajnoħè i mogæ byè đatwo porównywane.

9.3.8. Polecenie dyskowe niedotyczące transferu danych Oprócz poleceē inicjujæcych operacje odczytu i zapisu dyski mogæ otrzymywaè takľe inne polecenia. Na przykđad dysk majæcy pamiúè podrúcznæ (RAM) moľe otrzymaè polecenie jej opróľnienia i zapisu zawartoħci na dysku. Tego rodzaju polecenie nie jest transferem danych, zostađy one bowiem przekazane dyskowi wczeħniej, w trakcie operacji zapisu. Wymienione polecenia mogæ mieè wpđyw na wydajnoħè i wywođaè aktywnoħè dysku, z powodu której inne operacje wejħcia-wyjħcia búdæ oczekiwađy na wykonanie.

9.3. Koncepcje

455

9.3.9. Poziom wykorzystania Poziom wykorzystania moľna okreħliè jako czas, w którym dysk aktywnie wykonywađ zadania w badanym przedziale czasu. Dysk o poziomie wykorzystania wynoszæcym 0% jest „bezczynny”. Natomiast 100-procentowy poziom wykorzystania oznacza, ľe dysk jest nieustannie zajúty przeprowadzaniem operacji wejħcia-wyjħcia (i innych poleceē dyskowych). Dlatego teľ dyski o 100-procentowym poziomie wykorzystania sæ najczúħciej ļródđem problemów zwiæzanych z wydajnoħciæ, zwđaszcza jeħli poziom 100% utrzymuje siú przez pewien czas. Praktycznie jednak kaľdy poziom wykorzystania dysku moľe siú przekđadaè na gorszæ wydajnoħè, poniewaľ dyskowe operacje wejħcia-wyjħcia z reguđy sæ wolne. Miúdzy poziomami 0% i 100% moľe znajdowaè siú punkt (powiedzmy 60%), w którym wydajnoħè dysku nie búdzie dđuľej satysfakcjonujæca ze wzglúdu na wiúksze prawdopodobieēstwo wystæpienia kolejkowania w samym dysku bædļ w systemie operacyjnym. Dokđadna wartoħè poziomu wykorzystania, która moľe staè siú problemem, zaleľy od dysku, obciæľenia i wymagaē dotyczæcych opóļnienia. Zapoznaj siú z informacjami dotyczæcymi modelu M/D/1 i 60-procentowego poziomu wykorzystania przedstawionymi w punkcie 2.6.5, który znajdziesz w rozdziale 2. „Metodologia”. Aby sprawdziè, czy wysoki poziom wykorzystania powoduje problemy z aplikacjæ, przeanalizuj czas udzielania odpowiedzi przez dysk. Poza tym sprawdļ, czy aplikacja jest zablokowana przez wspomniane operacje wejħcia-wyjħcia. Aplikacja lub system operacyjny mogæ wykonywaè asynchroniczne operacje wejħcia-wyjħcia i tym samym wolne operacje wejħcia-wyjħcia nie búdæ bezpoħrednio wstrzymywađy dziađania aplikacji. Zwróè uwagú, ľe poziom wykorzystania jest podsumowaniem dotyczæcym pewnego przedziađu czasu. Dyskowe operacje wejħcia-wyjħcia mogæ pojawiaè siú falami, zwđaszcza podczas opróľniania bufora, co moľna przeoczyè, podsumowujæc dđuľsze przedziađy czasu. Wiúcej informacji na temat metryki w postaci poziomu wykorzystania zamieszczono w punkcie 2.3.11 w rozdziale 2. „Metodologia”.

Poziom użycia dysku wirtualnego W przypadku dysków wirtualnych dostarczanych przez sprzút (na przykđad kontroler dysku) system operacyjny moľe jedynie wiedzieè o zajútoħci takiego dysku wirtualnego, ale nic nie wie na temat wydajnoħci dysków, na podstawie których zostađ utworzony. Prowadzi to do sytuacji, w której zgđaszany przez system operacyjny poziom wykorzystania dysku wirtualnego znacznie róľni siú od stanu rzeczywistego w fizycznych dyskach (jest to sprzeczne z intuicjæ): 



Dyski wirtualne zawierajæce pamiúè podrúcznæ z buforowaniem zapisu mogæ wydawaè siú niezbyt obciæľone podczas operacji zapisu, poniewaľ kontroler dysku szybko koēczy operacjú, pomimo ľe dyski búdæ zajúte jeszcze przez pewien czas po jej zakoēczeniu. Dysk wirtualny wykorzystany w 100%, zbudowany na bazie kilku dysków fizycznych moľe byè w stanie akceptowaè kolejne zadania. Wspomniane 100% moľe oznaczaè, ľe niektóre dyski, nie wszystkie, byđy zajúte przez cađy czas, czyli niektóre byđy wolne.

456

Rozdział 9



Dyski

Z wymienionych powodów duľæ trudnoħè moľe sprawiaè interpretacja poziomu wykorzystania dysków wirtualnych utworzonych przez oprogramowanie systemu wirtualnego (programowæ macierz RAID). System operacyjny moľe jednak umoľliwiaè sprawdzanie poziomu wykorzystania dysków fizycznych i wtedy naleľy korzystaè z takiej opcji. Kiedy dysk fizyczny osiægnie 100% poziomu wykorzystania i pojawiæ siú ľædania kolejnych operacji wejħcia-wyjħcia, wtedy mamy do czynienia z nasyceniem.

9.3.10. Nasycenie Nasycenie to metryka kolejkowanych zadaē, które w danej chwili nie mogæ byè wykonane za pomocæ dostúpnych zasobów. W przypadku urzædzeē dyskowych nasycenie moľna okreħliè jako ħredniæ dđugoħè kolejki oczekiwania urzædzenia w systemie operacyjnym (przy zađoľeniu, ľe kolejkowanie wystúpuje). W ten sposób zyskujemy moľliwoħè pomiaru wydajnoħci po przekroczeniu 100% poziomu wykorzystania. W przypadku dysku 100-procentowy poziom wykorzystania nie musi oznaczaè nasycenia (kolejkowania), lecz wrúcz przeciwnie — moľe znaczæco wpđywaè na wydajnoħè ze wzglúdu na kolejkowanie operacji wejħcia-wyjħcia. Moľe siú wydawaè, ľe jeħli poziom wykorzystania dysku nie przekracza 100%, to nie mamy do czynienia z nasyceniem. Zaleľy to jednak od przedziađu czasu, w którym mierzony jest poziom wykorzystania. Poziom wykorzystania dysku wynoszæcy 50% moľe oznaczaè, ľe przez pođowú czasu dysk jest wykorzystany w 100%, natomiast przez pozostađæ pođowú czasu pozostaje bezczynny. Podobne problemy mogæ dotyczyè kaľdego podsumowania przedziađu czasu. W sytuacji gdy waľne jest dokđadne ustalenie, co siú zdarzyđo, do przeanalizowania zdarzeē wejħcia-wyjħcia naleľy zastosowaè monitorowanie.

9.3.11. Oczekiwanie na zakończenie operacji wejścia-wyjścia Oczekiwanie na zakoēczenie operacji wejħcia-wyjħcia to metryka wydajnoħci okreħlana dla procesora, oznaczajæca czas jego bezczynnoħci, podczas gdy w kolejce znajdujæ siú inne wætki (uħpione), zablokowane przez dyskowe operacje wejħcia-wyjħcia. W ten sposób czas bezczynnoħci procesora jest dzielony na zupeđny brak aktywnoħci i czas spúdzony na oczekiwaniu zakoēczenia operacji wejħcia-wyjħcia. Im wyľszy wskaļnik oczekiwania przez procesor na zakoēczenie operacji wejħcia-wyjħcia, tym wiúksze prawdopodobieēstwo, ľe dyski mogæ byè wæskim gardđem, a procesor búdzie musiađ czekaè, aľ zakoēczæ wykonywanie zadaē. Oczekiwanie na zakoēczenie operacji wejħcia-wyjħcia to metryka, której wartoħè moľe byè mylæca. Jeľeli w systemie pojawi siú inny proces bardzo obciæľajæcy procesor, to wartoħè omawianej metryki moľe spaħè: procesor ma do wykonania inne zadanie i nie musi bezczynnie czekaè na zakoēczenie operacji wejħcia-wyjħcia. Wspomniana operacja dyskowa jednak nadal jest wykonywana i blokuje wætek pomimo zmniejszenia wartoħci metryki. Odwrotna sytuacja czasami zdarza siú wtedy, gdy administrator systemu uaktualni oprogramowanie, a nowa wersja okazuje siú znacznie efektywniejsza i uľywa mniejszej liczby cykli procesora, ujawniajæc tym samym koniecznoħè oczeki-

9.3. Koncepcje

457

wania na zakoēczenie operacji wejħcia-wyjħcia. Administrator moľe sædziè, ľe uaktualnienie doprowadziđo do powstania problemu z dyskiem i pogorszenia wydajnoħci, choè w rzeczywistoħci wydajnoħè dysku pozostaje bez zmian, a poprawiđa siú jedynie wydajnoħè procesora. Istniejæ pewne subtelne róľnice w sposobie obliczania omawianej metryki w systemie Solaris. W 10. wydaniu systemu Solaris metryka oczekiwania na zakoēczenie operacji wejħcia-wyjħcia zostađa uznana za przestarzađæ i na stađe przypisano jej wartoħè 0 wyħwietlanæ przez narzúdzia, które nadal muszæ podawaè jej wartoħè (w celu zachowania wstecznej zgodnoħci). Znacznie bardziej wiarygodnæ metrykæ moľe byè czas, w którym wætki aplikacji sæ zablokowane przez dyskowe operacje wejħcia-wyjħcia. W ten sposób moľna okreħliè utrudnienia napotykane przez wætki aplikacji, powodowane przez dyskowe operacje wejħcia-wyjħcia, niezaleľnie od innych zadaē, jakie mogæ byè wykonywane przez procesor. Wartoħè tej metryki moľna ustaliè za pomocæ monitorowania statycznego lub dynamicznego. Oczekiwanie na zakoēczenie operacji wejħcia-wyjħcia to nadal bardzo popularna metryka w systemach Linux, pomimo ľe jej wartoħè moľe byè mylæca. Metryka ta jest z powodzeniem stosowana do identyfikacji pewnych rodzajów wæskich gardeđ zwiæzanych z dyskami, na przykđad w sytuacjach, gdy dyski sæ zajúte, a procesory bezczynne. Jednym ze sposobów jej interpretacji jest potraktowanie jakiegokolwiek oczekiwania na zakoēczenie operacji wejħcia-wyjħcia jako sygnađu wskazujæcego na istnienie wæskiego gardđa w systemie, a nastúpnie dostrojenie systemu w celu minimalizacji problemu, nawet jeħli operacje wejħcia-wyjħcia wciæľ wystúpujæ równoczeħnie z wykorzystaniem procesora. Wspóđbieľne operacje wejħcia-wyjħcia zwykle búdæ nieblokujæce i prawdopodobnie nie sæ bezpoħredniæ przyczynæ problemów. To niewspóđbieľne operacje wejħcia-wyjħcia búdæ prawdopodobnie blokujæcymi aplikacjú, a tym samym stanowiæcymi wæskie gardđo.

9.3.12. Operacje synchroniczne kontra asynchroniczne Trzeba koniecznie mieè ħwiadomoħè, ľe opóļnienie zwiæzane z dyskowymi operacjami wejħcia-wyjħcia nie musi bezpoħrednio przekđadaè siú na wydajnoħè aplikacji, jeħli wspomniane operacje sæ przeprowadzane asynchronicznie. Tego rodzaju sytuacja najczúħciej zdarza siú w przypadku istnienia pamiúci podrúcznej z buforowaniem zapisu — operacja wejħcia-wyjħcia aplikacji koēczy siú szybko, natomiast dyskowa jest wykonywana nieco póļniej. W celu przeprowadzania asynchronicznych operacji odczytu aplikacje mogæ uľywaè mechanizmu odczytu z wyprzedzeniem. Wówczas w trakcie dyskowej operacji wejħcia-wyjħcia aplikacja nie jest blokowana. System plików moľe sam zainicjowaè takie rozwiæzanie, aby rozgrzaè bufor (mechanizm prefetch). Nawet jeħli aplikacja wykonuje synchroniczne operacje wejħcia-wyjħcia i musi czekaè na ich zakoēczenie, ħcieľka kodu aplikacji nie musi mieè znaczenia krytycznego i moľe byè asynchroniczna wzglúdem ľædaē klienta aplikacji. Wiúcej informacji na ten temat znajdziesz w punktach 8.3.4, 8.3.5, 8.3.7 i 8.3.9 w rozdziale 8., noszæcym tytuđ „Systemy plików”.

458

Rozdział 9



Dyski

9.3.13. Dyskowe kontra aplikacji operacje wejścia-wyjścia Dyskowe operacje wejħcia-wyjħcia sæ wynikiem dziađania róľnych komponentów jædra, miúdzy innymi systemów plików i sterowników urzædzeē dyskowych. Istnieje wiele powodów, dla których czústotliwoħè i wielkoħè wspomnianych operacji moľe nie odpowiadaè operacjom wejħcia-wyjħcia wydawanym przez aplikacjú, na przykđad: 





zjawisko zwiúkszenia lub zmniejszenia operacji wejħcia-wyjħcia, ewentualnie wystæpienie niepowiæzanej operacji wejħcia-wyjħcia (zapoznaj siú z punktem 8.3.12 w rozdziale 8. „Systemy plików”); stronicowanie ze wzglúdu na mađæ iloħè wolnej pamiúci (zapoznaj siú z punktem 7.2.2 w rozdziale 7. „Pamiúè”); wielkoħè operacji wejħcia-wyjħcia sterownika napúdu dyskowego: zaokræglenie wartoħci w górú lub fragmentacja operacji wejħcia-wyjħcia.

Wspomniane niedopasowanie moľe byè mylæce, jeħli siú go nie spodziewasz. Niedopasowanie moľna poznaè dziúki analizie architektury i wydajnoħci.

9.4. Architektura W tym podrozdziale zostanie omówiona architektura dysku, któræ najczúħciej analizuje siú podczas planowania pojemnoħci. Analiza ma na celu ustalenie ograniczeē róľnych komponentów i konfiguracji. Powinna byè przeprowadzana równieľ w trakcie póļniejszego studiowania problemów z wydajnoħciæ, na wypadek gdyby problemy byđy zwiæzane z dokonanymi wczeħniej wyborami w zakresie architektury, a nie z bieľæcym obciæľeniem i dostrojeniem.

9.4.1. Rodzaje dysków Obecnie dwa najczúħciej spotykane rodzaje dysków to mechaniczne dyski twarde z obracajæcym siú talerzem magnetycznym oraz napúdy SSD, zbudowane na bazie pamiúci flash. Oba rodzaje dysków zapewniajæ moľliwoħè trwađego przechowywania danych. W przeciwieēstwie do pamiúci ulotnej ich zawartoħè zostaje zachowana po zaniku zasilania.

Dysk z obracającym się talerzem magnetycznym Ten rodzaj dysku, okreħlany mianem napúdu dysku twardego (ang. Hard Disk Drive, HDD), skđada siú z jednego lub wiúcej tak zwanych talerzy zaimpregnowanych czæsteczkami tlenku ľelaza. Bardzo mađy obszar wspomnianych czæsteczek moľe byè namagnetyzowany w jednym z dwóch kierunków; to rozwiæzanie jest stosowane do przechowywania bitu. Talerze obracajæ siú — mechaniczne ramiú zawiera ukđad elektroniczny odpowiedzialny za odczyt i zapis danych na powierzchni talerzy. Wspomniany ukđad to przede wszystkim gđowice, których moľe byè wiúcej niľ jedna,

9.4. Architektura

459

poniewaľ wtedy istnieje moľliwoħè jednoczesnego odczytu lub zapisu wielu bitów. Na talerzu dane sæ przechowywane na ħcieľkach podzielonych na sektory. Poniewaľ dysk twardy jest urzædzeniem mechanicznym, jego dziađanie jest stosunkowo wolne. Dziúki zastosowaniu zaawansowanej technologii napúdy SSD powoli wypierajæ tradycyjne dyski twarde. Nie ma wætpliwoħci, ľe pewnego dnia dyski twarde stanæ siú zbúdne (podobnie jak pamiúè búbnowa). Obecnie mechaniczne dyski twarde nadal sæ konkurencyjne w niektórych zastosowaniach, na przykđad jako ekonomiczny (niski koszt jednego megabajta) noħnik umoľliwiajæcy przechowywanie duľej iloħci danych. W kolejnych fragmentach ksiæľki podsumowano czynniki majæce wpđyw na wydajnoħè mechanicznych dysków twardych.

Wyszukiwanie i rotacja Wolne operacje wejħcia-wyjħcia w dyskach z obracajæcym siú talerzem magnetycznym sæ bardzo czústo skutkiem czasu wyszukiwania lokalizacji przez gđowice dysku oraz czasu obrotu talerza. Oba wymienione czasy mogæ zabieraè nawet milisekundy. W najlepszej sytuacji kolejna ľædana operacja wejħcia-wyjħcia búdzie zaczynađa siú w miejscu zakoēczenia aktualnej, aby gđowice dysku nie musiađy wyszukiwaè lokalizacji lub oczekiwaè na obrót talerza. Jak wczeħniej wspomniano, ten rodzaj operacji nosi nazwú sekwencyjnych operacji wejħcia-wyjħcia. Jeľeli operacja wymaga wyszukiwania lokalizacji przez gđowice lub oczekiwania na obrót talerza, to wówczas mówimy o losowej operacji wejħcia-wyjħcia. Istnieje wiele strategii umoľliwiajæcych skrócenie czasu wyszukiwania i oczekiwania na obrót. Oto niektóre z nich:  





buforowanie, powodujæce cađkowitæ eliminacjæ operacji wejħcia-wyjħcia; sposób zachowania i umieszczania danych przez system operacyjny (obejmuje miúdzy innymi technikú kopiowania przy zapisie); rozdzielenie obciæľeē miúdzy róľne dyski w celu unikniúcia wyszukiwania miúdzy poszczególnymi operacjami wejħcia-wyjħcia; przeniesienie odmiennych obciæľeē do róľnych systemów (takie rozwiæzanie jest stosowane w niektórych ħrodowiskach przetwarzania w chmurze, aby zmniejszyè efekt zwiæzany z istnieniem wielu tenantów);



wyszukiwanie cylindryczne przeprowadzane przez sam dysk;



stosowanie dysków o wyľszej gústoħci, aby dane byđy uđoľone jeszcze bliľej siebie;



partycjonowanie dysku, na przykđad zastosowanie techniki short stroking.

Dodatkowa strategia majæca na celu skrócenie czasu oczekiwania na obrót jest stosowana jedynie w szybszych dyskach. Talerze w mechanicznych dyskach twardych obracajæ siú z róľnymi szybkoħciami, miúdzy innymi: 5400, 7200, 10 000 (10k) i 15 000 (15k) obrotów na minutú (ang. Revolutions Per Minute, RPM).

460

Rozdział 9



Dyski

Teoretyczna przepustowość maksymalna Jeľeli znana jest maksymalna liczba sektorów na ħcieľce, to maksymalnæ przepustowoħè dysku moľna obliczyè za pomocæ poniľszego wzoru: maksymalna przepustowoĂÊ = maksymalna liczba sektorów na Ăcieĝce*wielkoĂÊ sektora*RPM/60

Powyľszy wzór byđ znacznie bardziej uľyteczny dla starszych modeli dysków, które podawađy dokđadne informacje o liczbie sektorów na ħcieľce. Nowoczesne dyski dostarczajæ systemom operacyjnym wirtualnych obrazów dysków i udostúpniajæ syntetyczne wartoħci wspomnianych atrybutów.

Technika short stroking Technika short stroking polega na wykorzystaniu jedynie zewnútrznych ħcieľek na dysku do obsđugi obciæľenia. Pozostađa czúħè dysku jest niewykorzystana lub uľywana dla obciæľenia niewymagajæcego duľej przepustowoħci (na przykđad dla archiwizacji). W ten sposób skraca siú czas wyszukiwania, poniewaľ gđowica porusza siú w mniejszym zakresie. Dysk moľe umieħciè gđowice na zewnútrznej granicy zakresu i tym samym skróciè czas pierwszego wyszukiwania po bezczynnoħci. Zewnútrzne ħcieľki najczúħciej charakteryzujæ siú lepszæ przepustowoħciæ ze wzglúdu na strefowanie sektorów (patrz nastúpny fragment). Pamiútaj o technice short stroking podczas analizowania opublikowanych testów wydajnoħci dysków, zwđaszcza jeħli nie zostađa podana cena i moľna byđo uľyè wielu dysków wraz z technikæ short stroking.

Strefowanie sektorów Dđugoħè ħcieľki na dysku jest zmienna, najkrótsze ħcieľki znajdujæ siú w centrum dysku, natomiast najdđuľsze na jego obrzeľach. Dlatego teľ liczba sektorów (i bitów) na ħcieľce nie jest stađa i stosowane jest strefowanie sektorów (nazywane równieľ multizone recording), które zwiúksza liczbú sektorów na dđuľszych ħcieľkach, poniewaľ moľna na nich fizycznie zapisaè wiúcej sektorów. Niemniej szybkoħè obrotu jest stađa i dlatego dđuľsze ħcieľki znajdujæce siú na zewnútrz talerza zapewniajæ wiúkszæ przepustowoħè (wyraľanæ w megabajtach na sekundú) niľ wewnútrzne.

Wielkość sektora W przemyħle pamiúci masowej opracowano nowy standard dla urzædzeē dyskowych, nazywany Advanced Format, który pozwala na obsđugú wiúkszych sektorów, przede wszystkim o wielkoħci 4 KB. W ten sposób zmniejszane jest obciæľenie zwiæzane z metadanymi przechowywanymi dla kaľdego sektora dysku. Sektory o wielkoħci 512 B nadal mogæ byè obsđugiwane przez oprogramowanie (firmware) dysku dziúki standardowi emulacji o nazwie Advanced Format 512e. W zaleľnoħci od dysku moľe to spowodowaè zwiúkszenie obciæľenia zwiæzanego z zapisem i wywođaè cykl odczyt-modyfikacja-zapis w celu mapowania 512 B na sektor o wielkoħci 4 KB. Inne problemy z wydajnoħciæ, których istnienia trzeba mieè ħwiadomoħè, to bđúdne uđoľenie operacji wejħcia-wyjħcia o wielkoħci 4 KB — na dwóch sektorach, co zwiúksza operacjú wejħcia-wyjħcia odpowiedzialnæ za ich obsđugú.

9.4. Architektura

461

Pamięć podręczna w dysku Powszechnie stosowanym komponentem w mechanicznych dyskach twardych jest mađa iloħè pamiúci RAM przeznaczonej do buforowania operacji odczytu i zapisu. Pamiúè ta umoľliwia równieľ kolejkowanie w urzædzeniu operacji wejħcia-wyjħcia (poleceē) i zmianú ich kolejnoħci na znacznie efektywniejszæ. W przypadku napúdów SCSI nosi to nazwú TCQ (ang. Tagged Command Queueing), natomiast w napúdach SATA — NCQ (ang. Native Command Queueing).

Wyszukiwanie cylindryczne Algorytm o nazwie elevator algorithm (znany równieľ jako wyszukiwanie cylindryczne) to jeden ze sposobów kolejkowania poleceē, wpđywajæcy na poprawú wydajnoħci. Kolejnoħè operacji wejħcia-wyjħcia zostaje zmieniona na podstawie pođoľenia danych na dysku, co ma zminimalizowaè poruszanie gđowicami dysku. Wynik przypomina dziađanie w budynku windy, która nie obsđuguje poszczególnych piúter zgodnie z kolejnoħciæ naciħniúcia przycisków wskazujæcych piútra, ale porusza siú w górú i dóđ, zatrzymujæc siú na kolejnych ľædanych piútrach. Takie zachowanie moľna zaobserwowaè po przeanalizowaniu stosu dyskowych operacji wejħcia-wyjħcia — przekonasz siú wówczas, ľe jeħli posortujesz je wedđug czasu zakoēczenia operacji, kolejnoħè nie búdzie odpowiadađa operacjom posortowanym zgodnie z czasem rozpoczúcia operacji. Wprawdzie przedstawione rozwiæzanie wydaje siú korzystne z punktu widzenia wydajnoħci, jednak rozwaľ nastúpujæcy przykđad. Dysk otrzymuje seriú ľædaē operacji wejħcia-wyjħcia dotyczæcych danych znajdujæcych siú w pođoľeniu okođo 1000 i jednæ operacjú dla danych w pođoľeniu okođo 2000. Gđowice dysku aktualnie znajdujæ siú w pođoľeniu 1000. Kiedy zostanæ odczytane dane w pođoľeniu 2000? A teraz rozwaľ kolejny przykđad. Podczas obsđugi operacji wejħcia-wyjħcia dla danych znajdujæcych siú w pođoľeniu okođo 1000 pojawia siú bardzo duľo ľædaē danych w pobliskim pođoľeniu. Operacji jest tak duľo, ľe dysk búdzie zajúty ich przetwarzaniem przez okođo 10 sekund. Kiedy zostanæ wreszcie odczytane dane w pođoľeniu 2000 i jaka búdzie ostateczna wartoħè opóļnienia operacji wejħcia-wyjħcia?

ECC Na koēcu kaľdego sektora dyski przechowujæ kod ECC, aby napúd mógđ sprawdziè, czy dane zostađy prawidđowo odczytane, po czym ewentualnie skorygowaè pewne bđúdy. Jeľeli sektor nie zostanie odczytany prawidđowo, gđowice dysku muszæ go odczytaè ponownie podczas kolejnego obrotu (taka sytuacja moľe siú powtórzyè wielokrotnie, w tym czasie pođoľenie gđowicy moľe ulec drobnej zmianie). Trzeba o tym koniecznie pamiútaè w kontekħcie wydajnoħci jako o moľliwym wyjaħnieniu nietypowo wolnych operacji wejħcia-wyjħcia. Potwierdzenie znajdziesz, przeprowadzajæc analizú liczników bđúdów dysku i systemu operacyjnego.

Wibracje Producenci napúdów dysków doskonale zdajæ sobie sprawú z istnienia problemów zwiæzanych z drganiem, choè nie sæ one zbyt dobrze znane oraz traktowane powaľnie przez przemysđ. W 2008 roku zajmowađem siú dziwnym problemem zwiæzanym

462

Rozdział 9



Dyski

z wydajnoħciæ. Zdecydowađem siú wówczas przeprowadziè eksperyment z wibracjami i krzyknæđem na macierz dysków w trakcie trwania testu wydajnoħci zapisu. To spowodowađo seriú bardzo wolnych operacji wejħcia-wyjħcia. Mój eksperyment zarejestrowano, a film umieszczono w serwisie YouTube, gdzie zdobyđ popularnoħè i zostađ okreħlony mianem pierwszej demonstracji wpđywu wibracji na wydajnoħè dysku (patrz odwođanie [Turner 10] na koēcu rozdziađu). Wideo obejrzano ponad 900 000 razy, co stanowiđo promocjú problemów zwiæzanych z drganiem dysku (patrz odwođanie [1] na koēcu rozdziađu). Na podstawie otrzymanych wiadomoħci e-mail mogú stwierdziè, ľe przypadkiem przyczyniđem siú do utworzenia nowego stanowiska pracy w centrach danych: obecnie moľna zatrudniè profesjonalistów, którzy analizujæ poziom dļwiúku w centrum danych i poprawiajæ wydajnoħè dysków na skutek eliminacji drgaē.

Sloth Disk Obecne problemy wydajnoħci zwiæzane z niektórymi dyskami mechanicznymi to odkrycie czegoħ, co nazywamy sloth disks. Tego rodzaju dyski czasami wykonujæ bardzo wolne, trwajæce ponad sekundú operacje wejħcia-wyjħcia, nie zgđaszajæc przy tym ľadnych bđúdów. W rzeczywistoħci byđoby lepiej, gdyby dysk zgđosiđ bđæd, zamiast tak dđugo wykonywaè pojedynczæ operacjú. W przypadku bđúdu bowiem system operacyjny lub kontroler dysku mogæ podjæè odpowiednie dziađanie, na przykđad wyđæczyè dysk i zgđosiè jego awariú. Dyski typu sloth disks sæ utrapieniem, zwđaszcza gdy stanowiæ czúħè dysku wirtualnego udostúpnianego przez macierz pamiúci podrúcznej. W takim przypadku system operacyjny nie ma do nich bezpoħredniego wglædu, co utrudnia identyfikacjú sloth disks.

Kontroler danych dysku Dyski mechaniczne udostúpniajæ systemowi prosty kontroler, narzucajæc stađy wspóđczynnik okreħlajæcy liczbú sektorów na ħcieľce oraz ciægđy zakres adresowanych wartoħci przesuniúè. To, co rzeczywiħcie dzieje siú w dysku, zaleľy od kontrolera danych dysku — wewnútrznego mikroprocesora dysku zaprogramowanego przez firmware. Sposób uđoľenia adresowanych wartoħci przesuniúè zaleľy od dysku, który moľe implementowaè algorytmy, takie jak strefowanie sektorów. Trzeba mieè tego ħwiadomoħè, choè przeanalizowanie moľe byè trudne, poniewaľ system operacyjny nie ma dostúpu do kontrolera danych dysku.

Solid State Drive Napúdy SSD zawdziúczajæ swojæ nazwú uľyciu komponentów elektronicznych o stađym stanie. Dane sæ przechowywane w postaci programowanej, nieulotnej pamiúci, która najczúħciej oferuje znacznie lepszæ wydajnoħè niľ w dyskach mechanicznych wyposaľonych w obracajæce siú talerze. Pozbawione poruszajæcych siú elementów dyski SSD sæ równieľ fizycznie znacznie trwalsze i niepodatne na problemy z wydajnoħciæ powodowane przez drgania. Wydajnoħè dysku SSD jest zwykle stađa niezaleľnie od miejsca pođoľenia danych (brak opóļnienia zwiæzanego z obrotem lub wyszukiwaniem) i przewidywalna dla danych wielkoħci operacji wejħcia-wyjħcia. Rodzaje operacji (losowe lub sekwencyjne) majæ

9.4. Architektura

463

mniejsze znaczenie niľ w tradycyjnych dyskach twardych. To wszystko powoduje, ľe znacznie đatwiej je analizowaè i uľywaè do planowania pojemnoħci. Jednak jeľeli w napúdzie SSD wystæpiæ patologie dotyczæce wydajnoħci, poznanie ich moľe byè równie skomplikowane jak w przypadku dysków mechanicznych, co wynika ze sposobu ich wewnútrznego dziađania. Niektóre napúdy SSD uľywajæ nieulotnej pamiúci DRAM (NV-DRAM), natomiast wiúkszoħè — pamiúci flash.

Pamięć flash Zbudowane na bazie pamiúci flash napúdy SSD to rodzaj pamiúci masowej oferujæcej wysokæ wydajnoħè operacji odczytu (zwđaszcza losowych), która o wiele rzúdów wielkoħci przekracza wydajnoħè w tym zakresie tradycyjnych dysków twardych. Wiúkszoħè pamiúci flash jest budowana na bazie pamiúci flash typu NAND, która wykorzystuje uľywajæcy elektronów noħnik potrafiæcy trwale przechowywaè je w sytuacji, gdy zanika zasilanie (patrz odwođanie [Cornwell 12] na koēcu rozdziađu). Nazwa flash wziúđa siú od sposobu zapisu danych. Zwykle wymaga on wymazania cađego bloku pamiúci (czústo wielu stron, najczúħciej 8 KB na stronú) i ponownego zapisu zawartoħci. Z powodu tego rodzaju obciæľenia podczas zapisu pamiúè flash charakteryzuje siú asymetrycznæ wydajnoħciæ odczytu i zapisu, czyli szybkim odczytem i wolniejszym zapisem. Pamiúè flash jest dostúpna w róľnych rodzajach. SLC (ang. Single Level Cell) przechowuje dane w pojedynczych komórkach, natomiast MLC (ang. Multi Level Cell) moľe przechowywaè wiele bitów w komórce (najczúħciej dwa, co wymaga czterech stanów napiúcia). Istnieje jeszcze TLC (ang. Tri Level Cell), umoľliwiajæcy przechowywanie trzech bitów (osiem poziomów napiúcia). MLC w porównaniu do SLC charakteryzuje siú wiúkszæ wydajnoħciæ i jest rozwiæzaniem preferowanym w ħrodowisku biznesowym, choè wiæľe siú z wiúkszym kosztem. Istnieje takľe eMLC, czyli MLC z zaawansowanym oprogramowaniem (firmware’em) przeznaczonym do uľycia w ħrodowisku biznesowym.

Kontroler Kontroler w napúdzie SSD ma nastúpujæce zadania (patrz odwođanie [Leventhal 13] na koēcu rozdziađu): 



obsđuga danych wejħciowych — operacje odczytu i zapisu przeprowadzane dla strony (najczúħciej 8 KB); zapis tylko dla wymazanych stron, a strony sæ wymazywane w blokach o wielkoħci od 32 do 64 (od 256 KB do 512 KB); obsđuga danych wyjħciowych — emulacja interfejsu bloku dysku twardego, odczyt lub zapis dowolnych sektorów (512 B lub 4 KB).

Translacja danych wejħciowych na dane wyjħciowe odbywa siú za pomocæ warstwy FTL (ang. Flash Translation Layer) kontrolera, który musi równieľ monitorowaè wolne bloki. W tym celu praktycznie uľywa wđasnego systemu plików, na przykđad o strukturze dziennika zdarzeē.

464

Rozdział 9



Dyski

Charakterystyka zapisu moľe byè problemem przy obciæľeniu zwiæzanym z operacjami zapisu, zwđaszcza jeħli wielkoħè operacji wejħcia-wyjħcia jest mniejsza od wielkoħci bloku pamiúci flash (ten moľe osiægnæè 512 KB). To powoduje powstanie tzw. write amplification, w którym pozostađa czúħè bloku jest kopiowana w inne miejsce przed usuniúciem, a opóļnienie wynosi co najmniej cykl wymazanie-zapis. Niektóre rodzaje napúdów opartych na pamiúci flash niwelujæ wspomniane opóļnienie dziúki wbudowanej, podtrzymywanej przez baterie, pamiúci podrúcznej w postaci pamiúci RAM. W takim przypadku operacje zapisu mogæ byè buforowane i przeprowadzane póļniej, nawet jeħli nastæpi awaria zasilania. Przekonađem siú, ľe najczúħciej spotykane, oparte na pamiúci flash napúdy klasy biznesowej dziađajæ optymalnie z operacjami odczytu o wielkoħci 4 KB i zapisu o wielkoħci 1 MB, co wynika z ukđadu pamiúci. Wymienione wartoħci mogæ siú róľniè w poszczególnych napúdach — dokđadne moľesz ustaliè to za pomocæ mikrotestów wydajnoħci operacji wejħcia-wyjħcia o róľnych wielkoħciach. Bioræc pod uwagú rozbieľnoħè miúdzy rodzimymi operacjami pamiúci flash a udostúpnianym interfejsem blokowym, moľna przyjæè, ľe istnieje moľliwoħè wprowadzania usprawnieē zarówno przez system operacyjny, jak i przez jego systemy plików. Przykđadem jest polecenie TRIM. Jego wykonanie informuje napúd SSD, ľe region nie jest juľ uľywany, co pozwala na đatwiejsze przypisanie wskazanego regionu do puli wolnych bloków. (W przypadku SCSI moľna to zaimplementowaè za pomocæ poleceē UNMAP lub WRITE SAME, natomiast w napúdach ATA za pomocæ polecenia DATA SET MANAGEMENT).

Trwałość Wystúpujæ róľne problemy z pamiúciæ NAND flash jako medium, miúdzy innymi wyczerpanie i zakđócenie odczytu (patrz odwođanie [Cornwell 12] na koēcu rozdziađu). Problemy moľna rozwiæzaè za pomocæ kontrolera SSD, który moľe przenosiè dane. Z reguđy oznacza to wystæpienie zjawiska wear leveling, czyli rozproszenia danych miúdzy róľnymi blokami w celu zmniejszenia cykli zapisu poszczególnych bloków. Ponadto istnieje nadmiarowa iloħè komponentów pamiúci (ang. memory overprovisionig), czyli zarezerwowanie pewnej dodatkowej iloħci pamiúci, któræ moľna mapowaè, jeħli búdzie potrzeba. Wprawdzie wymienione techniki wydđuľajæ ľywotnoħè napúdu SSD, ale mimo wszystko nadal ma on ograniczonæ liczbú cykli zapisu dla bloku, zaleľnæ od rodzaju pamiúci flash i funkcji wbudowanych w urzædzeniu. Napúdy klasy biznesowej stosujæ wspomnianæ nadmiarowoħè komponentów pamiúci i bardziej niezawodne rodzaje pamiúci flash (SLC), aby osiægnæè co najmniej milion cykli zapisu. Z kolei napúdy konsumenckie zbudowane na bazie pamiúci MLC mogæ mieè trwađoħè wynoszæcæ jedynie 1000 cykli zapisu.

Patologie Poniľej wymieniono pewne patologie zwiæzane z pamiúciæ flash stosowanæ w napúdach SSD; warto o nich wiedzieè:

9.4. Architektura







465

elementy odstajæce, charakteryzujæce siú duľym opóļnieniem ze wzglúdu na starzenie siú napúdu, któremu coraz trudniej prawidđowo odczytaè dane (do sprawdzenia prawidđowoħci stosuje siú ECC); wiúksze opóļnienie ze wzglúdu na fragmentacjú (ponowne formatowanie dysku moľe pomóc dziúki wyzerowaniu mapowania bloków FTL); niľsza wydajnoħè przepustowoħci, jeħli w SSD zaimplementowano wewnútrznæ kompresjú.

Sprawdzaj na bieľæco najnowsze informacje dotyczæce funkcji wydajnoħci w napúdach SSD oraz napotykane problemy.

9.4.2. Interfejsy Interfejs to obsđugiwany przez napúd protokóđ, sđuľæcy do komunikacji z systemem, zwykle za pomocæ kontrolera dysku. W dalszej czúħci przedstawiono krótkie podsumowanie interfejsów SCSI, SAS i SATA. Warto sprawdzaè, jakie sæ obecnie dostúpne interfejsy i ich przepustowoħci, poniewaľ interfejsy zmieniajæ siú na przestrzeni czasu, a poza tym sæ opracowywane i adaptowane nowe specyfikacje.

SCSI Interfejs SCSI (ang. Small Computer System Interface) poczætkowo byđ szynæ transportowæ uľywajæcæ wielu pođæczeē elektrycznych do równoczesnego transportu bitów. Pierwsza wersja tego interfejsu, o nazwie SCSI-1, wprowadzona w 1986 roku, miađa 8-bitowæ szynú danych, co pozwalađo na transfer 1 bajta w trakcie cyklu zegara — przepustowoħè siúgađa 5 MB/s. Podđæczenie odbywađo siú za pomocæ 50-pinowego przewodu Centronics C50. Póļniejsze wersje SCSI uľywađy wiúkszych szyn danych i wiúkszej liczby pinów (do 80) w przewodach, a przepustowoħè siúgađa setek megabajtów. Poniewaľ równolegđe SCSI to szyna wspóđdzielona, byđy pewne problemy z wydajnoħciæ na skutek rywalizacji o dostúp do szyny. Na przykđad zaplanowana operacja tworzenia kopii zapasowej mogđa spowodowaè nasycenie szyny operacjami wejħcia-wyjħcia o niskim priorytecie. Rozwiæzanie polegađo na podđæczaniu urzædzeē o niskim priorytecie za pomocæ oddzielnego kontrolera lub szyny. Równolegđa szyna stawađa siú równieľ problemem przy wiúkszych prúdkoħciach, co wraz z innymi problemami (na przykđad ograniczonym wyborem urzædzeē i koniecznoħciæ ich terminowania) doprowadziđo do przejħcia na wersjú szeregowæ, czyli SAS.

SAS Interfejs SAS (ang. Serial Attached SCSI) zostađ zaprojektowany jako protokóđ transportowy o duľej szybkoħci, w którym unikniúto rywalizacji znanej z równolegđego SCSI. Poczætkowo specyfikacja SAS oferowađa przepustowoħè 3 Gb/s, któræ zwiúkszono do 6 Gb/s (2009), a póļniej do 12 Gb/s (2012). Obsđugiwana jest moľliwoħè agregacji đæcza, a wiúc wiele portów moľna pođæczyè i uzyskaè w ten sposób wiúkszæ przepustowoħè. Rzeczywisty transfer danych wynosi okođo 80% przepustowoħci ze wzglúdu na kodowanie 8b/10b.

466

Rozdział 9



Dyski

Inne funkcje SAS obejmujæ podwójne portowanie dysków do uľycia z nadmiarowymi podđæczeniami i architekturami, tzw. wieloħcieľkowoħè operacji wejħcia-wyjħcia, domeny SAS, wymianú napúdów w dziađajæcym systemie i zgodnoħè z urzædzeniami SATA. Wspomniane funkcje powodujæ, ľe urzædzenia SAS, zwđaszcza o architekturze redundantnej, sæ czústo wybierane do zastosowaē biznesowych.

SATA Z podobnych powodów jak w przypadku SCSI i SAS, takľe standard równolegđego ATA (IDE) ewoluowađ i stađ siú interfejsem Serial ATA. Opracowany w 2001 roku SATA 1.0 oferowađ przepustowoħè 1,5 Gb/s — póļniejsze wersje oferujæ juľ 3 Gb/s i 6 Gb/s, a takľe funkcje dodatkowe, takie jak rodzime kolejkowanie poleceē. Poniewaľ SATA uľywa kodowania 8b/10b, to rzeczywisty transfer danych wynosi okođo 80% przepustowoħci. Interfejs SATA jest powszechnie uľywany w laptopach i biurowych komputerach konsumenckich.

9.4.3. Rodzaje pamięci masowej Pamiúè masowa moľe byè dostarczona serwerowi na wiele róľnych sposobów. W kolejnych fragmentach przedstawiono cztery ogólne architektury: urzædzenia dyskowe, macierz RAID, macierze pamiúci masowej i urzædzenia typu NAS.

Urządzenia dyskowe Najprostszæ architekturæ dla serwera sæ wewnútrzne dyski twarde, kontrolowane pojedynczo przez system operacyjny. Dyski sæ podđæczane do kontrolerów dysków, czyli ukđadów na pđycie gđównej komputera, lub dođæczane do pđyty gđównej. Wspomniany kontroler pozwala na zobaczenie dysku przez system operacyjny i uzyskanie do niego dostúpu. W tego rodzaju architekturze kontroler dysku dziađa w charakterze kanađu pozwalajæcego systemowi na komunikacjú z dyskami. Typowy komputer osobisty bædļ laptop posiada dyski podđæczone w ten wđaħnie sposób, tworzæce jego podstawowæ pamiúè masowæ. Ta architektura jest najđatwiejsza do analizy za pomocæ narzúdzi do sprawdzania wydajnoħci, poniewaľ kaľdy dysk jest znany systemowi operacyjnemu i moľe byè monitorowany niezaleľnie. Niektóre kontrolery dysków obsđugujæ tú architekturú, wtedy jest nazywana JBOD (ang. Just a Bunch of Disks).

RAID Zaawansowane kontrolery dysków mogæ zapewniè obsđugú architektury RAID (ang. Redundant Array of Independent Disks), czyli nadmiarowej macierzy niezaleľnych dysków. Poczætkowo skrót oznaczađ Redundant Array of Inexpensive Disks, czyli nadmiarowæ macierz niedrogich dysków (patrz odwođanie [Patterson 88] na koēcu rozdziađu). Dziúki macierzy RAID dyski mogæ zostaè przedstawione w postaci pojedynczego, duľego, szybkiego i niezawodnego dysku wirtualnego. Wspomniane kontrolery bardzo czústo zawierajæ takľe pamiúè podrúcznæ w postaci RAM, która poprawia wydajnoħè operacji odczytu i zapisu.

9.4. Architektura

467

Jeľeli kontroler dysku oferuje obsđugú macierzy RAID, wówczas nosi ona nazwú sprzútowej macierzy RAID. Macierz RAID moľe byè zaimplementowana takľe przez oprogramowanie systemu operacyjnego, choè preferowane jest rozwiæzanie sprzútowe. Bardzo obciæľajæce procesor obliczenia sumy kontrolnej i parzystoħci mogæ byè przeprowadzone znacznie szybciej w dedykowanym do tego celu sprzúcie. Jednak postúp, jaki dokonađ siú w procesorach, i wprowadzenie procesorów wielordzeniowych zmniejszyđy potrzebú eliminacji obciæľenia, jakim jest obliczania parzystoħci. Wiele róľnych rozwiæzaē pamiúci masowej zostađo przywróconych do postaci programowej macierzy RAID (na przykđad za pomocæ ZFS), co zmniejsza poziom skomplikowania i koszt sprzútu, a jednoczeħnie poprawia moľliwoħci monitorowania za pomocæ systemu operacyjnego. W kolejnych fragmentach przedstawiono charakterystykú wydajnoħci macierzy RAID.

Rodzaje Dostúpne sæ róľne rodzaje macierzy RAID przeznaczone do speđniania róľnych wymagaē w zakresie pojemnoħci, wydajnoħci i niezawodnoħci. Przedstawione tutaj podsumowanie koncentruje siú na wymienionych w tabeli 9.3 cechach charakterystycznych dotyczæcych wydajnoħci. Tabela 9.3. Rodzaje macierzy RAID Poziom

Opis

Wydajność

0 (łączenie)

Napędy są zapełniane pojedynczo.

Ostatecznie może poprawić wydajność losowych operacji odczytu, jeśli będą mogły wziąć w nich udział różne napędy.

0 (striping)

Napędy są używane jednocześnie, co pozwala podzielić operacje wejścia-wyjścia między wiele napędów.

Najlepsza wydajność dla losowych i sekwencyjnych operacji wejścia-wyjścia.

1 (lustrzany)

Kilka napędów (najczęściej dwa) zostaje zgrupowanych i przechowuje identyczne dane (nadmiarowość).

Dobra wydajność losowych i sekwencyjnych operacji odczytu (dane można jednocześnie odczytywać z wielu dysków, zależnie od implementacji). Zapis jest ograniczony najwolniejszym dyskiem w macierzy, a obciążenie związane z przepustowością podwojone (dwa napędy).

10

Połączenie RAID-0 z grupą napędów w RAID-1, zapewniające zarówno pojemność, jak i nadmiarowość.

Charakterystyka wydajności podobna do oferowanej przez RAID-1, ale macierz może się składać z większej liczby grup, na przykład RAID-0, co zwiększa przepustowość.

5

Dane są przechowywane na wielu dyskach (jak w RAID-0) wraz z dodatkowymi informacjami o parzystości, co ma zapewnić nadmiarowość.

Kiepska wydajność operacji zapisu ze względu na cykl odczyt-modyfikacja-zapis i obliczenia sumy kontrolnej.

6

RAID-5 wraz z dwoma dyskami parzystości dla każdego stripingu.

Podobnie jak RAID-5, ale jeszcze gorsza wydajność.

468

Rozdział 9



Dyski

Wprawdzie RAID-0 oferuje najlepszæ wydajnoħè, ale jednoczeħnie nie posiada ľadnej nadmiarowoħci, w wyniku czego jest niepraktycznym wyborem w wiúkszoħci ħrodowisk produkcyjnych.

Monitorowanie Jak przedstawiono we wczeħniejszej czúħci rozdziađu, przy okazji omawiania zagadnienia poziomu wykorzystania dysku wirtualnego, uľycie urzædzenia (sprzútu) dostarczajæcego dysku wirtualnego moľe znacznie utrudniè prowadzenie monitorowania w systemie operacyjnym, poniewaľ system nie búdzie wiedziađ, co tak naprawdú dzieje siú w fizycznych dyskach. Jeľeli macierz RAID jest tworzona w sposób programowy, poszczególne dyski najczúħciej moľna monitorowaè, a system operacyjny zarzædza nimi bezpoħrednio.

Odczyt-modyfikacja-zapis Kiedy dane sæ przechowywane jako striping wraz z sumæ kontrolnæ, jak ma to miejsce na przykđad w macierzy RAID-5, operacja wejħcia-wyjħcia zapisu moľe powodowaè powstanie dodatkowej operacji wejħcia-wyjħcia odczytu i przeprowadzenie obliczeē. Wynika to z faktu, ľe zapis mniejszy niľ wielkoħè stripingu oznacza koniecznoħè odczytu cađego stripingu, modyfikacji bajtów, obliczenia sumy kontrolnej i ponownego zapisania stripingu. Jeľeli zapis obejmuje cađy striping, moľe po prostu nadpisaè poprzedniæ zawartoħè bez koniecznoħci jej wczeħniejszego odczytu. W tego rodzaju ħrodowisku wydajnoħè moľna poprawiè wskutek ustawienia wielkoħci stripingu, takiej jak ħrednia wielkoħci operacji wejħcia-wyjħcia zapisu, co zmniejszy dodatkowe obciæľenie zwiæzane z odczytem.

Pamięć podręczna Kontroler dyskowy implementujæcy macierz RAID-5 moľe nieco poprawiè wydajnoħè cyklu odczyt-modyfikacja-zapis w wyniku uľycia pamiúci podrúcznej z moľliwoħciæ buforowania. Tego rodzaju pamiúci podrúczne sæ podtrzymywane przez baterie, a wiúc nawet jeħli dojdzie do awarii zasilania, búdzie moľna dokoēczyè buforowane operacje zapisu.

Funkcje dodatkowe Musisz mieè ħwiadomoħè, ľe zaawansowane karty kontrolerów dyskowych mogæ oferowaè dodatkowe funkcje wpđywajæce na wydajnoħè. Dobrym rozwiæzaniem búdzie przejrzenie dokumentacji dostarczanej przez producenta i przynajmniej sprawdzenie, jakie sæ dostúpne moľliwoħci. Poniľej wymieniono na przykđad wybrane funkcje oferowane przez karty Dell PERC 5: 

Patrolowanie odczytu. Co kilka dni nastúpuje odczyt wszystkich bloków dysku i weryfikacja ich sum kontrolnych. Jeľeli dyski sæ zajúte obsđugæ ľædaē, zasoby przeznaczone dla omawianej funkcji zostanæ zredukowane, aby uniknæè rywalizacji z obciæľeniem systemowym.

9.4. Architektura



469

Opróľnianie bufora w podanym przedziale czasu. Ustalony w sekundach czas, co jaki zmodyfikowane dane w buforze búdæ zapisywane na dysku. Dđuľszy czas moľe zmniejszyè dyskowe operacje wejħcia-wyjħcia, poniewaľ nastæpi zebranie i lepsza agregacja operacji zapisu. Jednoczeħnie moľe to zwiúkszyè opóļnienie odczytu podczas dđugich operacji opróľniania bufora.

Obie wymienione funkcjú mogæ mieè znaczny wpđyw na wydajnoħè.

Macierze pamięci masowej Macierze pamiúci masowej umoľliwiajæ podđæczanie wielu dysków do systemu. Wykorzystujæ zaawansowane kontrolery dysków pozwalajæce na konfiguracjú macierzy RAID i zwykle zapewniajæ ogromnæ (wyraľonæ w gigabajtach) pamiúè podrúcznæ poprawiajæcæ wydajnoħè operacji odczytu i zapisu. Wspomniane pamiúci masowe sæ zwykle podtrzymywane przez baterie, dziúki czemu moľliwe jest buforowanie zapisu. Powszechnæ praktykæ jest wyđæczenie moľliwoħci buforowania zapisu, jeħli dojdzie do awarii baterii. Pierwszym sygnađem wspomnianej zmiany jest spadek wydajnoħci operacji zapisu, co wynika z koniecznoħci oczekiwania na wykonanie cyklu odczyt-modyfikacja-zapis. Dodatkowym czynnikiem wpđywajæcym na wydajnoħè jest sposób podđæczenia macierzy pamiúci masowej do systemu — zwykle za pomocæ zewnútrznej karty kontrolera. Karta ta oraz transport miúdzy kartæ i macierzæ pamiúci masowej majæ ograniczenia zarówno w liczbie IOPS, jak i przepustowoħci. Aby poprawiè wydajnoħè i niezawodnoħè, macierze pamiúci masowej zwykle pozwalajæ na podwójne podđæczenie, czyli za pomocæ dwóch fizycznych przewodów do jednej karty bædļ dwóch róľnych kart kontrolera pamiúci masowej.

Urządzenia NAS Urzædzenia NAS (ang. Network-Attached Storage) sæ podđæczane do systemu poprzez istniejæcæ sieè i protokóđ sieciowy, taki jak: NFS, SMB/CIFS lub iSCSI. To sæ najczúħciej oddzielne systemy, które wđaħnie w taki sposób powinny byè analizowane. Pewne rodzaje analizy wydajnoħci moľna przeprowadziè z poziomu klienta, sprawdzajæc stosowane obciæľenie i opóļnienie operacji wejħcia-wyjħcia. Wydajnoħè samej sieci równieľ ma znaczenie, a problemy mogæ wynikaè z wysokiego poziomu wykorzystania sieci oraz opóļnienia zwiæzanego z koniecznoħciæ wykonania wielu przeskoków.

9.4.4. Stos dyskowych operacji wejścia-wyjścia w systemie operacyjnym Komponenty i warstwy na stosie dyskowej operacji wejħcia-wyjħcia zaleľæ od uľywanego systemu operacyjnego, jego wersji, oprogramowania i sprzútu. Ogólny model zostađ pokazany na rysunku 9.6. Peđny diagram znajdziesz w rozdziale 3., zatytuđowanym „Systemy operacyjne”.

470

Rozdział 9



Dyski

Rysunek 9.6. Ogólny stos dyskowych operacji wejścia-wyjścia

Interfejs urządzenia blokowego Interfejs urzædzenia blokowego zostađ opracowany we wczesnych wersjach systemu UNIX w celu uzyskania dostúpu do urzædzeē pamiúci blokowej w jednostce, jakæ sæ bloki (kaľdy o wielkoħci 512 bajtów) i zapewnienia podrúcznej pamiúci buforowej poprawiajæcej wydajnoħè. Ten interfejs nadal istnieje w systemach Linux i Solaris, choè rola podrúcznej pamiúci buforowej spadđa wraz z wprowadzeniem buforów systemów plików, jak omówiono to w rozdziale 8. „Systemy plików”. System UNIX zawiera ħcieľkú pozwalajæcæ pominæè podrúcznæ pamiúè buforowæ. Wspomniana ħcieľka to niezmodyfikowana operacja wejħcia-wyjħcia urzædzenia blokowego, której moľna uľywaè za pomocæ specjalnych plików urzædzeē (patrz rozdziađ 3. „Systemy operacyjne”). Tego rodzaju pliki najczúħciej nie sæ juľ domyħlnie instalowane w systemie Linux. Niezmodyfikowana operacja wejħcia-wyjħcia urzædzenia blokowego jest nieco inna, choè w pewien sposób podobna do bezpoħredniej operacji wejħcia-wyjħcia, jak to przedstawiono w rozdziale 8. „Systemy plików”. Interfejs blokowej operacji wejħcia-wyjħcia z reguđy moľna monitorowaè za pomocæ narzúdzi wydajnoħci systemu operacyjnego (iostat). To zarazem czústo uľywane miejsce do zastosowania monitorowania statycznego, a ostatnio nawet dynamicznego. W systemie Linux ten obszar jædra zostađ rozbudowany o funkcje dodatkowe tworzæce warstwú bloku.

Linux Warstwa bloku w systemie Linux zostađa pokazana na rysunku 9.7 (patrz odwođania [2] i [Bovet 05] na koēcu rozdziađu). Warstwa windy zapewnia ogólne moľliwoħci w zakresie sortowania, đæczenia i grupowania ľædaē w celu ich dostarczenia. Obejmuje opisany wczeħniej algorytm wyszukiwania cylindrycznego umoľliwiajæcy zmniejszenie ruchu gđowic dysku podczas obrotu

471

9.4. Architektura

Rysunek 9.7. Warstwa bloku w systemie Linux

(posortowanie oczekujących operacji wejścia-wyjścia na podstawie ich położenia). Zawiera także metody pozwalające na łączenie i koalescencję operacji wejścia-wyjścia, co przedstawiono na rysunku 9.8.

Rysunek 9.8. Rodzaje łączeń operacji wejścia-wyjścia

Wymienione możliwości pozwalają osiągnąć wyższą przepustowość i mniejsze opóźnienie operacji wejścia-wyjścia. Szeregowanie operacji wejścia-wyjścia umożliwia ich kolejkowanie i zmianę kolejności w celu optymalnego dostarczenia, co odbywa się zgodnie z wybraną polityką szeregowania. To może jeszcze bardziej poprawić i zrównoważyć wydajność, zwłaszcza w urządzeniach charakteryzujących się dużym opóźnieniem operacji wejścia-wyjścia (w dyskach mechanicznych z obracającymi się talerzami). Dostępne są następujące polityki: 



Noop. Ta polityka oznacza brak szeregowania („noop” w języku procesora oznacza brak operacji) i może być stosowana, gdy obciążenie związane z szeregowaniem niweluje jego zalety (na przykład dotyczy to RAMdysku). Deadline. Polityka próbuje wymusić stosowanie deadline dla opóźnienia, na przykład przez ustawienie wyrażonego w milisekundach czasu utraty ważności operacji odczytu i zapisu. To użyteczne rozwiązanie dla systemów czasu rzeczywistego, gdy determinizm jest pożądany. Może rozwiązać także

472

Rozdział 9



Dyski

problem ľarđocznoħci, gdy operacja wejħcia-wyjħcia wykorzystuje zasoby dyskowe, poniewaľ nowo wydane ľædanie zostaje umieszczone w kolejce, co oznacza powstanie opóļnienia elementów odstajæcych. Ľarđocznoħè moľe powstaè na skutek operacji zapisu wypierajæcych odczyt jako konsekwencja wyszukiwania cylindrycznego oraz sytuacji, kiedy intensywne operacje wejħcia-wyjħcia na pewnym obszarze dysku wypierajæ inne. Polityka deadline przynajmniej czúħciowo rozwiæzuje te problemy dziúki uľyciu trzech oddzielnych kolejek dla operacji wejħcia-wyjħcia: FIFO dla odczytu, FIFO dla zapisu oraz posortowanej. Wiúcej informacji na ten temat znajdziesz w pozycji wymienionej w odwođaniu [Love 14] na koēcu rozdziađu oraz w pliku Documentation/block/ deadline-iosched.txt dođæczonym do kodu ļródđowego jædra. 



Anticipatory. To jest rozszerzona wersja polityki deadline wraz z zastosowaniem heurystyki w celu poprawy wydajnoħci operacji wejħcia-wyjħcia oraz globalnej przepustowoħci. Moľe powodowaè pauzú liczonæ w milisekundach po odczycie zamiast natychmiastowej obsđugi zapisu z powodu zađoľenia, ľe inne ľædanie odczytu moľe siú pojawiè w trakcie wspomnianej pauzy i dotyczyè danych znajdujæcych siú w pobliľu. W ten sposób nastæpi zmniejszenie ogólnego wyszukiwania przez gđowice dysku. CFQ. Ta polityka szeregowa alokuje przedziađy czasu operacji wejħcia-wyjħcia, podobnie jak w przypadku szeregowania w procesorze. Wspomniane przedziađy sæ przeznaczone do uľycia przez zasoby dyskowe. Ponadto za pomocæ polecenia ionice umoľliwia stosowanie priorytetów i klas dla procesów uľytkownika. Zapoznaj siú z plikiem Documentation/block/cfq-iosched.txt, który dostúpny jest w kodzie ļródđowym jædra.

Po szeregowaniu operacji wejħcia-wyjħcia ľædanie zostanie umieszczone w kolejce urzædzenia blokowego i búdzie gotowe do wydania urzædzeniu.

Solaris Jædro systemu Solaris uľywa interfejsu prostego urzædzenia blokowego wraz z kolejkami w sterowniku docelowym (sd). Zaawansowane szeregowanie operacji wejħcia-wyjħcia jest z reguđy dostarczane przez system plików ZFS, który pozwala na stosowanie priorytetów oraz đæczenie operacji wejħcia-wyjħcia (na przykđad đæczenie miúdzy egzemplarzami systemu). W przeciwieēstwie do innych systemów plików ZFS stanowi pođæczenie menedľera woluminów i systemu plików: zarzædza wđasnymi urzædzeniami dysku wirtualnego i kolejkæ operacji wejħcia-wyjħcia (potokiem). Trzy najniľsze warstwy pokazane na rysunku 9.6 uľywajæ sterowników, takich jak: 

sterownik docelowego urzædzenia wejħcia-wyjħcia: sd, ssd,



sterownik wieloħcieľkowego urzædzenia wejħcia-wyjħcia: scsi_vhci, mpxio,



sterownik HBA: pmcs, mpt, nv_sata, ata.

Uľywane sterowniki zaleľæ od sprzútu serwera i jego konfiguracji.

9.5. Metodologia

473

9.5. Metodologia W tym podrozdziale zostanæ przedstawione róľne metodologie i èwiczenia dotyczæce analizy dyskowych operacji wejħcia-wyjħcia i ich dostrajania. Poruszone tematy podsumowano w tabeli 9.4. Tabela 9.4. Podsumowanie metodologii dotyczących wydajności dysku Metodologia

Opis

Metoda narzędzi

Analiza oparta na obserwacji.

Metoda USE

Analiza oparta na obserwacji.

Charakterystyka obciążenia

Analiza oparta na obserwacji, planowanie pojemności.

Monitorowanie wydajności

Analiza oparta na obserwacji, planowanie pojemności.

Analiza opóźnienia

Analiza oparta na obserwacji.

Monitorowanie zdarzeń

Analiza oparta na obserwacji.

Statyczne dopasowanie wydajności

Analiza oparta na obserwacji, planowanie pojemności.

Dostrojenie bufora

Analiza oparta na obserwacji, dostrojenie.

Kontrola zasobów

Dostrojenie.

Mikrotesty wydajności

Analiza oparta na eksperymentach.

Skalowanie

Planowanie pojemności, dostrojenie.

W rozdziale 2. „Metodologia” znajdziesz wiúcej strategii, jak równieľ wprowadzenie do wielu z nich. Nie musisz korzystaè ze wszystkich strategii, uľywaj ich pojedynczo lub w pođæczeniu z innymi. Podczas analizowania problemów z dyskami sugerujú korzystanie ze strategii w nastúpujæcej kolejnoħci: metoda USE, monitorowanie wydajnoħci, charakterystyka obciæľenia, analiza opóļnienia, mikrotesty wydajnoħci, analiza statyczna i monitorowanie zdarzeē. W podrozdziale 9.6 „Analiza” przedstawiono informacje o dostúpnych w systemach operacyjnych narzúdziach pozwalajæcych na uľycie omawianych strategii.

9.5.1. Metoda narzędzi Metoda narzúdzi to proces polegajæcy na okreħleniu dostúpnych narzúdzi i przeanalizowaniu oferowanych przez nie kluczowych metryk. Jest to co prawda prosta metodologia, lecz jej zastosowanie wiæľe siú z ryzykiem przeoczenia pewnych problemów, do których wykrywania dane narzúdzie nie ma odpowiednich procedur lub sprawdzajæ siú one kiepsko. Poza tym zastosowanie tej metody wymaga doħè duľej iloħci czasu. W przypadku dysków metoda narzúdzi moľe oznaczaè uľycie nastúpujæcych narzúdzi: 

iostat. Za pomocæ trybu rozszerzonego moľna wyszukaè obciæľone dyski (poziom wykorzystania przekraczajæcy 60%), dđugie ħrednie czasy obsđugi (na przykđad powyľej 10 ms) oraz wysokie wartoħci IOPS.

474

Rozdział 9









Dyski

iotop. W celu identyfikacji, który proces odpowiada za powstanie dyskowych operacji wejħcia-wyjħcia. dtrace/stap/perf. Wykorzystanie miúdzy innymi polecenia iosnoop, aby dokđadnie przeanalizowaè opóļnienie dyskowych operacji wejħcia-wyjħcia oraz zidentyfikowaè elementy odstajæce (o czasie wykonywana na przykđad powyľej 100 ms). Narzúdzi przeznaczonych do konkretnego kontrolera dysku. Narzúdzia przygotowane przez producenta.

Jeľeli znaleziony zostanie problem, za pomocæ dostúpnych narzúdzi naleľy przeanalizowaè go na wszystkich pđaszczyznach, aby lepiej poznaè kontekst. W podrozdziale 9.6 „Analiza” zamieszczono informacje szczegóđowe na temat poszczególnych narzúdzi. Inne metodologie mogæ pomóc zidentyfikowaè wiúkszæ liczbú problemów.

9.5.2. Metoda USE Metoda USE jest uľywana do identyfikacji na wczesnym etapie analizy wæskich gardeđ i bđúdów wystúpujæcych w dowolnych komponentach. W dalszej czúħci omówiono, jak metodú USE moľna zastosowaè wzglúdem urzædzeē dyskowych i kontrolerów. W podrozdziale 9.6 „Analiza” przedstawiono narzúdzia sđuľæce do pomiaru okreħlonych metryk.

Urządzenia dyskowe W przypadku kaľdego urzædzenia dyskowego naleľy sprawdziè:  



Poziom wykorzystania. Czas, przez który urzædzenie byđo zajúte. Nasycenie. Do jakiego stopnia operacje wejħcia-wyjħcia muszæ oczekiwaè w kolejce. Bđúdy. Bđúdy urzædzenia.

Sprawdzenie pod kætem bđúdów warto przeprowadziè jako pierwsze. Bđúdy mogæ byè przeoczone, poniewaľ system funkcjonuje prawidđowo — choè znacznie wolniej — pomimo awarii dysku, a dyski przecieľ bardzo czústo sæ konfigurowane w nadmiarowej puli dysków zaprojektowanej do tolerowania awarii. Pomijajæc oferowane przez system operacyjny standardowe liczniki bđúdów dysku, urzædzenia dyskowe mogæ obsđugiwaè takľe wiele innych liczników, których wartoħci búdæ pobierane za pomocæ specjalnych narzúdzi (przykđadem mogæ byè tutaj dane mechanizmu SMART). Jeľeli urzædzenia dyskowe sæ fizycznymi dyskami, poziom wykorzystania powinien byè cađkiem đatwy do ustalenia. Natomiast w przypadku dysków wirtualnych poziom wykorzystania nie musi odzwierciedlaè stanu dysków fizycznych. Wiúcej informacji na ten temat znajdziesz w punkcie 9.3.9.

Kontrolery dyskowe W przypadku kaľdego kontrolera dyskowego naleľy sprawdziè: 

Poziom wykorzystania. Przepustowoħè aktualna kontra maksymalna; to samo naleľy sprawdziè dla wspóđczynnika operacji.

9.5. Metodologia





475

Nasycenie. Do jakiego stopnia operacje wejħcia-wyjħcia muszæ oczekiwaè na wykonanie ze wzglúdu na nasycenie kontrolera. Bđúdy. Bđúdy kontrolera.

Tutaj metryka poziomu wykorzystania nie jest definiowana w kategoriach czasu, ale raczej przez ograniczenia karty kontrolera dysku: przepustowoħè (bajty na sekundú) i wspóđczynnik operacji (liczba operacji na sekundú). Operacje obejmujæ odczyt, zapis i inne polecenia dyskowe. Przepustowoħè lub wspóđczynnik operacji mogæ byè ograniczone przez warstwú transportowæ đæczæcæ dysk z systemem. Warstwa ta moľe stanowiè ograniczenie równieľ w trakcie đæczenia kontrolera z poszczególnymi dyskami. Kaľdæ warstwú transportowæ naleľy sprawdzaè w ten sam sposób: bđúdy, poziom wykorzystania i nasycenie. Moľesz siú przekonaè, ľe narzúdzia monitorowania (na przykđad iostat w systemie Linux) nie dostarczajæ metryk dla poszczególnych kontrolerów, ale jedynie dla dysków. Istnieje pewne rozwiæzanie tego problemu: jeľeli system ma tylko jeden kontroler, wartoħè IOPS i przepustowoħè moľesz obliczyè dla tego kontrolera, po prostu sumujæc metryki uzyskane dla poszczególnych dysków. W przypadku systemu wyposaľonego w wiele kontrolerów konieczne jest ustalenie, które dyski sæ podđæczone do poszczególnych kontrolerów, a nastúpnie odpowiednie zsumowanie metryk. Wydajnoħè kontrolerów dysków i warstwy transportowej bardzo czústo jest przeoczana. Na szczúħcie wymienione komponenty nie stanowiæ najczúħciej spotykanych ļródeđ wæskich gardeđ w systemie, a ich pojemnoħè zwykle jest znacznie wiúksza niľ podđæczonych dysków. Jeľeli przepustowoħè dysków i wartoħè IOPS zawsze znajduje siú na okreħlonym poziomie, nawet w przypadku róľnego rodzaju obciæľeē, to moľe byè wskazówkæ, ľe uľywane kontrolery dysków bædļ warstwa transportowa rzeczywiħcie powodujæ problemy.

9.5.3. Monitorowanie wydajności Monitorowanie wydajnoħci pozwala na identyfikacjú problemów i wzorców zachowania na przestrzeni czasu. W dyskowych operacjach wejħcia-wyjħcia metrykami o znaczeniu krytycznym sæ: 

poziom wykorzystania dysku,



czas udzielania odpowiedzi.

Jeľeli poziom wykorzystania dysków przez wiele sekund wynosi 100%, to prawdopodobnie stanowi problem. W zaleľnoħci od ħrodowiska przekroczenie wartoħci 60% równieľ moľe oznaczaè kiepskæ wydajnoħè ze wzglúdu na wiúksze kolejkowanie. Dđuľszy czas udzielania odpowiedzi wpđywa negatywnie na wydajnoħè i moľe byè skutkiem zmiany rodzaju obciæľenia lub dodania nowego, konkurujæcego z istniejæcym. Wartoħè okreħlana jako „normalna” lub „zđa” zaleľy od obciæľenia, ħrodowiska i wymagaē dotyczæcych opóļnienia. Jeľeli nie jesteħ pewien, to moľna przeprowadziè mikrotesty wydajnoħci obciæľenia zarówno uznawanego za dobre, jak i nietypowego, sprawdzajæc tym samym opóļnienie (na przykđad operacje losowe kontra sekwencyjne, mađe kontra duľe, jeden tenant kontra wiúcej). Zapoznaj siú z podrozdziađem 9.7 „Eksperymenty”.

476

Rozdział 9



Dyski

Wymienione metryki powinny byè analizowane dla poszczególnych dysków, aby wyszukaè obciæľenia, które nie zostađy zrównowaľone, oraz pojedyncze dyski charakteryzujæce siú niewystarczajæco dobræ wydajnoħciæ. Metryka, jakæ jest czas udzielania odpowiedzi, moľe byè monitorowana w postaci wartoħci ħredniej na sekundú i obejmowaè takľe inne wartoħci, takie jak maksimum i odchylenie standardowe. W idealnej sytuacji moľliwe búdzie przeanalizowanie peđnego rozkđadu czasu udzielania odpowiedzi, na przykđad za pomocæ histogramu lub mapy cieplnej, aby wyszukaè elementy odstajæce oraz inne wzorce. W systemach stosujæcych mechanizmy kontroli zasobów oparte na systemie plików uwzglúdniè moľna takľe dane statystyczne, aby przekonaè siú, jak i kiedy zastosowane zostađo ograniczenie. Dyskowe operacje wejħcia-wyjħcia mogæ staè siú wæskim gardđem na skutek nađoľonych ograniczeē, a nie aktywnoħci samego dysku. Poziom wykorzystania i czas udzielania odpowiedzi pokazujæ wydajnoħè dysku. Istnieje moľliwoħè dodania kolejnych metryk charakteryzujæcych obciæľenie — miúdzy innymi wartoħè IOPS i przepustowoħè. Otrzymasz wtedy waľne dane, które przydajæ siú podczas planowania pojemnoħci (zapoznaj siú z punktem kolejnym i punktem 9.5.11 w dalszej czúħci rozdziađu).

9.5.4. Charakterystyka obciążenia Charakterystyka obciæľenia to bardzo waľne zadanie podczas planowania pojemnoħci, przeprowadzania testów wydajnoħci i symulacji obciæľenia. Moľe prowadziè równieľ do uzyskania najwiúkszej poprawy wydajnoħci dziúki identyfikacji niepotrzebnych zadaē, które moľna wyeliminowaè. Poniľej wymieniono podstawowe atrybuty przeznaczone do scharakteryzowania obciæľenia w postaci dyskowych operacji wejħcia-wyjħcia — wszystkie razem mogæ dostarczyè wskazówek dotyczæcych zadaē wykonywanych przez dyski: 

czústotliwoħè operacji wejħcia-wyjħcia,



przepustowoħè operacji wejħcia-wyjħcia,



wielkoħè operacji wejħcia-wyjħcia,



rodzaj operacji: losowe czy sekwencyjne,



wspóđczynnik operacji odczytu/zapisu.

Rodzaj operacji (losowe kontra sekwencyjne), wspóđczynnik operacji odczytu/zapisu i wielkoħè operacji wejħcia-wyjħcia omówiono w podrozdziale 9.3 „Koncepcje”. Czústotliwoħè operacji wejħcia-wyjħcia (IOPS) i przepustowoħè zdefiniowano w podrozdziale 9.1 „Terminologia”. Charakterystyka moľe siú zmieniaè z sekundy na sekundú, zwđaszcza w przypadku aplikacji i systemów plików, które buforujæ operacje zapisu i opróľniajæ bufor w zdefiniowanych odstúpach czasu. Aby lepiej scharakteryzowaè obciæľenie, konieczne jest przechwycenie wartoħci maksymalnych oraz ħrednich. Najwđaħciwsze búdzie przeanalizowanie peđnego rozkđadu wartoħci na przestrzeni czasu.

9.5. Metodologia

477

Oto przykđadowy opis obciæľenia pokazujæcy, jak moľna razem wyraziè wymienione wczeħniej atrybuty: Obciæľenie dysków w systemie to lekkie, losowe operacje odczytu, ħrednio 350 IOPS, przepustowoħè 3 MB/s, 96% operacji stanowi odczyt. Co pewien czas na krótko pojawiajæ siú sekwencyjne operacje zapisu. Wówczas dysk osiæga maksymalnie 4800 IOPS, a przepustowoħè siúga 560 MB/s. Wielkoħè operacji odczytu wynosi okođo 8 KB, natomiast zapisu okođo 128 KB.

Wspomniane cechy charakterystyczne mogæ byè podawane dla cađego systemu bædļ teľ w celu przedstawienia obciæľenia operacjami wejħcia-wyjħcia poszczególnych dysków lub kontrolerów.

Zaawansowana charakterystyka obciążenia i lista rzeczy do sprawdzenia Przygotowujæc charakterystykú obciæľenia, moľna wziæè pod uwagú jeszcze informacje dodatkowe. Zostađy one wymienione w postaci pytaē, na które naleľy spróbowaè udzieliè odpowiedzi. Przedstawione pytania mogæ sđuľyè równieľ w charakterze listy rzeczy do zrobienia, gdy chcesz dokđadnie przeanalizowaè problemy zwiæzane z dyskami. 



Jaka jest wartoħè IOPS dla cađego systemu oraz dla poszczególnych dysków i kontrolerów? Jaka jest przepustowoħè dla cađego systemu oraz dla poszczególnych dysków i kontrolerów?



Jakie aplikacje lub jacy uľytkownicy uľywajæ dysków?



Jakie sæ uľywane systemy plików lub pliki?



Czy spotykane sæ jakiekolwiek bđúdy? Czy bđæd jest skutkiem nieprawidđowego ľædania, czy raczej problemów zwiæzanych z dyskami?



Czy operacje wejħcia-wyjħcia sæ rozđoľone miúdzy dostúpnymi dyskami?



Jaka jest wartoħè IOPS dla poszczególnych kanađów komunikacji?



Jaka jest przepustowoħè dla poszczególnych kanađów komunikacji?



Jakie wykonywane sæ polecenia dyskowe niedotyczæce transferu danych?







Dlaczego zostađa wykonana dyskowa operacja wejħcia-wyjħcia? Jak wyglæda ħcieľka wywođania na poziomie jædra? Do jakiego stopnia dyskowe operacje wejħcia-wyjħcia wykonywane przez aplikacjú sæ synchroniczne? Jak przedstawia siú rozkđad czasu operacji wejħcia-wyjħcia?

Pytania dotyczæce wartoħci IOPS i przepustowoħci moľna sformuđowaè oddzielnie dla operacji odczytu i zapisu. Kaľdæ z przedstawionych wartoħci moľna sprawdzaè na przestrzeni czasu, wyszukujæc minimum, maksimum i wariancje oparte na czasie. Zapoznaj siú w rozdziale 2. „Metodologia” z punktem 2.5.10, w którym znajdziesz ogólne podsumowanie cech charakterystycznych wartych sprawdzenia (kto?, dlaczego?, co? i jak?).

478

Rozdział 9



Dyski

Charakterystyka wydajności Na podstawie przedstawionych pytaē (porównaj je z poprzednimi pytaniami, dotyczæcymi charakterystyki obciæľenia) moľna przygotowaè charakterystykú wydajnoħci dysków dziađajæcych pod danym obciæľeniem:  

Jaki jest poziom wykorzystania poszczególnych dysków? Czy wystúpuje nasycenie w poszczególnych dyskach podczas wykonywania operacji wejħcia-wyjħcia (czyli czy istnieje kolejka oczekiwania)?



Jaki jest ħredni czas obsđugi operacji wejħcia-wyjħcia?



Jaki jest ħredni czas oczekiwania dla operacji wejħcia-wyjħcia?



 



Czy istniejæ elementy odstajæce, o duľo wiúkszym opóļnieniu, operacji wejħcia-wyjħcia? Jak przedstawia siú peđny rozkđad opóļnienia operacji wejħcia-wyjħcia? Czy stosowane sæ jakiekolwiek mechanizmy kontroli zasobów, na przykđad dyskowych operacji wejħcia-wyjħcia? Jakie jest opóļnienie poleceē dyskowych niedotyczæcych transferu danych?

9.5.5. Analiza opóźnienia Analiza opóļnienia oznacza gđúbsze dræľenie systemu w celu znalezienia ļródđa opóļnienia. W przypadku dysków bardzo czústo oznacza to dotarcie do interfejsu dysku: czas miúdzy wydaniem ľædania operacji wejħcia-wyjħcia a przerwaniem oznaczajæcym jej zakoēczenie. Jeľeli wspomniany czas odpowiada opóļnieniu operacji wejħciawyjħcia na poziomie aplikacji, wówczas moľna bezpiecznie przyjæè zađoľenie, ľe opóļnienie ma swoje ļródđo w dyskach, po czym skoncentrowaè siú na ich analizie. W przypadku róľnic w opóļnieniu jego pomiar na róľnych poziomach stosu systemu operacyjnego pomoľe w identyfikacji ļródđa opóļnienia. Na rysunku 9.9 pokazano stos operacji wejħcia-wyjħcia, przy czym opóļnienie zaprezentowano na róľnych poziomach elementów odstajæcych dwóch operacji wejħciawyjħcia: A i B. Opóļnienie operacji wejħcia-wyjħcia A jest podobne na wszystkich poziomach aplikacji, aľ do sterowników dysków. Ta korelacja wskazuje dyski (lub sterownik dysku) jako przyczynú opóļnienia. Potwierdzenie moľna uzyskaè, mierzæc opóļnienie niezaleľnie w poszczególnych warstwach — okazuje siú podobne. W przypadku operacji wejħcia-wyjħcia B opóļnienie wydaje siú powstawaè na poziomie systemu plików (blokowanie lub kolejkowanie), poniewaľ na niľszych poziomach stosu jego wartoħè jest duľo mniejsza. Musisz mieè ħwiadomoħè, ľe róľne warstwy stosu mogæ zwiúkszaè lub zmniejszaè operacjú wejħcia-wyjħcia, co oznacza moľliwoħè wystúpowania róľnic w wielkoħci, liczbie i opóļnieniu operacji wejħcia-wyjħcia w poszczególnych warstwach. Przykđad B moľe byè przypadkiem majæcym miejsce podczas monitorowania tylko jednej operacji wejħcia-wyjħcia na niľszych poziomach (10 ms), gdy nie zostađy uwzglúdnione inne, powiæzane z niæ operacje wejħcia-wyjħcia wystúpujæce podczas obsđugi tej samej operacji systemu plików (na przykđad metadanych).

9.5. Metodologia

479

Rysunek 9.9. Analiza opóźnienia stosu

Opóļnienie na poszczególnych poziomach moľna przedstawiè w postaci: 





ħredniej wartoħci operacji wejħcia-wyjħcia w przedziale czasu — typowa wartoħè zgđaszana przez narzúdzia dostarczane wraz z systemem operacyjnym; peđnego rozkđadu operacji wejħcia-wyjħcia — w postaci histogramów lub map cieplnych; zapoznaj siú w punktem 9.6.12 w dalszej czúħci rozdziađu; wartoħci opóļnienia dla poszczególnych operacji wejħcia-wyjħcia — zapoznaj siú z kolejnym punktem, dotyczæcym monitorowania zdarzeē.

Dwa ostatnie punkty sæ przydatne podczas wyszukiwania ļródđa powstawania elementów odstajæcych, co moľe pomóc w identyfikacji przypadków, w których nastúpuje podziađ lub koalescencja operacji wejħcia-wyjħcia.

9.5.6. Monitorowanie zdarzeń Monitorowanie zdarzeē przechwytuje informacje szczegóđowe o kaľdej operacji wejħcia-wyjħcia. W analizie opartej na obserwacji to jest rozwiæzanie ostateczne. Negatywnie wpđywa na wydajnoħè ze wzglúdu na koniecznoħè przechwycenia i zapisania wspomnianych informacji, które zwykle sæ umieszczane w plikach dzienników zdarzeē w celu dalszej analizy. Pliki te mogæ zawieraè nastúpujæce informacje szczegóđowe o danej operacji wejħcia-wyjħcia: 

identyfikator urzædzenia dyskowego,



rodzaj operacji wejħcia-wyjħcia: odczyt lub zapis,

480

Rozdział 9





wartoħè przesuniúcia operacji wejħcia-wyjħcia: pođoľenie na dysku,



wielkoħè operacji wejħcia-wyjħcia: wyraľona w bajtach,







Dyski

znacznik czasu ľædania operacji wejħcia-wyjħcia: godzina wydania ľædania operacji wejħcia-wyjħcia skierowanego do urzædzenia (nazywana takľe strategiæ operacji wejħcia-wyjħcia), znacznik czasu ukoēczenia operacji wejħcia-wyjħcia: godzina zakoēczenia operacji wejħcia-wyjħcia (przerwanie informujæce o ukoēczeniu operacji), stan ukoēczenia operacji wejħcia-wyjħcia: bđúdy.

Informacje dodatkowe mogæ zawieraè identyfikator procesu, identyfikator uľytkownika, nazwú aplikacji, nazwú pliku i zdarzenia dla poleceē dyskowych niedotyczæcych transferu danych (oraz wszelkie inne informacje o tych poleceniach). Znaczniki czasu wydania ľædania i zakoēczenia operacji wejħcia-wyjħcia pozwalajæ na obliczenie opóļnienia dyskowej operacji wejħcia-wyjħcia. Podczas odczytu dziennika zdarzeē uľyteczne búdzie oddzielne posortowanie wspomnianych znaczników czasu w celu ich porównania, aby przekonaè siú, jak urzædzenie zmieniđo kolejnoħè dyskowych operacji wejħcia-wyjħcia. Na podstawie znaczników czasu moľna przestudiowaè takľe rozkđad wykonywania operacji. Poniewaľ dyskowe operacje wejħcia-wyjħcia sæ bardzo czústo analizowane, do tego celu z reguđy sæ dostúpne odpowiednie punkty instrumentacji statycznej, umoľliwiajæce monitorowanie ľædaē i ich ukoēczenia. Istnieje równieľ moľliwoħè zastosowania monitorowania dynamicznego do analizy zaawansowanej. Podobne dzienniki zdarzeē moľna zebraè dla wymienionych poniľej: 

operacji wejħcia-wyjħcia sterownika urzædzenia blokowego,



polecenia interfejsu sterownika (na przykđad sd),



polecenia sterownika urzædzenia dyskowego.

Polecenia oznaczajæ zarówno odczyt, jak i zapis, a takľe inne operacje niedotyczæce transferu danych. Przykđady znajdziesz w podrozdziale 9.6, zatytuđowanym „Analiza”.

9.5.7. Statyczne dopasowanie wydajności Statyczne dopasowanie wydajnoħci jest skoncentrowane na kwestiach pojawiajæcych siú w skonfigurowanym ħrodowisku. W przypadku analizy wydajnoħci dysków konieczne jest przeanalizowanie nastúpujæcych aspektów konfiguracji statycznej: 

Ile jest zamontowanych dysków i ile z nich jest uľywanych?



Jaka jest wersja firmware’u na dyskach?



Ile jest dostúpnych kontrolerów dysków? Jakiego typu to sæ interfejsy?



Czy karty kontrolerów sæ podđæczone do slotów o duľej szybkoħci dziađania?



Jaka jest wersja firmware’u w kartach kontrolerów dysków?



Czy uľywana jest macierz RAID? Jaka dokđadnie jest jej konfiguracja?

9.5. Metodologia



Czy jest dostúpna i skonfigurowana wieloħcieľkowoħè?



Jaka jest wersja sterownika urzædzenia dyskowego?





481

Czy istniejæ jakiekolwiek bđúdy lub poprawki dla systemu plików dla któregokolwiek sterownika urzædzeē pamiúci masowej? Czy stosowane sæ jakiekolwiek mechanizmy kontroli zasobów dla dyskowych operacji wejħcia-wyjħcia?

Warto pamiútaè, ľe bđúdy zwiæzane z wydajnoħciæ mogæ mieè miejsce w sterownikach urzædzeē i oprogramowaniu (firmwarze). W najlepszej sytuacji búdæ wyeliminowane dziúki uaktualnieniom wydawanym przez producenta. Udzielenie odpowiedzi na wymienione wczeħniej pytania moľe ujawniè przeoczone wczeħniej opcje konfiguracyjne. Niekiedy zdarza siú, ľe system jest skonfigurowany pod kætem pewnego obciæľenia, a nastúpnie wykorzystywany do innych celów. Dziúki omawianej metodzie búdzie moľna wprowadziè odpowiednie korekty. Wiúkszoħè narzekaē, z jakimi spotykađem sæ podczas pracy w charakterze lidera zajmujæcego siú wydajnoħciæ produktu pamiúci masowej Sun ZFS, wynikađa z bđúdnej konfiguracji: uľycia pođowy JBOD (12 dysków) macierzy RAID-Z2 (striping). Nauczyđem siú, ľeby w pierwszej kolejnoħci prosiè o podanie dokđadnej konfiguracji (zwykle przez telefon), a dopiero potem przystúpowađem do logowania do systemu i analizowania opóļnienia operacji wejħcia-wyjħcia.

9.5.8. Dostrojenie bufora W systemie moľe byè dostúpnych wiele róľnych buforów, miúdzy innymi na poziomie aplikacji, systemu plików, kontrolera dysku oraz w samym dysku. Poszczególne bufory zostađy omówione w punkcie 9.3.3 i mogæ byè dostrojone zgodnie z informacjami przedstawionymi w punkcie 2.5.17 w rozdziale 2. „Metodologia”. Podsumowujæc — warto ustaliè, jakie istniejæ bufory, przekonaè siú, czy w ogóle dziađajæ, sprawdziè, czy dziađajæ zgodnie z oczekiwaniami, okreħliè ich wielkoħè, a nastúpnie dostosowaè obciæľenie do bufora i bufor do obciæľenia.

9.5.9. Kontrola zasobów System operacyjny moľe dostarczaè narzúdzi pozwalajæcych na dokđadne okreħlenie ograniczeē w zakresie alokacji dyskowych operacji wejħcia-wyjħcia dla procesów lub grup procesów. To moľe oznaczaè istnienie na stađe ustalonej maksymalnej wartoħci IOPS i przepustowoħci. Moľna ewentualnie stosowaè znacznie elastyczniejsze podejħcie. Wiúcej informacji szczegóđowych na temat implementacji takiego rozwiæzania znajdziesz w podrozdziale 9.8 „Dostrajanie”.

9.5.10. Mikrotesty wydajności Mikrotesty wydajnoħci dyskowych operacji wejħcia-wyjħcia zostađy wprowadzone w rozdziale 8. „Systemy plików”, w którym wyjaħniono róľnicú miúdzy testowaniem operacji wejħcia-wyjħcia dla systemu plików i dysku. Tutaj chcemy przetestowaè dyskowe operacje

482

Rozdział 9



Dyski

wejħcia-wyjħcia, co zwykle oznacza testowanie za pomocæ ħcieľek urzædzeē systemu operacyjnego, przede wszystkim ħcieľki niezmodyfikowanego urzædzenia (o ile taka jest dostúpna), aby uniknæè zachowaē typowych dla systemu plików (miúdzy innymi buforowania, dzielenia operacji wejħcia-wyjħcia, koalescencji operacji wejħcia-wyjħcia, obciæľenia zwiæzanego ze ħcieľkami kodu oraz róľnic w mapowaniu przesuniúè). Poniľej wymieniono czynniki, które naleľy wziæè pod uwagú podczas mikrotestów wydajnoħci: 

kierunek: odczyt lub zapis,



wzorzec przesuniúcia dyskowego: losowy lub sekwencyjny,



 



zakres przesuniúcia: peđny dysk lub ħcisđy zakres (na przykđad wartoħè przesuniúcia wynosi jedynie 0), wielkoħè operacji wejħcia-wyjħcia: od 512 B (typowe minimum) do 1 MB, wspóđbieľnoħè: liczba wykonywanych operacji wejħcia-wyjħcia lub liczba wætków wykonujæcych te operacje, liczba urzædzeē: test pojedynczego dysku lub ich wiúkszej liczby w celu wykrycia ograniczeē kontrolera bædļ szyny.

W dwóch kolejnych fragmentach przekonasz siú, jak wymienione czynniki moľna đæczyè w celu testowania wydajnoħci dysków i kontrolerów dysków. Wiúcej informacji dotyczæcych konkretnych narzúdzi, które moľna wykorzystaè do przeprowadzania tych testów, zebrano w podrozdziale 9.7 „Eksperymenty”.

Dyski Mikrotesty wydajnoħci mogæ byè przeprowadzane wzglúdem poszczególnych dysków, aby ustaliè wartoħci dla danego obciæľenia. Tymi wartoħciami sæ: 









maksymalna przepustowoħè dysku (wyraľona w megabajtach na sekundú): sekwencyjne odczyty o wielkoħci 128 KB, maksymalna wielkoħè wspóđczynnika operacji (IOPS): odczyty o wielkoħci 512 B, wartoħè przesuniúcia wynoszæca tylko 0, maksymalna szybkoħè losowych odczytów z dysku (IOPS): odczyty o wielkoħci 512 B, róľne wartoħci przesuniúcia, profil opóļnienia odczytu (wartoħè ħrednia wyraľona w mikrosekundach): odczyty sekwencyjne, testy naleľy przeprowadziè dla wielkoħci 512 B, 1 KB, 2 KB, 4 KB itd, profil opóļnienia losowych operacji wejħcia-wyjħcia (wartoħè ħrednia wyraľona w mikrosekundach): odczyty o wielkoħci 512 B, testy naleľy powtórzyè dla peđnego zakresu wartoħci przesuniúcia.

Wymienione testy moľna powtórzyè dla operacji zapisu. „Wartoħè przesuniúcia wynoszæca tylko 0” jest przeznaczona do buforowania danych w pamiúci podrúcznej dysku, aby moľna byđo zmierzyè czas dostúpu do bufora.

9.5. Metodologia

483

Kontrolery dysków Mikrotesty wydajnoħci kontrolerów dysków moľna przeprowadziè na skutek zastosowania obciæľenia dla wielu dysków, co ma za zadanie maksymalne wykorzystanie kontrolera. Wspomniane testy moľna przeprowadziè w celu sprawdzenia wartoħci dla danego obciæľenia dysków. Tymi wartoħciami sæ: 



maksymalna przepustowoħè kontrolera (wyraľona w megabajtach na sekundú): sekwencyjne odczyty o wielkoħci 128 KB, maksymalna wielkoħè wspóđczynnika operacji kontrolera (IOPS): odczyty o wielkoħci 512 B, wartoħè przesuniúcia wynoszæca tylko 0.

Obciæľenie naleľy stosowaè kolejno dla dysków i obserwowaè osiægane wartoħci. Peđne wykorzystanie kontrolera moľe wymagaè uľycia dziesiúciu lub nawet wiúcej dysków.

9.5.11. Skalowanie Dyski i kontrolery majæ swoje ograniczenia w zakresie przepustowoħci i wartoħci IOPS, które moľna okreħliè za pomocæ mikrotestów wydajnoħci, jak to zaprezentowano wczeħniej. Dostrojenie umoľliwia poprawú wydajnoħci, ale jedynie w ramach wspomnianych ograniczeē. Jeľeli wymagane jest osiægniúcie wiúkszej wydajnoħci dyskowej, a inne strategie buforowania nie sprawdzajæ siú, to trzeba búdzie przystæpiè do skalowania dysków. Oto prosta metoda oparta na planowaniu pojemnoħci zasobów. 1. Ustal obciæľenie docelowe w kategoriach przepustowoħci i wartoħci IOPS. Jeľeli analizowany jest nowy system, zapoznaj siú z podrozdziađem 2.7 „Planowanie pojemnoħci” w rozdziale 2. „Metodologia”. Jeľeli to jest istniejæcy i dziađajæcy system, liczbú uľytkowników wyraļ w kategoriach obecnej przepustowoħci dysku i wartoħci IOPS, a nastúpnie przeskaluj te wartoħci na docelowæ liczbú uľytkowników. (Jeľeli równoczeħnie nie búdzie przeskalowany bufor, obciæľenie dyskowe moľe siú zwiúkszyè, poniewaľ wspóđczynnik wyraľajæcy stosunek bufora do uľytkownika stanie siú niľszy i zwiúkszy siú liczba dyskowych operacji wejħcia-wyjħcia). 2. Oblicz liczbú dysków niezbúdnych do obsđugi danego obciæľenia. Uwzglúdnij konfiguracjú macierzy RAID. Nie uľywaj maksymalnych wartoħci IOPS i przepustowoħci dla dysku, poniewaľ wtedy zaplanujesz 100-procentowy poziom ich wykorzystania, co natychmiast doprowadzi do problemów z wydajnoħciæ na skutek nasycenia i kolejkowania ľædaē. Wybierz docelowy poziom wykorzystania (powiedzmy 50%) i odpowiednio przeskaluj wartoħci. 3. Oblicz liczbú kontrolerów dyskowych niezbúdnych do obsđugi danego obciæľenia. 4. Sprawdļ, czy nie zostanæ osiægniúte ograniczenia warstwy transportowej i ewentualnie przeskaluj jæ, jeħli zachodzi potrzeba. 5. Oblicz liczbú cykli procesora przypadajæcych na dyskowæ operacjú wejħcia-wyjħcia oraz cađkowitæ liczbú wymaganych procesorów.

484

Rozdział 9



Dyski

Maksymalne wartoħci przepustowoħci i IOPS dla poszczególnych dysków búdæ zaleľađy od rodzajów dysków. Zapoznaj siú z punktem 9.3.7 we wczeħniejszej czúħci rozdziađu. Mikrotesty wydajnoħci moľna wykorzystaè do wyszukania okreħlonych ograniczeē dla operacji wejħcia-wyjħcia o danej wielkoħci i typie. Z kolei charakterystykú obciæľenia moľna wykorzystaè do sprawdzenia, jaka wielkoħè i jakie typy majæ znaczenie w istniejæcym obciæľeniu. Aby uzyskaè wymagane obciæľenie dyskowe, nierzadko trzeba uľyè wielu serwerów z dziesiætkami dysków podđæczonych poprzez macierze pamiúci masowej. Kiedyħ mówiđo siú: „dodaj wiúcej dysków twardych”, a teraz mówimy: „dodaj wiúcej pamiúci flash”.

9.6. Analiza W tym podrozdziale zostanæ omówione narzúdzia analizy wydajnoħci dyskowych operacji wejħcia-wyjħcia w systemach operacyjnych Linux i Solaris. Strategie uľycia omawianych tutaj narzúdzi znajdziesz w poprzednim podrozdziale. W tabeli 9.5 wymieniono narzúdzia, które búdæ uľywane w niniejszym podrozdziale. Tabela 9.5. Polecenia służące do analizy wydajności dysków Linux

Solaris

Opis

iostat

iostat

Różne dane statystyczne dotyczące dysku.

sar

sar

Różne dane statystyczne, w tym również historyczne.

pidstat, iotop

iotop

Poziom użycia dyskowych operacji wejścia-wyjścia przez poszczególne procesy.

blktrace

iosnoop

Monitorowanie zdarzeń dyskowych operacji wejścia-wyjścia.

dtrace

dtrace

Monitorowanie dynamiczne i statyczne operacji dyskowych.

megacli

megacli

Dane statystyczne kontrolera LSI.

smartctl

smartctl

Dane statystyczne kontrolera dysków.

Wymienione narzúdzia zostađy wybrane pod kætem moľliwoħci obsđugi metodologii przedstawionych w podrozdziale 9.5. Na poczætku listy znajdujæ siú narzúdzia monitorowania na poziomie cađego systemu. Nastúpnie mamy narzúdzia generujæce dane statystyczne dla poszczególnych procesów, a na koēcu przechodzimy do monitorowania zdarzeē i danych statystycznych kontrolera. Omówienie funkcji poszczególnych narzúdzi znajdziesz w dokumentacji, miúdzy innymi na stronach podrúcznika man.

9.6.1. iostat Polecenie iostat wyħwietla dla poszczególnych dysków podsumowanie danych statystycznych dotyczæcych operacji wejħcia-wyjħcia, miúdzy innymi metryki do charakterystyki obciæľenia, poziomu wykorzystania i nasycenia. Omawiane polecenie moľe byè wydane przez dowolnego uľytkownika, z reguđy jest to pierwsze polecenie wydawane

9.6. Analiza

485

w powđoce podczas analizy problemów zwiæzanych z dyskowymi operacjami wejħcia-wyjħcia. Wyħwietlane dane statystyczne sæ zawsze obsđugiwane przez jædro, a wiúc obciæľenie zwiæzane z uľywaniem polecenia iostat moľna uznaè za minimalne. Nazwa polecenia jest skrótem od „I/O statistics”, czyli „dane statystyczne operacji wejħcia-wyjħcia”. Jednak znacznie lepszæ nazwæ byđaby „diskiostat”, poniewaľ odzwierciedliđaby rodzaj podawanych informacji. Czasami zdarza siú sytuacja, w której uľytkownik wie, ľe aplikacja wykonuje operacje wejħcia-wyjħcia (system plików), ale zastanawia siú, dlaczego nie sæ one widoczne w danych wyjħciowych polecenia iostat (dyski). Polecenie iostat zostađo opracowane we wczesnych latach osiemdziesiætych ubiegđego wieku, dostúpne sæ jego róľne wersje dla róľnych systemów operacyjnych. Standardowo znajduje siú w systemie Solaris, natomiast do systemu Linux moľe byè dodane w ramach pakietu sysstat. Wprawdzie ogólne przeznaczenie obu wspomnianych wersji polecenia jest takie samo, ale róľniæ siú one opcjami i wyħwietlanymi kolumnami danych wyjħciowych. Dokđadne informacje o moľliwoħciach polecenia iostat w uľywanym przez Ciebie systemie operacyjnym znajdziesz na stronie podrúcznika systemowego man. W dalszej czúħci przedstawiono omówienie polecenia iostat w systemach Linux i Solaris. Opcje i dane wyjħciowe róľniæ siú w obu tych systemach. W wywođaniu polecenia iostat moľna umieħciè róľne opcje, a nastúpnie opcjonalny przedziađ czasu i liczbú.

Linux Najczúħciej uľywane opcje iostat zostađy wymienione w tabeli 9.6. Tabela 9.6. Opcje iostat w systemie Linux Opcja

Opis

-c

Wyświetlenie raportu dotyczącego procesora.

-d

Wyświetlenie raportu dotyczącego dysku.

-k

Użycie kilobajtów zamiast 512-bajtowych bloków.

-m

Użycie megabajtów zamiast 512-bajtowych bloków.

-p

Dołączenie danych statystycznych dla poszczególnych partycji.

-t

Umieszczenie znaczników czasu w danych wyjściowych.

-x

Rozbudowane dane statystyczne.

-z

Pominięcie wyświetlania podsumowania dla zerowej aktywności.

Domyħlnie wđæczone sæ opcje -c i -d. Podanie jednej z nich w wywođaniu sprawia, ľe nastúpuje wyđæczenie drugiej. Niektóre starsze wersje polecenia iostat zawierađy opcjú -n, powodujæcæ wyħwietlenie danych statystycznych NFS. Poczæwszy od wersji 9.1.3 pakietu sysstat wymieniona funkcjonalnoħè zostađa przeniesiona do oddzielnego polecenia nfsiostat. W przypadku braku jakichkolwiek argumentów lub opcji wyħwietlane jest podsumowanie danych od chwili uruchomienia systemu oraz raporty wskazywane przez opcje -c i -d. Takie wywođanie przedstawiono tutaj jako wprowadzenie do omawianego

486

Rozdział 9



Dyski

polecenia. Nie spodziewaj siú jednak uľywania polecenia iostat w tym trybie, poniewaľ omówiony nieco dalej tryb rozszerzony jest, ogólnie rzecz bioræc, znacznie bardziej uľyteczny. $ iostat Linux 3.2.6-3.fc16.x86_64 (prod201) 04/14/13 avg-cpu: %user %nice %system %iowait %steal 0.03 0.00 0.02 0.00 0.00 Device: tps kB_read/s kB_wrtn/s sdb 0.01 0.75 0.87 sda 1.67 0.43 17.66 dm-0 0.22 0.75 0.87 dm-1 4.44 0.42 17.66 dm-2 0.00 0.00 0.00

_x86_64_ (16 CPU) %idle 99.95 kB_read kB_wrtn 4890780 5702856 2811164 115693005 4890245 5702856 2783497 115669936 5976 22748

Domyħlnie polecenie iostat wyħwietla najpierw wiersz podsumowania dotyczæcego systemu, miúdzy innymi wersjú jædra, nazwú komputera, datú, architekturú, liczbú procesorów. Nastúpnie znajdziemy podsumowanie danych statystycznych zebranych od chwili uruchomienia systemu — dotyczæ one procesorów (avg-cpu) i urzædzeē dyskowych (sekcja Device:). Informacje o poszczególnych dyskach sæ wyħwietlane w oddzielnych wierszach. Kolumny zawierajæ informacje podstawowe:  



tps — liczba transakcji na sekundú (IOPS), kB_read/s, kB_wrtn/s — liczba kilobajtów odczytywanych w trakcie sekundy, liczba kilobajtów zapisywanych w trakcie sekundy, kB_read, kB_wrtn — cađkowita liczba odczytanych i zapisanych kilobajtów.

Urzædzenia SCSI, miúdzy innymi napúdy taħmowe i CD-ROM-y, nie sæ obecnie obsđugiwane przez polecenie iostat w systemie Linux. To prowadzi nas do moľliwoħci pewnego obejħcia wymienionego problemu, czyli na przykđad zastosowania skryptu iostat-scsi.stp z SystemTap (patrz odwođanie [3] na koēcu rozdziađu)1. Warto równieľ wspomnieè, ľe choè omawiane polecenie informuje o operacjach odczytu i zapisu urzædzenia blokowego, moľe pomijaè inne rodzaje poleceē urzædzeē dyskowych. Zaleľy to od jædra (zapoznaj siú z funkcjæ blk_do_io_stat()). Jak wczeħniej wspomniano, opcja -m moľe byè wykorzystana do wyħwietlania danych wyjħciowych w megabajtach. W starszych wersjach polecenia iostat (pakiet sysstat 9.0.6 i wczeħniejsze) dane wyjħciowe sæ domyħlnie podawane w 512-bajtowych blokach zamiast w kilobajtach. Przywrócenie starszego zachowania moľna wymusiè za pomocæ poniľszej zmiennej ħrodowiskowej: $ POSIXLY_CORRECT=1 iostat [...] Device: tps Blk_read/s [...]

1

Blk_wrtn/s

Blk_read

Niestety w czasie pisania tej ksiæľki wymieniony skrypt nie dziađađ.

Blk_wrtn

9.6. Analiza

487

Bardziej rozbudowane dane wyjħciowe sæ wyħwietlane po uľyciu opcji -x. Zawierajæ wtedy dodatkowe kolumny uľyteczne w wielu omówionych wczeħniej strategiach. We wspomnianych kolumnach dodatkowych znajdujæ siú metryki w postaci wartoħci IOPS i przepustowoħci, przydatne podczas przygotowywania charakterystyki obciæľenia, jak równieľ metryki dotyczæce poziomu wykorzystania i dđugoħci kolejki, uľyteczne w metodzie USE, a takľe metryki dotyczæce czasu udzielania odpowiedzi przez dysk, przydatne z kolei podczas przygotowywania charakterystyki wydajnoħci i analizy opóļnienia. Przedstawione dalej dane wyjħciowe sæ zbyt szerokie, aby zmieħciđy siú na stronie, dlatego zostađy podzielone na dwie czúħci. W wywođaniu uľyto opcji -d w celu wyħwietlenia jedynie raportu dla dysku, opcji -k powodujæcej wyħwietlanie danych w kilobajtach oraz opcji -z pomijajæcej wiersze zawierajæce tylko zera (urzædzenia bezczynne): $ iostat -xkdz 1 Linux 3.2.6-3.fc16.x86_64 (prod201) 04/14/13 Device: rrqm/s wrqm/s r/s w/s sdb 0.04 1.89 0.01 0.07 sda 0.00 0.00 0.00 0.00 dm-0 0.00 0.00 0.05 0.10

_x86_64_ rkB/s wkB/s 1.56 7.86 0.00 0.00 0.19 0.39

Device: sdb

rrqm/s 0.00

wrqm/s 0.00

r/s 230.00

w/s 0.00

rkB/s 2292.00

wkB/s 0.00

Device: sdb

rrqm/s 0.00

wrqm/s 0.00

r/s 231.00

w/s 0.00

rkB/s 2372.00

wkB/s 0.00

\ / \ / \ / \ / \ /

(16 CPU) ... ... ... ... ... ... ... ... ... ...

Kolumny danych wyjħciowych wyħwietlajæ nastúpujæce informacje: 







rrqm/s — liczba ľædaē odczytu umieszczonych w kolejce sterownika i pođæczonych w ciægu sekundy, wrqm/s — liczba ľædaē zapisu umieszczonych w kolejce sterownika i pođæczonych w ciægu sekundy, r/s — liczba ľædaē odczytu skierowanych w ciægu sekundy do urzædzenia dyskowego, w/s — liczba ľædaē zapisu skierowanych w ciægu sekundy do urzædzenia dyskowego,



rkB/s — liczba kilobajtów odczytanych w ciægu sekundy z urzædzenia dyskowego,



wkB/s — liczba kilobajtów zapisanych w ciægu sekundy w urzædzeniu dyskowym.

Wartoħci niezerowe w kolumnach rrqm/s i wrqm/s pokazujæ, ľe ciægđe ľædania sæ đæczone przed ich przekazaniem do urzædzenia, co poprawia wydajnoħè. Ta metryka jednoczeħnie oznacza wykonywanie operacji sekwencyjnych. Kolumny r/s i w/s pokazujæ ľædania, które rzeczywiħcie zostađy skierowane do urzædzenia.

488

Rozdział 9



Dyski

Oto druga czúħè danych wyjħciowych: $ iostat -xkdz 1 Linux 3.2.6-3.fc16.x86_64 (prod201) Device: sdb sda dm-0 Device: sdb Device: sdb

\ / \ / \ / \ / \ /

... ... ... ... ... ... ... ... ... ...

\ / \ / \ / \ / \ /

04/14/13

_x86_64_

(16 CPU)

avgrq-sz avgqu-sz 227.13 0.00 11.16 0.00 8.00 0.00

await r_await w_await 41.13 4.51 47.65 1.40 1.17 2.04 12.83 3.61 21.05

svctm 0.54 1.40 0.04

%util 0.00 0.00 0.00

avgrq-sz avgqu-sz 19.93 0.99

await r_await w_await 4.30 4.30 0.00

svctm 4.30

%util 99.00

avgrq-sz avgqu-sz 20.54 1.00

await r_await w_await 4.33 4.33 0.00

svctm %util 4.33 100.00

Kolumny danych wyjħciowych wyħwietlajæ nastúpujæce informacje:  











avgrq-sz — ħrednia wielkoħè ľædania wyraľona w sektorach (512 bajtów), avgqu-sz — ħrednia liczba ľædaē oczekujæcych w kolejce sterownika oraz aktywnych w urzædzeniu, await — ħredni czas udzielenia odpowiedzi operacji wejħcia-wyjħcia, obejmujæcy czas oczekiwania w kolejce sterownika oraz czas udzielenia odpowiedzi przez urzædzenia (ms), r_await — ta sama wartoħè, co w kolumnie await, ale dotyczæca jedynie operacji odczytu (ms), w_await — ta sama wartoħè, co w kolumnie await, ale dotyczæca jedynie operacji zapisu (ms), svctm — ħredni czas udzielenia odpowiedzi operacji wejħcia-wyjħcia dla urzædzenia dyskowego (ms), %util — wartoħè procentowa okreħlajæca, przez jakæ czúħè czasu urzædzenie byđo zajúte przetwarzaniem ľædaē operacji wejħcia-wyjħcia (poziom wykorzystania).

Poniewaľ kolumna avgrq-sz podaje wartoħè juľ po pođæczeniu, mniejsze wartoħci (16 sektorów lub mniej) sæ sygnađem wskazujæcym na losowe operacje wejħcia-wyjħcia, których nie moľna byđo pođæczyè. Wiúksze wartoħci mogæ oznaczaè ogromne operacje wejħcia-wyjħcia lub operacje pođæczone sekwencyjne (jak wskazujæ wczeħniejsze kolumny). Najwaľniejsza metryka dotyczæca wydajnoħci jest wyħwietlana w kolumnie await. Jeľeli aplikacja i system plików uľywajæ technik pozwalajæcych zmniejszyè opóļnienia zapisu (na przykđad zapisu skroħnego), wówczas wartoħè w kolumnie w_await nie ma aľ tak duľego znaczenia i moľna siú skoncentrowaè na r_await. Z perspektywy uľycia zasobów i planowania pojemnoħci waľna jest wartoħè kolumny %util, ale pamiútaj, ľe pokazuje ona jedynie stopieē zajútoħci (czas inny niľ bezczynnoħci) i moľe mieè niewielkæ uľytecznoħè w przypadku urzædzeē wirtualnych

9.6. Analiza

489

utworzonych na bazie wielu dysków. Tego rodzaju urzædzenia moľna najlepiej poznaè dziúki zastosowanemu obciæľeniu: IOPS (kolumny r/s i w/s) oraz przepustowoħè (kolumny rkB/s i wkB/s). Kolumny r_await i w_await sæ jednym z nowszych dodatków w poleceniu iostat, wczeħniej byđa dostúpna jedynie kolumna await. Na stronie podrúcznika man poħwiúconej iostat zamieszczono ostrzeľenie, ľe kolumna svctm búdzie usuniúta w kolejnych wydaniach polecenia, poniewaľ wyħwietlana przez niæ metryka jest uznawana za nieodpowiedniæ. (Osobiħcie nie uwaľam jej za nieodpowiedniæ, ale jestem przekonany, ľe mogđa zmyliè niektórych uľytkowników, poniewaľ to wartoħè wywnioskowana, a nie zmierzone opóļnienie urzædzenia). Poniľej przedstawiono inne uľyteczne pođæczenie parametrów: $ iostat -xkdzt -p ALL 1 Linux 3.2.6-3.fc16.x86_64 (prod201) 04/14/2013 10:50:20 PM Device: rrqm/s sdb 0.00 sdb1 0.00 [...]

wrqm/s 0.21 0.21

04/14/13 r/s 0.01 0.01

w/s 0.00 0.00

_x86_64_ rkB/s 0.74 0.74

wkB/s 0.87 0.87

(16 CPU) \ ... / ... \ ...

Opcja -t powoduje dođæczenie znacznika czasu, który búdzie uľyteczny podczas porównywania danych wyjħciowych z innymi zawierajæcymi znaczniki czasu. Z kolei opcja -p ALL powoduje wyħwietlenie danych statystycznych dla poszczególnych partycji. Niestety obecna wersja iostat nie wyħwietla bđúdów dysków. Gdyby nie ten brak, wszystkie metryki metody USE moľna by sprawdziè za pomocæ tylko jednego narzúdzia!

Solaris Wyħwietlenie listy dostúpnych opcji odbywa siú w wyniku uľycia -h (pomimo komunikatu bđúdu informujæcego o podaniu „niedozwolonej opcji”): $ iostat -h iostat: illegal option -- h Usage: iostat [-cCdDeEiImMnpPrstxXYz] [-l n] [-T d|u] [disk ...] [interval [count]] -c: report percentage of time system has spent in user/system/wait/idle mode -C: report disk statistics by controller -d: display disk Kb/sec, transfers/sec, avg. service time in milliseconds -D: display disk reads/sec, writes/sec, percentage disk utilization -e: report device error summary statistics -E: report extended device error statistics -i: show device IDs for -E output -I: report the counts in each interval, instead of rates, where applicable -l n: Limit the number of disks to n

490

Rozdział 9

-m: -M: -n: -p: -P: -r: -s: -T d|u -t: -x: -X: -Y: -z:



Dyski

Display mount points (most useful with -p) Display data throughput in MB/sec instead of Kb/sec convert device names to cXdYtZ format report per-partition disk statistics report per-partition disk statistics only, no per-device disk statistics Display data in comma separated format Suppress state change messages Display a timestamp in date (d) or unix time_t (u) display chars read/written to terminals display extended disk statistics display I/O path statistics display I/O path (I/T/L) statistics Suppress entries with all zero values

Jak moľesz siú przekonaè, dostúpne sæ opcje -e i -E podajæce wartoħci liczników bđúdów. Opcja -I powoduje wyħwietlenie wartoħci liczników zamiast obliczonego podsumowania dla przedziađu czasu. Zwykle jest uľywana przez oprogramowanie monitorujæce, które wywođuje iostat w ustalonych odstúpach czasu, a nastúpnie przeprowadza wđasne obliczenia na podstawie uzyskanych danych wyjħciowych i generuje podsumowanie: $ iostat tty ramdisk1 tin tout kps tps serv 0 10 1 0 0

sd0 kps tps serv 0 0 0

sd1 kps tps serv 5360 111 1

cpu us sy wt id 9 6 0 85

Poczæwszy od lewej strony domyħlne dane wyjħciowe wyħwietlajæ informacje o terminalu danych wejħciowych (tty), znakach danych wyjħciowych (tin, tout), a nastúpnie wyħwietlajæ do trzech grup kolumn (kps, tps i serv) dla urzædzeē dyskowych. Na koēcu znajduje siú grupa danych statystycznych dotyczæcych procesora (cpu). W omawianym przykđadzie pokazane urzædzenia dyskowe to ramdisk1, sd0 i sd1. Wiúcej urzædzeē nie zostanie pokazanych w ten sposób, poniewaľ polecenie iostat próbuje respektowaè ograniczenie szerokoħci danych wyjħciowych do 80 znaków. Poniľej wymieniono kolumny urzædzenia dyskowego: 

kps — kilobajty na sekundú, odczyt i zapis,



tps — transakcje na sekundú (IOPS),



serv — czas usđugi wyraľony w milisekundach.

W kolejnym przykđadzie uľyto opcji -n w celu wyħwietlenia opisowych nazw /dev urzædzeē dyskowych zamiast stosowanych przez jædro nazw egzemplarzy. Opcja -z powoduje pominiúcie wierszy zawierajæcych same zera (urzædzenie bezczynne): $ iostat -xnz 1 r/s 0.1

w/s 0.2

extended device statistics kr/s kw/s wait actv wsvc_t asvc_t 0.7 0.6 0.0 0.0 0.0 0.0

%w 0

%b device 0 ramdisk1

9.6. Analiza

491

12.3

98.7

r/s 1041.7

w/s 8.0

r/s 1911.9

w/s 1.0

r/s 746.1 [...]

w/s 1.0

315.6 5007.8 extended kr/s kw/s 1044.7 95.6 extended kr/s kw/s 1959.4 7.9 extended kr/s kw/s 1016.6 8.0

0.0 0.1 0.0 0.8 device statistics wait actv wsvc_t asvc_t 0.0 0.7 0.0 0.6 device statistics wait actv wsvc_t asvc_t 0.0 0.6 0.0 0.3 device statistics wait actv wsvc_t asvc_t 0.0 0.8 0.0 1.0

0

2 c0t0d0

%w 1

%b device 65 c0t0d0

%w 1

%b device 55 c0t0d0

%w 0

%b device 75 c0t0d0

Kolumny danych wyjħciowych wyħwietlajæ nastúpujæce informacje: 

r/s, w/s — liczba operacji odczytu i zapisu w ciægu sekundy,



kr/s, kw/s — liczba kilobajtów odczytanych i zapisanych w ciægu sekundy,



 







wait — ħrednia liczba ľædaē oczekujæcych w kolejce sterownika urzædzenia blokowego, actv — ħrednia liczba ľædaē wykonanych i aktywnych w urzædzeniu, wsvc_t — wyraľony w milisekundach ħredni czas oczekiwania w kolejce sterownika urzædzenia blokowego (wsvc_t to czas oczekiwania na obsđugú), asvc_t — wyraľony w milisekundach ħredni czas aktywnoħci w urzædzeniu (asvc_t to czas aktywnej obsđugi, choè w rzeczywistoħci to ħredni czas udzielania odpowiedzi przez urzædzenie), %w — procent czasu, przez który operacja wejħcia-wyjħcia znajdowađa siú w kolejce oczekiwania, %b — procent czasu, przez który operacja wejħcia-wyjħcia byđa zajúta (poziom wykorzystania).

Ħrednia wielkoħè operacji odczytu lub zapisu nie jest podawana (w przeciwieēstwie do polecenia iostat w systemie Linux), ale moľna bardzo đatwo jæ obliczyè. Wystarczy podzieliè przez wartoħè IOPS ħredniæ wielkoħè na przykđad odczytu = (kr/s) / (r/s). Poniľej przedstawiono inne uľyteczne pođæczenie parametrów: $ iostat -xnmpzCTd 1 April 14, 2013 08:44:58 AM UTC extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t 1.5 33.9 146.5 1062.6 0.0 0.0 0.0 1.2 0.1 0.0 0.5 0.0 0.0 0.0 0.0 0.1 0.1 0.0 0.5 0.0 0.0 0.0 0.0 0.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 3.6 1.5 33.9 146.0 1062.6 0.0 0.0 0.0 1.2 1.5 33.9 146.0 1062.6 0.0 0.0 0.0 1.2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 6.0 [...]

%w 0 0 0 0 0 0 0

%b 1 0 0 0 1 1 0

device c0 c0t0d0 c0t0d0p0 c0t0d0p1 c0t1d0 c0t1d0s0 c0t1d0p0

492

Rozdział 9



Dyski

Opcja -C powoduje wyħwietlenie danych statystycznych dla poszczególnych kontrolerów, natomiast opcja -p — dla poszczególnych partycji. Z kolei uľycie opcji -Td powoduje umieszczenie znacznika czasu w danych wyjħciowych. Liczniki bđúdów búdæ wyħwietlone w danych wejħciowych po uľyciu opcji -e: $ iostat -xnze 1 r/s w/s 0.0 0.0 0.0 0.0 0.1 0.0 1.5 33.9 [...]

extended device statistics ---- errors --kr/s kw/s wait actv wsvc_t asvc_t %w %b s/w h/w trn tot device 0.1 0.0 0.0 0.0 0.3 0.6 0 0 0 0 0 0 lofi1 0.2 0.1 0.0 0.0 0.0 0.0 0 0 0 0 0 0 ramdisk1 0.5 0.0 0.0 0.0 0.0 0.1 0 0 0 0 0 0 c0t0d0 146.0 1062.6 0.0 0.0 0.0 1.2 0 1 0 0 0 0 c0t1d0

Jeħli nie masz urzædzenia, w którym czústo zdarzajæ siú bđúdy, wyħwietlenie podsumowania dla jedynie pewnego przedziađu czasu nie búdzie aľ tak bardzo uľyteczne. Aby sprawdziè wartoħci liczników wyđæcznie od chwili uruchomienia, uľyj opcji -E, która spowoduje sformatowanie danych wyjħciowych iostat w nieco inny sposób: $ iostat -En c1t0d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: Vendor: iDRAC Product: LCDRIVE Revision: 0323 Serial Size: 0.00GB Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 0 Predictive Failure Analysis: 0 c2t0d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: Vendor: iDRAC Product: Virtual CD Revision: 0323 Serial Size: 0.00GB Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 0 Predictive Failure Analysis: 0 [...]

0 No:

0 No:

Wartoħè Soft Errors (s/w w danych wyjħciowych generowanych wskutek uľycia opcji -e) wskazuje moľliwe do usuniúcia bđúdy, które mogæ spowodowaè problemy z wydajnoħciæ. Z kolei Hard Errors (h/w w danych wyjħciowych generowanych w wyniku uľycia opcji -e) wskazuje bđúdy niemoľliwe do usuniúcia przez dyski, choè moľliwe do usuniúcia na wyľszym poziomie architektury (RAID). To pozwala systemowi kontynuowaè dziađanie, ale niekiedy jednoczeħnie powoduje problemy z wydajnoħciæ (na przykđad opóļnienie zwiæzane z przekroczeniem czasu operacji wejħcia-wyjħcia, a tym samym degradacjú usđugi). Liczniki bđúdów moľna znacznie đatwiej sprawdziè za pomocæ takiego wywođania: $ iostat -En | grep Hard c1t0d0 Soft Errors: c2t0d0 Soft Errors: c2t0d1 Soft Errors: c3t0d0 Soft Errors: c0t0d0 Soft Errors: c0t1d0 Soft Errors:

0 0 0 0 0 0

Hard Hard Hard Hard Hard Hard

Errors: Errors: Errors: Errors: Errors: Errors:

0 0 0 0 0 0

Transport Transport Transport Transport Transport Transport

Errors: Errors: Errors: Errors: Errors: Errors:

0 0 0 0 0 0

9.6. Analiza

493

W metodzie USE moľna zastosowaè polecenie iostat i wykorzystaè wymienione kolumny:  

%b. Pokazuje poziom wykorzystania dysku. actv. Liczba wiúksza niľ 1 jest oznakæ nasycenia, kolejkowania w urzædzeniu. W przypadku urzædzeē wirtualnych utworzonych na bazie wielu urzædzeē fizycznych búdzie to trudne do ustalenia (zaleľy od stosowanej polityki macierzy RAID). Z kolei wartoħè actv wiúksza niľ liczba urzædzeē to duľe prawdopodobieēstwo nasycenia urzædzenia.



wait. Liczba wiúksza niľ 1 jest oznakæ nasycenia, kolejkowania w sterowniku.



errors tot. Cađkowita liczba bđúdów.

Jak przedstawiono w punkcie 9.4.1 we wczeħniejszej czúħci rozdziađu, w dyskach mogæ wystúpowaè bđúdy, które nie spowodujæ inkrementacji licznika bđúdów. Na szczúħcie tego rodzaju sytuacje zdarzajæ siú rzadko i byè moľe nie búdziesz miađ z nimi do czynienia. Oto przykđad takiego wđaħnie problemu: $ iostat -xnz 1 [...] r/s 0.0

w/s 0.0

r/s 0.0

w/s 0.0

r/s 0.0 [...]

w/s 0.0

extended kr/s kw/s 0.0 0.0 extended kr/s kw/s 0.0 0.0 extended kr/s kw/s 0.0 0.0

device statistics wait actv wsvc_t asvc_t 0.0 4.0 0.0 0.0 device statistics wait actv wsvc_t asvc_t 0.0 4.0 0.0 0.0 device statistics wait actv wsvc_t asvc_t 0.0 4.0 0.0 0.0

%w %b device 0 100 c0t0d0 %w %b device 0 100 c0t0d0 %w %b device 0 100 c0t0d0

Zwróè uwagú, ľe dysk jest wykorzystany w 100%, ale nie wykonuje ľadnych operacji wejħcia-wyjħcia (wartoħci 0 w kolumnach r/s i w/s). Ten konkretny przykđad to problem zwiæzany z kontrolerem RAID. Jeľeli búdzie wystúpowađ w krótkich przedziađach czasu, powstanæ wielosekundowe opóļnienia operacji wejħcia-wyjħcia i ujawniæ siú problemy zwiæzane z wydajnoħciæ. Jeľeli problemy te búdæ trwađy dđuľej, búdzie mogđo siú wydawaè, ľe system ulegđ zawieszeniu.

9.6.2. sar Polecenie sar moľna wykorzystaè do sprawdzenia bieľæcej aktywnoħci systemu i miúdzy innymi do wyħwietlenia danych statystycznych dotyczæcych dysków. Istnieje moľliwoħè skonfigurowania narzúdzia w taki sposób, aby archiwizowađo i podawađo takľe historyczne dane statystyczne. To polecenie jest stosowane równieľ w innych rozdziađach, gdy zajdzie potrzeba.

494

Rozdział 9



Dyski

Podsumowanie dotyczæce dysku jest wyħwietlane w wyniku uľycia opcji -d. Zostanie to przedstawione w kolejnych przykđadach, w których wskazano takľe jednosekundowy przedziađ czasu.

Linux Dane wyjħciowe zawierajæce podsumowanie informacji na temat dysku sæ bardzo szerokie i dlatego podzielono je na dwie czúħci: $ sar -d 1 Linux 2.6.32-21-server (prod103) 04/15/2013 02:39:26 AM DEV tps rd_sec/s wr_sec/s 02:39:27 AM dev8-16 0.00 0.00 0.00 02:39:27 AM dev8-0 418.00 0.00 12472.00 02:39:27 AM dev251-0 0.00 0.00 0.00 02:39:27 AM dev251-1 1559.00 0.00 12472.00 02:39:27 AM dev251-2 0.00 0.00 0.00 [...]

_x86_64_ avgrq-sz avgqu-sz 0.00 0.00 29.84 29.35 0.00 0.00 8.00 113.87 0.00 0.00

(8 \ / \ / \ /

CPU) ... ... ... ... ... ...

Oto pozostađe kolumny danych wyjħciowych: $ sar -d 1 Linux 2.6.32-21-server 02:39:26 AM \ ... \ 02:39:27 AM / ... / 02:39:27 AM \ ... \ 02:39:27 AM / ... / 02:39:27 AM \ ... \ 02:39:27 AM / ... / [...]

(prod103) await svctm 0.00 0.00 70.22 0.69 0.00 0.00 73.04 0.19 0.00 0.00

04/15/2013 %util 0.00 29.00 0.00 29.00 0.00

_x86_64_

(8 CPU)

Wiele kolumn jest podobnych do wyħwietlanych przez polecenie iostat (patrz poprzedni punkt), ale z nastúpujæcymi róľnicami:  

tps — transfer danych urzædzenia w ciægu sekundy, rd_sec/s, wr_sec/s — liczba odczytanych i zapisanych 512-bajtowych sektorów w ciægu sekundy.

Solaris Przedstawione wywođanie powoduje uruchomienie polecenia sar ze wskazaniem jednosekundowego przedziađu czasu do zgđoszenia bieľæcej aktywnoħci: $ sar -d 1 SunOS prod072 5.11 joyent_20120509T003202Z i86pc 04/15/2013 02:52:30 device %busy avque r+w/s blks/s avwait 02:52:31 sd0 0 0.0 0 0 0.0 sd1 0 0.0 0 0 0.0 sd2 0 0.0 0 0 0.0

avserv 0.0 0.0 0.0

9.6. Analiza

495

sd3 sd3,a sd3,b

0 0 0

0.0 0.0 0.0

3 0 3

33 0 30

0.0 0.0 0.0

0.1 0.0 0.1

[...]

Kolumny danych wyjħciowych sæ podobne do wyħwietlanych przez polecenie iostat w trybie rozszerzonym, choè majæ inne nazwy. Na przykđad kolumna %busy w danych wyjħciowych iostat nosi nazwú %b, natomiast avwait i avserv w danych wyjħciowych iostat to, odpowiednio, wsvc_t i asvc_t.

9.6.3. pidstat Polecenie pidstat w systemie Linux domyħlnie wyħwietla informacje o poziomie wykorzystania procesora; po uľyciu opcji -d wyħwietlane sæ dane statystyczne dotyczæce dyskowych operacji wejħcia-wyjħcia. Wymienione dane sæ dostúpne dla jædra w wersji 2.6.20 i nowszych, na przykđad: $ pidstat -d 1 22:53:11 22:53:12 22:53:12

PID 10512 10513

kB_rd/s 3366.34 0.00

kB_wr/s kB_ccwr/s 0.00 0.00 6051.49 13813.86

Command tar gzip

22:53:12 22:53:13 22:53:13

PID 10512 10513

kB_rd/s 5136.00 0.00

kB_wr/s kB_ccwr/s 0.00 0.00 4416.00 0.00

Command tar gzip

Dane wyjħciowe zawierajæ miúdzy innymi nastúpujæce kolumny: 

kB_rd/s — liczba kilobajtów odczytanych w trakcie sekundy,



kB_wr/s — liczba kilobajtów zapisanych w trakcie sekundy,



kB_ccwr/s — liczba kilobajtów w ciægu sekundy anulowanych do zapisu (na przykđad zostađy wczeħniej nadpisane).

Jedynie uľytkownik z uprawnieniami root moľe uzyskaè dostúp do danych statystycznych procesów, których nie jest wđaħcicielem. Wspomniane dane sæ odczytywane za pomocæ /proc/PID/io.

9.6.4. DTrace Narzúdzie DTrace moľe byè uľywane do analizowania z poziomu jædra zdarzeē dyskowych operacji wejħcia-wyjħcia, miúdzy innymi operacji wejħcia-wyjħcia interfejsu urzædzenia blokowego, zdarzeē szeregowania, zdarzeē docelowego sterownika wejħcia-wyjħcia, a takľe sterownika urzædzenia wejħcia-wyjħcia. Wymienione moľliwoħci pozwalajæ na przygotowanie charakterystyki obciæľenia i przeprowadzenie analizy opóļnienia. Znajdziesz tutaj wprowadzenie dotyczæce uľycia narzúdzia DTrace do analizy dyskowych operacji wejħcia-wyjħcia w systemach Linux i Solaris. O ile nie zostanie to

496

Rozdział 9



Dyski

wyraļnie okreħlone, polecenia DTrace sæ przeznaczone do wydawania w obu wymienionych systemach operacyjnych. Krótkie, ogólne wprowadzenie do DTrace zaprezentowano w rozdziale 4., zatytuđowanym „Narzúdzia monitorowania”. Dostawcy DTrace uľywani do monitorowania dyskowych operacji wejħcia-wyjħcia zostali wymienieni w tabeli 9.7. Tabela 9.7. Dostawcy DTrace używani podczas analizy operacji wejścia-wyjścia Warstwa

Stabilni dostawcy

Niestabilni dostawcy

Aplikacja

w zależności od aplikacji

pid

Biblioteka systemowa

-

pid

Wywołania systemowe

-

syscall

VFS

fsinfo

fbt

System plików

-

fbt

Interfejs urządzenia blokowego

io

fbt

Sterownik docelowy

-

fbt

Sterownik urządzenia

-

fbt

Jeľeli istnieje moľliwoħè, zawsze naleľy korzystaè z dostawców stabilnych. Jednak dla stosu dyskowych operacji wejħcia-wyjħcia do powaľnej analizy tak naprawdú liczy siú jedynie dostawca io. Sprawdļ, czy dla uľywanego przez Ciebie systemu operacyjnego nie sæ dostúpni znacznie stabilniejsi dostawcy. Jeľeli nie sæ dostúpni, to moľna wykorzystaè interfejs niestabilnych dostawców, choè moľe byè konieczne uaktualnienie skryptów i dostosowanie ich do zmian w oprogramowaniu.

Dostawca io Dostawca io zapewnia moľliwoħè analizy interfejsu urzædzenia blokowego, a ponadto moľna go wykorzystaè do przygotowania charakterystyki dyskowych operacji wejħcia-wyjħcia oraz pomiaru opóļnienia. Dostúpne sæ nastúpujæce sondy:  

io:::start. Ľædanie wejħcia-wyjħcia zostađo skierowane do urzædzenia. io:::done. Ľædanie wejħcia-wyjħcia zostađo ukoēczone przez urzædzenie (informuje o tym przerwanie).



io:::wait-start. Wætek rozpoczyna oczekiwanie na ľædanie wejħcia-wyjħcia.



io:::wait-done. Wætek zakoēczyđ oczekiwanie na ľædanie wejħcia-wyjħcia.

Przedstawione dalej polecenie powoduje wyħwietlenie listy sond dostúpnych w systemie Solaris dla dostawcy io: # dtrace -ln io::: ID PROVIDER 731 io

MODULE genunix

FUNCTION NAME biodone done

9.6. Analiza

732 733 744 745 746 2014 2015 2016 2017 2018 2019

497

io io io io io io io io io io io

genunix genunix genunix genunix genunix nfs nfs nfs nfs nfs nfs

biowait biowait default_physio bdev_strategy aphysio nfs4_bio nfs3_bio nfs_bio nfs4_bio nfs3_bio nfs_bio

wait-done wait-start start start start done done done start start start

Kolumny MODULE i FUNCTION wskazujæ na pođoľenie sond (jako szczegóđy implementacji, nie sæ czúħciæ interfejsu stabilnego). Zwróè uwagú, ľe w systemie Solaris operacje wejħcia-wyjħcia klienta nfs równieľ sæ monitorowane za pomocæ dostawcy io, co wynika z dostúpnych sond moduđu nfs. Sondy charakteryzujæ siú spójnæ listæ argumentów dostarczajæcych szczegóđowych informacji o operacji wejħcia-wyjħcia:  



args[0]->b_count — wyraľona w bajtach wielkoħè operacji wejħcia-wyjħcia, args[0]->b_blkno — wyraľone w blokach przesuniúcie operacji wejħcia-wyjħcia w urzædzeniu, args[0]->b_flags — opcje bitowe, miúdzy innymi B_READ wskazujæca operacje odczytu,



args[0]->b_error — informacje o bđúdach,



args[1]->dev_statname — nazwa urzædzenia i jego numer,



args[1]->dev_pathname — ħcieľka dostúpu do urzædzenia,



args[2]->fi_pathname — ħcieľka dostúpu do pliku (o ile jest znana),



args[2]->fi_fs — typ systemu plików.

Poza udostúpnianiem standardowych, wbudowanych poleceē DTrace wymienione argumenty umoľliwiajæ tworzenie oferujæcych potúľne moľliwoħci jednowierszowych wywođaē DTrace.

Monitorowanie zdarzeń Poniľsze wywođanie przeprowadza monitorowanie wszystkich dyskowych operacji wejħcia-wyjħcia. Dane wyjħciowe zawierajæ identyfikator procesu, nazwú procesu i wielkoħè operacji wejħcia-wyjħcia (w bajtach). # dtrace -n 'io:::start { printf("%d %s %d", pid, execname, args[0]->b_bcount); }' dtrace: description 'io:::start ' matched 6 probes CPU ID FUNCTION:NAME 0 745 bdev_strategy:start 22747 tar 65536 0 745 bdev_strategy:start 22747 tar 65536

498

0 0 0 [...]

Rozdział 9

745 745 745



Dyski

bdev_strategy:start 22747 tar 131072 bdev_strategy:start 22747 tar 131072 bdev_strategy:start 22747 tar 131072

Do wyħwietlenia informacji szczegóđowych o poszczególnych operacjach wejħcia-wyjħcia w przedstawionym wywođaniu uľywane jest polecenie printf(). Dane wyjħciowe pokazujæ, ľe proces tar o identyfikatorze 22747 wykonađ piúè operacji wejħcia-wyjħcia, których wielkoħè wynosiđa 64 KB lub 128 KB. W omawianym przykđadzie wætek aplikacji nadal znajdowađ siú w procesorze podczas wykonywania ľædania operacji wejħciawyjħcia, co widaè za pomocæ wywođania execname. Jeħli zdarzæ siú sytuacje, w których operacje wejħcia-wyjħcia búdæ wykonywane asynchronicznie, wówczas wywođanie zamiast nazwy procesu poda jædro (sched).

Podsumowanie dotyczące wielkości operacji wejścia-wyjścia Prezentowane polecenie wyħwietla podsumowanie dotyczæce wielkoħci operacji wejħcia-wyjħcia wedđug nazw aplikacji: # dtrace -n 'io:::start { @[execname] = quantize(args[0]->b_bcount); }' dtrace: description 'io:::start ' matched 6 probes ^C tar value ------------- Distribution ------------- count 2048 | 0 4096 | 1 8192 | 0 16384 | 0 32768 | 0 65536 |@@@@ 13 131072 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 121 262144 | 0 sched value ------------- Distribution ------------- count 256 | 0 512 | 3 1024 |@@@@@@@ 63 2048 |@@@@@@@@ 72 4096 |@@@@@ 46 8192 |@@@@@ 51 16384 |@@@ 31 32768 |@ 5 65536 | 0 131072 |@@@@@@@@@@@ 100 262144 | 0

Zamiast uľywaè narzúdzia DTrace do podawania wielkoħci ħredniej, minimalnej lub maksymalnej operacji wejħcia-wyjħcia, przedstawione wywođanie generuje wykres pokazujæcy peđny rozkđad. Kolumna value zawiera zakres podawany w bajtach,

9.6. Analiza

499

natomiast kolumna count podaje liczbú operacji wejħcia-wyjħcia mieszczæcych siú w tym zakresie. Podczas analizowanej sesji monitorowania proces o nazwie tar wykonađ 121 operacji wejħcia-wyjħcia o wielkoħci miúdzy 128 KB a 256 KB (od 131 072 B do 262 144 B). Jædro (sched) przedstawia interesujæcy rozkđad (wyglæda jak bimodalny), który na pewno nie moľe byè prawidđowo zrozumiany na podstawie analizy jedynie pojedynczej wartoħci ħredniej. Poza podsumowaniem wedđug nazw procesów (execname) wielkoħè operacji wejħcia-wyjħcia moľna podsumowaè takľe wedđug:  

Nazwy urzædzenia. Do tego celu sđuľy argument args[1]->dev_statname. Kierunku (odczyt/zapis). Do tego celu sđuľy argument args[0]->b_flags & B_READ ? "read" : "write".

Podsumowywanymi wartoħciami mogæ byè takľe charakterystyki inne niľ wielkoħè (args[0]->b_count). Na przykđad moľna przeanalizowaè pođoľenie na dysku w celu pomiaru czasu wyszukiwania operacji wejħcia-wyjħcia.

Podsumowanie czasu wyszukiwania operacji wejścia-wyjścia Podsumowanie czasu wyszukiwania operacji wejħcia-wyjħcia monitoruje czas wyszukiwania pođoľenia danych wskazywanych przez kolejne operacje wejħcia-wyjħcia w tym samym urzædzeniu oraz pochodzæce z tej samej aplikacji. Podsumowanie przyjmuje postaè histogramu wedđug procesów. Wywođanie jest zbyt dđugie na to, ľeby umieħciè je w jednym wierszu i dlatego zostađo zaimplementowane w postaci przedstawionego skryptu (diskseeksize.d) narzúdzia DTrace: #!/usr/sbin/dtrace -s self int last[dev_t]; io:::start /self->last[args[0]->b_edev] != 0/ { this->last = self->last[args[0]->b_edev]; this->dist = (int)(args[0]->b_blkno - this->last) > 0 ? args[0]->b_blkno - this->last : this->last - args[0]->b_blkno; @[pid, curpsinfo->pr_psargs] = quantize(this->dist); } io:::start { self->last[args[0]->b_edev] = args[0]->b_blkno + args[0]->b_bcount / 512; }

Zaprezentowany skrypt oblicza wyraľanæ w sektorach odlegđoħè miúdzy pierwszym sektorem nowej operacji wejħcia-wyjħcia a ostatnim sektorem poprzedniej operacji wejħcia-wyjħcia (wartoħè przesuniúcia poczætkowego + wielkoħè). Monitorowanie odbywa siú dla poszczególnych urzædzeē i wætków (za pomocæ self->), co pozwala na oddzielne analizowanie wzorców obciæľenia dla róľnych procesów.

500

# ./diskseeksize.d dtrace: script './diskseeksize.d' matched 8 probes ^C 3 fsflush value ------------- Distribution ------------2 | 4 |@ 8 | 16 |@@@@@ 32 | 64 | 128 | 256 | 512 | 1024 | 2048 | 4096 | 8192 | 16384 |@@@@@@@@@ 32768 |@@@@ 65536 |@@@@@ 131072 |@@@@@@@@@@@@ 262144 |@@@ 524288 | [...]

Rozdział 9



Dyski

count 0 2 0 15 0 0 0 0 0 0 0 0 0 24 13 15 34 9 0

Przykđad pokazuje operacje wejħcia-wyjħcia wætku fsflush, który zwykle wyszukuje wiúcej niľ 8192 bloki. Wartoħè 0 dla wiúkszoħci rozkđadu zwykle oznacza, ľe wykonywane sæ operacje sekwencyjne.

Podsumowanie opóźnienia operacji wejścia-wyjścia Skrypt disklatency.d monitoruje rozpoczúcie i zakoēczenie zdarzeē blokowych operacji wejħcia-wyjħcia, a nastúpnie przedstawia w postaci histogramu podsumowanie rozkđadu opóļnienia: #!/usr/sbin/dtrace -s io:::start { start[arg0] = timestamp; } io:::done /start[arg0]/ { @["block I/O latency (ns)"] = quantize(timestamp - start[arg0]); start[arg0] = 0; }

Znacznik czasu jest rejestrowany na poczætku operacji, co pozwala na jej koēcu obliczyè wartoħè delta. Sztuczka zastosowana w omawianym skrypcie polega na wygenerowaniu znaczników czasu na poczætku i koēcu operacji. Uľywana jest tablica

9.6. Analiza

501

asocjacyjna, której kluczami sæ unikalne identyfikatory operacji wejħcia-wyjħcia (to wskaļniki do struktury bufora). Oto przykđad uruchomienia skryptu: # ./disklatency.d dtrace: script './disklatency.d' matched 10 probes ^C block I/O latency (ns) value ------------- Distribution ------------- count 2048 | 0 4096 | 26 8192 | 0 16384 | 4 32768 |@@@@ 227 65536 |@@@@@@@@@@@@@@@@@ 1047 131072 |@@@@@@@@@@@@@ 797 262144 |@@@@ 220 524288 |@@ 125 1048576 |@ 40 2097152 | 18 4194304 | 0 8388608 | 0 16777216 | 1 33554432 | 0

W pokazanej sesji monitorowania wiúkszoħè operacji wejħcia-wyjħcia mieħciđa siú w zakresie od 65 536 ns do 262 144 ns (czyli od 0,07 ms do 0,26 ms). Najwolniejsze byđy pojedyncze operacje wejħcia-wyjħcia w zakresie od 16 ms do 33 ms. Tak wygenerowany histogram doskonale spisuje siú podczas identyfikacji elementów odstajæcych opóļnienia operacji wejħcia-wyjħcia. W omawianym przykđadzie pokazano podsumowanie dla wszystkich urzædzeē. Skrypt moľna rozbudowaè w taki sposób, aby generowađ oddzielne histogramy dla poszczególnych urzædzeē, procesów lub na podstawie innych kryteriów.

Stosy operacji wejścia-wyjścia Stos operacji wejħcia-wyjħcia bardzo czústo zlicza ľædania wywođania stosu jædra dla ľædaē wejħcia-wyjħcia kierowanych do sterownika urzædzenia blokowego (pođoľenie sondy io:::start). W systemie Solaris: # dtrace -n 'io:::start { @[stack()] = count(); }' dtrace: description 'io:::start ' matched 6 probes ^C [...] genunix`ldi_strategy+0x4e zfs`vdev_disk_io_start+0x170 zfs`vdev_io_start+0x12 zfs`zio_vdev_io_start+0x7b zfs`zio_next_stage_async+0xae zfs`zio_nowait+0x9

502

Rozdział 9



Dyski

zfs`vdev_queue_io_done+0x68 zfs`vdev_disk_io_done+0x74 zfs`vdev_io_done+0x12 zfs`zio_vdev_io_done+0x1b genunix`taskq_thread+0xbc unix`thread_start+0x8 751 ufs`lufs_read_strategy+0x8a ufs`ufs_getpage_miss+0x2b7 ufs`ufs_getpage+0x802 genunix`fop_getpage+0x47 genunix`segmap_fault+0x118 genunix`fbread+0xc4 ufs`ufs_readdir+0x14b genunix`fop_readdir+0x34 genunix`getdents64+0xda unix`sys_syscall32+0x101 3255

Dane wyjħciowe sæ bardzo obszerne i pokazujæ dokđadnæ ħcieľkú kodu prowadzæcæ od jædra do wykonania dyskowej operacji wejħcia-wyjħcia, a takľe zawierajæ liczniki dla poszczególnych stosów. Tego rodzaju dane wyjħciowe sæ najczúħciej uľyteczne podczas analizy dodatkowych, nieoczekiwanych operacji wejħcia-wyjħcia (asynchronicznych, metadanych) pojawiajæcych siú poza oczekiwanymi dla danego obciæľenia. Stos na górze pokazuje asynchroniczne operacje wejħcia-wyjħcia ZFS (wætku taskq dziađajæcego w potoku ZIO), natomiast stos dolny — synchroniczne operacje wejħcia-wyjħcia UFS wygenerowane przez wywođanie systemowe getdents(). Kolejny przykđad pochodzi z systemu Linux. Tym razem przeprowadzono monitorowanie dynamiczne funkcji jædra submit_bio(); sonda io:::start nadal jest w fazie eksperymentalnej dla tego prototypu: # dtrace -n 'fbt::submit_bio:entry { @[stack()] = count(); }' dtrace: description 'fbt::submit_bio:entry ' matched 1 probe ^C [...] kernel`submit_bio+0x1 kernel`mpage_readpages+0x105 kernel`ext4_get_block kernel`ext4_get_block kernel`__getblk+0x2c kernel`ext4_readpages+0x1d kernel`__do_page_cache_readahead+0x1c7 kernel`ra_submit+0x21 kernel`ondemand_readahead+0x115 kernel`mutex_lock+0x1d kernel`page_cache_sync_readahead+0x33 kernel`generic_file_aio_read+0x4f8 kernel`vma_merge+0x121 kernel`do_sync_read+0xd2 kernel`security_file_permission+0x93

9.6. Analiza

503

kernel`rw_verify_area+0x61 kernel`vfs_read+0xb0 kernel`sys_read+0x4a kernel`system_call_fastpath+0x16 146

Ħcieľka pokazuje wczeħniejsze wywođania, poczæwszy od interfejsu wywođaē systemowych (na dole), przez VFS, bufor stron i system plików ext4. Kaľdy wiersz stosów moľe byè monitorowany oddzielnie za pomocæ monitorowania dynamicznego, oferowanego przez narzúdzie DTrace i jego dostawcú fbt. Przykđad monitorowania funkcji sd_start_cmds() za pomocæ dostawcy fbt znajdziesz w podrozdziale 9.8 „Dostrajanie”.

Zdarzenia SCSI Skrypt scsireasons.d pokazuje monitorowanie na poziomie warstwy SCSI, zgđaszanie zakoēczenia operacji wejħcia-wyjħcia za pomocæ specjalnego kodu SCSI, który wskazuje przyczynú jej zakoēczenia. W tym miejscu przedstawiono jedynie kluczowe fragmenty skryptu, odwođanie do peđnego skryptu znajdziesz w nastúpnym fragmencie: dtrace:::BEGIN { /* * Dane zostaáy wygenerowane za pomocą sed na podstawie definicji * CMD_* pkt_reason w /usr/include/sys/scsi/scsi_pkt.h. */ scsi_reason[0] = "no transport errors- normal completion"; scsi_reason[1] = "transport stopped with not normal state"; scsi_reason[2] = "dma direction error occurred"; scsi_reason[3] = "unspecified transport error"; scsi_reason[4] = "Target completed hard reset sequence"; scsi_reason[5] = "Command transport aborted on request"; scsi_reason[6] = "Command timed out"; [...] fbt::scsi_destroy_pkt:entry { this->code = args[0]->pkt_reason; this->reason = scsi_reason[this->code] != NULL ? scsi_reason[this->code] : ""; [...]

Omawiany skrypt uľywa tablicy asocjacyjnej do translacji liczby cađkowitej wskazujæcej powód zakoēczenia operacji SCSI na postaè komunikatu czytelnego dla czđowieka. Komunikaty takie sæ uľywane przez funkcjú scsi_destroy_pkt(), w której zliczane sæ powody zakoēczenia operacji. W omawianym przypadku podczas monitorowania nie wystæpiđy ľadne bđúdy. # ./scsireasons.d Tracing... Hit Ctrl-C to end. ^C

504

Rozdział 9

SCSI I/O completion reason summary: no transport errors- normal completion SCSI I/O reason errors by disk device and reason: DEVICE ERROR REASON



Dyski

38346 COUNT

Monitorowanie zaawansowane Monitorowanie dynamiczne moľe dostarczyè wielu znacznie dokđadniejszych informacji o stosie operacji wejħcia-wyjħcia, jeħli sæ one niezbúdne do bardziej zaawansowanej analizy. Aby zademonstrowaè próbkú dostúpnych moľliwoħci, w tabeli 9.8 wymieniono skrypty z rozdziađu ksiæľki poħwiúconej narzúdziu DTrace (patrz odwođanie [Gregg 11] na koēcu rozdziađu). Skrypty te sæ dostúpne w internecie (patrz odwođanie [4] na koēcu rozdziađu). Tabela 9.8. Skrypty pozwalające na monitorowanie zaawansowane operacji wejścia-wyjścia pamięci masowej Skrypt

Warstwa Opis

iopattern

blok

Pokazuje dane statystyczne dotyczące dyskowych operacji wejścia-wyjścia, między innymi odsetek operacji losowych.

sdqueue.d

SCSI

Pokazuje czasy oczekiwania w kolejce operacji wejścia-wyjścia. Dane mają postać wykresu rozkładu dla poszczególnych urządzeń.

sdretry.d

SCSI

Narzędzie wskazujące stan prób ponawianych przez urządzenie SCSI.

scsicmds.d

SCSI

Polecenie liczników częstotliwości dotyczące SCSI, wraz z opisami.

scsilatency.d

SCSI

Podsumowanie opóźnienia poleceń SCSI według typu i wyniku.

scsirw.d

SCSI

Różne dane statystyczne dotyczące odczytu/zapisu/synchronizacji SCSI, między innymi liczba bajtów.

scsireasons.d

SCSI

Pokazuje powody zakończenia operacji wejścia-wyjścia SCSI oraz nazwy urządzeń.

satacmds.d

SATA

Polecenie liczników częstotliwości dotyczące SATA, wraz z opisami.

satarw.d

SATA

Różne dane statystyczne dotyczące odczytu/zapisu/synchronizacji SATA, między innymi liczba bajtów.

satareasons.d

SATA

Pokazuje powody zakończenia operacji wejścia-wyjścia SATA oraz nazwy urządzeń.

satalatency.d

SATA

Podsumowanie opóźnienia poleceń SATA według typu i wyniku.

idelatency.d

IDE

Podsumowanie opóźnienia poleceń IDE według typu i wyniku.

iderw.d

IDE

Różne dane statystyczne dotyczące odczytu/zapisu/synchronizacji IDE, między innymi liczba bajtów.

ideerr.d

IDE

Pokazuje powody ukończenia operacji wejścia-wyjścia IDE, wraz z błędami.

mptsasscsi.d

SAS

Pokazuje polecenia SAS SCSI wraz z informacjami szczegółowymi SCSI i mpt.

mptevents.d

SAS

Monitorowanie zdarzeń specjalnych SAS mpt i podanie informacji szczegółowych na ich temat.

mptlatency.d

SAS

Wyświetlenie czasu poleceń SCSI mpt w postaci wykresu rozkładu.

9.6. Analiza

505

Wprawdzie moľliwy stopieē monitorowania jest wrúcz niewiarygodny, ale wiele z wymienionych skryptów monitorowania dynamicznego jest powiæzanych z konkretnymi komponentami jædra i búdzie wymagađo uaktualnieē, aby dopasowaè je do zmian wprowadzanych w nowszych wersjach jædra.

9.6.5. SystemTap W systemie Linux do monitorowania dynamicznego zdarzeē dyskowych operacji wejħcia-wyjħcia moľna wykorzystaè takľe SystemTap. Z kolei za pomocæ dostawcy ioblock moľna przeprowadziè monitorowanie statyczne. Zapoznaj siú z podrozdziađem 4.4 w rozdziale 4. „Narzúdzia monitorowania” oraz z dodatkiem E. Znajdziesz tam informacje pomocne w konwersji wczeħniej przedstawionych skryptów DTrace.

9.6.6. perf W systemie Linux narzúdzie perf (wprowadzone w rozdziale 6. „Procesory”) dostarcza punktów instrumentacji, które moľna wykorzystaè do zebrania pewnych informacji podstawowych. Prezentowane polecenie wyħwietla listú punktów dotyczæcych urzædzeē blokowych: # perf list | grep block: block:block_rq_abort block:block_rq_requeue block:block_rq_complete block:block_rq_insert block:block_rq_issue block:block_bio_bounce block:block_bio_complete block:block_bio_backmerge block:block_bio_frontmerge block:block_bio_queue block:block_getrq block:block_sleeprq block:block_plug block:block_unplug block:block_split block:block_bio_remap block:block_rq_remap

[Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint

event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event]

Na przykđad przedstawione teraz wywođanie monitoruje problemy urzædzenia blokowego przez wyħwietlenie wykresu stosów, co uđatwia ich analizú. Polecenie sleep 10 okreħla dđugoħè sesji monitorowania. # perf [ perf [ perf # perf [...]

record -age block:block_rq_issue sleep 10 record: Woken up 4 times to write data ] record: Captured and wrote 0.817 MB perf.data (~35717 samples) ] report | more

506

Rozdział 9

100.00%



Dyski

tar [kernel.kallsyms] [k] blk_peek_request | --- blk_peek_request do_virtblk_request blk_queue_bio generic_make_request submit_bio submit_bh | |--100.00%-- bh_submit_read | ext4_ext_find_extent | ext4_ext_map_blocks | ext4_map_blocks | ext4_getblk | ext4_bread | dx_probe | ext4_htree_fill_tree | ext4_readdir | vfs_readdir | sys_getdents | system_call | __getdents64

[...]

Dane wyjħciowe sæ bardzo obszerne i prezentujæ dokđadnæ ħcieľkú kodu prowadzæcæ od jædra do wykonania dyskowej operacji wejħcia-wyjħcia. Pokazany fragment dotyczy operacji odczytu katalogu w systemie plików ext4.

9.6.7. iotop Polecenie iotop jest odmianæ polecenia top, ale zawierajæcæ kolumny dotyczæce dyskowych operacji wejħcia-wyjħcia. Pierwsza wersja zostađa przygotowana w 2005 roku dla systemu Solaris (patrz odwođanie [McDougall 06b] na koēcu rozdziađu) i zostađa oparta na narzúdziu DTrace. Byđa to opracowana w stylu top wersja wczeħniejszego polecenia psio, uľywanego we frameworku búdæcym poprzednikiem DTrace. Polecenie iotop i uzupeđniajæce je iosnoop sæ obecnie domyħlnie dostarczane wraz z DTrace w wielu systemach operacyjnych, miúdzy innymi OS X i Oracle Solaris 11. Polecenie iotop jest dostúpne równieľ dla systemu Linux, w którym dziađa, bazujæc na danych statystycznych zbieranych przez jædro (patrz odwođanie [5] na koēcu rozdziađu).

Linux Polecenie iotop wymaga jædra w wersji co najmniej 2.6.20 (lub byè moľe nieco wczeħniejszej, w zaleľnoħci od stanu przenoszonej wersji polecenia) oraz wđæczonych nastúpujæcych opcji jædra: CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING, CONFIG_ ´TASKSTATS i CONFIG_VM_EVENT_COUNTERS.

9.6. Analiza

507

Sposób użycia Istnieje moľliwoħè uľycia róľnych opcji zmieniajæcych wyħwietlane dane wyjħciowe: # iotop -h Usage: /usr/bin/iotop [OPTIONS] [...] Options: --version show program's version number and exit -h, --help show this help message and exit -o, --only only show processes or threads actually doing I/O -b, --batch non-interactive mode -n NUM, --iter=NUM number of iterations before ending [infinite] -d SEC, --delay=SEC delay between iterations [1 second] -p PID, --pid=PID processes/threads to monitor [all] -u USER, --user=USER users to monitor [all] -P, --processes only show processes, not all threads -a, --accumulated show accumulated I/O instead of bandwidth -k, --kilobytes use kilobytes instead of a human friendly unit -t, --time add a timestamp on each line (implies --batch) -q, --quiet suppress some lines of header (implies --batch)

Domyħlnie polecenie iotop usuwa zawartoħè ekranu, a nastúpnie wyħwietla podsumowanie dotyczæce 1 sekundy.

Tryb wsadowy Tryb wsadowy (-b) moľna wykorzystaè w celu dostarczania kolejnych danych wyjħciowych (bez wczeħniejszego usuwania zawartoħci ekranu). Takie rozwiæzanie zademonstrowano w kolejnym przykđadzie, który dotyczy jedynie operacji wejħcia-wyjħcia procesów (-o); wskazany przedziađ czasu to 5 sekund (-d5): # iotop -bod5 Total DISK READ: TID PRIO USER 22400 be/4 root 279 be/3 root 22446 be/4 root Total DISK READ: TID PRIO USER 279 be/3 root 22446 be/4 root 646 be/4 root [...]

4.78 K/s | Total DISK DISK READ DISK WRITE 4.78 K/s 0.00 B/s 0.00 B/s 1657.27 K/s 0.00 B/s 10.16 M/s 0.00 B/s | Total DISK DISK READ DISK WRITE 0.00 B/s 9.55 M/s 0.00 B/s 10.37 M/s 0.00 B/s 272.71 B/s

WRITE: 15.04 M/s SWAPIN IO COMMAND 0.00 % 13.76 % [flush-252:0] 0.00 % 9.25 % [jbd2/vda2-8] 0.00 % 0.00 % beam.smp -K true ... WRITE: 10.75 M/s SWAPIN IO COMMAND 0.00 % 0.01 % [jbd2/vda2-8] 0.00 % 0.00 % beam.smp -K true ... 0.00 % 0.00 % rsyslogd -n -c 5

Przedstawione dane wyjħciowe pokazujæ, ľe proces beam.smp (Riak) przeprowadza operacje zapisu z szybkoħciæ okođo 10 MB/s. Inne uľyteczne opcje to miúdzy innymi: -a powodujæca akumulacjú operacji wejħcia-wyjħcia zamiast podawania wartoħci ħredniej dla przedziađu czasu oraz -o wyħwietlajæca jedynie procesy przeprowadzajæce operacje wejħcia-wyjħcia.

508

Rozdział 9



Dyski

Solaris Polecenie iotop moľe byè dostúpne w katalogu /opt/DTT lub /usr/DTT. Ponadto znajduje siú w pakiecie DTraceToolkit, z którego to w ogóle zostađo zaczerpniúte.

Sposób użycia W tym miejscu pokazano wyħwietlony komunikat informujæcy o sposobie uľycia omawianego polecenia: # iotop -h USAGE: iotop [-C] [-D|-o|-P] [-j|-Z] [-d device] [-f filename] [-m mount_point] [-t top] [interval [count]] -C -D -j -o -P -Z -d -f -m -t

# Nie usuwaj zawartoĞci ekranu. # WyĞwietlenie wartoĞci czasu delta oraz upáywającego. # WyĞwietlenie identyfikatora projektu. # WyĞwietlenie wartoĞci czasu delta dla dysku. # WyĞwietlenie wyraĪonych w procentach informacji o operacjach wejĞcia-wyjĞcia (wartoĞci czasu delta dla dysków). # WyĞwietlenie identyfikatora strefy. device # Podanie nazwy egzemplarza, który bĊdzie analizowany. filename # Analiza jedynie wskazanego pliku. mount_point # Tylko podany system plików. top # WyĞwietlenie tylko najwiĊkszych wartoĞci.

eg, iotop iotop 1 iotop -P

# DomyĞlne dane wyjĞciowe, czyli z 5 sekund. # Próbkowanie przez sekundĊ. # WyĞwietlenie wyraĪonych w procentach informacji o operacjach wejĞcia-wyjĞcia (na podstawie czasu). iotop -m / # Analiza zdarzeĔ jedynie systemu plików /. iotop -t 20 # WyĞwietlenie jedynie 20 wierszy z najwiĊkszymi wartoĞciami. iotop -C 5 12 # WyĞwietlenie wartoĞci 12 piĊciusekundowych próbek.

Działanie domyślne Domyħlnie dane wyjħciowe dotyczæ piúciosekundowego przedziađu czasu, a dane statystyczne sæ podawane w bajtach: # iotop 2013 Mar 16 08:12:00, load: 1.46, UID PID PPID CMD 0 71272 33185 tar

disk_r: 306580 KB, DEVICE MAJ MIN D sd5 83 320 R

disk_w:

0 KB BYTES 314855424

W powyľszym przykđadzie polecenie tar odczytađo z urzædzenia sd5 okođo 300 MB danych w podanym przedziale 5 sekund.

Poziom wykorzystania Opcja -P wyħwietla poziom wykorzystania dysku, natomiast -C powoduje wyħwietlanie kolejnych danych bez usuwania poprzednich:

9.6. Analiza

509

# iotop -CP 1 Tracing... Please wait. 2013 Mar 16 08:18:53, load: 1.46, UID 0

PID 61307

PPID CMD 33185 tar

2013 Mar 16 08:18:54, UID 0 [...]

PID 61307

PPID CMD 33185 tar

load: 1.47,

disk_r:

55714 KB,

disk_w:

DEVICE sd5

MAJ MIN D 83 320 R

%I/O 82

disk_r:

55299 KB,

disk_w:

DEVICE sd5

MAJ MIN D 83 320 R

%I/O 78

0 KB

0 KB

Dane wyjħciowe pokazujæ, ľe dziađanie polecenia tar spowodowađo wykorzystanie dysku sd5 w okođo 80%.

disktop.stp Inna wersja polecenia iotop, o nazwie disktop.stp, zostađa przygotowana dla SystemTap. Nazwa disktop powinna byè usprawnieniem w stosunku do iotop, poniewaľ czæstka io jest mylæca i prawdopodobnie oznacza poziom aplikacji (VFS) lub dysku. Niestety czæstka disk w nazwie disktop.stp odnosi siú do „operacji odczytu lub zapisu dysku z punktu widzenia przestrzeni uľytkownika”, co odbywa siú na skutek monitorowania VFS. Dlatego teľ dane wyjħciowe disktop.stp mogæ w ogóle nie odpowiadaè danym wyjħciowym polecenia iotop w przypadku aplikacji, które intensywnie korzystajæ z bufora systemu plików.

9.6.8. iosnoop Polecenie iosnoop powoduje jednoczesne monitorowanie wszystkich dysków za pomocæ interfejsu urzædzenia blokowego i wyħwietla po jednym wierszu danych wyjħciowych dla kaľdej dyskowej operacji wejħcia-wyjħcia. Róľne opcje polecenia umoľliwiajæ wyħwietlanie dodatkowych danych wyjħciowych. Poniewaľ iosnoop to krótki skrypt DTrace, wiúc moľna go đatwo zmodyfikowaè i dostosowaè do wđasnych potrzeb. Omawiane polecenie jest uľyteczne do przeprowadzania wymienionych wczeħniej dziađaē w zakresie monitorowania oraz do analizy strategii opóļnieē.

Sposób użycia Pokazano tutaj wyħwietlony komunikat informujæcy o sposobie uľycia omawianego polecenia: # iosnoop -h USAGE: iosnoop [-a|-A|-DeghiNostv] [-d device] [-f filename] [-m mount_point] [-n name] [-p PID] iosnoop # DomyĞlne dane wyjĞciowe. -a # WyĞwietlenie (prawie) wszystkich danych. -A # Zapis wszystkich danych, bĊdą rozdzielone spacjami. -D # WyĞwietlenie wartoĞci czasu delta (upáywającego).

510

Rozdział 9

-e -g -i -N -o -s -t -v -d -f -m -n -p

eg,



Dyski

# WyĞwietlenie nazwy urządzenia. # WyĞwietlenie argumentów polecenia. # WyĞwietlenie egzemplarza urządzenia. # WyĞwietlenie liczb, zarówno waĪnych, jak i mniej waĪnych. # WyĞwietlenie wartoĞci czasu delta dla dysku. # WyĞwietlenie czasu rozpoczĊcia operacji. # WyĞwietlenie czasu zakoĔczenia operacji. # WyĞwietlenie czasu zakoĔczenia operacji, ale w postaci ciągu tekstowego. device # Podanie nazwy egzemplarza, który bĊdzie analizowany. filename # Analiza jedynie wskazanego pliku. mount_point # Tylko podany system plików. name # Tylko proces o podanej nazwie. PID # Tylko proces o podanym identyfikatorze.

iosnoop -v iosnoop -N iosnoop -m /

# Znaczniki czasu w postaci czytelnej dla czáowieka. # WyĞwietlanie liczb, zarówno waĪnych, jak i mniej waĪnych. # Analiza zdarzeĔ jedynie systemu plików /.

Monitorowanie dyskowych operacji wejścia-wyjścia Kolejny przykđad pokazuje dyskowe operacje wejħcia-wyjħcia wykonywane podczas uruchamiania (niebuforowanego) edytora tekstów vim: # iosnoop UID PID 100 6602 100 6602 100 6602 100 6602 [...] 100 6602 100 6602 100 6602 100 6602 100 6602 100 6602 100 6602 100 6602 [...]

D BLOCK R 20357048 R 20356920 R 76478 R 14848848

SIZE 4096 4096 1024 4096

COMM bash vim vim vim

R 20357024 R 3878942 R 20356944 R 4062944 R 4074064 R 4072464 R 20356960 R 4104304

12288 1024 8192 1024 6144 2048 4096 1024

vim vim vim vim vim vim vim vim

PATHNAME /usr/opt/sfw/bin/vim /usr/opt/sfw/bin/vim /usr/sfw/lib/libgtk-1.2.so.0 /usr/sfw/lib/libgtk-1.2.so.0.9.1 /usr/opt/sfw/bin/vim /usr/opt/sfw/share /usr/opt/sfw/bin/vim /usr/opt/sfw/share/terminfo /usr/opt/sfw/share/terminfo/d /usr/opt/sfw/share/terminfo/d/dtterm /usr/opt/sfw/bin/vim /usr/opt/sfw/share/vim

Dane wyjħciowe zawierajæ nastúpujæce kolumny: 

PID — identyfikator procesu,



COMM — nazwa procesu,



D — kierunek operacji (R = odczyt, W = zapis),



BLOCK — adres bloku na dysku (sektor),



SIZE — wielkoħè operacji wejħcia-wyjħcia (wyraľona w bajtach),



PATHNAME — ħcieľka dostúpu do pliku w systemie plików (o ile jest dostúpna i znana).

9.6. Analiza

511

W przedstawionym przykđadnie monitorowanie dotyczyđo systemu plików UFS, dla którego ħcieľki dostúpu sæ zwykle znane. Zdarzajæ siú sytuacje, gdy pozostajæ nieznane, na przykđad dla metadanych systemu plików UFS oraz obecnie dla wszystkich operacji wejħcia-wyjħcia systemu plików ZFS. Zgđoszono ľædanie dodania funkcji w postaci obsđugi nazw ħcieľek przez dostawcú narzúdzia DTrace, na podstawie którego opracowano polecenie iosnoop. (Na razie nazwy ħcieľek ZFS moľna ustalaè za pomocæ monitorowania dynamicznego jædra).

Znaczniki czasu Przedstawiony przykđad dotyczy bazy danych Riak w chmurze (uľywana jest maszyna wirtualna Erlang — beam.smp). System plików to ZFS, który uľywa dysku wirtualnego dostarczanego przez sprzútowy kontroler pamiúci masowej. # iosnoop -Dots STIME(us) TIME(us) 1407309985123 1407309991565 1407309991930 1407310004498 1407310001067 1407310004955 1407309998479 1407310008407 1407309976205 1407310008875 1407310006093 1407310013903 1407310006020 1407310014495 1407310009203 1407310016667 1407310008714 1407310018792 1407310017175 1407310023456 [...]

DELTA(us) 6441 12567 3888 9928 32670 7810 8474 7464 10077 6280

DTIME(us) 3231 12933 457 3452 467 5028 591 2172 2124 4663

UID 103 103 103 103 103 103 103 103 103 103

PID 20008 20008 20008 20008 20008 20008 20008 20008 20008 20008

D R R R R R R R R R R

BLOCK SIZE ... 1822533465 131072 564575763 131072 1568995398 131072 299165216 131072 1691114933 131072 693606806 131072 693607318 131072 1065600468 131072 927976467 131072 1155898834 131072

Dane wyjħciowe sæ znacznie szersze, wiúc zostađy skrócone, aby zmieħciđy siú w ksiæľce — niewidoczne kolumny po prawej stronie to miúdzy innymi COMM PATHNAME. We wszystkich kolumnach wartoħciæ jest beam.smp . Dane wyjħciowe wskazujæ na obciæľenie w postaci operacji odczytu o wielkoħci 128 KB losowych adresów bloków. Potwierdzenie tego rodzaju obciæľenia moľna uzyskaè za pomocæ danych wyjħciowych polecenia iostat: # iostat -xnz 1 [...] r/s 204.9

extended device statistics w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 26232.2 0.0 0.0 1.2 0.0 6.1 0 74 c0t1d0

Jednak dane wyjħciowe polecenia iostat nie pokazujæ wariancji czasu udzielania odpowiedzi operacji wejħcia-wyjħcia, które znajdziemy w danych iosnoop — kolumna DELTA(us); te wartoħci sæ wyraľone w mikrosekundach. W omawianym przykđadzie wykonanie operacji wejħcia-wyjħcia zajmowađo od 3888 μs do 32 670 μs. Kolumna DTIME(us) pokazuje czas ukoēczenia operacji wejħcia-wyjħcia poprzedniego zdarzenia dyskowego jako oszacowanie rzeczywistego czasu obsđugi danej operacji wejħcia-wyjħcia.

512

Rozdział 9



Dyski

Dana wyjħciowe iosnoop sæ z grubsza posortowane wedđug czasu zakoēczenia operacji podawanego przez kolumnú TIME(us). Zwróè uwagú, ľe czas rozpoczúcia operacji STIME(us) niekoniecznie búdzie podawany w tej samej kolejnoħci. To wyraļny dowód, ľe urzædzenie dyskowe zmienia kolejnoħè wykonywania ľædaē. Ľædanie wykonania najwolniejszej operacji wejħcia-wyjħcia zostađo wydane okođo 1407309976205, co jest czasem wczeħniejszym niľ wczeħniej ukoēczona operacja wejħcia-wyjħcia, której ľædanie wykonania wydano o 1407310001067. W przypadku tradycyjnych dysków twardych przyczynú zmiany kolejnoħci wykonywania ľædaē moľna bardzo czústo poznaè, analizujæc adres dysku (BLOCK) i uwzglúdniajæc algorytm wyszukiwania cylindrycznego. W prezentowanym przykđadzie to nie jest takie oczywiste, poniewaľ dysk wirtualny zostađ zbudowany na bazie wielu dysków fizycznych, a wartoħè przesuniúcia mapowania jest znana jedynie kontrolerowi dysku. W obciæľonych serwerach produkcyjnych dane wyjħciowe polecenia iosnoop mogæ siúgaè setek wierszy po zaledwie kilku sekundach monitorowania. To jest uľyteczne (pozwala na dokđadne sprawdzenie tego, co siú dzieje), ale jednoczeħnie wymaga duľej iloħci czasu potrzebnego na przejrzenie zebranych danych. Rozwaľ wiúc wizualizacjú danych wyjħciowych za pomocæ innych narzúdzi (na przykđad omówionych w punkcie 9.6.12, przeznaczonych do tworzenia wykresów), co umoľliwia przeprowadzenie analizy w znacznie krótszym czasie.

9.6.9. blktrace Polecenie blktrace pozwala na monitorowanie w systemie Linux zdarzeē wejħciawyjħcia urzædzeē blokowych. Zawiera komponent jædra przeznaczony do monitorowania i buforowania danych (zostađ póļniej przeniesiony do punktów monitorowania), a takľe ma moľliwoħè kontrolowania i przekazywania danych poleceniom w przestrzeni uľytkownika, miúdzy innymi: blktrace, blkparse i btrace. Polecenie blktrace umoľliwia monitorowanie sterownika blokowego jædra i pobieranie niezmodyfikowanych danych, które nastúpnie moľna przetworzyè za pomocæ blkparse i wygenerowaè tym samym czytelne dane wyjħciowe. Dla wygody uľytkownika polecenie btrace uruchamia blktrace i blkparse. Dlatego teľ oba wymienione poniľej wywođania sæ swoimi odpowiednikami: # blktrace -d /dev/sda -o - | blkparse -i # btrace /dev/sda

Domyślne dane wyjściowe Przedstawione wywođanie pokazuje domyħlne dane wyjħciowe polecenia btrace i powoduje przechwycenie spowodowanego przez polecenie cksum pojedynczego zdarzenia odczytu z dysku: # btrace 8,16 8,16 8,16

/dev/sdb 3 1 3 2 3 3

0.429604145 20442 0.429604569 20442 0.429606014 20442

A Q G

R 184773879 + 8 10.2.0.2.33771: Flags [P.], seq

556

Rozdział 10



Sieć

4235343542:4235343734, ack 4053030377, win 132, options [nop,nop,TS val 328647671 ecr 2313764364], length 192 01:20:46.769470 IP 10.2.0.2.33771 > 10.2.203.2.22: Flags [.], ack 192, win 501, options [nop,nop,TS val 2313764392 ecr 328647671], length 0 01:20:46.787673 IP 10.2.203.2.22 > 10.2.0.2.33771: Flags [P.], seq 192:560, ack 1, win 132, options [nop,nop,TS val 328647672 ecr 2313764392], length 368 01:20:46.788050 IP 10.2.0.2.33771 > 10.2.203.2.22: Flags [.], ack 560, win 501, options [nop,nop,TS val 2313764394 ecr 328647672], length 0 01:20:46.808491 IP 10.2.203.2.22 > 10.2.0.2.33771: Flags [P.], seq 560:896, ack 1, win 132, options [nop,nop,TS val 328647674 ecr 2313764394], length 336 [...]

Przedstawione dane wyjħciowe zawierajæ wiersze podsumowujæce kaľdy pakiet, miúdzy innymi informacje szczegóđowe o adresach IP, portach TCP oraz inne szczegóđy zwiæzane z nagđówkiem TCP. Poniewaľ przechwytywanie pakietów to operacja intensywnie wykorzystujæca procesor, wiúkszoħè implementacji oferuje moľliwoħè pomijania zdarzeē zamiast ich przechwytywania, gdy system jest przeciæľony. Liczba zagubionych pakietów moľe byè umieszczona w dzienniku zdarzeē. Pomijajæc uľycie buforów cyklicznych, implementacje przechwytywania pakietów bardzo czústo umoľliwiajæ stosowanie wyraľeē filtrujæcych podawanych przez uľytkownika i przeprowadzajæ filtrowanie w jædrze. W ten sposób, ze wzglúdu na nieprzekazywanie niechcianych pakietów na poziom uľytkownika, zmniejsza siú obciæľenie.

10.5.7. Analiza TCP Oprócz zagadnieē przedstawionych w punkcie 10.5.4, we wczeħniejszej czúħci rozdziađu, przeanalizowaè moľna jeszcze inne zachowania TCP, miúdzy innymi: 

uľycie w TCP buforów dla odbieranych i wysyđanych danych,



uľycie w TCP kolejek backlog,



pakiety zagubione przez jædro na skutek zapeđnienia kolejki backlog,



wielkoħè okna przeciæľenia, w tym takľe zerowe rozgđoszenia,



pakiety SYN otrzymane w trakcie TCP TIME-WAIT1.

Ostatni z wymienionych punktów moľe staè siú przyczynæ problemu zwiæzanego ze skalowalnoħciæ, gdy serwer búdzie czústo nawiæzywađ pođæczenie z innym serwerem na tym samym porcie oraz uľywajæc tych samych adresów IP: ļródđowego i docelowego. Jedynym czynnikiem róľniæcym poszczególne pođæczenia jest port ļródđowy klienta — tak zwany ephemeral port, który dla TCP jest 16-bitowæ wartoħciæ i moľe byè ograniczony jeszcze przez parametry systemu operacyjnego (minimum i maksimum). W pođæczeniu z przedziađem czasu TCP TIME-WAIT, który moľe wynieħè 60 sekund, 1

Wprawdzie w dokumencie RFC 793 (patrz odwođanie [RFC 793] na koēcu rozdziađu) uľywane jest wyraľenie TIME-WAIT, ale bardzo czústo jest ono spotykane (i programowane) jako TIME_WAIT.

10.5. Metodologia

557

wiúksza liczba pođæczeē (ponad 65 536 w ciægu 60 sekund) moľe kolidowaè z nowymi pođæczeniami. W omawianym przypadku pakiet SYN búdzie wysđany do portu ephemeral nadal powiæzanego z poprzedniæ sesjæ TCP, znajdujæcæ siú w stanie TIME-WAIT, a nowy pakiet SYN búdzie odrzucony na skutek jego bđúdnej identyfikacji jako czúħci poprzedniego pođæczenia (kolizja). Aby uniknæè tego rodzaju problemu, jædro systemu Linux próbuje ponownie uľywaè pođæczeē (co zwykle doskonale siú sprawdza).

10.5.8. Analiza drążąca Jeľeli zachodzi potrzeba, to moľna przeanalizowaè wewnútrzne komponenty jædra dotyczæce stosu sieciowego. Podczas takiej analizy moľna przejħè w dóđ aľ do warstw przetwarzajæcych pakiety w sterowniku interfejsu sieciowego. Wewnútrzne komponenty sæ skomplikowane, a sama analiza dræľæca búdzie zajúciem wymagajæcym poħwiúcenia duľej iloħci czasu. Poniľej wymieniono powody przeprowadzania analizy dræľæcej: 





Sprawdzenie, czy jest potrzeba zmiany wartoħci modyfikowanych parametrów sieci (zamiast zmieniaè je eksperymentalnie). Potwierdzenie, ľe dostúpne w jædrze funkcje dotyczæce wydajnoħci sieci dziađajæ. Przykđadem tego rodzaju funkcji moľe byè IP fanout lub koalescencja przerwaē. Sprawdzenie powodów gubienia pakietów przez jædro.

Analiza wykonywania funkcji jædra powiæzanych ze stosem sieci zwykle obejmuje zastosowanie monitorowania dynamicznego.

10.5.9. Statyczne dostosowanie wydajności Statyczne dostrojenie wydajnoħci koncentruje siú na kwestiach pojawiajæcych siú w skonfigurowanym ħrodowisku. W przypadku analizy wydajnoħci sieci konieczne jest przeanalizowanie nastúpujæcych aspektów konfiguracji statycznej: 

Ile jest dostúpnych do uľycia interfejsów sieciowych? Czy obecnie sæ uľywane?



Jaka jest maksymalna szybkoħè interfejsów sieciowych?



Jaka jest obecna, wynegocjowana szybkoħè interfejsów sieciowych?



Czy interfejsy sieciowe zostađy wynegocjowane do dziađania w trybie póđdupleksu czy peđnego dupleksu?



Jaka jest obecna wartoħè MTU dla interfejsów sieciowych?



Czy interfejsy sieciowe sæ obciæľone?



Jakie modyfikowalne parametry istniejæ dla sterownika urzædzenia? Warstwa IP? Warstwa TCP?



Czy któremukolwiek ze wspomnianych parametrów zmieniono wartoħè domyħlnæ?



Jak przedstawia siú konfiguracja routingu? Jaka jest brama domyħlna?

558

Rozdział 10





 







Sieć

Jaka jest maksymalna przepustowoħè komponentów sieciowych znajdujæcych siú na ħcieľce danych (wszystkich komponentów, đæcznie z przeđæcznikami i routerami)? Czy wđæczono opcjú przekazywania portów? Czy system dziađa w charakterze routera? Jak przedstawia siú konfiguracja DNS? Czy serwer DNS znajduje siú daleko? Czy istniejæ jakiekolwiek znane problemy (bđúdy) zwiæzane z wydajnoħciæ uľywanej wersji firmware’u interfejsu sieciowego? Czy istniejæ jakiekolwiek znane problemy (bđúdy) zwiæzane z wydajnoħciæ uľywanej wersji sterownika urzædzenia sieciowego lub stosu TCP/IP znajdujæcego siú w jædrze? Czy stosowane sæ jakiekolwiek mechanizmy ograniczeē przepustowoħci (kontroli zasobów)? Jakie to sæ ograniczenia?

Udzielenie odpowiedzi na postawione pytania moľe ujawniè przeoczone wczeħniej opcje konfiguracyjne. Ostatnie pytanie jest szczególnie waľne w ħrodowiskach przetwarzanie w chmurze, poniewaľ tam przepustowoħè sieci moľe byè ograniczana.

10.5.10. Kontrola zasobów System operacyjny moľe dostarczaè narzúdzi pozwalajæcych na dokđadne okreħlenie ograniczeē w zakresie alokacji zasobów sieciowych dla procesów lub grup procesów. Moľe to oznaczaè istnienie wymienionych rodzajów ograniczeē: 



Ograniczenie przepustowoħci sieciowej. Dozwolona (maksymalna) przepustowoħè dla róľnych protokođów lub aplikacji. Jest to ograniczenie nakđadane przez jædro. IP QoS (ang. Quality of Service). Nadawanie priorytetów ruchowi sieciowemu. To jest ograniczenie nakđadane przez komponenty sieciowe, na przykđad routery. Ograniczenie moľe byè zaimplementowane na wiele sposobów. Nagđówek IP zawiera bity ToS (ang. Type of Service), miúdzy innymi priorytet. Wspomniane bity zostađy przedefiniowane w nowszych schematach QoS, miúdzy innymi Differentiated Services (patrz odwođanie [RFC 2474] na koēcu rozdziađu). Mogæ istnieè jeszcze inne priorytety zaimplementowane przez inne warstwy protokođu i sđuľæce do tego samego celu.

W sieci moľe wystúpowaè róľny ruch, zakwalifikowany jako o niskim lub wysokim priorytecie. Ruch o niskim priorytecie to na przykđad tworzenie kopii zapasowej przez sieè lub ruch zwiæzany z monitorowaniem wydajnoħci. Z kolei ruch o wysokim priorytecie moľe wystúpowaè miúdzy serwerem produkcyjnym a klientami. W celu ograniczenia ruchu o niskim priorytecie moľna zastosowaè dowolny mechanizm kontroli zasobów i tym samym zapewniè wiúkszæ wydajnoħè ruchowi o wiúkszym priorytecie.

10.6. Analiza

559

Wiúcej informacji szczegóđowych na temat implementacji takiego rozwiæzania znajdziesz w podrozdziale 10.8, zatytuđowanym „Dostrajanie”.

10.5.11. Mikrotesty wydajności Istnieje wiele narzúdzi pozwalajæcych na przeprowadzanie mikrotestów wydajnoħci sieci. Szczególnie uľyteczne sæ podczas analizowania problemów zwiæzanych z przepustowoħciæ w ħrodowiskach aplikacji rozproszonych. Wspomniana analiza ma potwierdziè, ľe sieè osiæga przynajmniej oczekiwanæ przepustowoħè. Jeľeli tak nie jest, wydajnoħè sieci moľna dalej studiowaè za pomocæ narzúdzi przeznaczonych do przeprowadzania mikrotestów wydajnoħci. Najczúħciej búdzie to rozwiæzanie znacznie mniej skomplikowane i szybsze niľ debugowanie aplikacji. Po dostrojeniu sieci i osiægniúciu oczekiwanej szybkoħci jej dziađania moľna skoncentrowaè uwagú ponownie na aplikacji. Poniľej wymieniono czynniki, które naleľy uwzglúdniè w trakcie mikrotestów wydajnoħci: 

kierunek: wysyđanie lub odbieranie danych,



protokóđ: TCP lub UDP, ponadto port,



liczba wætków,



wielkoħè bufora,



wielkoħè wartoħci MTU dla interfejsu sieciowego.

Szybsze interfejsy sieciowe, na przykđad 10 Gb/s, mogæ wymagaè u klienta pracy wielu wætków, aby zapewniè dziađanie z maksymalnæ przepustowoħciæ. Przykđad narzúdzia (perf) przeznaczonego do przeprowadzania mikrotestów wydajnoħci sieci znajdziesz w punkcie 10.7.1 w dalszej czúħci rozdziađu.

10.6. Analiza W tym podrozdziale zostanæ zaprezentowane narzúdzia analizy wydajnoħci sieci w systemach operacyjnych Linux i Solaris. Strategie uľycia omawianych tutaj narzúdzi znajdziesz w poprzednim podrozdziale. 

W tabeli 10.4 wymieniono narzúdzia, które búdæ uľywane w bieľæcym podrozdziale.

Wymienione narzúdzia zostađy wybrane pod kætem moľliwoħci obsđugi metodologii przedstawionych w podrozdziale 10.5. Na poczætku listy znajdujæ siú narzúdzia monitorowania na poziomie cađego systemu. W dalszej kolejnoħci umieszczono narzúdzia do przechwytywania pakietów i monitorowania zdarzeē. Omówienie funkcji poszczególnych narzúdzi znajdziesz w dokumentacji, miúdzy innymi na stronach podrúcznika man.

560

Rozdział 10



Sieć

Tabela 10.4. Polecenia służące do analizy wydajności sieci Linux

Solaris

Opis

netstat

netstat

Różne dane statystyczne dotyczące stosu sieciowego i interfejsów sieciowych.

sar

-

Różne dane statystyczne, w tym również historyczne.

ifconfig

ifconfig

Konfiguracja interfejsu sieciowego.

ip

dladm

Dane statystyczne dotyczące interfejsu sieciowego.

nicstat

nicstat

Przepustowość i poziom wykorzystania interfejsu sieciowego.

ping

ping

Sprawdzenie możliwości nawiązania połączenia sieciowego.

traceroute

traceroute

Przetestowanie tras sieciowych.

pathchar

pathchar

Określenie charakterystyki ścieżki sieciowej.

tcpdump

snoop/tcpdump

Podsłuchiwanie pakietów sieciowych.

Wireshark

Wireshark

Narzędzie do graficznej analizy pakietów.

dtrace, perf

dtrace

Monitorowanie stosu TCP/IP: połączenia, pakiety, zagubione pakiety, opóźnienia.

10.6.1. netstat Polecenie netstat wyħwietla róľne dane statystyczne o sieci. Rodzaj wyħwietlanych danych zaleľy od uľytych opcji. Polecenie przypomina narzúdzie o wielu moľliwoħciach z róľnymi funkcjami. Poniľej wymieniono wybrane opcje: 

(domyĂlnie) — wyħwietlenie listy pođæczonych gniazd,



-a — wyħwietlenie informacji o wszystkich gniazdach,



-s — wyħwietlenie danych statystycznych dotyczæcych stosu sieciowego,



-i — wyħwietlenie danych statystycznych na temat interfejsu sieciowego,



-r — wyħwietlenie tabeli routingu.

Inne opcje mogæ spowodowaè modyfikacje danych wyjħciowych. Na przykđad zastosowanie opcji -n zapobiega zamianie adresu IP na nazwú komputera, natomiast uľycie opcji -v powoduje wyħwietlenie informacji szczegóđowych, o ile sæ dostúpne. Dane wyjħciowe generowane przez polecenie netstat nieco siú róľniæ w poszczególnych systemach operacyjnych.

Linux Poniľej zaprezentowano przykđad danych wyjħciowych zawierajæcych dane statystyczne o interfejsie:

10.6. Analiza

$ netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR eth0 1500 0 933760207 0 0 0 eth3 1500 0 718900017 0 0 0 lo 16436 0 21126497 0 0 0 ppp5 1496 0 4225 0 0 0 ppp6 1496 0 1183 0 0 0 tun0 1500 0 695581 0 0 0 tun1 1462 0 0 0 0 0

561

TX-OK TX-ERR TX-DRP TX-OVR Flg 1090211545 0 0 0 BMRU 587534567 0 0 0 BMRU 21126497 0 0 0 LRU 3736 0 0 0 MOPRU 1143 0 0 0 MOPRU 692378 0 0 0 MOPRU 4 0 0 0 PRU

Kolumny w przedstawionych danych zawierajæ informacje o interfejsie sieciowym (Iface), wartoħci MTU, a takľe seriú metryk dotyczæcych danych otrzymywanych (RX-) i wysyđanych (TX-): 

OK — pakiety, których transfer zakoēczyđ siú powodzeniem,



ERR — bđúdy pakietów,



DRP — pakiety zagubione,



OVR — przepeđnienia.

Pakiety zagubione i przepeđnienia wskazujæ na nasycenie interfejsu sieciowego i wraz z bđúdami mogæ byè poddane dalszej analizie jako czúħè metody USE. Tryb pracy ciægđej (opcja -c) moľe byè uľyty wraz z opcjæ -i — powoduje to wyħwietlenie co sekundú skumulowanych wartoħci liczników. W ten sposób otrzymujesz dane potrzebne do obliczenia czústotliwoħci pakietów. To jest przykđad wygenerowanych przez polecenie netstat danych statystycznych (skróconych) dotyczæcych stosu sieciowego: $ netstat -s Ip: 2195174600 total packets received 1896 with invalid headers 996084485 forwarded 4315 with unknown protocol 0 incoming packets discarded 1197785508 incoming packets delivered 1786035083 requests sent out 11 outgoing packets dropped 589 fragments dropped after timeout 465974 reassemblies required 232690 packets reassembled ok [...] Tcp: 102171 active connections openings 126729 passive connection openings 11932 failed connection attempts 19492 connection resets received 27 connections established

562

Rozdział 10

627019277 segments received 325718869 segments send out 346436 segments retransmited 5 bad segments received. 24172 resets sent Udp: 12331498 packets received 35713 packets to unknown port received. 0 packet receive errors 67417483 packets sent TcpExt: 1749 invalid SYN cookies received 2665 resets received for embryonic SYN_RECV sockets 7304 packets pruned from receive queue because of socket buffer overrun 2565 ICMP packets dropped because they were out-of-window 78204 TCP sockets finished time wait in fast timer 67 time wait sockets recycled by time stamp 901 packets rejects in established connections because of timestamp 2667251 delayed acks sent 2897 delayed acks further delayed because of locked socket Quick ack mode was activated 255240 times 1051749 packets directly queued to recvmsg prequeue. 4533681 bytes directly in process context from backlog 953003585 bytes directly received in process context from prequeue 372483184 packet headers predicted 695654 packets header predicted and directly queued to user 14056833 acknowledgments not containing data payload received 235440239 predicted acknowledgments 64430 times recovered from packet loss by selective acknowledgements 167 bad SACK blocks received Detected reordering 60 times using FACK Detected reordering 132 times using SACK Detected reordering 36 times using time stamp 40 congestion windows fully recovered without slow start 366 congestion windows partially recovered using Hoe heuristic 10 congestion windows recovered without slow start by DSACK 60182 congestion windows recovered without slow start after partial ack 252507 TCP data loss events TCPLostRetransmit: 1088 1 timeouts after reno fast retransmit 9781 timeouts after SACK recovery 337 timeouts in loss state 125688 fast retransmits 2191 forward retransmits 8423 retransmits in slow start 122301 other TCP timeouts 598 SACK retransmits failed 1 times receiver scheduled too late for direct processing 5543656 packets collapsed in receive queue due to low socket buffer [...]



Sieć

10.6. Analiza

563

Zaprezentowane dane wyjħciowe zawierajæ róľne dane statystyczne o sieci, w wiúkszoħci pochodzæce z TCP i zgrupowane wedđug protokođu. Na szczúħcie wiele z nich ma dđugie, opisowe nazwy, co pozwala na prawidđowe rozszyfrowanie przedstawianych danych. Niestety dane wyjħciowe sæ niespójne i majæ bđúdy júzykowe — to niewygoda podczas przetwarzania wspomnianych danych w sposób programowy. Wybrane metryki wydajnoħci zostađy wyħwietlone pogrubionæ czcionkæ, aby w ten sposób pokazaè rodzaj dostúpnych informacji. Wiele informacji wymaga dobrej znajomoħci zachowania TCP, miúdzy innymi nowszych funkcji oraz algorytmów wprowadzonych w ostatnich latach. Poniľej wymieniono pewne metryki, które warto sprawdziè: 







Wysoki wspóđczynnik wyraľajæcy stosunek przekazanych pakietów do cađkowitej liczby otrzymanych pakietów: sprawdļ, czy serwer zostađ skonfigurowany do przekazywania (routingu) pakietów. Nawiæzywanie pođæczeē pasywnych — moľna to monitorowaè, aby sprawdziè obciæľenie w kategoriach pođæczeē pochodzæcych od klientów. Wysoki wspóđczynnik wyraľajæcy stosunek retransmitowanych segmentów do cađkowitej liczby wysđanych segmentów — moľe to wskazywaè na zawodnæ sieè. Tego rodzaju zachowanie jest oczekiwane w przypadku klientów pochodzæcych z internetu. Pakiety usuwane z kolejki otrzymanych pakietów ze wzglúdu na przepeđnienie bufora gniazda — to jest sygnađ ħwiadczæcy o nasyceniu sieci. Rozwiæzaniem moľe byè zwiúkszenie bufora gniazda — przy zađoľeniu, ľe dostúpna jest wystarczajæca iloħè zasobów systemowych dla aplikacji.

W nazwach niektórych danych statystycznych sæ bđúdy júzykowe. Ich poprawienie moľe byè problemem, jeħli inne narzúdzia monitorowania zostađy zbudowane na podstawie tych samych danych wyjħciowych. Wspomniane narzúdzia mogæ dziađaè lepiej, traktujæc interfejs /proc jako ļródđo uľywanych danych statystycznych, na przykđad /proc/net/snmp i /proc/net/netstat: $ grep ^Tcp /proc/net/snmp Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 1 200 120000 -1 102378 126946 11940 19495 24 627115849 325815063 346455 5 24183

Wymienione dane statystyczne, pochodzæce z /proc/net/snmp, sæ przeznaczone równieľ dla informacji MIB (ang. Management Information Base) protokođu SNMP — informacje te zapewniajæ dalszæ dokumentacjú dotyczæcæ przeznaczenia poszczególnych danych statystycznych. Poszerzone dane statystyczne znajdujæ siú w /proc/ net/netstat. Wyraľony w sekundach odstúp czasu moľna wskazaè w poleceniu netstat, aby nieustannie we wskazanym odstúpie czasu byđy wyħwietlane wartoħci skumulowanych liczników. Tak otrzymane dane wyjħciowe moľna nastúpnie przetworzyè i obliczyè wspóđczynniki dla poszczególnych liczników.

564

Rozdział 10



Sieć

Solaris To jest przykđad danych wyjħciowych zawierajæcych dane statystyczne dotyczæce interfejsu: $ netstat -i Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 loopback localhost 40 0 40 0 0 0 ixgbe0 1500 headnode headnode 4122107616 0 4102310328 0 0 0 external0 1500 10.225.140.0 10.225.140.4 7101105 0 4574375 0 0 0 devnet0 1500 10.3.32.0 10.3.32.4 6566405 0 3895822357 0 0 0 Name lo0

Mtu Net/Dest 8252 localhost

Address localhost

Ipkts 40

Ierrs Opkts 0 40

Oerrs Collis 0 0

Kolumny danych wyjħciowych gromadzæ informacje o interfejsie sieciowym (Name), wartoħci MTU, sieci (Net/Dest), adresie interfejsu (Address), a takľe seriú metryk: 

Ipkts — pakiety otrzymane,



Ierrs — bđúdy w pakietach otrzymanych,



Opkts — pakiety wysđane,



Oerrs — bđúdy w pakietach wysđanych (na przykđad póļne kolizje),





Collis — kolizje pakietów (obecnie mađo prawdopodobne dziúki uľyciu przeđæczników korzystajæcych z buforów), Queue — zawsze ma wartoħè 0 (zdefiniowana na stađe, wartoħè historyczna).

Jeľeli búdzie podany argument w postaci wyraľonego w sekundach odstúpu czasu, dane wyjħciowe búdæ zawierađy podsumowanie pojedynczego interfejsu na przestrzeni czasu. Moľna wówczas uľyè opcji -I i wskazaè interfejs, którego dane majæ byè wyħwietlane. To jest przykđad wygenerowanych przez polecenie netstat danych statystycznych (skróconych) dotyczæcych stosu sieciowego: $ netstat -s RAWIP rawipInDatagrams rawipInCksumErrs rawipOutErrors

= = =

184 0 0

rawipInErrors rawipOutDatagrams

= =

0 937 0 0

UDP

udpInDatagrams udpOutDatagrams

=664557 =677322

udpInErrors udpOutErrors

= =

TCP

tcpRtoAlgorithm tcpRtoMax tcpActiveOpens tcpAttemptFails tcpCurrEstab tcpOutDataSegs

= 4 = 60000 =967141 =110230 = 7 =69720123

tcpRtoMin tcpMaxConn tcpPassiveOpens tcpEstabResets tcpOutSegs tcpOutDataBytes

= 400 = -1 = 3134 = 183 =78452503 =3753060671

10.6. Analiza

IPv4

565

tcpRetransSegs = 12265 tcpOutAck =19678899 tcpOutUrg = 0 tcpOutWinProbe = 0 tcpOutRsts = 1935 tcpInSegs =50303684 tcpInAckSegs = 0 tcpInDupAck =974778 tcpInInorderSegs =57165053 tcpInUnorderSegs = 1789 tcpInDupSegs = 1880 tcpInPartDupSegs = 0 tcpInPastWinSegs = 0 tcpInWinProbe = 1 tcpInClosed = 40 tcpRttUpdate =32655394 tcpTimRetransDrop = 218 tcpTimKeepaliveProbe= 2512 tcpListenDrop = 0 tcpHalfOpenDrop = 0

tcpRetransBytes tcpOutAckDelayed tcpOutWinUpdate tcpOutControl tcpOutFastRetrans

=10767035 =10664701 = 3679 =1833674 = 23

tcpInAckBytes tcpInAckUnsent tcpInInorderBytes tcpInUnorderBytes tcpInDupBytes tcpInPartDupBytes tcpInPastWinBytes tcpInWinUpdate tcpRttNoUpdate tcpTimRetrans tcpTimKeepalive tcpTimKeepaliveDrop tcpListenDropQ0 tcpOutSackRetrans

=3753841314 = 0 =813978589 =106836 =121354 = 0 = 0 = 0 = 0 = 16559 = 25489 = 150 = 0 = 7262

ipForwarding ipInReceives ipInAddrErrors ipForwDatagrams ipInUnknownProtos ipInDelivers ipOutDiscards

ipDefaultTTL ipInHdrErrors ipInCksumErrs ipForwProhibits ipInDiscards ipOutRequests ipOutNoRoutes

= 255 = 0 = 2 = 0 = 188 =91980660 = 2

= 1 =3970771620 = 0 =3896325662 = 4 =74383918 = 1122

[...]

Przedstawione dane wyjħciowe zawierajæ róľne dane statystyczne dotyczæce sieci, pogrupowane wedđug protokođu. Wiele z nich jest opartych na informacjach MIB protokođu SNMP, co umoľliwia prawidđowe rozszyfrowanie prezentowanych danych. Wybrane metryki wydajnoħci zostađy wyħwietlone pogrubionæ czcionkæ, aby w ten sposób wskazaè na rodzaj dostúpnych informacji. W przypadku wielu informacji niezbúdna jest dobra znajomoħè zachowania TCP, miúdzy innymi nowszych funkcji oraz algorytmów wprowadzonych w ostatnich latach. Metryki, które warto sprawdziè, sæ podobne do tych, wspomnianych w opisie polecenia w systemie Linux. Z pewnoħciæ warto takľe sprawdziè: 

tcpListenDrop i tcpListenDropQ0. Liczba odrzuconych pakietów dla kolejek, odpowiednio, Listen Backlog i SYN backlog. Rosnæca wartoħè tcpListenDrops wskazuje na wiúcej ľædaē pođæczeē, niľ aplikacja jest w stanie zaakceptowaè. W tej sytuacji istniejæ dwa moľliwe rozwiæzania. Pierwsze, zwiúkszenie wielkoħci kolejki backlog (tcp_conn_req_max_q), dziúki czemu moľna umieħciè w kolejce wiúkszæ liczbú pođæczeē. Drugie, przydzielenie aplikacji wiúkszej iloħci zasobów.

566

Rozdział 10



Sieć

Wyħwietlane tutaj metryki pochodzæ z narzúdzia kstat i sæ dostúpne za pomocæ interfejsu libkstat. Istnieje moľliwoħè wskazania odstúpu czasu, co powoduje wyħwietlenie podsumowania od chwili uruchomienia systemu, a nastúpnie podsumowania dla podanego przedziađu czasu. Kaľde podsumowanie zawiera dane statystyczne dla danego odstúpu czasu (w przeciwieēstwie do wersji w systemie Linux), a wiúc wartoħci wspóđczynników sæ oczywiste, na przykđad: # netstat -s 1 | grep tcpActiveOpens tcpActiveOpens =11460494 tcpActiveOpens = 224 tcpActiveOpens = 193 tcpActiveOpens = 53 tcpActiveOpens = 216 [...]

tcpPassiveOpens tcpPassiveOpens tcpPassiveOpens tcpPassiveOpens tcpPassiveOpens

= = = = =

783 0 0 1 0

Powyľsze dane wyjħciowe pokazujæ wspóđczynniki dotyczæce pođæczeē TCP aktywnych i pasywnych, nawiæzywanych w ciægu sekundy.

10.6.2. sar Polecenie sar moľna wykorzystaè do sprawdzenia bieľæcej aktywnoħci systemu i miúdzy innymi do wyħwietlenia danych statystycznych o sieci. Narzúdzie moľna skonfigurowaè w taki sposób, aby archiwizowađo i podawađo takľe historyczne dane statystyczne. To polecenie zostađo wprowadzone w rozdziale 4. „Narzúdzia monitorowania” i jest stosowane, gdy zajdzie taka potrzeba, takľe w innych rozdziađach. Wersja znajdujæca siú w systemie Linux dostarcza danych statystycznych o sieci za pomocæ nastúpujæcych opcji: 

-n DEV — dane statystyczne o interfejsie sieciowym,



-n EDEV — dane statystyczne o bđúdach interfejsu sieciowego,



-n IP — dane statystyczne o datagramach IP,



-n EIP — dane statystyczne o bđúdach IP,



-n TCP — dane statystyczne o TCP,



-n ETCP — dane statystyczne o bđúdach TCP,



-n SOCK — dane statystyczne o uľyciu gniazda.

Dostarczane dane statystyczne zostađy wymienione w tabeli 10.5. Wiele nazw danych statystycznych zawiera informacje o kierunku przepđywu danych w mierzonych jednostkach: rx — dla danych otrzymanych, i — w przypadku danych wejħciowych, seg — w przypadku segmentów itd. Peđnæ listú znajdziesz na stronie podrúcznika systemowego man, który gromadzi takľe informacje szczegóđowe o innych dodatkowych danych statystycznych dotyczæcych ICMP, UDP, NFS i IPv6, a ponadto przedstawia pewne odpowiedniki nazw SNMP (na przykđad ipInReceived dla irec/s).

10.6. Analiza

567

Tabela 10.5. Generowane przez narzędzie sar w systemie Linux dane statystyczne dotyczące sieci Opcja

Opis Dane statystyczne

Jednostka

-n DEV

rxpkt/s

Otrzymane pakiety.

pakiety/s

-n DEV

txpkt/s

Wysłane pakiety.

pakiety/s

-n DEV

rxkB/s

Liczba otrzymanych kilobajtów.

KB/s

-n DEV

txkB/s

Liczba wysłanych kilobajtów.

KB/s

-n EDEV

rxerr/s

Liczba otrzymanych pakietów z błędami.

pakiety/s

-n EDEV

txerr/s

Liczba wysłanych pakietów z błędami.

pakiety/s

-n EDEV

coll/s

Kolizje.

pakiety/s

-n EDEV

rxdrop/s

Odrzucone pakiety po ich otrzymaniu (zapełniony bufor).

pakiety/s

-n EDEV

txdrop/s

Odrzucone pakiety po ich wysłaniu (zapełniony bufor).

pakiety/s

-n EDEV

rxfifo/s

Liczba błędów przepełnienia FIFO dla otrzymanych pakietów.

pakiety/s

-n EDEV

txfifo/s

Liczba błędów przepełnienia FIFO dla wysłanych pakietów.

pakiety/s

-n IP

irec/s

Datagramy danych wejściowych (otrzymane).

datagramy/s

-n IP

fwddgm/s

Przekazane datagramy.

datagramy/s

-n IP

orq/s

Żądania datagramów danych wyjściowych (wysłane).

datagramy/s

-n EIP

idisc/s

Odrzucone dane wejściowe (zapełniony bufor).

datagramy/s

-n EIP

odisc/s

Odrzucone dane wyjściowe (zapełniony bufor).

datagramy/s

-n TCP

active/s

Nowe aktywne połączenia TCP (connect()).

połączenia/s

-n TCP

passive/s

Nowe pasywne połączenia TCP (listen()).

połączenia/s

-n TCP

iseg/s

Segmenty danych wejściowych (otrzymane).

segmenty/s

-n TCP

oseg/s

Segmenty danych wyjściowych (otrzymane).

segmenty/s

-n ETCP

atmptf/s

Awarie aktywnych połączeń TCP.

połączenia/s

-n ETCP

retrans/s

Liczba retransmitowanych segmentów TCP.

segmenty/s

-n SOCK

totsck

Całkowita liczba używanych gniazd.

gniazda

-n SOCK

ip-frag

Obecnie kolejkowane fragmenty IP.

fragmenty

-n SOCK

tcp-tw

Gniazda TCP w stanie TIME-WAIT.

gniazda

Zamieszczone tutaj wywođanie powoduje wyħwietlenie co sekundú danych statystycznych o TCP: $ sar -n TCP 1 Linux 3.5.4joyent-centos-6-opt (dev99)

04/22/2013

09:36:26 PM 09:36:27 PM 09:36:28 PM

oseg/s 4090.10 3671.00

active/s passive/s 0.00 35.64 0.00 34.00

iseg/s 4084.16 3652.00

_x86_64_ (4 CPU)

568

Rozdział 10

09:36:29 PM 09:36:30 PM [...]

0.00 0.00

30.00 33.33

3229.00 3291.92



Sieć

3309.00 3310.10

Dane wyjħciowe pokazujæ, ľe liczba pođæczeē pasywnych (przychodzæcych) oscyluje w okolicach 30 na sekundú. Kolumna danych statystycznych dotyczæcych interfejsu sieciowego (NET) wyħwietla wszystkie interfejsy, choè najczúħciej interesuje nas tylko jeden. W poniľszym przykđadzie wykorzystano polecenie awk do filtrowania danych wyjħciowych: $ sar -n 09:36:06 09:36:07 09:36:08 09:36:09 09:36:10 [...]

DEV 1 | awk 'NR == 3 || $3 == PM IFACE rxpck/s txpck/s PM eth0 4131.68 4148.51 PM eth0 4251.52 4266.67 PM eth0 4249.00 4248.00 PM eth0 3384.16 3443.56

"eth0"' rxkB/s 2628.52 2696.05 2695.03 2149.98

txkB/s rxcmp/s txcmp/s 2512.07 0.00 0.00 2576.82 0.00 0.00 2574.10 0.00 0.00 2060.31 0.00 0.00

rxmcst/s 0.00 0.00 0.00 0.00

Uzyskane dane pokazujæ przepustowoħè sieci dla danych otrzymanych i wysyđanych. W omawianym przykđadzie przepustowoħè w obu kierunkach wynosi ponad 2 MB/s. Wersja polecenia sar w systemie Solaris obecnie nie dostarcza danych statystycznych dotyczæcych sieci. (Jeħli chcesz je otrzymaè, uľyj poleceē netstat, nicstat lub dladm).

10.6.3. ifconfig Polecenie ifconfig umoľliwia przeprowadzenie rúcznej konfiguracji interfejsów sieciowych. Wyħwietla równieľ konfiguracjú bieľæcæ wszystkich interfejsów, co búdzie uľyteczne podczas statycznego dostrajania wydajnoħci oraz sprawdzania, jak zostađy skonfigurowane: system, sieè i trasy. W systemie Linux dane wyjħciowe polecenia ifconfig zawierajæ dane statystyczne: $ ifconfig eth0 Link encap:Ethernet HWaddr 00:21:9b:97:a9:bf inet addr:10.2.0.2 Bcast:10.2.0.255 Mask:255.255.255.0 inet6 addr: fe80::221:9bff:fe97:a9bf/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:933874764 errors:0 dropped:0 overruns:0 frame:0 TX packets:1090431029 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:584622361619 (584.6 GB) TX bytes:537745836640 (537.7 GB) Interrupt:36 Memory:d6000000-d6012800 eth3 Link encap:Ethernet HWaddr 00:21:9b:97:a9:c5 [...]

10.6. Analiza

569

Liczniki sæ takie same, jak omówione wczeħniej dla polecenia netstat -i. Wartoħè txqueuelen wskazuje dđugoħè kolejki dla danych wychodzæcych przez dany interfejs. Modyfikacja wymienionej wartoħci zostađa przedstawiona na stronie podrúcznika man: W przypadku wolniejszych urzædzeē, o stosunkowo duľym opóļnieniu (đæcza modemowe, ISDN) uľyteczne búdzie ustawienie mađej wartoħci, aby uniknæè sytuacji, gdy duľa liczba transferów búdzie bardzo przeszkadzađa w interaktywnym ruchu, takim jak telnet.

W systemie Linux polecenie ifconfig jest obecnie uznawane za przestarzađe i zostađo zastæpione przez ip. W systemie Solaris róľne funkcje polecenia ifconfig równieľ zostađy uznane za przestarzađe i zastæpione poleceniami ipadm oraz dladm.

10.6.4. ip Znajdujæce siú w systemie Linux polecenie ip moľna wykorzystaè do konfiguracji interfejsów sieciowych i tras, a takľe do obserwacji ich danych statystycznych. Przedstawione wywođanie pokazuje dane statystyczne o đæczu: $ ip -s link 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 RX: bytes packets errors dropped overrun mcast 1200720212 21176087 0 0 0 0 TX: bytes packets errors dropped carrier collsns 1200720212 21176087 0 0 0 0 2: eth0: mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:21:9b:97:a9:bf brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 507221711 933878009 0 0 0 46648551 TX: bytes packets errors dropped carrier collsns 876109419 1090437447 0 0 0 0 3: eth1: mtu 1500 qdisc noop state DOWN qlen 1000 [...]

Liczniki sæ takie same, jak omówione wczeħniej dla polecenia netstat -i, ale z dodaniem informacji o danych otrzymanych (RX) i wysyđanych (TX). Dziúki temu moľna bardzo đatwo monitorowaè przepustowoħè. Jednak obecna wersja polecenia ip nie oferuje moľliwoħci wyħwietlania raportów dla wskazanego przedziađu czasu (zamiast tego naleľy uľyè polecenia sar).

10.6.5. nicstat Poczætkowo utworzone dla systemu Solaris, polecenie nicstat powoduje wyħwietlenie danych statystycznych dotyczæcych interfejsu sieciowego, miúdzy innymi danych o przepustowoħci i poziomie wykorzystania. W omawianym poleceniu stosowany jest styl tradycyjnych narzúdzi iostat i mpstat, dostarczajæcych danych statystycznych o zasobach. Przygotowane zostađy wersje polecenia nicstat w júzykach C i Perl zarówno dla systemu Solaris, jak i Linux (patrz odwođanie [3] na koēcu rozdziađu).

570

Rozdział 10



Sieć

To sæ przykđadowe dane wyjħciowe wygenerowane przez polecenie nicstat w wersji 1.92 w systemie Linux: # nicstat -z 1 Time Int rKB/s 01:20:58 eth0 0.07 01:20:58 eth4 0.28 01:20:58 vlan123 0.00 01:20:58 br0 0.00 Time Int rKB/s 01:20:59 eth4 42376.0 Time Int rKB/s 01:21:00 eth0 0.05 01:21:00 eth4 41834.7 Time Int rKB/s 01:21:01 eth4 42017.9

wKB/s rPk/s wPk/s 0.00 0.95 0.02 0.01 0.20 0.10 0.00 0.00 0.02 0.00 0.00 0.00 wKB/s rPk/s wPk/s 974.5 28589.4 14002.1 wKB/s rPk/s wPk/s 0.00 1.00 0.00 977.9 28221.5 14058.3 wKB/s rPk/s wPk/s 979.0 28345.0 14073.0

rAvs 79.43 1451.3 42.00 42.00 rAvs 1517.8 rAvs 56.00 1517.9 rAvs 1517.9

wAvs 64.81 80.11 64.81 42.07 wAvs 71.27 wAvs 0.00 71.23 wAvs 71.24

%Util 0.00 0.00 0.00 0.00 %Util 35.5 %Util 0.00 35.1 %Util 35.2

Sat 0.00 0.00 0.00 0.00 Sat 0.00 Sat 0.00 0.00 Sat 0.00

Na poczætku danych wyjħciowych znajduje siú podsumowanie od chwili uruchomienia systemu, a w dalszej kolejnoħci sæ podsumowania dla poszczególnych przedziađów czasu. Podsumowanie dla przedziađu czasu od chwili uruchomienia systemu pokazuje, ľe interfejs eth4 jest wykorzystany w 35% (to obecnie najwyľszy poziom wykorzystania dla kierunku RX lub TX), a odczyt danych nastúpuje z szybkoħciæ 42 MB/s. Kolumny danych wyjħciowych zawierajæ informacje takie jak: nazwa interfejsu (Int), maksymalny poziom wykorzystania (%Util), wartoħè odzwierciedlajæca dane statystyczne dotyczæce nasycenia interfejsu (Sat), a takľe serie danych statystycznych poprzedzonych literæ r (odczyt) lub w (zapis) dla danych, odpowiednio, otrzymywanych i wysyđanych: 

KB/s: kilobajty na sekundú,



Pk/s: pakiety na sekundú,



Avs: wyraľona w bajtach ħrednia wielkoħè pakietu.

Obsđugiwane sæ róľne opcje, miúdzy innymi -z (stosowana w celu pominiúcia wierszy z zerami — interfejs bezczynny) oraz -t (wyħwietlajæca dane statystyczne dotyczæce TCP). Polecenie nicstat jest szczególnie uľyteczne w metodzie USE, poniewaľ podaje wartoħci wskazujæce poziom wykorzystania i nasycenie interfejsu.

10.6.6. dladm W systemie Solaris polecenie dladm moľe wyħwietliè dane statystyczne o interfejsie, miúdzy innymi: transfer danych wyraľony w bajtach i pakietach, iloħè bđúdów, poziom wykorzystania. Ponadto moľe podaè informacje o fizycznych interfejsach. Poniľsze wywođanie powoduje wyħwietlenie w sekundowych odstúpach informacji o ruchu sieciowym dla interfejsu ixgbe0:

10.6. Analiza

571

$ dladm show-link -s -i 1 ixgbe0 LINK IPACKETS RBYTES IERRORS ixgbe0 8442628297 5393508338540 0 ixgbe0 1548 501475 0 ixgbe0 1581 515611 0 ixgbe0 1491 478794 0 ixgbe0 1590 566174 0 [...]

OPACKETS 8422583725 1538 1592 1495 1567

OBYTES OERRORS 6767471933614 0 476283 0 517697 0 479232 0 477956 0

Pierwszy wiersz danych wyjħciowych zawiera podsumowanie od chwili uruchomienia systemu. Kolejne wiersze to podsumowania dla kolejnego odstúpu czasu (opcja -i 1). W prezentowanym przykđadzie widzimy, ľe interfejs obecnie wysyđa i otrzymuje dane z szybkoħciæ okođo 500 KB/s. Wywođanie dladm show-link -S generuje alternatywne dane wyjħciowe zawierajæce informacje podane w kilobajtach i pakietach, jak równieľ kolumnú %Util. Kolejne wywođanie wyħwietla informacje o stanie fizycznego interfejsu: $ dladm show-phys LINK MEDIA ixgbe0 Ethernet ixgbe1 Ethernet igb0 Ethernet igb1 Ethernet igb2 Ethernet igb3 Ethernet

STATE up up unknown unknown unknown unknown

SPEED 10000 10000 0 0 0 0

DUPLEX full full half half half half

DEVICE ixgbe0 ixgbe1 igb0 igb1 igb2 igb3

To informacje bardzo uľyteczne podczas statycznego dostrajania wydajnoħci. Dziúki nim moľesz sprawdziè, czy interfejs wynegocjowađ maksymalnæ moľliwæ szybkoħè. Przed wprowadzeniem polecenia dladm wspomniane atrybuty moľna byđo sprawdziè za pomocæ polecenia ndd.

10.6.7. ping Polecenie ping sprawdza moľliwoħè nawiæzania pođæczenia przez sieè. W tym celu wysyđa pakiety ICMP echo, na przykđad: # ping www.joyent.com PING www.joyent.com (165.225.132.33) 56(84) bytes of data. 64 bytes from 165.225.132.33: icmp_req=1 ttl=239 time=67.9 ms 64 bytes from 165.225.132.33: icmp_req=2 ttl=239 time=68.3 ms 64 bytes from 165.225.132.33: icmp_req=3 ttl=239 time=69.6 ms 64 bytes from 165.225.132.33: icmp_req=4 ttl=239 time=68.1 ms 64 bytes from 165.225.132.33: icmp_req=5 ttl=239 time=68.1 ms ^C --- www.joyent.com ping statistics --5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 67.935/68.443/69.679/0.629 ms

572

Rozdział 10



Sieć

Zaprezentowane dane wyjħciowe zawierajæ informacje o czasie potrzebnym pakietowi na pokonanie drogi do adresata oraz z powrotem (rtt). Poza tym dla kaľdego pakietu wyħwietlane jest podsumowanie z róľnymi danymi statystycznymi. Poniewaľ czas jest mierzony przez polecenie ping, znaczniki czasu obejmujæ takľe pewien czas potrzebny na wykonanie ħcieľki kodu w procesorze miúdzy pobraniem znacznika czasu a przeprowadzeniem sieciowej operacji wejħcia-wyjħcia. W systemie Solaris polecenie ping wymaga uľycia opcji -s, aby nieustannie wysyđaè pakiety. Pakiety ICMP uľywane przez omawiane polecenie mogæ byè traktowane przez routery jako pakiety o niľszym priorytecie niľ generowane przez protokođy aplikacji, a tym samym wartoħè opóļnienia búdzie nieco wiúksza niľ zwykle.

10.6.8. traceroute Polecenie traceroute wysyđa seriú pakietów testowych w celu eksperymentalnego okreħlenia aktualnej trasy do komputera. Odbywa siú to wskutek zwiúkszenia o 1 wartoħci TTL (ang. Time To Live) protokođu IP dla kaľdego pakietu. W ten sposób sekwencja bram do komputera ujawnia siú w wyniku wysđania komunikatu ICMP informujæcego o przekroczeniu czasu oczekiwania (oczywiħcie przy zađoľeniu, ľe pakiety nie zostanæ zablokowane przez zaporú sieciowæ). Na przykđad prezentowane wywođanie powoduje sprawdzenie bieľæcej trasy miúdzy nadawcæ znajdujæcym siú w Kalifornii a odbiorcæ w Wirginii: # traceroute www.joyent.com 1 165.225.148.2 (165.225.148.2) 0.333 ms 13.569 ms 0.279 ms 2 te-3-2.car2.Oakland1.Level3.net (4.71.202.33) 0.361 ms 0.309 ms 0.295 ms 3 ae-11-11.car1.Oakland1.Level3.net (4.69.134.41) 2.040 ms 2.019 ms 1.964 ms 4 ae-5-5.ebr2.SanJose1.Level3.net (4.69.134.38) 1.245 ms 1.230 ms 1.241 ms 5 ae-72-72.csw2.SanJose1.Level3.net (4.69.153.22) 1.269 ms 1.307 ms 1.240 ms 6 ae-2-70.edge1.SanJose3.Level3.net (4.69.152.80) 1.810 ms ae-160.edge1.SanJose3.Level3.net (4.69.152.16) 1.903 ms 1.735 ms 7 Savvis-Level3.Dallas3.Level3.net (4.68.62.106) 1.829 ms 1.813 ms 1.900 ms 8 cr2-tengig0-7-3-0.sanfrancisco.savvis.net (204.70.206.57) 3.889 ms 3.839 ms 3.805 ms 9 cr2-ten-0-15-3-0.dck.nyr.savvis.net (204.70.224.209) 77.315 ms 92.287 ms 77.684 ms 10 er2-tengig-1-0-1.VirginiaEquinix.savvis.net (204.70.197.245) 77.144 ms 77.114 ms 77.193 ms 11 internap.VirginiaEquinix.savvis.net (208.173.159.2) 77.373 ms 77.363 ms 77.445 ms 12 border10.pc1-bbnet1.wdc002.pnap.net (216.52.127.9) 77.114 ms 77.093 ms 77.116 ms 13 joyent-3.border10.wdc002.pnap.net (64.94.31.202) 77.203 ms 85.554 ms 90.106 ms 14 165.225.132.33 (165.225.132.33) 77.089 ms 77.097 ms 77.076 ms

Kaľdy przeskok pokazuje seriú trzech RTT, które mogæ byè ļródđem opóļnienia sieci. Podobnie jak w przypadku polecenia ping, takľe pakiety generowane przez traceroute majæ niski priorytet i mogæ wskazywaè wiúksze opóļnienie niľ w innych protokođach aplikacji.

10.6. Analiza

573

Wybranæ trasú moľna przeanalizowaè jako fragment statycznego dostrajania wydajnoħci. Sieci zostađy zaprojektowane jako dynamiczne i reagujæce na awarie. Wydajnoħè sieci moľe spaħè, gdy nastæpi zmiana trasy. Polecenie traceroute zostađo utworzone przez Vana Jacobsona, który póļniej przygotowađ takľe inne niesamowite polecenie — o nazwie pathchar.

10.6.9. pathchar Polecenie pathchar jest podobne do traceroute, ale zawiera informacje o przepustowoħci miúdzy przeskokami (patrz odwođanie [4] na koēcu rozdziađu). Wspomniana przepustowoħè jest okreħlana w wyniku wielokrotnego wysđania serii pakietów, a nastúpnie przeprowadzenia analizy statystycznej. Oto przykđadowe dane wyjħciowe omawianego polecenia: # pathchar 192.168.1.10 pathchar to 192.168.1.1 (192.168.1.1) doing 32 probes at each of 64 to 1500 by 32 0 localhost | 30 Mb/s, 79 us (562 us) 1 neptune.test.com (192.168.2.1) | 44 Mb/s, 195 us (1.23 ms) 2 mars.test.com (192.168.1.1) 2 hops, rtt 547 us (1.23 ms), bottleneck 30 Mb/s, pipe 7555 bytes

Niestety polecenie pathchar nie jest zbyt popularne (prawdopodobnie z powodu nieudostúpnienia jego kodu ļródđowego) i w zwiæzku z tym trudno jest znaleļè jego dziađajæcæ wersjú dla nowoczesnego systemu operacyjnego. Dziađanie tego polecenia wymaga równieľ naprawdú duľo czasu, nawet kilkudziesiúciu minut, w zaleľnoħci od liczby przeskoków. Zaproponowano nawet metody pozwalajæce skróciè wspomniany czas (patrz odwođanie [Downey 99] na koēcu rozdziađu).

10.6.10. tcpdump Pakiety sieciowe moľna przechwyciè i przestudiowaè za pomocæ polecenia tcpdump. Omawiane polecenie potrafi nawet przekazaè do standardowego wyjħcia podsumowanie pakietu lub zapisaè jego dane w pliku do póļniejszej analizy. Ostatnia z wymienionych moľliwoħci jest zwykle znacznie praktyczniejsza, poniewaľ czústotliwoħè pojawiania siú pakietów moľe byè po prostu zbyt duľa, aby skutecznie przeglædaè ich podsumowanie w czasie rzeczywistym. Poniľsze wywođanie powoduje zapisanie w pliku /tmp/out.tcpdump pakietów przechwyconych w interfejsie eth4: # tcpdump -i eth4 -w /tmp/out.tcpdump tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 65535 bytes ^C273893 packets captured 275752 packets received by filter 1859 packets dropped by kernel

574

Rozdział 10



Sieć

Powyľsze dane wyjħciowe informujæ o liczbie pakietów odrzuconych przez jædro zamiast przekazanych poleceniu tcpdump. Tego rodzaju sytuacja zdarza siú, gdy czústotliwoħè pojawiania siú pakietów jest zbyt duľa. To jest przykđad zapisanych w pliku danych pakietów: # tcpdump -nr /tmp/out.tcpdump reading from file /tmp/out.tcpdump, link-type EN10MB (Ethernet) 02:24:46.160754 IP 10.2.124.2.32863 > 10.2.203.2.5001: Flags [.], seq 3612664461:3612667357, ack 180214943, win 64436, options [nop,nop,TS val 692339741 ecr 346311608], length 2896 02:24:46.160765 IP 10.2.203.2.5001 > 10.2.124.2.32863: Flags [.], ack 2896, win 18184, options [nop,nop,TS val 346311610 ecr 692339740], length 0 02:24:46.160778 IP 10.2.124.2.32863 > 10.2.203.2.5001: Flags [.], seq 2896:4344, ack 1, win 64436, options [nop,nop,TS val 692339741 ecr 346311608], length 1448 02:24:46.160807 IP 10.2.124.2.32863 > 10.2.203.2.5001: Flags [.], seq 4344:5792, ack 1, win 64436, options [nop,nop,TS val 692339741 ecr 346311608], length 1448 02:24:46.160817 IP 10.2.203.2.5001 > 10.2.124.2.32863: Flags [.], ack 5792, win 18184, options [nop,nop,TS val 346311610 ecr 692339741], length 0 [...]

W kaľdym wierszu znajdujæ siú informacje o czasie przechwycenia pakietu (z dokđadnoħciæ do mikrosekund), adresach IP: ļródđowym i docelowym, a takľe wartoħci nagđówka TCP. Dziúki analizie tych danych moľna dokđadnie poznaè sposób dziađania protokođu TCP i miúdzy innymi przekonaè siú, jak jego zaawansowane funkcje sprawdzajæ siú w danym obciæľeniu. Opcja -n zostađa uľyta w tym celu, aby adresy IP nie byđy tđumaczone na nazwy komputerów. Istnieje wiele innych opcji, pozwalajæcych miúdzy innymi na wyħwietlanie informacji szczegóđowych (-v), o ile sæ dostúpne, wyħwietlanie nagđówków warstwy đæcza (-e), a takľe adresów w formacie szesnastkowym (-x lub -X). W kolejnym przykđadzie przedstawiono uľycie niektórych z wymienionych opcji: # tcpdump -enr /tmp/out.tcpdump -vvv -X reading from file /tmp/out.tcpdump, link-type EN10MB (Ethernet) 02:24:46.160754 80:71:1f:ad:50:48 > 84:2b:2b:61:b6:ed, ethertype IPv4 (0x0800), length 2962: (tos 0x0, ttl 63, id 46508, offset 0, flags [DF], proto TCP (6), length 2948) 10.2.124.2.32863 > 10.2.203.2.5001: Flags [.], cksum 0x667f (incorrect -> 0xc4da), seq 3612664461:3612667357, ack 180214943, win 64436, options [nop,nop,TS val 692339741 ecr 346311608], length 289 6 0x0000: 4500 0b84 b5ac 4000 3f06 1fbf 0a02 7c02 E.....@.?.....|. 0x0010: 0a02 cb02 805f 1389 d754 e28d 0abd dc9f .........T...... 0x0020: 8010 fbb4 667f 0000 0101 080a 2944 441d ....f.......)DD. 0x0030: 14a4 4bb8 3233 3435 3637 3839 3031 3233 ..K.234567890123 0x0040: 3435 3637 3839 3031 3233 3435 3637 3839 4567890123456789 [...]

10.6. Analiza

575

Podczas przeprowadzania analizy wydajnoħci uľyteczna moľe byè zmiana kolumny znaczników czasu, tak aby wyħwietlađa czas delta miúdzy pakietami (opcja -ttt) lub czas od pierwszego pakietu (opcja -ttttt). Istnieje moľliwoħè zdefiniowania wyraľenia okreħlajæcego sposób filtrowania pakietów (patrz pcapfilter), aby tym samym móc skoncentrowaè siú jedynie na wybranych pakietach. Filtrowanie jest przeprowadzane w jædrze (poczæwszy od wersji 2.0 jædra), co ma zapewniè jego efektywnoħè. Przechwytywanie pakietów to kosztowna operacja w kategoriach poziomu wykorzystania zarówno procesora, jak i pamiúci masowej. Jeľeli jest moľliwoħè, polecenia tcpdump naleľy uľywaè jedynie przez krótki czasu, aby ograniczyè jego negatywny wpđyw na wydajnoħè dziađania systemu. Polecenie tcpdump moľna zainstalowaè w systemie Solaris, wtedy nie ma powodów uľywania polecenia snoop.

10.6.11. snoop Wprawdzie polecenie tcpdump zostađo przeniesione do systemu Solaris, ale domyħlnym poleceniem przeznaczonym do przechwytywania i studiowania pakietów jest snoop. Jego dziađanie jest podobne do tcpdump, równieľ potrafi zapisywaè przechwycone pakiety w pliku do dalszej ich analizy. Pliki zawierajæce pakiety przechwycone za pomocæ polecenia snoop stosujæ standard zdefiniowany w dokumencie RFC 1761 (patrz odwođanie [RFC 1761] na koēcu rozdziađu). Poniľsze wywođanie powoduje zapisanie w pliku /tmp/out.snoop pakietów przechwyconych w interfejsie ixgbe0: # snoop -d ixgbe0 -o /tmp/out.snoop Using device ixgbe0 (promiscuous mode) 46907 ^C

Dane wyjħciowe zawierajæ informacje o liczbie otrzymanych dotæd pakietów. Uľyteczne moľe byè zawieszenie podawania tych informacji przez wđæczenie trybu cichego (opcja -q). W ten sposób dane wyjħciowe nie powodujæ generowania dodatkowych pakietów podczas sesji prowadzonej w sieci. To jest przykđad danych zapisanych w pliku: # snoop -ri /tmp/out.snoop 1 0.00000 10.2.0.2 -> 10.2.204.2 TCP D=5001 S=33896 Ack=2831460534 Seq=3864122818 Len=1448 Win=46 Options= 2 0.00000 10.2.0.2 -> 10.2.204.2 TCP D=5001 S=33896 Ack=2831460534 Seq=3864124266 Len=1448 Win=46 Options= 3 0.00002 10.2.0.2 -> 10.2.204.2 TCP D=5001 S=33896 Ack=2831460534 Seq=3864125714 Len=1448 Win=46 Options= [...]

Kaľdy wiersz zawiera informacje o pojedynczym pakiecie. Na poczætku znajduje siú identyfikator pakietu, a nastúpnie podany jest czas przechwycenia pakietu (wyraľony w sekundach z dokđadnoħciæ do mikrosekund), ļródđowy i docelowy adres IP, a takľe

576

Rozdział 10



Sieć

inne szczegóđy dotyczæce protokođu. Tđumaczenie adresów IP na nazwy komputerów zostađo wyđæczone na skutek uľycia opcji -r. Podczas przeprowadzania analizy wydajnoħci znaczniki czasu mogæ byè zmodyfikowane, jeħli zachodzi potrzeba. Domyħlnie podajæ one czas delta, czyli czas, jaki upđynæđ miúdzy kolejnymi pakietami. Opcja -ta powoduje wyħwietlenie czasu bezwzglúdnego, czyli rzeczywistego. Z kolei opcja -tr wyħwietla czas wzglúdny, czyli róľnicú w stosunku do pierwszego pakietu. Opcja -V powoduje wyħwietlenie nieco bardziej szczegóđowych danych wyjħciowych, miúdzy innymi wiersza z informacjami dotyczæcymi warstwy protokođu: # snoop -ri /tmp/out.snoop -V ............................... 1 0.00000 10.2.0.2 -> 10.2.204.2 ETHER Type=0800 (IP), size=1514 bytes 1 0.00000 10.2.0.2 -> 10.2.204.2 IP D=10.2.204.2 S=10.2.0.2 LEN=1500, ID=35573, TOS=0x0, TTL=63 1 0.00000 10.2.0.2 -> 10.2.204.2 TCP D=5001 S=33896 Ack=2831460534 Seq=3864122818 Len=1448 Win=46 Options= ............................... 2 0.00000 10.2.0.2 -> 10.2.204.2 ETHER Type=0800 (IP), size=1514 bytes 2 0.00000 10.2.0.2 -> 10.2.204.2 IP D=10.2.204.2 S=10.2.0.2 LEN=1500, ID=35574, TOS=0x0, TTL=63 2 0.00000 10.2.0.2 -> 10.2.204.2 TCP D=5001 S=33896 Ack=2831460534 Seq=3864124266 Len=1448 Win=46 Options= ............................... [...]

Opcja -v (mađa litera v) wyħwietla bardzo szczegóđowe dane wyjħciowe, których wielkoħè to bardzo czústo cađa strona dla kaľdego pakietu: # snoop -ri /tmp/out.snoop -v ETHER: ----- Ether Header ----ETHER: ETHER: Packet 1 arrived at 8:07:54.31917 ETHER: Packet size = 1514 bytes ETHER: Destination = 84:2b:2b:61:b7:62, ETHER: Source = 80:71:1f:ad:50:48, ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = not ECN capable transport IP: .... ...0 = no ECN congestion experienced IP: Total length = 1500 bytes

10.6. Analiza

IP: IP: IP: IP: IP: IP: IP: IP: IP: IP: IP: IP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: TCP: [...]

577

Identification = 35573 Flags = 0x4 .1.. .... = do not fragment ..0. .... = last fragment Fragment offset = 0 bytes Time to live = 63 seconds/hops Protocol = 6 (TCP) Header checksum = cb1e Source address = 10.2.0.2, 10.2.0.2 Destination address = 10.2.204.2, 10.2.204.2 No options ----- TCP Header ----Source port = 33896 Destination port = 5001 Sequence number = 3864122818 Acknowledgement number = 2831460534 Data offset = 32 bytes Flags = 0x10 0... .... = No ECN congestion window reduced .0.. .... = No ECN echo ..0. .... = No urgent pointer ...1 .... = Acknowledgement .... 0... = No push .... .0.. = No reset .... ..0. = No Syn .... ...0 = No Fin Window = 46 Checksum = 0xe7b4 Urgent pointer = 0 Options: (12 bytes) - No operation - No operation - TS Val = 2333449053, TS Echo = 694358367

W przedstawionych danych wyjħciowych zamieszczono informacje dotyczæce tylko pierwszego pakietu. Polecenie snoop zostađo opracowane tak, aby umoľliwiè poznanie sposobów przetwarzania wielu protokođów. Dziúki temu uľytkownik moľe szybko przeanalizowaè róľne rodzaje ruchu sieciowego. Istnieje moľliwoħè zdefiniowania wyraľenia pozwalajæcego wskazaè sposób filtrowania pakietów (zapoznaj siú ze stronæ podrúcznika man poħwiúconæ poleceniu snoop). Dziúki temu moľesz skoncentrowaè siú na wybranych pakietach. O ile to moľliwe, operacja filtrowania jest przeprowadzana w jædrze, co ma zapewniè jej efektywnoħè. Warto zwróciè uwagú, ľe domyħlnie polecenie snoop powoduje przechwycenie cađego pakietu đæcznie z przenoszonymi przez niego danymi. Takie zachowanie moľna zmieniè za pomocæ opcji -s, podajæc dđugoħè przechwytywanych danych. Wiele wersji snoop domyħlnie stosuje opcjú skracania przechwytywanych pakietów.

578

Rozdział 10



Sieć

10.6.12. Wireshark Wprawdzie polecenia tcpdump i snoop sprawdzajæ siú doskonale podczas niezbyt czústych operacji studiowania pakietów, ale przeprowadzenie za ich pomocæ gđúbszej analizy pakietów w powđoce moľe zajæè duľo czasu. Narzúdzie Wireshark (wczeħniej Ethereal) oferuje graficzny interfejs uľytkownika przeznaczony do przechwytywania i analizy pakietów. Omawiane narzúdzie ma moľliwoħè importu plików z pakietami utworzonych przez polecenia tcpdump i snoop (patrz odwođanie [5] na koēcu rozdziađu). Do uľytecznych funkcji narzúdzia Wireshark zaliczamy równieľ identyfikacjú pođæczeē sieciowych i powiæzanych z nimi pakietów, co pozwala na oddzielnæ analizú pakietów. Narzúdzie Wireshark umoľliwia takľe translacjú setek nagđówków protokođów.

10.6.13. Dtrace Narzúdzie DTrace moľe byè uľywane do analizowania z poziomu jædra i aplikacji zdarzeē sieciowych, takich jak: pođæczenia za pomocæ gniazd, gniazda wejħcia-wyjħcia, zdarzenia TCP, transmisja pakietów, odrzucenia pakietów z powodu zapeđnienia dziennika backlog, retransmisja TCP. Wymienione moľliwoħci pozwalajæ na przygotowanie charakterystyki obciæľenia i przeprowadzenie analizy opóļnienia. W dalszej czúħci znajdziesz wprowadzenie do uľycia narzúdzia DTrace w celu analizy sieci w systemach Linux i Solaris. Wiúkszoħè przedstawionych przykđadów dotyczy systemu Solaris, a tylko niektóre systemu Linux. Krótkie, ogólne wprowadzenie do DTrace zaprezentowano w rozdziale 4., zatytuđowanym „Narzúdzia monitorowania”. Dostawców DTrace uľywanych do monitorowania sieci wymieniono w tabeli 10.6. Tabela 10.6. Dostawcy DTrace używani podczas analizy sieci Warstwa

Stabilni dostawcy

Niestabilni dostawcy

Aplikacja

w zależności od aplikacji

pid

Biblioteka systemowa

-

pid

Wywołania systemowe

-

syscall

Gniazdo

-

fbt

TCP

tcp, mib

fbt

UDP

udp, mib

fbt

IP

ip, mib

fbt

Warstwa łącza

-

fbt

Sterownik urządzenia

-

fbt

Zawsze naleľy korzystaè z dostawców stabilnych, ale mogæ byè niedostúpni dla uľywanego przez Ciebie systemu operacyjnego lub danej wersji DTrace. Jeľeli nie sæ dostúpni, to moľna wykorzystaè interfejs niestabilnych dostawców, choè moľe byè konieczne uaktualnienie skryptów i dostosowanie ich do zmian w oprogramowaniu.

10.6. Analiza

579

Połączenia gniazd Aktywnoħè gniazd moľna monitorowaè za pomocæ funkcji sieciowych aplikacji, bibliotek gniazd systemowych, warstwy wywođaē systemowych lub za pomocæ jædra. Zwykle preferowane jest wykorzystanie warstwy wywođaē systemowych, poniewaľ jest doskonale udokumentowana, charakteryzuje siú niskim obciæľeniem systemu (jeħli dziađa w jædrze) i obejmuje zasiúgiem cađy system. Poniľsze polecenie powoduje zliczenie za pomocæ funkcji count() pođæczeē wychodzæcych: # dtrace -n 'syscall::connect:entry { @[execname] = count(); }' dtrace: description 'syscall::connect:entry ' matched 1 probe ^C ssh node haproxy

1 16 22

Wymienione jednowierszowe wywođanie DTrace zlicza liczbú wywođaē systemowych connect(). W przedstawionym przykđadzie najwiúksza liczba wywođaē dotyczy procesu o nazwie haproxy, który 22 razy wywođađ connect(). Jeľeli zachodzi potrzeba, dane wyjħciowe mogæ zawieraè jeszcze inne informacje szczegóđowe, miúdzy innymi: identyfikator procesu, argumenty procesu oraz argumenty wywođania systemowego connect(). Poniľsze polecenie powoduje zliczenie za pomocæ funkcji accept() pođæczeē przychodzæcych: # dtrace -n 'syscall::accept:return { @[execname] = count(); }' dtrace: description 'syscall::accept:return ' matched 1 probe ^C sshd unicorn beam.smp node

2 5 12 24

W przedstawionym przykđadzie proces o nazwie node zaakceptowađ najwiúcej pođæczeē, a dokđadnie 24. W trakcie wystúpowania zdarzeē gniazd jest moľliwoħè monitorowania stosów zarówno na poziomie jædra, jak i uľytkownika, co pozwala na sprawdzenie sposobu ich dziađania jako fragmentu procesu przygotowywania charakterystyki obciæľenia. Na przykđad prezentowane wywođanie DTrace monitoruje wywođania systemowe connect() stosów na poziomie uľytkownika dla procesów zawierajæcych w nazwie ssh: # dtrace -n 'syscall::connect:entry /execname == "ssh"/ { ustack(); }' dtrace: description 'syscall::connect:entry ' matched 1 probe CPU ID FUNCTION:NAME 1 1011 connect:entry libc.so.1`__so_connect+0x15 libsocket.so.1`connect+0x23 ssh`timeout_connect+0x20 ssh`ssh_connect+0x1b7

Więcej na: www.ebook4all.pl 580

Rozdział 10



Sieć

ssh`main+0xc83 ssh`_start+0x83 ^C

Moľna takľe monitorowaè argumenty wywođania systemowego. To wymaga jednak nieco wiúcej wysiđku niľ w przypadku zwykđego wywođania DTrace, poniewaľ interesujæce nas informacje znajdujæ siú w strukturze, któræ trzeba skopiowaè z przestrzeni uľytkownika do przestrzeni jædra. Do przeprowadzenia wspomnianego monitorowania przygotowano skrypt o nazwie soconnect.d. Wiúcej informacji na jego temat znajdziesz w odwođaniu [Gregg 11] na koēcu rozdziađu: #!/usr/sbin/dtrace -s #pragma D option quiet #pragma D option switchrate=10hz /* If AF_INET i AF_INET6 są "nieznane" dla DTrace, zastąp je liczbami: */ inline int af_inet = AF_INET; inline int af_inet6 = AF_INET6; dtrace:::BEGIN { /* Z pliku /usr/include/sys/errno.h moĪna dodaü dowolne translacje. */ err[0] = "Success"; err[EINTR] = "Interrupted syscall"; err[EIO] = "I/O error"; err[EACCES] = "Permission denied"; err[ENETDOWN] = "Network is down"; err[ENETUNREACH] = "Network unreachable"; err[ECONNRESET] = "Connection reset"; err[EISCONN] = "Already connected"; err[ECONNREFUSED] = "Connection refused"; err[ETIMEDOUT] = "Timed out"; err[EHOSTDOWN] = "Host down"; err[EHOSTUNREACH] = "No route to host"; err[EINPROGRESS] = "In progress"; printf("%-6s %-16s %-3s %-16s %-5s %8s %s\n", "PID", "PROCESS", "FAM", "ADDRESS", "PORT", "LAT(us)", "RESULT"); } syscall::connect*:entry { /* Dopóki nie bĊdzie moĪna przeanalizowaü rodziny, przyjmujemy zaáoĪenie, Īe to sockaddr_in. */ this->s = (struct sockaddr_in *)copyin(arg1, sizeof (struct sockaddr)); this->f = this->s->sin_family; } syscall::connect*:entry /this->f == af_inet/ {

10.6. Analiza

581

self->family = this->f; self->port = ntohs(this->s->sin_port); self->address = inet_ntop(self->family, (void *)&this->s->sin_addr); self->start = timestamp; } syscall::connect*:entry /this->f == af_inet6/ { /* Ponowne pobranie sockaddr_in6. */ this->s6 = (struct sockaddr_in6 *)copyin(arg1, sizeof (struct sockaddr_in6)); self->family = this->f; self->port = ntohs(this->s6->sin6_port); self->address = inet_ntoa6((in6_addr_t *)&this->s6->sin6_addr); self->start = timestamp; } syscall::connect*:return /self->start/ { this->delta = (timestamp - self->start) / 1000; this->errstr = err[errno] != NULL ? err[errno] : lltostr(errno); printf("%-6d %-16s %-3d %-16s %-5d %8d %s\n", pid, execname, self->family, self->address, self->port, this->delta, this->errstr); self->family = 0; self->address = 0; self->port = 0; self->start = 0; }

Oto przykđadowe dane wyjħciowe wygenerowane za pomocæ przedstawionego skryptu: # ./soconnect.d PID PROCESS 13489 haproxy 13489 haproxy 65585 ssh 3319 node 12585 haproxy 13674 haproxy 13489 haproxy [...]

FAM 2 2 2 2 2 2 2

ADDRESS 10.2.204.18 10.2.204.18 10.2.203.2 10.2.204.26 10.2.204.24 10.2.204.24 10.2.204.18

PORT 8098 8098 22 80 636 636 8098

LAT(us) 32 2 701 35 24 62 33

RESULT In progress Already connected Success In progress In progress In progress In progress

Przedstawiony skrypt monitoruje wywođania systemowe connect(), a nastúpnie wyħwietla wiersz danych wyjħciowych w celu podsumowania wykrytego wywođania systemowego. Podsumowanie to zawiera informacje o opóļnieniu wywođania systemowego, kod bđúdu (errno) zwrócony przez wywođanie systemowe (RESULT) przeksztađcony na ciæg tekstowy. Kodem bđúdu bardzo czústo jest komunikat In progress, który wystúpuje w przypadku nieblokujæcych wywođaē systemowych connect().

582

Rozdział 10



Sieć

Poza wymienionymi wywođaniami systemowymi connect() i accept() moľna monitorowaè równieľ socket() i close(). W ten sposób moľna sprawdziè tworzenie deskryptora pliku (FD) oraz ľywotnoħè gniazda, co pozwala na obliczenie czasu delta.

Operacje wejścia-wyjścia gniazda Po utworzeniu gniazda kolejne zdarzenia odczytu i zapisu moľna monitorowaè na poziomie warstwy wywođaē systemowych, korzystajæc z deskryptora pliku. W tym zakresie do dyspozycji mamy dwa rozwiæzania: 



Tablica asocjacyjna deskryptorów plików gniazd. To rozwiæzanie obejmuje monitorowanie syscall:socket:return i utworzenie tablicy asocjacyjnej, na przykđad is_socket[pid, arg1] = 1;. Tú tablicú moľna sprawdzaè w predykacie przyszđych wywođaē systemowych wejħcia-wyjħcia, aby zidentyfikowaè, które z nich sæ deskryptorami plików. Pamiútaj o koniecznoħci usuniúcia wartoħci w syscall::close:entry. Stan wartoħci fds[].fi_fs, o ile jest oferowana przez uľywanæ wersjú DTrace. To jest opis w postaci ciægu tekstowego, wskazujæcy typ systemu plików. Poniewaľ gniazda sæ mapowane na VFS, ich operacje wejħcia-wyjħcia sæ powiæzane z wirtualnym systemem pliku gniazda.

Prezentowane jednowierszowe wywođanie narzúdzia DTrace pokazuje uľycie drugiego z wymienionych wczeħniej rozwiæzaē. Zliczanie operacji odczytu gniazd przez execname, przeprowadzanych za pomocæ read() lub recv(): # dtrace -n 'syscall::read:entry,syscall::recv:entry /fds[arg0].fi_fs == "sockfs"/ { @[probefunc] = count(); }' dtrace: description 'syscall::read:entry,syscall::recv:entry ' matched 2 probes ^C master sshd beam.smp haproxy node

2 16 82 208 1218

Dane wyjħciowe pokazujæ, ľe w trakcie sesji monitorowania proces o nazwie node przeprowadziđ 1218 operacji odczytu z gniazd, uľywajæc dowolnego z wymienionych wywođaē systemowych. Zliczanie operacji zapisu gniazd przez execname, przeprowadzanych za pomocæ write() lub send(), przedstawia poniľsze jednowierszowe wywođanie narzúdzia DTrace: dtrace -n 'syscall::write:entry,syscall::send:entry /fds[arg0].fi_fs == "sockfs"/ { @[probefunc] = count(); }'

Zwróè uwagú na fakt, ľe Twój system operacyjny moľe uľywaè odmian wymienionych wywođaē systemowych (na przykđad readv()), które równieľ naleľy monitorowaè.

10.6. Analiza

583

Wielkoħè operacji wejħcia-wyjħcia moľna przeanalizowaè za pomocæ monitorowania wartoħci zwrotnej sondy dla kaľdego wywođania systemowego.

Opóźnienie gniazda Bioræc pod uwagú moľliwoħè monitorowania zdarzeē gniazda na warstwie wywođaē systemowych, wymienione pomiary moľna przeprowadziè jak fragment operacji analizy opóļnienia: 





Opóļnienie pođæczenia. W przypadku synchronicznych wywođaē systemowych to búdzie czas spúdzony w connect(). Dla nieblokujæcych operacji wejħcia-wyjħcia búdzie to z kolei czas, jaki upđynæđ od wydania connect() do chwili, gdy poll() lub select() (bædļ teľ inne wywođanie systemowe) zgđosi gotowoħè gniazda. Opóļnienie pierwszego bajta. To jest czas od chwili wydania connect() lub zakoēczenia dziađania accept() do chwili, gdy pierwszy bajt danych zostanie otrzymany za pomocæ dowolnej operacji wejħcia-wyjħcia wywođania systemowego dla danego gniazda. Czas trwania gniazda. To jest czas od chwili wykonania socket() do close() dla tego samego deskryptora pliku. Aby jeszcze bardziej skoncentrowaè siú na czasie trwania pođæczenia, moľna przeprowadziè pomiar czasu od wywođania connect() do zakoēczenia dziađania accept().

Wymienione pomiary moľna przeprowadziè za pomocæ dđugich jednowierszowych wywođaē DTrace lub jako skrypty. Istnieje równieľ moľliwoħè ich wykonania na poziomie innych warstw stosu sieciowego, na przykđad TCP.

Wewnętrzne komponenty gniazda Wewnútrzne komponenty jædra dotyczæce gniazd moľna monitorowaè za pomocæ dostawcy fbt. Na przykđad poniľsze wywođanie powoduje w systemie Linux nasđuchiwanie funkcji o nazwie rozpoczynajæcej siú od sock_: # dtrace -ln 'fbt::sock*:entry' ID PROVIDER MODULE 21690 fbt kernel 36306 fbt kernel 36312 fbt kernel 36314 fbt kernel 36316 fbt kernel 36328 fbt kernel 36330 fbt kernel [...]

FUNCTION sock_has_perm socket_suspend socket_reset socket_setup socket_early_resume socket_shutdown socket_insert

NAME entry entry entry entry entry entry entry

Dane wyjħciowe zostađy skrócone, zawierađy bowiem ponad 100 sond. Kaľdæ z nich moľna monitorowaè indywidualnie wraz z argumentami i znacznikami czasu. Dziúki temu moľna uzyskiwaè odpowiedzi na dowolne pytania dotyczæce zachowania gniazd.

584

Rozdział 10



Sieć

Zdarzenia TCP Podobnie jak w przypadku gniazd, takľe wewnútrzne komponenty jædra dotyczæce protokođu TCP moľna monitorowaè za pomocæ dostawcy fbt. Tymczasem opracowany przeze mnie stabilny dostawca tcp moľe byè dostúpny dla uľywanego przez Ciebie systemu operacyjnego. Dostúpne sondy zostađy wymienione w tabeli 10.7. Tabela 10.7. Dostawcy sond TCP w narzędziu DTrace Sondy TCP

Opis

accept-established

Połączenie przychodzące zostało zaakceptowane (pasywne otwarcie).

connect-request

Zainicjowano połączenie wychodzące (aktywne otwarcie).

connect-established

Nawiązano połączenie wychodzące (zakończono trzyetapowy proces negocjacji).

accept-refused

Żądanie połączenia zostało odrzucone (zamknięty port lokalny).

connect-refused

Żądanie połączenia zostało odrzucone (zamknięty port zdalny).

send

Nastąpiło wysłanie segmentu (IP może mapować segmenty bezpośrednio na pakiety).

receive

Nastąpiło otrzymanie segmentu (IP może mapować segmenty bezpośrednio na pakiety).

state-change

Nastąpiła zmiana stanu sesji (informacje szczegółowe znajdują się w argumentach sondy).

Wiúkszoħè wspomnianych argumentów pokazuje informacje szczegóđowe nagđówka protokođu, a takľe informacje o wewnútrznym stanie jædra, miúdzy innymi identyfikator „buforowanego” procesu. Nazwa procesu, zwykle monitorowana za pomocæ wbudowanego w DTrace execname, nie musi byè prawidđowa, poniewaľ zdarzenia TCP w jædrze mogæ wystúpowaè asynchronicznie do procesu. Przedstawione wywođanie zlicza iloħè zaakceptowanych pođæczeē TCP (pasywnych) wraz ze zdalnymi adresami IP i portami lokalnymi: # dtrace -n 'tcp:::accept-established { @[args[3]->tcps_raddr, args[3]->tcps_lport] = count(); }' dtrace: description 'tcp:::accept-established ' matched 1 probe ^C 10.2.0.2 10.2.204.24 10.2.204.28 10.2.204.30

22 8098 636 636

1 4 5 5

Podczas monitorowania komputer o adresie 10.2.204.30 piúciokrotnie nawiæzađ pođæczenie z portem lokalnym TCP o numerze 636. Podobne opóļnienia moľna monitorowaè za pomocæ sond TCP, jak to omówiono nieco wczeħniej we fragmencie poħwiúconym opóļnieniu gniazd. Do tego celu naleľy wykorzystaè sondy TCP.

10.6. Analiza

585

To polecenie powoduje wyħwietlenie listy dostúpnych sond: # dtrace -ln 'tcp:::' ID PROVIDER 1810 tcp 1813 tcp 1814 tcp 1827 tcp 1870 tcp 1871 tcp [...]

MODULE ip ip ip ip ip ip

FUNCTION tcp_input_data tcp_input_data tcp_input_data tcp_xmit_early_reset tcp_input_data tcp_input_listener

NAME accept-established connect-refused connect-established accept-refused receive receive

Kolumny MODULE i FUNCTION NAME wyħwietlajæ (niestabilne) pođoľenie sondy w kodzie jædra, które moľna monitorowaè za pomocæ dostawcy fbt, aby uzyskaè wiúcej informacji szczegóđowych.

Transmisja pakietu Aby przeanalizowaè wewnútrzne komponenty jædra poza dostawcæ tcp lub jeħli wymieniony dostawca jest niedostúpny, naleľy uľyè dostawcy fbt. To jest jeden z przypadków, w których monitorowanie dynamiczne umoľliwia przeprowadzenie operacji, ale niekoniecznie búdzie ona đatwa — to i tak lepiej niľ brak moľliwoħci jej wykonania! Wewnútrzne komponenty stosu sieciowego sæ skomplikowane i osoba poczætkujæca moľe poħwiúciè cađe dnie, zanim pozna ħcieľki kodu. Rozwiæzaniem pozwalajæcym na szybkie poruszanie siú po stosie jest gđúbokie monitorowanie zdarzeē, a nastúpnie analiza wsteczna stosu. Na przykđad w systemie Linux przedstawione wywođanie powoduje monitorowanie ip_output() za pomocæ stack: # dtrace -n 'fbt::ip_output:entry { @[stack(100)] = count(); }' dtrace: description 'fbt::ip_output:entry ' matched 1 probe ^C [...] kernel`ip_output+0x1 kernel`ip_local_out+0x29 kernel`ip_queue_xmit+0x14f kernel`tcp_transmit_skb+0x3e4 kernel`__kmalloc_node_track_caller+0x185 kernel`sk_stream_alloc_skb+0x41 kernel`tcp_write_xmit+0xf7 kernel`__alloc_skb+0x8c kernel`__tcp_push_pending_frames+0x26 kernel`tcp_sendmsg+0x895 kernel`inet_sendmsg+0x64 kernel`sock_aio_write+0x13a kernel`do_sync_write+0xd2 kernel`security_file_permission+0x2c kernel`rw_verify_area+0x61 kernel`vfs_write+0x16d kernel`sys_write+0x4a

586

Rozdział 10



Sieć

kernel`sys_rt_sigprocmask+0x84 kernel`system_call_fastpath+0x16 639

Kaľdy wiersz wskazuje funkcjú jædra, któræ moľna monitorowaè oddzielnie. Wymagane jest wiúc przeanalizowanie kodu ļródđowego w celu ustalenia roli poszczególnych funkcji i ich argumentów. Przykđadowo, bioræc pod uwagú fakt, ľe czwartym argumentem funkcji tcp_ ´sendmsg() jest wielkoħè wyraľona w bajtach, moľna jæ monitorowaè w nastúpujæcy sposób: # dtrace -n 'fbt::tcp_sendmsg:entry { @["TCP send bytes"] = quantize(arg3); }' dtrace: description 'fbt::tcp_sendmsg:entry ' matched 1 probe ^C TCP send bytes value ------------- Distribution ------------- count 16 | 0 32 |@@@@@@@@ 154 64 |@@@ 54 128 |@@@@@@@@@@@@@@@@@@@ 375 256 |@@@@@@@@@ 184 512 | 2 1024 | 1 2048 | 3 4096 | 4 8192 | 0

Przedstawione jednowierszowe wywođanie DTrace uľywa akcji quantize() do podsumowania wielkoħci wysyđanego segmentu TCP i przygotowania jego rozkđadu. Wiúkszoħè segmentów miađa wielkoħè w zakresie od 128 bajtów do 511 bajtów. Istnieje moľliwoħè przygotowania dđuľszych, jednowierszowych wywođaē i skryptów, pozwalajæcych na przykđad monitorowaè retransmisje TCP i odrzucenia pakietów przez kolejkú backlog.

Monitorowanie retransmisji Studiowanie informacji o retransmisji TCP moľe byè uľytecznym zadaniem podczas analizy stanu sieci. Wprawdzie historycznie tego rodzaju zadanie byđo przeprowadzane przez narzúdzia przeznaczone do przechwytywania wszystkich pakietów i zapisywania ich w pliku do dalszej analizy, ale narzúdzie DTrace pozwala przeprowadzaè analizú w czasie rzeczywistym i przy niewielkim obciæľeniu systemu. Przedstawiony skrypt dla jædra systemu Linux w wersji 3.2.6 powoduje monitorowanie funkcji tcp_retransmit_ ´skb() i wyħwietla uľyteczne informacje szczegóđowe: #!/usr/sbin/dtrace -s #pragma D option quiet dtrace:::BEGIN { trace("Tracing TCP retransmits... Ctrl-C to end.\n"); }

10.6. Analiza

587

fbt::tcp_retransmit_skb:entry { this->so = (struct sock *)arg0; this->d = (unsigned char *)&this->so->__sk_common.skc_daddr; printf("%Y: retransmit to %d.%d.%d.%d, by:", walltimestamp, this->d[0], this->d[1], this->d[2], this->d[3]); stack(99); }

To sæ przykđadowe dane wyjħciowe wygenerowane przez skrypt: # ./tcpretransmit.d Tracing TCP retransmits... Ctrl-C to end. 2013 Feb 23 18:24:11: retransmit to 10.2.124.2, by: kernel`tcp_retransmit_timer+0x1bd kernel`tcp_write_timer+0x188 kernel`run_timer_softirq+0x12b kernel`tcp_write_timer kernel`__do_softirq+0xb8 kernel`read_tsc+0x9 kernel`sched_clock+0x9 kernel`sched_clock_local+0x25 kernel`call_softirq+0x1c kernel`do_softirq+0x65 kernel`irq_exit+0x9e kernel`smp_apic_timer_interrupt+0x6e kernel`apic_timer_interrupt+0x6e [...]

Dane wyjħciowe zawierajæ czas, docelowy adres IP, a takľe stos jædra, co pomoľe w wyjaħnieniu przyczyny ponownej transmisji pakietu. Wiúcej informacji moľna uzyskaè dziúki oddzielnemu monitorowaniu poszczególnych funkcji ze stosu jædra. Podobny skrypt zostađ opracowany dla systemu SmartOS i stanowi czúħè zestawu narzúdziowego dla operatorów ħrodowiska przetwarzania w chmurze (patrz odwođanie [6] na koēcu rozdziađu). Skrypt nosi nazwú tcpretranssnoop.d, a wygenerowane przez niego przykđadowe dane wyjħciowe pokazano poniľej: # ./tcpretranssnoop.d TIME TCP_STATE 2012 Sep 8 03:12:12 TCPS_ESTABLISHED 2012 Sep 8 03:12:12 TCPS_ESTABLISHED 2012 Sep 8 03:12:12 TCPS_FIN_WAIT_1 2012 Sep 8 03:12:12 TCPS_ESTABLISHED 2012 Sep 8 03:12:12 TCPS_ESTABLISHED 2012 Sep 8 03:12:12 TCPS_ESTABLISHED [...]

SRC 10.225.152.20 10.225.152.20 10.225.152.20 10.225.152.24 10.225.152.30 10.225.152.37

DST 10.225.152.189 10.225.152.161 10.88.122.66 10.40.254.88 10.249.197.234 10.117.114.41

PORT 40900 62450 54049 34620 3234 49700

Dane wyjħciowe zawierajæ docelowy adres IP dla retransmisji (zmieniony w przedstawionych danych) i informacje o stanie TCP w jædrze.

588

Rozdział 10



Sieć

Odrzucenia pakietów przez kolejkę backlog Ostatni skrypt równieľ pochodzi ze zbioru narzúdziowego skryptów TCP dla systemu SmartOS. Jest uľywany do sprawdzenia, czy konieczne jest zmodyfikowanie parametrów dotyczæcych kolejki backlog, aby zapewniè jej efektywne dziađanie. To jest nieco dđuľszy skrypt — zostađ tutaj zaprezentowany jako przykđad analizy zaawansowanej: #!/usr/sbin/dtrace -s #pragma D option quiet #pragma D option switchrate=4hz dtrace:::BEGIN { printf("Tracing... Hit Ctrl-C to end.\n"); } fbt::tcp_input_listener:entry { this->connp = (conn_t *)arg0; this->tcp = (tcp_t *)this->connp->conn_proto_priv.cp_tcp; self->max = strjoin("max_q:", lltostr(this->tcp->tcp_conn_req_max)); self->pid = strjoin("cpid:", lltostr(this->connp->conn_cpid)); @[self->pid, self->max] = quantize(this->tcp->tcp_conn_req_cnt_q); } mib:::tcpListenDrop { this->max = self->max; this->pid = self->pid; this->max != NULL ? this->max : ""; this->pid != NULL ? this->pid : ""; @drops[this->pid, this->max] = count(); } fbt::tcp_input_listener:return { self->max = 0; self->pid = 0; } dtrace:::END { printf("tcp_conn_req_cnt_q distributions:\n"); printa(@); printf("tcpListenDrops:\n"); printa(" %-32s %-32s %@8d\n", @drops); }

Skrypt uľywa niestabilnego dostawcy fbt do pobrania stanu TCP oraz dostawcy mib w celu zliczenia liczby odrzuconych pakietów. Przykđadowe dane wyjħciowe skryptu sæ nastúpujæce:

10.6. Analiza

589

# ./tcpconnreqmaxq-pid.d Tracing... Hit Ctrl-C to end. ^C tcp_conn_req_cnt_q distributions: cpid:11504 max_q:128 value ------------- Distribution ------------- count -1 | 0 0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 7279 1 |@@ 405 2 |@ 255 4 |@ 138 8 | 81 16 | 83 32 | 62 64 | 67 128 | 34 256 | 0 tcpListenDrops: cpid:11504 max_q:128 34

Po naciħniúciu klawiszy Ctrl+C wyħwietlane jest podsumowanie pokazujæce identyfikatory buforowanych procesów (cpid), aktualnæ maksymalnæ dđugoħè kolejki backlog gniazda (max_q) i wykres rozkđadu wskazujæcy dđugoħè kolejki mierzonæ podczas dodawania nowych pođæczeē. Z danych wyjħciowych moľna odczytaè, ľe dla procesu o identyfikatorze 11504 nastæpiđy 34 odrzucenia pakietów, a maksymalna dđugoħè kolejki wynosi 128. Rozkđad pokazuje, ľe przez wiúkszoħè czasu dđugoħè kolejki byđa zerowa, a jedynie na bardzo krótko osiægađa ona swojæ maksymalnæ dđugoħè. W omawianej sytuacji dobrym rozwiæzaniem moľe byè zwiúkszenie dđugoħci kolejki. Wspomniana kolejka backlog jest zwykle dostrajana jedynie wtedy, gdy nastúpujæ odrzucenia pakietów, co búdzie widoczne w liczniku tcpListenDrops w danych wyjħciowych polecenia netstat -s. Omawiany tutaj skrypt DTrace pozwala przewidzieè odrzucanie pakietów i zastosowaè odpowiednie rozwiæzanie, zanim odrzucanie pakietów stanie siú problemem. To sæ inne dane wyjħciowe omawianego skryptu: cpid:16480 value -1 0 1 2 4 8 16 32 64 128 256

max_q:128 ------------- Distribution ------------- count | 0 |@@@@@@@ 1666 |@@ 457 |@ 262 |@ 332 |@@ 395 |@@@ 637 |@@@ 578 |@@@@ 939 |@@@@@@@@@@@@@@@@@ 3947 | 0

590

Rozdział 10



Sieć

W przedstawionym przykđadzie kolejka backlog zwykle ma swojæ dđugoħè maksymalnæ (128). To sugeruje, ľe aplikacja jest przeciæľona i nie ma przydzielonej wystarczajæcej iloħci zasobów (najczúħciej procesora) do obsđugi bieľæcego obciæľenia.

Jeszcze więcej monitorowania Monitorowanie dynamiczne moľe dostarczyè wielu znacznie dokđadniejszych informacji o sieci, jeħli sæ one niezbúdne do bardziej zaawansowanej analizy. Aby zademonstrowaè próbkú dostúpnych moľliwoħci, w tabeli 10.8 wymieniono skrypty z rozdziađu ksiæľki poħwiúconej narzúdziu DTrace (patrz odwođanie [Gregg 11] na koēcu rozdziađu). Skrypty te sæ dostúpne w internecie (patrz odwođanie [7] na koēcu rozdziađu). Tabela 10.8. Skrypty pozwalające na zaawansowane monitorowanie sieci Skrypt

Warstwa

Opis

soconnect.d

gniazdo

Monitorowanie wywołań connect() gniazda klienta, wyświetlanie nazwy procesu i komputera.

soaccept.d

gniazdo

Monitorowanie wywołań accept() gniazda klienta, wyświetlanie nazwy procesu i komputera.

soclose.d

gniazdo

Monitorowanie czasu połączenia gniazda: od chwili wywołania connect() do close().

socketio.d

gniazdo

Pokazanie operacji wejścia-wyjścia gniazda według procesu i typu.

socketiosort.d

gniazdo

Pokazanie operacji wejścia-wyjścia gniazda według procesu i typu, posortowane według procesu.

so1stbyte.d

gniazdo

Monitorowanie opóźnienia połączenia i opóźnienia pierwszego bajta na warstwie gniazda.

sotop.d

gniazdo

Narzędzie stanu, wyświetlanie listy najbardziej zajętych gniazd.

soerror.d

gniazdo

Identyfikacja błędów gniazd.

ipstat.d

IP

Wyświetlanie co sekundę danych statystycznych IP.

ipio.d

IP

Monitorowanie otrzymywania i wysyłania danych IP.

ipproto.d

IP

Podsumowanie hermetyzowanego prototypu IP.

ipfbtsnoop.d

IP

Monitorowanie pakietów IP: demonstracja monitorowania za pomocą dostawcy fbt.

tcpstat.d

TCP

Wyświetlanie co sekundę danych statystycznych TCP.

tcpaccept.d

TCP

Podsumowanie przychodzących połączeń TCP.

tcpacceptx.d

TCP

Podsumowanie przychodzących połączeń TCP, tłumaczenie adresów IP na nazwy komputerów.

tcpconnect.d

TCP

Podsumowanie wychodzących połączeń TCP.

tcpioshort.d

TCP

Monitorowanie otrzymywania i wysyłania danych TCP na żywo i wyświetlanie podstawowych informacji.

tcpio.d

TCP

Monitorowanie otrzymywania i wysyłania danych TCP na żywo, ustawiona flaga translacji nazw.

10.6. Analiza

591

Tabela 10.8. Skrypty pozwalające na zaawansowane monitorowanie sieci — ciąg dalszy Skrypt

Warstwa

Opis

tcpbytes.d

TCP

Podsumowanie liczby bajtów danych TCP otrzymanych przez klienta i port lokalny.

tcpsize.d

TCP

Wyświetlenie rozkładu wielkości operacji wejścia-wyjścia dla otrzymanych i wysłanych danych TCP.

tcpnmap.d

TCP

Wykrycie potencjalnej operacji skanowania portu TCP.

tcpconnlat.d

TCP

Pomiar opóźnienia TCP przez zdalny komputer.

tcp1stbyte.d

TCP

Pomiar opóźnienia pierwszego bajta TCP przez zdalny komputer.

tcp_rwndclosed.d

TCP

Identyfikacja, że TCP otrzymuje zdarzenia Zero Windows. Dane zawierają także informacje o ich opóźnieniu.

tcpfbtwatch.d

TCP

Nasłuchiwanie przychodzących połączeń TCP.

tcpsnoop.d

TCP

Monitorowanie operacji wejścia-wyjścia TCP i wyświetlanie informacji szczegółowych o procesie.

udpstat.d

UDP

Wyświetlanie co sekundę danych statystycznych UDP.

udpio.d

UDP

Monitorowanie otrzymywania i wysyłania danych UDP na żywo i wyświetlanie podstawowych informacji.

icmpstat.d

ICMP

Wyświetlanie co sekundę danych statystycznych ICMP.

icmpsnoop.d

ICMP

Monitorowanie pakietów ICMP i wyświetlanie szczegółowych informacji o nich.

superping.d

ICMP

Poprawienie dokładności pomiaru czasu podróży pakietu ping w obie strony.

xdrshow.d

XDR

Pokazywanie wywołań zewnętrznej reprezentacji danych (XDR) i wywołań funkcji.

macops.d

MAC

Zliczanie operacji warstwy MAC (ang. Media Access Control) według interfejsu i typu.

ngesnoop.d

sterownik

Monitorowanie na żywo zdarzeń sterownika nge dla Ethernetu.

ngelink.d

sterownik

Monitorowanie zmian w stanie łącza nge.

We wspomnianej ksiæľce poħwiúconej narzúdziu DTrace, a dokđadnie w rozdziale o protokođach warstwy aplikacji, znajdziesz jeszcze wiúcej skryptów, przeznaczonych do monitorowania NFS, CIFS, HTTP, DNS, FTP, iSCSI, FC, SSH, NIS i LDAP. Wprawdzie moľliwy stopieē monitorowania jest wrúcz niewiarygodny, jednak wiele wymienionych skryptów monitorowania dynamicznego jest powiæzanych z konkretnymi komponentami jædra i búdæ wymagađy uaktualnieē, aby dopasowaè je do zmian wprowadzanych w nowszych wersjach jædra. Z kolei inne skrypty opierajæ siú na konkretnych dostawcach DTrace, którzy mogæ byè niedostúpni dla uľywanego przez Ciebie systemu operacyjnego.

592

Rozdział 10



Sieć

10.6.14. SystemTap W systemie Linux do monitorowania dynamicznego zdarzeē dotyczæcych sieci moľna wykorzystaè takľe SystemTap. Zapoznaj siú z podrozdziađem 4.4 w rozdziale 4. „Narzúdzia monitorowania” oraz z dodatkiem E. Znajdziesz tam informacje pomocne w konwersji wczeħniej przedstawionych skryptów DTrace.

10.6.15. perf Zestaw narzúdziowy LPE (wprowadzony w rozdziale 6. „Procesory”) równieľ moľe daè moľliwoħè statycznego i dynamicznego monitorowania zdarzeē sieci. To moľe byè bardzo uľyteczne rozwiæzanie podczas identyfikacji stosów prowadzæcych do aktywnoħci sieciowej w jædrze, jak to zademonstrowano wczeħniej w trakcie stosowania narzúdzia DTrace do monitorowania transmisji i retransmisji pakietów. Jest równieľ moľliwoħè opracowania znacznie bardziej zaawansowanych narzúdzi do przetwarzania zebranych danych. Przedstawione tutaj polecenie uľywa perf do utworzenia dynamicznych punktów instrumentacji funkcji jædra o nazwie tcp_sendmsg(), a nastúpnie monitoruje jæ przez 5 sekund i wyħwietla stos wywođaē: # perf probe --add='tcp_sendmsg' Add new event: probe:tcp_sendmsg (on tcp_sendmsg) [...] # perf record -e probe:tcp_sendmsg -aR -g sleep 5 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.091 MB perf.data (~3972 samples) ] # perf report --stdio [...] # Overhead Command Shared Object Symbol # ........ ....... ................. ........... # 100.00% sshd [kernel.kallsyms] [k] tcp_sendmsg | --- tcp_sendmsg sock_aio_write do_sync_write vfs_write sys_write system_call __GI___libc_write

Dane wyjħciowe pokazujæ stos dla procesu sshd, który doprowadziđ jædro do wywođania funkcji tcp_sendmsg() i wysđania danych przez pođæczenie TCP. Istniejæ jeszcze inne zdarzenia punktów instrumentacji, predefiniowane dla sieci: # perf list [...] skb:kfree_skb

[Tracepoint event]

10.6. Analiza

skb:consume_skb skb:skb_copy_datagram_iovec net:net_dev_xmit net:net_dev_queue net:netif_receive_skb net:netif_rx

593

[Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint

event] event] event] event] event] event]

Punkty instrumentacji skb sæ przeznaczone dla zdarzeē bufora gniazda, natomiast net — dla urzædzeē sieciowych. Okazujæ siú bardzo uľyteczne podczas analizy sieci.

10.6.16. Inne narzędzia W systemie Linux narzúdzia przeznaczone do analizy wydajnoħci sieci to miúdzy innymi: 



strace. Monitorowanie wywođaē systemowych powiæzanych z gniazdami oraz analiza uľytych opcji (zwróè uwagú, ľe dziađanie strace wiæľe siú z duľym obciæľeniem dla systemu). lsof. Wyħwietlenie listy otwartych plików, pogrupowanych wedđug identyfikatora procesu. Dane wyjħciowe zawierajæ informacje szczegóđowe o gniazdach.



ss. Dane statystyczne dotyczæce gniazda.



nfsstat. Dane statystyczne dotyczæce serwera NFS i klienta.





iftop. Podsumowanie przepustowoħci interfejsu sieciowego, dane sæ wyħwietlane wedđug komputerów. /proc/net. Katalog zawierajæcy wiele plików z danymi statystycznymi o sieci.

Dla systemu Solaris dostúpne sæ miúdzy innymi: 





 

truss. Monitorowanie wywođaē systemowych powiæzanych z gniazdami oraz analiza uľytych opcji (zwróè uwagú, ľe dziađanie truss wiæľe siú z duľym obciæľeniem dla systemu). pfiles. Analiza gniazd uľywanych przez proces. Dane wyjħciowe obejmujæ opcje i wielkoħè bufora gniazda. routeadm. Polecenie umoľliwiajæce sprawdzenie stanu routingu i przekazywania IP. nfsstat. Dane statystyczne dotyczæce serwera NFS i klienta. kstat. Narzúdzie dostarczajæce jeszcze wiúcej danych statystycznych o stosie sieci i sterownikach urzædzeē sieciowych (wiúkszoħè z nich pozostaje nieudokumentowana poza kodem ļródđowym).

Istniejæ takľe pewne rozwiæzania w zakresie monitorowania sieci oparte na protokole SNMP lub na dziađaniu wđasnych agentów.

594

Rozdział 10



Sieć

10.7. Eksperymenty Poza omówionymi wczeħniej poleceniami ping, traceroute i pathchar inne eksperymentalne narzúdzia przeznaczone do analizy wydajnoħci sieci dotyczæ mikrotestów wydajnoħci. Wspomniane narzúdzia moľna wykorzystaè w celu okreħlenia maksymalnej przepustowoħci miúdzy komputerami. Moľliwoħè sprawdzenia, czy przepustowoħè miúdzy dwoma punktami koēcowymi sieci stanowi problem, búdzie pomocna podczas debugowania aplikacji pod kætem bđúdów zwiæzanych z wydajnoħciæ sieci. Do wyboru jest wiele narzúdzi przeznaczonych do przeprowadzania mikrotestów wydajnoħci. W tym podrozdziale zademonstrowano iperf, które jest doħè popularne i đatwe w uľyciu. Innym narzúdziem, o którym warto wspomnieè, jest netperf — pozwala ono równieľ na przetestowanie wydajnoħci ľædaē i odpowiedzi na nie (patrz odwođanie [8] na koēcu rozdziađu).

10.7.1. iperf Polecenie iperf to narzúdzie typu open source przeznaczone do testowania maksymalnej przepustowoħci TCP i UDP. Obsđuguje wiele róľnych opcji, miúdzy innymi moľliwoħè pracy w trybie równolegđym, gdy uľywanych jest wiele wætków klienta, co moľe byè konieczne, aby w peđni wykorzystaè sieè. Polecenie iperf musi byè uruchomione zarówno w serwerze, jak i kliencie. Poniľej pokazano przykđad wydania polecenia iperf w serwerze: $ iperf -s -l 128k -----------------------------------------------------------Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------

W powyľszym wywođaniu zwiúkszono wielkoħè bufora gniazda do 128 KB (opcja -l 128k) z wielkoħci domyħlnej wynoszæcej 8 KB. To jest przykđad uruchomienia narzúdzia po stronie klienta: # iperf -c 10.2.203.2 -l 128k -P 2 -i 1 -t 60 -----------------------------------------------------------Client connecting to 10.2.203.2, TCP port 5001 TCP window size: 48.0 KByte (default) -----------------------------------------------------------[ 4] local 10.2.124.2 port 41407 connected with 10.2.203.2 port 5001 [ 3] local 10.2.124.2 port 35830 connected with 10.2.203.2 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 6.00 MBytes 50.3 Mbits/sec [ 3] 0.0- 1.0 sec 22.5 MBytes 189 Mbits/sec [SUM] 0.0- 1.0 sec 28.5 MBytes 239 Mbits/sec [ 3] 1.0- 2.0 sec 16.1 MBytes 135 Mbits/sec [ 4] 1.0- 2.0 sec 12.6 MBytes 106 Mbits/sec [SUM] 1.0- 2.0 sec 28.8 MBytes 241 Mbits/sec [...]

10.8. Dostrajanie

[ 4] [ 3] [SUM]

0.0-60.0 sec 0.0-60.0 sec 0.0-60.0 sec

595

748 MBytes 996 MBytes 1.70 GBytes

105 Mbits/sec 139 Mbits/sec 244 Mbits/sec

W przedstawionym przykđadzie zostađy uľyte nastúpujæce opcje: 

-c host: nawiæzanie pođæczenia z komputerem o podanej nazwie lub adresie IP,



-l 128k: uľycie bufora gniazda o wielkoħci 128 KB,



-P 2: uruchomienie narzúdzia w trybie równolegđym, z dwoma wætkami po stronie klienta,



-i 1: podsumowanie dotyczæce przedziađu czasu wyħwietlane co sekundú,



-t 60: cađkowity czas przeprowadzania testu wynoszæcy 60 sekund.

Ostatni wiersz danych wyjħciowych zawiera informacjú o ħredniej przepustowoħci osiægniútej podczas testu, podsumowanej dla wszystkich równolegle dziađajæcych wætków: 244 Mb/s. Istnieje moľliwoħè przestudiowania podsumowaē dla wskazanych przedziađów czasu, aby sprawdziè odchylenia wartoħci przepustowoħci na przestrzeni czasu. Opcja --reportstyle C powoduje umieszczenie danych wyjħciowych w pliku CSV, aby mogđy zostaè zaimportowane przez inne narzúdzia, na przykđad tworzæce wykresy.

10.8. Dostrajanie Modyfikowane parametry dotyczæce sieci zazwyczaj majæ juľ ustawione wartoħci zapewniajæce osiægniúcie wysokiej wydajnoħci. Stos sieciowy takľe jest zwykle zaprojektowany tak, aby dynamicznie odpowiadaè na róľne obciæľenia i zagwarantowaè optymalnæ wydajnoħè. Przed wypróbowaniem modyfikowalnych parametrów w pierwszej kolejnoħci warto poznaè sposób wykorzystania sieci. Dziúki temu moľliwe jest zidentyfikowanie niepotrzebnie wykonywanych zadaē, których wyeliminowanie przynosi najwiúkszæ poprawú wydajnoħci. Spróbuj przeprowadziè charakterystykú wydajnoħci i statyczne dostrojenie wydajnoħci za pomocæ narzúdzi przedstawionych we wczeħniejszej czúħci rozdziađu. Dostúpne opcje i przypisywane im wartoħci zaleľæ od wersji uľywanego systemu operacyjnego. Odpowiednie informacje znajdziesz w dokumentacji. W dalszej czúħci przedstawiono przykđady opcji, które mogæ byè dostúpne, i sposoby ich dostrajania. Naleľy je potraktowaè jako punkt wyjħcia i odpowiednio skorygowaè na podstawie obciæľenia i uľywanego ħrodowiska.

10.8.1. Linux Modyfikowalne parametry moľna przeglædaè i ustawiaè za pomocæ polecenia sysctl oraz zapisywaè w pliku /etc/sysctl.conf. Poza tym parametry mogæ byè odczytywane i zapisywane w systemie plików /proc, a dokđadnie w /proc/sys/net.

596

Rozdział 10



Sieć

Informacje o tym, jakie parametry sæ aktualnie dostúpne dla TCP, moľna znaleļè, wyszukujæc tekst tcp w danych wyjħciowych sysctl: # sysctl -a | grep tcp [...] net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_retrans_collapse = 1 net.ipv4.tcp_syn_retries = 5 net.ipv4.tcp_synack_retries = 5 net.ipv4.tcp_max_orphans = 65536 net.ipv4.tcp_max_tw_buckets = 65536 net.ipv4.tcp_keepalive_time = 7200 [...]

W sprawdzanym jædrze (3.2.6-3) znajdujæ siú 63 parametry zawierajæce w nazwie tekst tcp oraz znacznie wiúcej z czæstkæ net, miúdzy innymi: parametry dla IP, Ethernetu, routingu i interfejsów sieciowych. Przykđady konkretnych modyfikacji zostanæ przedstawione w kolejnych fragmentach.

Gniazda i bufory TCP Maksymalnæ wielkoħè bufora gniazda dla wszystkich rodzajów protokođów, zarówno dla odczytu (rmem_max), jak i zapisu (wmem_max), moľna ustawiè za pomocæ poniľszych parametrów: net.core.rmem_max = 16777216 net.core.wmem_max = 16777216

Wartoħci sæ podawane w bajtach. Aby zapewniè moľliwoħè obsđugi pođæczeē o szybkoħci 10 GbE, moľe byè potrzeba ustawienia powyľszym parametrom wartoħci 16 MB lub wiúkszej. Nastúpny prezentowany parametr pozwala na automatyczne dostrojenie bufora otrzymywanych danych TCP: tcp_moderate_rcvbuf = 1

Kolejne przedstawiane parametry powodujæ automatyczne dostrojenie parametrów dla buforów odczytu i zapisu TCP: net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216

Kaľdy parametr ma trzy wartoħci: minimalnæ, domyħlnæ i maksymalnæ liczbú bajtów do uľycia. Stosowana wielkoħè jest automatycznie dostrajana do wartoħci domyħlnej. W celu poprawy przepustowoħci TCP warto zwiúkszyè wartoħè maksymalnæ. Zwiúkszenie wartoħci minimalnej i domyħlnej spowoduje, ľe pođæczenia búdæ zuľywaè wiúkszæ iloħè pamiúci, co moľe okazaè siú niepotrzebne.

10.8. Dostrajanie

597

TCP Backlog Pierwsza kolejka backlog jest przeznaczona dla póđotwartych pođæczeē: tcp_max_syn_backlog = 4096

Z kolei druga kolejka backlog jest przeznaczona dla pođæczeē przekazywanych funkcji accept(): net.core.somaxconn = 1024

Oba wymienione parametry mogæ wymagaè zwiúkszenia wartoħci domyħlnych, na przykđad do 4096 i 1024 lub wiúcej, aby lepiej obsđuľyè duľe skoki obciæľenia.

Backlog urządzenia Poniľszy parametr umoľliwia zwiúkszenie dđugoħci kolejki backlog urzædzenia sieciowego dla poszczególnych procesorów: net.core.netdev_max_backlog = 10000

Ta wartoħè równieľ moľe wymagaè zwiúkszenia, na przykđad do 10 000 dla kart sieciowych w standardzie 10 GbE.

Kontrola przeciążenia w TCP System Linux obsđuguje dođæczane algorytmy kontroli przeciæľenia. Poniľsze polecenie powoduje wyħwietlenie listy aktualnie dostúpnych algorytmów: # sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = cubic reno

Pewne algorytmy mogæ byè dostúpne, ale aktualnie niewczytane. Poniľej pokazano na przykđad, jak dodaè htcp: # modprobe tcp_htcp # sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = cubic reno htcp

Bieľæcy algorytm moľna wskazaè nastúpujæco: net.ipv4.tcp_congestion_control = cubic

Opcje TCP Inne parametry TCP, które moľna ustawiè, to miúdzy innymi: net.ipv4.tcp_sack = 1 net.ipv4.tcp_fack = 1

598

Rozdział 10



Sieć

net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 0

Rozszerzenia SACK i FACK mogæ poprawiè wydajnoħè przepustowoħci w sieciach charakteryzujæcych siú duľym opóļnieniem, choè odbywa siú to kosztem wiúkszego zuľycia procesora. Parametr tcp_tw_reuse pozwala na ponowne uľycie sesji TIME-WAIT, gdy taka moľliwoħè wydaje siú bezpieczna. W ten sposób moľna zapewniè wiúkszæ liczbú pođæczeē miúdzy dwoma komputerami, na przykđad miúdzy serwerem WWW i bazæ danych, bez osiægniúcia 16-bitowego ograniczenia portu ephemeral z sesjami w TIME-WAIT. Z kolei tcp_tw_recycle to inny sposób na ponowne uľycie sesji TIME-WAIT, choè nie jest tak bezpieczny jak tcp_tw_reuse.

Interfejs sieciowy Dđugoħè kolejki TX moľna zwiúkszyè za pomocæ polecenia ifconfig, na przykđad: ifconfig eth0 txqueuelen 10000

Takie rozwiæzanie moľe byè konieczne dla kart sieciowych w standardzie 10 GbE. Ustawienie moľna dodaè do /etc/rc.local, aby byđo stosowane w trakcie uruchamiania systemu.

Kontrola zasobów Grup kontenerów (cgroups) podsystemu priorytetu sieci (net_prio) moľna uľywaè w celu nadawania priorytetu ruchowi wychodzæcemu dla procesów lub grup procesów. Takie rozwiæzanie moľna zastosowaè w celu preferowania ruchu sieciowego o wysokim priorytecie, na przykđad dla obciæľenia produkcyjnego, kosztem ruchu o niľszym priorytecie, na przykđad tworzenia kopii zapasowych lub monitorowania. Skonfigurowana wartoħè priorytetu jest przeksztađcana na poziom IP ToS (lub uaktualniony schemat uľywajæcy tych samych bitów) i umieszczana w pakietach.

10.8.2. Solaris Modyfikowalne parametry byđy historycznie ustawiane i przeglædane za pomocæ polecenia ndd lub teľ ustawiane przez /etc/system i przeglædane za pomocæ mdb. Obecnie nastæpiđa migracja do polecenia ipadm, które stanowi zunifikowane i elastyczne narzúdzie przeznaczone do zarzædzania wđaħciwoħciami stosu IP. Przedstawione tutaj wydanie polecenia ipadm powoduje wyħwietlenie listy wđaħciwoħci, na przykđad: # ipadm show-prop PROTO PROPERTY ipv4 forwarding ipv4 ttl ipv6 forwarding ipv6 hoplimit

PERM rw rw rw rw

CURRENT on 255 off 255

PERSISTENT on ----

DEFAULT off 255 off 255

POSSIBLE on,off 1-255 on,off 1-255

10.8. Dostrajanie

599

ipv6

hostmodel

rw

weak

--

ipv4

hostmodel

rw

src-priority --

icmp icmp tcp

recv_maxbuf send_maxbuf ecn

rw rw rw

8192 8192 passive

----

tcp tcp tcp tcp

extra_priv_ports largest_anon_port recv_maxbuf sack

rw rw rw rw

2049,4045 65535 128000 active

-----

tcp tcp tcp udp udp udp udp udp udp [...]

send_maxbuf smallest_anon_port smallest_nonpriv_port extra_priv_ports largest_anon_port recv_maxbuf send_maxbuf smallest_anon_port smallest_nonpriv_port

rw rw rw rw rw rw rw rw rw

49152 32768 1024 2049,4045 65535 57344 57344 32768 1024

----------

weak

strong, src-priority, weak weak strong, src-priority, weak 8192 4096-65536 8192 4096-65536 passive never,passive, active 2049,4045 1-65535 65535 1024-65535 128000 2048-1073741824 active never,passive, active 49152 4096-1073741824 32768 1024-65535 1024 1024-32768 2049,4045 1-65535 65535 1024-65535 57344 128-1073741824 57344 1024-1073741824 32768 1024-65535 1024 1024-32768

Najczúħciej búdziesz zaczynaè od znalezienia Solaris Tunable Parameters Reference Manual (patrz odwođanie [9] na koēcu rozdziađu) w wydaniu odpowiednim dla uľywanej przez Ciebie wersji systemu Solaris. Ksiæľka ta zawiera informacje o kluczowych parametrach, które moľna modyfikowaè. Przedstawione informacje to miúdzy innymi: typ parametru, informacja o tym, kiedy naleľy go ustawiaè, wartoħè domyħlna oraz prawidđowy zakres wartoħci. Przykđady parametrów znajdziesz w dalszej czúħci rozdziađu. Parametry oparte na poleceniu ndd moľna mapowaè na ipadm, gdy stanæ siú dostúpne. Ponadto, zanim przystæpisz do modyfikacji czegokolwiek, w pierwszej kolejnoħci sprawdļ, czy na dostrajanie parametrów pozwala polityka firmy lub producenta.

Bufory Poniľej pokazano, jak moľna ustawiè wielkoħè róľnych buforów: ndd ndd ndd ndd

-set -set -set -set

/dev/tcp /dev/tcp /dev/tcp /dev/tcp

tcp_max_buf 16777216 tcp_cwnd_max 8388608 tcp_xmit_hiwat 1048576 tcp_recv_hiwat 1048576

Parametr tcp_max_buf ustawia maksymalnæ wielkoħè bufora gniazda — moľna to zrobiè takľe za pomocæ setsockopt(). Z kolei tcp_cwnd_max to maksymalna wielkoħè okna przeciæľenia TCP. Zwiúkszenie wartoħci obu parametrów moľe poprawiè wydajnoħè przepustowoħci sieci.

600

Rozdział 10



Sieć

Parametry tcp_xmit_hiwat i tcp_recv_hiwat pozwalajæ ustawiè domyħlnæ wielkoħè okna wysyđania i otrzymywania TCP. Sæ one dostúpne w poleceniu ipadm jako send_maxbuf i recv_maxbuf.

TCP Backlog Modyfikacjú wielkoħci kolejek backlog moľna przeprowadziè nastúpujæco: ndd -set /dev/tcp tcp_conn_req_max_q0 4096 ndd -set /dev/tcp tcp_conn_req_max_q 1024

Parametr _q0 jest przeznaczony dla kolejki pođæczeē póđotwartych, natomiast _q — dla pođæczeē czekajæcych na akceptacjú. Oba wymienione parametry mogæ wymagaè zwiúkszenia wartoħci domyħlnych, na przykđad do 4096 i 1024 lub wiúcej, aby lepiej obsđuľyè duľe skoki obciæľenia.

Opcje TCP Jest wiele sposobów dostrojenia czústotliwoħci pođæczeē miúdzy tymi samymi komputerami i ponownego uľycia portów ephemeral, gdy sesje nadal znajdujæ siú w stanie TIME-WAIT: 





tcp_smallest_anon_port. Tú wartoħè moľna zmniejszyè do 10000 oraz zmniejszyè po stronie klienta, aby zwiúkszyè zakres uľycia portu ephemeral. Takie rozwiæzanie zwykle nieco pomaga. tcp_time_wait_interval. Tú wartoħè moľna zmniejszyè z domyħlnej 60000 (jednostkæ sæ milisekundy), aby sesje TIME-WAIT byđy znacznie szybciej poddawane recyklingowi. Jednak takie rozwiæzanie zostađo w dokumencie RFC okreħlone jako zabronione (patrz odwođanie [RFC 1122] na koēcu rozdziađu). tcp_iss_incr. Tú wartoħè moľna zmniejszyè, co pozwala jædru na wykrywanie nowych sesji i automatyczny recykling sesji TIME-WAIT. (Omawiana moľliwoħè zostađa wprowadzona w jædrze illumos).

Inne opcje TCP moľliwe do dostrojenia obejmujæ miúdzy innymi tcp_slow_start_ ´initial — bardzo czústo ma ustawianæ najwiúkszæ moľliwæ wartoħè, aby sesje TCP mogđy znacznie szybciej osiægaè wysokæ przepustowoħè.

Urządzenie sieciowe Ustawienie poniľszego parametru moľe poprawiè wydajnoħè dziúki rozđoľeniu obciæľenia sieciowego miúdzy wszystkie procesory: set ip:ip_squeue_fanout=1

10.8. Dostrajanie

601

Zachowanie domyħlne polega na powiæzaniu pođæczenia z procesorem, który obsđugiwađ jego utworzenie. Skutkiem moľe byè nierówny rozkđad pođæczeē w procesorach, tak ľe niektóre procesory mogæ zostaè wykorzystane w 100%, co prowadzi do powstania wæskiego gardđa.

Kontrola zasobów Polecenie dladm umoľliwia ustawienie róľnych wđaħciwoħci interfejsu sieciowego, miúdzy innymi maxbw okreħlajæcego maksymalnæ przepustowoħè. Wymieniona wđaħciwoħè moľe byè zastosowana wzglúdem interfejsów wirtualnych, co siú czústo zdarza w przypadku tenantów goħci w ħrodowiskach przetwarzania w chmurze. W takiej sytuacji omawiana wđaħciwoħè dziađa w charakterze mechanizmu kontroli zasobów. Polecenie flowadm (dodane w ramach projektu Crossbow) zapewnia jeszcze dokđadniejszæ kontrolú. Moľna je wykorzystaè do zdefiniowania przepđywu, który zostanie dopasowany do warstwy transportowej (TCP) i portów. Ponadto polecenie to zapewnia obsđugú wđaħciwoħci takich jak maxbw i priority. Priorytet moľe byè ustawiony jako low, normal, high lub rt (czas rzeczywisty). Takie rozwiæzanie moľna zastosowaè po to, aby preferowaè ruch sieciowy o wysokim priorytecie, na przykđad dla obciæľenia produkcyjnego, kosztem ruchu o niľszym priorytecie, na przykđad tworzenia kopii zapasowych lub monitorowania. System Solaris oferuje równieľ obsđugú IP QoS (IPQoS) w celu nadawania priorytetów pakietom sieciowym — odbywa siú to za pomocæ ipqosconf.

10.8.3. Konfiguracja Poza modyfikowalnymi parametrami mogæ byè dostúpne jeszcze wymienione poniľej opcje konfiguracyjne, pozwalajæce na dostrojenie wydajnoħci sieci: 





Ramki jumbo w Ethernecie. Zwiúkszenie wartoħci domyħlnej MTU z 1500 do okođo 9000 moľe poprawiè wydajnoħè przepustowoħci sieci, o ile jej architektura zapewnia obsđugú ramek jumbo. Agregacja đæcza. Istnieje moľliwoħè zgrupowania wielu interfejsów sieci, ľeby w ten sposób pođæczyè ich przepustowoħè. Aby takie rozwiæzanie dziađađo prawidđowo, wymagana jest jego obsđuga ze strony przeđæczenia sieciowego i wprowadzenie w nim odpowiedniej konfiguracji. Opcje gniazda. Wielkoħè bufora moľna dostroiè przez aplikacjú za pomocæ funkcji setsockopt(). Zwiúkszenie wielkoħci (aľ do omówionej wczeħniej wielkoħci maksymalnej narzucanej przez system) moľe poprawiè wydajnoħè przepustowoħci sieci.

Wymienione opcje konfiguracyjne sæ powszechnie stosowane w obu rodzajach systemów operacyjnych (Solaris i Linux).

602

Rozdział 10



Sieć

10.9. Ćwiczenia 1. Odpowiedz na pytania z zakresu terminologii: 

Jaka jest róľnica miúdzy przepustowoħciæ i transferem?



Co to jest opóļnienie pođæczenia?



Co to jest opóļnienie pierwszego bajta?



Co to jest czas podróľy pakietu w obie strony?

2. Odpowiedz na poniľsze pytania dotyczæce koncepcji: 

Jak moľesz opisaè poziom wykorzystania i nasycenie sieci?



Co to jest kolejka TCP Backlog oraz w jaki sposób jest uľywana?



Jakie sæ wady i zalety gromadzenia przerwaē?

3. Odpowiedz na nastúpujæce, dokđadniejsze pytania: 



Dlaczego w przypadku pođæczenia TCP bđæd ramki sieciowej (lub pakietu) moľe mieè negatywny wpđyw na wydajnoħè? Co siú dzieje, gdy interfejs sieciowy jest przeciæľony zadaniami? Jaki to búdzie miađo wpđyw na wydajnoħè aplikacji?

4. Zaimplementuj w uľywanym systemie operacyjnym wymienione procedury: 



Metoda USE w postaci listy rzeczy do zrobienia dotyczæcych zasobów sieci (interfejsów sieciowych i kontrolerów). Uwzglúdnij sposób pobrania poszczególnych metryk (podaj konkretne polecenia do wykonania) i wskaľ, jak moľna interpretowaè otrzymane wyniki. Przed instalacjæ lub uľyciem dodatkowego oprogramowania spróbuj wykorzystaè narzúdzia monitorowania oferowane przez wykorzystywany system operacyjny. Przygotuj charakterystykú obciæľenia w postaci listy rzeczy do zrobienia dotyczæcych zasobów sieciowych. Uwzglúdnij sposób pobrania poszczególnych metryk, spróbuj w pierwszej kolejnoħci wykorzystaè narzúdzia monitorowania oferowane przez uľywany system operacyjny.

5. Wykonaj wymienione poniľej zadania (mogæ wymagaè zastosowania monitorowania dynamicznego): 



Zmierz opóļnienie pierwszego bajta dla wychodzæcych (aktywnych) pođæczeē TCP. Zmierz opóļnienie pođæczenia TCP. Skrypt powinien obsđugiwaè nieblokujæce wywođania connect().

6. (Opcjonalne, zaawansowane) Zmierz opóļnienie na poziomie stosu TCP/IP dla RX i TX. W przypadku RX pomiar powinien obejmowaè czas od chwili przerwania do momentu odczytu danych z gniazda. Natomiast dla TX pomiar powinien obejmowaè czas od chwili zapisu danych przez gniazdo do momentu ich transferu przez urzædzenie. Opracowane rozwiæzanie przetestuj pod obciæľeniem. Czy mogæ zostaè dođæczone informacje dodatkowe w celu wyjaħnienia przyczyny powstawania elementów odstajæcych pod kætem opóļnienia?

10.10. Odwołania

603

10.10. Odwołania [Saltzer 84]

J. Saltzer, D. Reed, D. Clark, End-to-End Arguments in System Design, ACM TOCS, listopad 1984.

[Mathis 96]

M. Mathis, J. Mahdavi, Forward Acknowledgement: Refining TCP Congestion Control, ACM SIGCOMM, 1996.

[Downey 99]

A. Downey, Using pathchar to Estimate Internet Link Characteristics, ACM SIGCOMM, paļdziernik 1999.

[Hassan 03]

M. Hassan, R. Jain, High Performance TCP/IP Networking, Prentice Hall, 2003.

[Deri 04]

L. Deri, Improving Passive Packet Capture: Beyond Device Polling, Proceedings of SANE, 2004.

[McDougall 06a] R. McDougall, J. Mauro, Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture, Prentice Hall, 2006. [Gregg 11]

B. Gregg, J. Mauro, DTrace: Dynamic Tracing in Oracle Solaris, Mac OS X and FreeBSD, Prentice Hall, 2011.

[Nichols 12]

K. Nichols, V. Jacobson, Controlling Queue Delay, „Communications of the ACM”, lipiec 2012.

[Stevens 13]

W.R. Stevens, TCP/IP od ħrodka. Protokođy, wyd. 3, Helion, 2013.

[RFC 768]

User Datagram Protocol, 1980.

[RFC 793]

Transmission Control Protocol, 1981.

[RFC 896]

Congestion Control in IP/TCP Internetworks, 1984.

[RFC 1122]

Requirements for Internet Hosts — Communication Layers, 1989.

[RFC 1761]

Snoop Version 2 Packet Capture File Format, 1995.

[RFC 2474]

Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, 1998.

[1]

http://www.bufferbloat.net

[2]

https://web.archive.org/web/20110916015351/http:// hub.opensolaris.org/bin/view/Project+ip%2Drefactor/

[3]

https://blogs.oracle.com/timc/entry/nicstat_the_solaris_and_linux

[4]

ftp://ftp.ee.lbl.gov/pathchar

[5]

http://www.wireshark.org

[6]

https://github.com/brendangregg/dtrace-cloud-tools

[7]

http://www.dtracebook.com/

[8]

http://www.netperf.org/netperf/

[9]

http://docs.oracle.com/cd/E23824_01/html/821-1450/index.html

604

Rozdział 10



Sieć

11 Przetwarzanie w chmurze

Rozwój sektora przetwarzania w chmurze rozwiæzađ pewne problemy zwiæzane z wydajnoħciæ, ale jednoczeħnie spowodowađ inne. Tak zwana chmura najczúħciej jest zbudowana na bazie technologii wirtualizacji i pozwala wielu egzemplarzom systemu operacyjnego, czyli tenantom, na wspóđdzielenie jednego fizycznego serwera. To oznacza prawdopodobieēstwo wystæpienia rywalizacji o dostúp do zasobów. Wspomniana rywalizacja búdzie wystúpowađa nie tylko miúdzy procesami, jak ma to miejsce w systemie UNIX, ale równieľ miúdzy poszczególnymi systemami operacyjnymi. Izolacja wpđywu kaľdego tenanta na wydajnoħè ma znaczenie krytyczne, podobnie jak identyfikacja sytuacji, gdy kiepska wydajnoħè jest spowodowana przez inne tenanty. W tym rozdziale przeanalizujemy wydajnoħè ħrodowisk przetwarzania w chmurze. Rozdziađ moľna podzieliè na trzy czúħci: 





Wprowadzenie. Tutaj zostanie przedstawiona ogólna architektura przetwarzania w chmurze oraz zwiæzane z tym implikacje wydajnoħci. Wirtualizacja systemu operacyjnego. Mamy z niæ do czynienia, gdy pojedyncze jædro zarzædza komputerem, tworzæc egzemplarze oddzielnych wirtualnych systemów operacyjnych. W tej czúħci jako przykđad implementacji zostanie zademonstrowany system SmartOS. Wirtualizacja sprzútowa. Mamy z niæ do czynienia, gdy hipernadzorca zarzædza wieloma systemami operacyjnymi goħci, z których kaľdy ma uruchomione wđasne jædro wraz z wirtualnymi urzædzeniami. W tej czúħci jako przykđadowe implementacje zostanæ zademonstrowane rozwiæzania Xen i KVM.

605

606

Rozdział 11



Przetwarzanie w chmurze

Przykđadowe technologie búdæ przedstawione w rozdziale po to, aby na ich podstawie przeanalizowaè charakterystykú wydajnoħci róľnych rodzajów wirtualizacji. Peđnæ dokumentacjú sposobów ich uľycia, a takľe prezentacje innych technologii wirtualizacji znajdziesz w internecie. Ħrodowiska przetwarzania w chmurze, które nie uľywajæ wirtualizacji, mogæ byè potraktowane jako systemy rozproszone. Do ich analizy moľna wykorzystaè techniki omówione w poprzednich rozdziađach. Natomiast w przypadku systemów wirtualnych materiađ przedstawiony w tym rozdziale búdzie doskonađym uzupeđnieniem materiađu z poprzednich rozdziađów.

11.1. Wprowadzenie Technologia przetwarzania w chmurze umoľliwia dostarczanie zasobów komputera w postaci usđugi i zastosowanie skalowania od niewielkiej czúħci serwera do systemów opartych na wielu serwerach. Jest dostúpnych wiele róľnego rodzaju rozwiæzaē, w zaleľnoħci od wielkoħci zainstalowanego i skonfigurowanego stosu oprogramowania. W tym rozdziale koncentrujemy siú na podstawach: IaaS (ang. Infrastructure as a Service), czyli na infrastrukturze jako usđudze dostarczajæcej systemów operacyjnych w postaci egzemplarzy serwera. Przykđadami dostawców typu IaaS sæ: AWS (ang. Amazon Web Services), Rackspace i Joyent. Egzemplarze serwera to zwykle wirtualne systemy operacyjne, które mogæ byè tworzone i usuwane w ciægu dosđownie kilku minut (lub nawet poniľej minuty) oraz natychmiast umieszczane w ħrodowisku produkcyjnym. API chmury jest najczúħciej dostarczane, a wiúc cađy proces moľna zautomatyzowaè przez inny program. Podsumowujæc technologiú chmury — przetwarzanie w chmurze oznacza dynamiczny framework przeznaczony dla egzemplarzy serwerów. Wiele egzemplarzy serwerów jest uruchomionych jako goħcie fizycznego systemu gospodarza. Wspomniani goħcie sæ równieľ okreħlani mianem tenantów, natomiast pojúcie multitenancy jest uľywane w celu okreħlenia ich wpđywu na inne tenanty. Komputer gospodarza jest obsđugiwany przez operatorów firmy dostarczajæcej ħrodowiska chmury. Z kolei systemy goħci (tenanty) sæ obsđugiwane i zarzædzane przez klientów, którzy je kupili. Przetwarzanie w chmurze wiæľe siú z wieloma implikacjami dotyczæcymi wydajnoħci, takimi jak: wspóđczynnik cena/wydajnoħè, architektura, planowanie pojemnoħci, pamiúè masowa i multitenancy. Ich podsumowanie przedstawiono w kolejnych punktach.

11.1.1. Współczynnik cena/wydajność Jest wielu dostawców publicznej chmury, którzy sprzedajæ egzemplarze serwerów w chmurze. Klient najczúħciej pđaci za godziny oraz na podstawie iloħci pamiúè (DRAM) przydzielonej egzemplarzowi serwera. Egzemplarz z przydzielonymi 8 GB pamiúci RAM zwykle kosztuje osiem razy wiúcej niľ egzemplarz z przydzielonym 1 GB pamiúci. Inne zasoby, takie jak procesor, równieľ sæ skalowane i rozliczane zgodnie z wielkoħciæ pamiúci. Wynikiem moľe byè powstanie spójnego wspóđczynnika cena/wydajnoħè wraz z pewnymi rabatami majæcymi na celu zachúcenie klientów do uľycia wiúkszych systemów.

11.1. Wprowadzenie

607

Niektórzy dostawcy pobierajæ dodatkowe opđaty za wiúksze przydziađy zasobów procesora (tak zwany egzemplarz z duľymi zasobami procesora). Uľycie innych zasobów, na przykđad przepustowoħci sieci i pamiúci masowej, równieľ moľe byè rozliczane.

11.1.2. Skalowalna architektura Ħrodowiska przemysđowe tradycyjnie stosowađy skalowalnoħè pionowæ podczas obsđugi obciæľenia: tworzenie wiúkszych, pojedynczych systemów (mainframe’ów). Tego rodzaju podejħcie wiæľe siú z pewnymi ograniczeniami. Istnieje praktyczny limit okreħlajæcy fizycznæ wielkoħè komputera, który moľna zbudowaè (ograniczenie moľe wynikaè z szerokoħci drzwi windy lub wielkoħci kontenera uľywanego do przewoľenia sprzútu). Ponadto wraz ze wzrostem liczby procesorów zwiúkszajæ siú takľe trudnoħci zwiæzane z zachowaniem koherencji pamiúci podrúcznych procesorów. Rozwiæzaniem dla wspomnianych ograniczeē jest rozđoľenie obciæľenia miúdzy wiele (prawdopodobnie mniejszych) systemów — nosi to nazwú skalowalnoħci poziomej. W ħrodowisku przemysđowym uľywane sæ zespođy komputerów i klastry, zwđaszcza w przypadku, gdy trzeba zapewniè wysoko wydajne obliczenia (ang. High Performance Computing, HPC). Przetwarzanie w chmurze równieľ jest oparte na skalowalnoħci poziomej. Na rysunku 11.1 pokazano przykđadowe ħrodowisko obejmujæce równowaľenie obciæľenia, serwery WWW, serwery aplikacji i bazy danych.

Rysunek 11.1. Architektura chmury: skalowanie poziome

Kaľda warstwa ħrodowiska skđada siú z jednego egzemplarza lub wiúkszej liczby egzemplarzy serwerów dziađajæcych jednoczeħnie, dodanych w celu obsđuľenia danego obciæľenia. Egzemplarze mogæ byè dodawane pojedynczo lub teľ architektura moľe byè podzielona na pionowe partycje, w których grupa skđada siú z serwerów bazy danych, serwerów aplikacji i serwerów WWW dodawanych jako jedna jednostka. Warstwæ sprawiajæcæ najwiúcej trudnoħci podczas jednoczesnego dziađania jest warstwa bazy danych. Wynika to z tradycyjnego modelu bazy danych, w którym jeden

608

Rozdział 11



Przetwarzanie w chmurze

egzemplarz bazy musi byè podstawowy. Dane w tego rodzaju bazach danych, na przykđad MySQL, mogæ byè dzielone logicznie na grupy nazywane shards, z których kaľda jest zarzædzana przez wđasnæ bazú danych (para podstawowa/drugorzúdna). Nowsze architektury baz danych, takie jak Riak, dynamicznie potrafiæ obsđugiwaè jednoczesne dziađanie i obciæľenie, które sæ rozkđadane na wszystkie dostúpne egzemplarze. Egzemplarz serwera zwykle ma niewielkæ iloħè pamiúci, powiedzmy 1 GB (fizyczny komputer jest wyposaľony w 128 GB pamiúci RAM lub nawet wiúcej), i drobiazgowe skalowanie moľna zastosowaè w celu osiægniúcia optymalnego wspóđczynnika cena/ wydajnoħè. Dziúki temu nie trzeba inwestowaè w ogromne systemy, które przez wiúkszoħè czasu pozostajæ bezczynne.

11.1.3. Planowanie pojemności W ħrodowiskach przemysđowych serwery mogæ wiæzaè siú ze znacznym kosztem infrastruktury, gdy weļmie siú pod uwagú zarówno koszt zakup samego sprzútu, jak i usđug jego serwisowania przez kilka lat. Umieszczenie serwerów w ħrodowisku produkcyjnym moľe zajæè nawet miesiæce: czas potrzebny na zatwierdzenie ich zakupu, oczekiwanie na dostúpnoħè sprzútu, dostarczanie sprzútu, jego montaľ, instalacja i niezbúdne testy. Planowanie pojemnoħci ma tutaj znaczenie krytyczne, aby zakupione systemy miađy odpowiedniæ pojemnoħè: zbyt mađa oznacza poraľkú, zbyt duľa — niepotrzebny koszt (w przypadku umów dotyczæcych ħwiadczenia usđug serwisowych koszt moľe dotyczyè kilku kolejnych lat). Planowanie pojemnoħci moľe równieľ pomóc w przewidywaniu jej wzrostu w przyszđoħci, tak aby dđugie procedury zakupu zostađy zainicjowane odpowiednio wczeħnie. Przetwarzanie w chmurze jest zupeđnie inne. Egzemplarze serwerów sæ niedrogie, mogæ byè tworzone i usuwane praktycznie natychmiast. Zamiast poħwiúcaè czas na planowanie pojemnoħci, firma moľe zwiúkszyè liczbú egzemplarzy serwerów, kiedy búdzie taka potrzeba, i tym samym dynamicznie reagowaè na bieľæce obciæľenie. Moľna to robiè takľe automatycznie za pomocæ API chmury, korzystajæc z metryk dostarczanych przez oprogramowanie przeznaczone do monitorowania wydajnoħci. Mađe firmy lub dopiero rozpoczynajæce dziađalnoħè mogæ „rozrosnæè siú” od pojedynczego, niewielkiego egzemplarza serwera aľ do tysiúcy egzemplarzy, bez koniecznoħci przeprowadzania dokđadnego planowania pojemnoħci, jak ma to miejsce w typowych ħrodowiskach biznesowych. W przypadku nowych firm innym czynnikiem, który warto wziæè pod uwagú, sæ zmiany w kodzie. Kod produkcyjny witryn internetowych jest czústo uaktualniany co tydzieē, a nawet kaľdego dnia. Analiza planowania pojemnoħci trwa tygodniami. Poniewaľ jest oparta na migawce metryk wydajnoħci, w chwili ukoēczenia moľe byè juľ nieaktualna. To róľnica w stosunku do ħrodowisk przemysđowych dziađajæcych na bazie oprogramowania komercyjnego, które moľe byè modyfikowane nie czúħciej niľ kilka razy w roku. Dziađania podejmowane podczas planowania pojemnoħci w chmurze obejmujæ: 

dynamicznæ zmianú wielkoħci — automatyczne dodawanie i usuwanie egzemplarzy serwerów,

11.1. Wprowadzenie



609

testowanie skalowalnoħci — zakup wiúkszego ħrodowiska w chmurze na krótki okres w celu przetestowania skalowalnoħci kontra syntetycznemu obciæľeniu (to jest przeprowadzanie testów wydajnoħci).

Przy uwzglúdnieniu ograniczeē czasowych istnieje równieľ moľliwoħè modelowania skalowalnoħci (podobnie do analizy przeprowadzanej w przedsiúbiorstwach) w celu oszacowania, jak przedstawia siú rzeczywista skalowalnoħè.

Dynamiczna zmiana wielkości Automatyczne dodawanie egzemplarzy serwerów moľe rozwiæzaè problem szybkiej reakcji na obciæľenie, choè wiæľe siú jednoczeħnie z ryzykiem wystæpienia nadmiarowoħci (ang. overprovisioning), jak pokazano na rysunku 11.2. Na przykđad atak typu DoS moľe spowodowaè zwiúkszenie obciæľenia prowadzæce do kosztownego zwiúkszenia liczby serwerów. Podobne ryzyko jest wtedy, gdy zmiana wprowadzona w aplikacji spowoduje spadek wydajnoħci, a tym samym koniecznoħè uľycia wiúkszej liczby serwerów do obsđugi tego samego obciæľenia. Monitorowanie jest bardzo waľne, poniewaľ pozwala sprawdziè, czy wspomniany wzrost liczby serwerów ma w ogóle sens.

Rysunek 11.2. Dynamiczna zmiana wielkości

Niektóre rozwiæzania w chmurze pozwalajæ takľe na zmniejszenie kosztu, gdy obciæľenie spadnie. Na przykđad w grudniu 2012 roku firma Pinterest ogđosiđa zmniejszenie kosztu z 54 USD za godzinú do 20 USD za godzinú dziúki automatycznemu wyđæczaniu systemu w chmurze po godzinach (patrz odwođanie [1] na koēcu rozdziađu). Podobne, natychmiastowe oszczúdnoħci mogæ byè wynikiem dostrojenia wydajnoħci, a tym samym zmniejszenia liczby egzemplarzy niezbúdnych do obsđugi mniejszego obciæľenia. Pewne rodzaje architektury w chmurze (patrz podrozdziađ 11.2 „Wirtualizacja systemu operacyjnego”) umoľliwiajæ natychmiastowæ dynamicznæ alokacjú wiúkszych zasobów procesora, o ile sæ dostúpne, za pomocæ strategii o nazwie bursting. To wcale nie musi siú wiæzaè z dodatkowymi kosztami i ma pomóc w unikniúciu nadmiarowoħci. Rozwiæzanie polega na dostarczeniu bufora w trakcie zwiúkszonego obciæľenia, aby przekonaè siú, czy dane obciæľenie jest rzeczywiste i búdzie siú utrzymywaè przez dđuľszy czas. Jeľeli tak, dođæczone zostanæ kolejne egzemplarze serwerów i tym samym dostarczone búdæ zasoby gwarantujæce kontynuacjú dziađania. Dowolna z wymienionych technik powinna byè znacznie efektywniejsza niľ ħrodowiska biznesowe, zwđaszcza te o stađej wielkoħci, wybrane do obsđugi oczekiwanego maksymalnego obciæľenia przez cađy cykl ľyciowy serwera. W takim przypadku serwery przez wiúkszoħè czasu pozostajæ bezczynne.

610

Rozdział 11



Przetwarzanie w chmurze

11.1.4. Pamięć masowa Egzemplarz serwera w chmurze zwykle posiada lokalnæ pamiúè masowæ obsđugiwanæ przez lokalne dyski, przeznaczonæ dla plików tymczasowych. Wspomniana pamiúè jest ulotna, a jej zawartoħè bezpowrotnie tracona po usuniúciu egzemplarza serwera. Jeľeli potrzebna jest trwađa pamiúè masowa, to zwykle uľywana jest niezaleľna usđuga, która zapewnia serwerowi pamiúè masowæ w postaci: 

magazynu plików — na przykđad pliki przez NFS,



magazynu bloków — na przykđad bloki przez iSCSI,



magazynu obiektów — najczúħciej przez API, zwykle oparte na HTTP.

To jest dođæczona przez sieè infrastruktura zarówno urzædzeē sieciowych, jak i pamiúci masowej, wspóđdzielonych przez tenanty. Z wymienionych powodów wydajnoħè búdzie znacznie mniej niezawodna niľ oferowana przez dyski lokalne. Obie konfiguracje zostađy pokazane na rysunku 11.3.

Rysunek 11.3. Pamięć masowa w chmurze

Wiúksze opóļnienie dostúpu sieciowej pamiúci masowej moľna zwykle zmniejszyè dziúki uľyciu umieszczonego w pamiúci bufora dla najczúħciej ľædanych danych. Niektóre urzædzenia pamiúci masowej pozwalajæ na zakup konkretnej wartoħci IOPS, gdy wymagane jest zapewnienie niezawodnej wydajnoħci (przykđadem moľe byè tutaj AWS EBS Provisioned IOPS volume).

11.1.5. Multitenancy UNIX to wielozadaniowy system operacyjny, zaprojektowany do pracy z wieloma uľytkownikami i procesami uzyskujæcymi dostúp do tych samych zasobów. Zmiany wprowadzone póļniej w systemach BSD, Solaris i Linux zapewniđy pewne mechanizmy kontroli zasobów i moľliwoħè ich wspóđdzielenia w sposób nieco bardziej sprawiedliwy. Ponadto dostarczone zostađy narzúdzia umoľliwiajæce monitorowanie i wykrywanie sytuacji, gdy wystúpujæ problemy z wydajnoħciæ zwiæzane z rywalizacjæ o dostúp do zasobów. Przetwarzanie w chmurze jest inne, poniewaľ wszystkie egzemplarze systemu operacyjnego wspóđistniejæ w tym samym fizycznym komputerze. Kaľdy goħè jest samodzielnym, odizolowanym systemem operacyjnym: goħcie nie majæ dostúpu do uľytkowników i procesów naleľæcych do innych goħci dziađajæcych w tym samym komputerze — to byđby wyciek informacji — nawet pomimo wspóđdzielenia zasobów fizycznych.

11.2. Wirtualizacja systemu operacyjnego

611

Poniewaľ zasoby sæ wspóđdzielone przez tenanty, problemy zwiæzane z wydajnoħciæ mogæ byè spowodowane przez tak zwanych hađaħliwych sæsiadów. Na przykđad inny goħè w tym samym komputerze moľe przeprowadzaè zapis peđnej bazy danych na dysku. Jeľeli w tym samym czasie Twój serwer znajduje siú pod maksymalnym obciæľeniem, nastæpi zakđócenie dyskowych i sieciowych operacji wejħcia-wyjħcia. Co gorsza, goħè moľe sprawdzaè dostawcú usđug przetwarzania w chmurze wskutek wykonywania mikrotestów wydajnoħci, co niewætpliwie doprowadzi do nasycenia zasobów w celu ustalenia ich wartoħci granicznych. Istniejæ pewne rozwiæzania przedstawionego problemu. Efekt multitenancy moľe byè kontrolowany przez zarzædzanie zasobami: zdefiniowanie w systemie operacyjnym mechanizmu kontroli zasobów zapewniajæcego izolacjú wydajnoħci (inna nazwa to izolacja zasobów). W takim przypadku priorytety lub ograniczenia dla poszczególnych tenantów sæ ustalane wzglúdem uľycia zasobów systemowych: procesora, pamiúci, operacji wejħcia-wyjħcia systemu plików lub dysku, a takľe przepustowoħci sieciowej. Nie wszystkie technologie chmury zapewniajæ peđnæ wymienionæ izolacjú zasobów, dotyczy to przede wszystkim ograniczeē w zakresie dyskowych operacji wejħcia-wyjħcia. Ograniczenie operacji wejħcia-wyjħcia w systemie plików ZFS zostađo opracowane dla publicznej chmury Joyent, aby tym samym rozwiæzaè problem hađaħliwych sæsiadów w zakresie uľycia dysków. Poza ograniczaniem uľycia zasobów moľliwoħè monitorowania rywalizacji tenantów moľe pomóc operatorom w dostrojeniu ograniczeē i lepszym zrównowaľeniu tenantów w dostúpnych komputerach. Stopieē, do którego moľna prowadziè monitorowanie, zaleľy od rodzaju wirtualizacji: systemu operacyjnego lub sprzútowej.

11.2. Wirtualizacja systemu operacyjnego Wirtualizacja systemu operacyjnego powoduje jego partycjonowanie na egzemplarze dziađajæce jak oddzielne serwery goħci, moľliwe do zdalnego administrowania i ponownego uruchamiania niezaleľnie od gospodarza. W ten sposób klienci chmury otrzymujæ egzemplarze serwerów charakteryzujæce siú wysokæ wydajnoħciæ, natomiast operatorzy chmury zyskujæ wysokæ gústoħè oferowanych serwerów. Wirtualizacja systemu operacyjnego zostađa pokazana na rysunku 11.4 — wykorzystano w niej terminologiú stref systemu Solaris. Na rysunku pokazano strefú globalnæ, odnoszæcæ siú do systemu operacyjnego gospodarza, który widzi wszystkie strefy goħci (nazywane takľe strefami nieglobalnymi). Tego rodzaju podejħcie ma swoje ļródđo w poleceniu chroot systemu UNIX — polecenie to izoluje procesy w poddrzewie globalnego systemu plików (czyli zmienia katalog gđówny /). W 1998 roku w dystrybucji FreeBSD poszerzono tú koncepcjú do postaci FreeBSD jails, zapewniajæc tym samym bezpieczny schowek dziađajæcy w charakterze oddzielnego serwera. W 2010 roku w systemie Solaris 10 znalazđa siú zmodyfikowana wersja wymienionego rozwiæzania. Nazwano jæ strefami Solarisa — dziađa ona na bazie róľnych mechanizmów kontroli zasobów. Dziúki systemowi OpenSolaris i póļniej SmartOS wspomniane strefy zostađy wykorzystane do przygotowania publicznej chmury Joyent. Ostatnio projekty wirtualizacji systemu operacyjnego powstađy dla systemu

612

Rozdział 11



Przetwarzanie w chmurze

Rysunek 11.4. Wirtualizacja systemu operacyjnego

Linux; sæ to miúdzy innymi: lxc Linux Containers (patrz odwođanie [2] na koēcu rozdziađu) i Open Virtuozzo (OpenVZ) — patrz odwođanie [3] na koēcu rozdziađu. Rozwiæzanie OpenVZ jest obsđugiwane przez Parallels, Inc. i wymaga zmodyfikowanej wersji jædra systemu Linux (patrz odwođanie [4] na koēcu rozdziađu). Podstawowa róľnica w stosunku do technologii wirtualizacji sprzútowej polega na tym, ľe w przypadku wirtualizacji systemu operacyjnego uruchomione jest tylko jedno jædro. Oznacza to nastúpujæce korzyħci: 









Istnieje niewielki negatywny wpđyw lub nie ma ľadnego takiego wpđywu na wydajnoħè operacji wejħcia-wyjħcia generowanych przez aplikacje goħcia, poniewaľ mogæ one wykonywaè wywođania systemowe bezpoħrednio do jædra gospodarza. Pamiúè zaalokowana dla goħcia moľe byè w cađoħci wykorzystana na potrzeby jego aplikacji. Nie trzeba jej uľywaè dla jædra, zarówno systemu operacyjnego hipernadzorcy, jak i goħcia. Dostúpny jest ujednolicony bufor systemu plików. Nie ma podwójnego buforowania, czyli buforowania w systemach gospodarza i goħcia. Wszystkie procesy uruchamiane przez goħcia sæ moľliwe do monitorowania z poziomu gospodarza, co pozwala na wykrywanie powodowanych przez nie problemów z wydajnoħciæ (miúdzy innymi rywalizacjæ o zasoby). Procesor jest prawdziwym procesorem, czyli istnieje moľliwoħè stosowania adaptacyjnych blokad muteksu.

Tego rodzaju rozwiæzanie ma równieľ pewne wady: 

Ewentualna awaria jædra dotyczy wszystkich goħci.



Goħè nie moľe uruchamiaè innej wersji jædra.

Aby móc uruchamiaè inne wersje jædra lub systemu operacyjnego, konieczne jest zastosowanie wirtualizacji sprzútowej, która búdzie tematem podrozdziađu 11.3. Wirtualizacja systemu operacyjnego moľe to zapewniè jedynie do pewnego stopnia dziúki uľyciu

11.2. Wirtualizacja systemu operacyjnego

613

alternatywnych interfejsów wywođaē systemowych. Przykđadem moľe byè lx Branded Zones w systemie Solaris — to rozwiæzanie dostarczađo systemowi Solaris interfejsu dla wywođaē systemowych Linuksa i odpowiedniego ħrodowiska aplikacji. W kolejnych punktach zostanæ przedstawione cechy charakterystyczne wirtualizacji systemu operacyjnego, czyli obciæľenie, kontrola zasobów i monitorowanie. Treħè zostađa przygotowana na podstawie publicznej chmury búdæcej w uľyciu od kilku lat (i prawdopodobnie búdæcej najwiúkszæ chmuræ oferujæcæ wirtualizacjú systemu operacyjnego): Joyent SmartOS, czyli implementacji stref Solarisa. Ogólnie rzecz bioræc, przedstawione tutaj informacje powinny byè odpowiednie dla wszystkich implementacji wirtualizacji systemu operacyjnego. Wiúkszoħè róľnic búdzie dotyczyđa sposobu konfiguracji mechanizmu kontroli zasobów. Na przykđad lxc Linux Containers mogæ uľywaè cgroups, co zostanie równieľ tutaj omówione.

11.2.1. Obciążenie Umiejútnoħè okreħlenia, kiedy obciæľenie zwiæzane z wirtualizacjæ búdzie miađo wpđyw na wydajnoħè, jest bardzo waľna z punktu widzenia analizy problemów wydajnoħci chmury. Wspomniane obciæľenie moľna podsumowaè, omawiajæc obciæľenie zwiæzane z dziađaniem procesora, wykonywanie operacji wejħcia-wyjħcia oraz efekt wpđywu innych tenantów.

Procesor Obciæľenie zwiæzane z dziađaniem procesora, gdy wætek znajduje siú w trybie uľytkownika, wynosi 0. Nie jest wymagana emulacja lub symulacja synchronizacji — wætki dziađajæ bezpoħrednio w procesorze aľ do chwili, gdy skoēczy siú przydzielony im czas lub zostanæ wywđaszczone. Wprawdzie nie zdarza siú to czústo — a tym samym nie ma duľego wpđywu na wydajnoħè — ale dziađania takie jak nasđuchiwanie stanu systemu z poziomu jædra mogæ spowodowaè pewne dodatkowe obciæľenie procesora, poniewaľ filtrowane sæ dane statystyczne dotyczæce innych tenantów. Obejmuje to odczyt interfejsu /proc przez polecenia monitorujæce stan (takie jak prstat i top), które analizujæ wszystkie wpisy đæcznie z dotyczæcymi innych tenantów, choè zwracajæ filtrowanæ listú. Oto odpowiedzialny za takie dziađanie fragment kodu pochodzæcy z funkcji readdir_procdir(): /* * Wykonywanie pĊtli aĪ do speánienia Īądania uĪytkownika * lub do chwili przeanalizowania wszystkich procesów. */ while ((error = gfs_readdir_pred(&gstate, uiop, &n)) == 0) { uint_t pid; int pslot; proc_t *p; /* * Wyszukanie nastĊpnego elementu. PominiĊcie procesów niewidocznych * w miejscu, w którym zamontowano /proc. */

614

Rozdział 11



Przetwarzanie w chmurze

mutex_enter(?dlock); while (n < v.v_proc && ((p = pid_entry(n)) == NULL || p->p_stat == SIDL || (zoneid != GLOBAL_ZONEID && p->p_zone->zone_id != zoneid) || secpolicy_basic_procinfo(CRED(), p, curproc) != 0)) n++;

Pomiar przeprowadzony w bieľæcych systemach wskazađ koszt w postaci dodatkowych 40 μs dla kaľdego dodatkowego 1000 wpisów procesów. W przypadku rzadkiej aktywnoħci wspomniany koszt jest nieistotny. (Jeľeli koszt jest wiúkszy, moľe to oznaczaè, ľe kod jædra siú zmieniđ).

Operacja wejścia-wyjścia Obciæľenie zwiæzane z operacjami wejħcia-wyjħcia wynosi 0, o ile nie zostađy skonfigurowane funkcje dodatkowe. Aby podstawowa postaè wirtualizacji dziađađa, nie ma koniecznoħci uľycia dodatkowej warstwy w stosie oprogramowania. Rozwiæzanie pokazano na rysunku 11.5, na którym porównano ħcieľki operacji wejħcia-wyjħcia procesów systemu UNIX ze strefami.

Rysunek 11.5. Ścieżki operacji wejścia-wyjścia procesów systemu UNIX i stref

Poniľej przedstawiono dwa stosy jædra (uzyskane za pomocæ narzúdzia DTrace) podczas transmisji pakietów sieciowych z komputera gospodarza (fizycznego) do goħcia: Host: mac`mac_tx+0xda dld`str_mdata_fastpath_put+0x53 ip`ip_xmit+0x82d ip`ire_send_wire_v4+0x3e9 ip`conn_ip_output+0x190 ip`tcp_send_data+0x59 ip`tcp_output+0x58c

Guest: mac`mac_tx+0xda dld`str_mdata_fastpath_put+0x53 ip`ip_xmit+0x82d ip`ire_send_wire_v4+0x3e9 ip`conn_ip_output+0x190 ip`tcp_send_data+0x59 ip`tcp_output+0x58c

11.2. Wirtualizacja systemu operacyjnego

ip`squeue_enter+0x426 ip`tcp_sendmsg+0x14f sockfs`so_sendmsg+0x26b sockfs`socket_sendmsg+0x48 sockfs`socket_vop_write+0x6c genunix`fop_write+0x8b genunix`write+0x250 genunix`write32+0x1e unix`_sys_sysenter_post_swapgs+0x14

615

ip`squeue_enter+0x426 ip`tcp_sendmsg+0x14f sockfs`so_sendmsg+0x26b sockfs`socket_sendmsg+0x48 sockfs`socket_vop_write+0x6c genunix`fop_write+0x8b genunix`write+0x250 genunix`write32+0x1e unix`_sys_sysenter_post_swapgs+0x14

Jak moľesz siú przekonaè, obydwa stosy jædra sæ identyczne. Dodatkowa warstwa najczúħciej pojawia siú w postaci kolejnych ramek na stosie. W przypadku dostúpu do systemu plików strefa moľe byè skonfigurowana do zamontowania jako system plików loopback, który z kolei jest montowany w systemie plików gospodarza. Tego rodzaju strategia jest stosowana w modelu stref sparse-root: sposób wspóđdzielenia miúdzy strefami jedynie plików tylko do odczytu (na przykđad /usr/bin). Jeľeli uľywany jest system plików loopback, operacje wejħcia-wyjħcia systemu plików charakteryzujæ siú niewielkim obciæľeniem procesora.

Inne tenanty Obecnoħè innych dziađajæcych tenantów prawdopodobnie búdzie miađa wpđyw na wydajnoħè, niezaleľnie od stosowanej technologii wirtualizacji: 





Pamiúci podrúczne procesora mogæ mieè mniejszy wspóđczynnik trafnoħci, poniewaľ inne tenanty búdæ korzystađy z pamiúci podrúcznej i usuwađy znajdujæce siú w niej elementy. Czas wykonywania kodu w procesorze moľe byè przerywany na krótki okres przez urzædzenia innych tenantów (na przykđad sieciowe operacje wejħcia-wyjħcia) przeprowadzajæce procedury obsđugi przerwaē. Moľe wystæpiè stan rywalizacji o zasoby systemowe (takie jak dyski, interfejsy sieciowe) miúdzy uľywajæcymi je tenantami.

Ostatni czynnik jest zarzædzany przez mechanizm kontroli zasobów. Wprawdzie niektóre z przedstawionych czynników wystúpujæ w tradycyjnych ħrodowiskach wielodostúpnych, ale sæ rozpowszechnione w ħrodowiskach przetwarzania w chmurze.

11.2.2. Kontrola zasobów Infrastruktura wirtualizacji systemu operacyjnego zajmuje siú zapewnieniem bezpieczeēstwa miúdzy sæsiadami, natomiast mechanizm kontroli zasobów zarzædza wydajnoħciæ. W tabeli 11.1 wymieniono zakresy kontroli zasobów; jako przykđady wykorzystano opartæ na strefach SmartOS konfiguracjú publicznej chmury Joyent. Obszary zostađy podzielone na dwie kategorie: priorytet i limit, które sæ ustawiane dla poszczególnych goħci przez oprogramowanie lub operatora chmury.

616

Rozdział 11

Przetwarzanie w chmurze



Tabela 11.1. Przykłady kontroli zasobów w wirtualizacji systemu operacyjnego Zasób

Priorytet

Limit

Procesor

FFS

ograniczenia

Pojemność pamięci

rcapd/zoneadmd

limit VM

Operacje wejścia-wyjścia systemu plików

ograniczanie operacji wejścia-wyjścia systemu plików ZFS

-

Pojemność systemu plików

-

limity ZFS, limity systemu plików

Dyskowe operacje wejścia-wyjścia

patrz operacje wejścia-wyjścia systemu plików

-

Sieciowe operacje wejścia-wyjścia

priorytet przepływu

limity przepustowości

Limit to wartoħè graniczna uľycia danego zasobu. Z kolei priorytety sterujæ konsumpcjæ zasobów i sđuľæ do zrównowaľenia obciæľenia miúdzy sæsiadami na podstawie wartoħci okreħlajæcej wagú. Naleľy uľywaè priorytetu lub limitu dla danego zasobu — dla niektórych zasobów oznacza to uľycie i jednego, i drugiego.

Procesor Poniewaľ w wirtualizacji systemu operacyjnego goħè moľe bezpoħrednio „widzieè” wszystkie fizyczne procesory w komputerze, czasami ma moľliwoħè wykorzystania ich w 100%. W komputerze, który przez wiúkszoħè czasu pozostaje bezczynny, pozwala to goħciowi wykorzystaè zasoby procesora, przede wszystkim w krótkich okresach wzmoľonego obciæľenia. Tú moľliwoħè Joyent okreħla mianem bursting — pomaga klientom chmury w obsđuľeniu krótkotrwađego, wiúkszego obciæľenia bez koniecznoħci ponoszenia dodatkowych kosztów zwiæzanych z nadmiarowoħciæ.

Limity zasobów procesora Wyraľone w kategoriach wartoħci procentowej cađkowite zasoby procesora mogæ nađoľyè ograniczenie na poziom uľycia procesora przez goħcia, uniemoľliwiajæc bursting. Niektórzy klienci preferujæ takie rozwiæzanie, poniewaľ zapewnia stađæ oczekiwanæ wydajnoħè, co z kolei uđatwia planowanie pojemnoħci. W przypadku innych klientów stosowane jest domyħlne ustawienie Joyent, czyli automatyczne zwiúkszenie zasobów procesora do wartoħci wielokrotnie wyľszej (na przykđad oħmiokrotnie) niľ oczekiwana przez klienta. W ten sposób istnieje moľliwoħè uľycia wiúkszej iloħci zasobów procesora, o ile sæ dostúpne. Jeľeli bursting utrzymuje siú przez godziny lub dni (co moľna ustaliè dziúki monitorowaniu), klient moľe zostaè zachúcony do uaktualnienia wielkoħci systemu goħcia, aby konsumowane przez niego zasoby procesora byđy alokowane niezawodnie, zamiast polegaè na burstingu. To moľe spowodowaè problem wtedy, gdy klient jest nieħwiadomy tworzenia burstingu, a stan ten utrzymuje siú tygodniami. W pewnym momencie moľe siú pojawiè inny tenant intensywnie korzystajæcy z zasobów procesora i skonsumuje jego wolne zasoby, pozostawiajæc znacznie mniej dla pierwszego tenanta. W takim przypadku pierwszy tenant doħwiadczy spadku wydajnoħci, a jego wđaħciciel na pewno nie búdzie z tego

11.2. Wirtualizacja systemu operacyjnego

617

zadowolony. Taka sytuacja przypomina podróľowanie klasæ ekonomicznæ w samolocie, gdy przez cađy miesiæc pasaľer ma szczúħcie i cađy rzæd foteli pozostaje wolny. Nastúpnie, po miesiæcu, zdarza siú lot, w którym wszystkie miejsca sæ zajúte. Oczekiwania moľna utrzymaè w ryzach przez wyđæczenie burstingu, jak opisano wczeħniej. Przypomina to pođoľenie worka ziemniaków na wolnych miejscach w samolocie, aby ľaden pasaľer nie przyzwyczaiđ siú do nadmiaru wolnego miejsca. Twoi klienci mogæ preferowaè zarzædzanie oczekiwaniami na skutek poinformowania ich o korzystaniu z burstingu zamiast cađkowitego wyđæczenia tej moľliwoħci.

Współdzielenie procesora Wspóđdzielenie moľe byè przeprowadzone za pomocæ cađkiem sprawiedliwego szeregowania (ang. Fair-Share Scheduler, FSS) w celu odpowiedniego podziađu zasobów procesora miúdzy goħci. Udziađy mogæ byè alokowane dowolnie i uľywane do obliczenia iloħci zasobów procesora wykorzystywanych przez zajútego goħcia w danym czasie. Do obliczeē korzystamy ze wzoru: czas procesora zabrany przez goĂcia = wszystkie procesory·udziaïy goĂci/caïkowita ´liczba zajÚtych udziaïów w systemie

Rozwaľmy system ze 100 udziađami zaalokowanymi dla kilku goħci. W danym momencie tylko goħcie A i B ľædajæ zasobów procesora. Goħè A ma 10 udziađów, natomiast B — 30 udziađów. Dlatego teľ goħè A moľe uľyè 25% cađkowitych zasobów procesora w systemie: wszystkie procesoryŧ10/(10+30). W przypadku firmy Joyent kaľdy goħè ma pewnæ liczbú udziađów równæ wielkoħci jego pamiúci wyraľonej w megabajtach (a tym samym zaleľnæ od zapđaconej kwoty). System o dwukrotnie wiúkszej liczbie przydzielonych zasobów kosztuje dwukrotnie wiúcej, a jednoczeħnie oferuje dwukrotnie wiúcej udziađów procesora. W ten sposób wszystkie zasoby procesora sæ sprawiedliwie dzielone przez uľytkowników potrzebujæcych ich i pđacæcych za nie. Limity przydzielonych zasobów procesora sæ stosowane takľe do nađoľenia ograniczeē na bursting, aby oczekiwania uľytkownika nie wymknúđy siú spod kontroli.

Pojemność pamięci Istniejæ dwa rodzaje zasobów pamiúci, kaľdy z wđasnæ strategiæ w zakresie kontroli zasobów: pamiúè operacyjna (RSS) i pamiúè wirtualna (VM). Dostúpne sæ równieľ tak zwane funkcje kontroli zasobów, opisane na stronie podrúcznika man poħwiúconej resource_controls (patrz odwođanie [5] na koēcu rozdziađu). Oferujæ one zestaw modyfikowalnych parametrów dotyczæcych mechanizmu kontroli zasobów.

Pamięć operacyjna Ograniczenie pamiúci operacyjnej jest trudniejsze, niľ moľe siú wydawaè — wiæľe siú bowiem z nađoľeniem sztywnego limitu na oczekiwania. Kiedy system UNIX uľywa wiúkszej iloħci pamiúci, niľ jest rzeczywiħcie dostúpna, wtedy dochodzi do stronicowania (patrz rozdziađ 7., zatytuđowany „Pamiúè”).

618

Rozdział 11



Przetwarzanie w chmurze

Takie samo zachowanie zostađo replikowane dla goħcia w systemie SmartOS (przez wætek w demonie administracji zoneadmd tworzonym dla poszczególnych stref). Stronicowanie w systemie goħcia odbywa siú wczeħnie, na podstawie mechanizmu kontroli zasobów (zone.max-physical-memory). Ponadto zachowana jest docelowa wielkoħè pamiúci (odbywa siú to przez ograniczanie operacji page-in za pomocæ opóļnieē, aby umoľliwiè nadæľenie operacjom page-out). Wymieniona funkcja byđa wczeħniej przeprowadzana przez demona zasobów rcapd, który jednak byđ pojedynczym procesem dla wszystkich stref (i nie skalowađ siú po dodaniu wielu stref).

Pamięć wirtualna Wđaħciwoħè kontroli zasobów dla pamiúci wirtualnej to zone.max-swap, która jest sprawdzana synchronicznie podczas alokacji (malloc()). W przypadku usđug oferowanych przez Joyent pamiúè wirtualna jest dwukrotnie wiúksza niľ przydzielona pamiúè operacyjna. Po wykorzystaniu limitu kolejne operacje alokacji koēczæ siú niepowodzeniem (bđúdy „Out of memory”).

Operacje wejścia-wyjścia systemu plików Aby rozwiæzaè problem dyskowych operacji wejħcia-wyjħcia zwiæzany z hađaħliwymi sæsiadami, operacje wejħcia-wyjħcia sæ kontrolowane na poziomie systemu plików. Odbywa siú to za pomocæ funkcji ZFS o nazwie ograniczenia operacji wejħcia-wyjħcia, opracowanej przez Billa Pijewskiego z firmy Joyent. Powoduje ona alokacjú udziađów dla stref, podobnie jak w przypadku FFS dla procesora, i sprawiedliwsze równowaľenie zasobów wejħcia-wyjħcia miúdzy tenantami. Rozwiæzanie dziađa na skutek proporcjonalnego ograniczenia tenantów wykonujæcych najwiúcej dyskowych operacji wejħcia-wyjħcia, co ma na celu ograniczenie ich rywalizacji z innymi tenantami. Rzeczywisty mechanizm ograniczania polega na zastosowaniu opóļnieē w ukoēczeniu operacji wejħcia-wyjħcia, przed powrotem do przestrzeni uľytkownika. W tym czasie wætki sæ najczúħciej zablokowane w oczekiwaniu na zakoēczenie operacji wejħcia-wyjħcia, a zwiúkszenie opóļnienia jest odbierane jako nieco wolniejsze wykonywanie operacji wejħcia-wyjħcia.

Pojemność systemu plików Lokalne systemy plików majæ sztywny limit: jest nim cađkowita iloħè miejsca dostarczanego przez mapowane urzædzenia pamiúci masowej. Z reguđy dobrym rozwiæzaniem jest podzielenie tej pojemnoħci dla goħci w systemie gospodarza, co moľna zrobiè w nastúpujæcy sposób: 

utworzyè wirtualne woluminy o wskazanej wielkoħci,



uľyè systemów plików obsđugujæcych ograniczenia (na przykđad ZFS).

Sieciowe systemy plików i pamiúè masowa równieľ mogæ stosowaè pewne ograniczenia w zakresie pojemnoħci systemu plików, co w przypadku dostawców chmury zwykle jest zwiæzane z cenæ.

11.2. Wirtualizacja systemu operacyjnego

619

Dyskowe operacje wejścia-wyjścia Obecnie strefa SmartOS kontroluje dyskowe operacje wejħcia-wyjħcia przez dostúp do systemu plików. Zapoznaj siú z wczeħniejszym fragmentem dotyczæcym operacji wejħcia-wyjħcia systemu plików.

Sieciowe operacje wejścia-wyjścia Poniewaľ kaľda strefa jest skonfigurowana z wđasnym wirtualnym interfejsem sieciowym, przepustowoħè moľna ograniczyè za pomocæ wđaħciwoħci maxbw (maksymalna przepustowoħè) đæcza z poziomu polecenia dladm. Dokđadniejsza kontrola sieciowych operacji wejħcia-wyjħcia jest moľliwa za pomocæ polecenia flowadm, które pozwala na ustawianie wartoħci maxbw i priority, a takľe dopasowanie ruchu na podstawie rodzaju transportu i portu. Firma Joyent obecnie nie ogranicza sieciowych operacji wejħciawyjħcia (cađa infrastruktura opiera siú na standardzie 10 GbE, a wiúc z reguđy przepustowoħè nie stanowi problemu). Wymienione wartoħci sæ ustawiane rúcznie, jeħli którykolwiek klient naduľywa sieci.

11.2.3. Monitorowanie W przypadku wirtualizacji systemu operacyjnego zastosowana technologia domyħlnie pozwala kaľdemu uzyskaè wglæd do wszystkiego. Konieczne jest wprowadzenie ograniczeē, aby nieħwiadomie nie doprowadziè do niebezpieczeēstwa. Wspomniane ograniczenia to przynajmniej:  







Dla goħcia interfejs /proc wyħwietla jedynie procesy naleľæce do danego goħcia. Dla goħcia polecenie netstat wyħwietla jedynie informacje sesji dotyczæce sesji goħcia. Dla goħcia narzúdzia systemu plików wyħwietlajæ jedynie systemy plików naleľæce do goħcia. Dla goħcia inne strefy nie mogæ byè wyħwietlane za pomocæ narzúdzi administracyjnych sđuľæcych do obsđugi stref. Goħè nie ma moľliwoħci przeglædania wewnútrznych komponentów jædra (brak dostawcy fbt w narzúdziu DTrace i brak moľliwoħci wydania polecenia mdb -k).

Operator komputera gospodarza moľe widzieè wszystko: procesy, sesje TCP, a takľe systemy plików naleľæce zarówno do systemu gospodarza, jak i wszystkich goħci. Z poziomu gospodarza istnieje poza tym moľliwoħè bezpoħredniego monitorowania cađej aktywnoħci goħcia, bez koniecznoħci logowania siú do niego. W kolejnych fragmentach rozdziađu zostanæ przedstawione narzúdzia monitorowania dostúpne dla gospodarza oraz dla goħci. Omówione búdæ takľe strategie stosowane podczas analizy wydajnoħci. W tym rozdziale do prezentacji wspomnianego rodzaju informacji wykorzystamy system operacyjny SmartOS i jego narzúdzia monitorowania, ale odpowiednie narzúdzia powinny byè dostúpne równieľ w wirtualnym systemie operacyjnym.

620

Rozdział 11



Przetwarzanie w chmurze

Gospodarz Po zalogowaniu siú do systemu gospodarza wszystkie zasoby systemowe (procesor, pamiúè, system plików, dysk, sieè) moľna analizowaè za pomocæ narzúdzi omówionych w poprzednich rozdziađach. Wystúpujæ dwa dodatkowe czynniki, które naleľy wziæè pod uwagú podczas uľywania stref: 

dane statystyczne dla poszczególnych stref,



efekt stosowania kontroli zasobów.

Przeanalizowanie danych statystycznych dla strefy jest czasami moľliwe dziúki uľyciu opcji -Z, na przykđad: global# ps -efZ ZONE UID global root global root global root global root global root [...] 72188ca0 0000101 b8b2464c root 2e8ba1ab webservd 2e8ba1ab 0001003 2e8ba1ab root d305ee44 0000103 8bbc4000 root [...]

PID 0 4 1 2 3

PPID 0 0 0 0 0

16010 57428 13419 13879 13418 15101 10933

12735 57427 13418 12905 1 15041 1

C 0 0 0 0 0

STIME Oct 03 Oct 03 Oct 03 Oct 03 Oct 03

TTY ? ? ? ? ?

0 00:43:07 ? 0 Oct 21 ? 0 Oct 03 ? 0 Oct 03 ? 0 Oct 03 ? 0 Oct 03 ? 0 Oct 03 ?

TIME 0:01 0:16 0:07 0:00 952:42

CMD sched kcfpoold /sbin/init pageout fsflush

0:00 0:01 0:00 121:25 0:00 6:07 0:00

pickup -l -t fifo -u /usr/lib/saf/ttymon /opt/local/sbin/nginx ... /opt/local/bin/ruby19 ... /opt/local/sbin/nginx ... /opt/riak/lib/os_mon-2... /usr/sbin/rsyslogd -c5 -n

Pierwsza kolumna danych wyjħciowych pokazuje nazwú strefy (dane zostađy nieco skrócone, aby mieħciđy siú na stronie ksiæľki). Polecenie prstat równieľ obsđuguje opcjú -Z: global# prstat -Zc 1 PID USERNAME SIZE 22941 root 40M 22947 root 44M 15041 103 2263M [...] ZONEID NPROC SWAP 21 23 342M 6 21 2342M 16 2 1069M 15 2 1066M 19 2 1069M Total: 391 processes,

RSS 23M 25M 2089M

STATE wait wait sleep

PRI NICE TIME CPU PROCESS/NLWP 1 0 38:01:38 4.0% node/4 1 0 23:20:56 3.9% node/4 59 0 168:09:53 0.9% beam.smp/86

RSS MEMORY TIME CPU ZONE 194M 0.4% 0:28:48 7.9% b8b2464c-55ed-455e-abef-bd... 2109M 4.3% 180:29:09 0.9% d305ee44-ffaf-47ca-a558-89... 1057M 2.1% 107:03:45 0.3% 361f610e-605a-4fd3-afa4-94... 1054M 2.1% 104:16:33 0.3% 25bedede-e3fc-4476-96a6-c4... 1055M 2.1% 105:23:21 0.3% 9f68c2c8-75f8-4f51-8a6b-a8... 1755 lwps, load averages: 2.39, 2.31, 2.24

11.2. Wirtualizacja systemu operacyjnego

621

Górna czúħè danych wyjħciowych (skrócona) pokazuje standardowæ listú procesów — te zuľywajæce najwiúcej zasobów procesora zostađy wymienione na poczætku. Natomiast dolna czúħè danych wyjħciowych to podsumowanie poszczególnych stref. Kolumny majæ nastúpujæce znaczenie:  







SWAP — cađkowita wielkoħè pamiúci wirtualnej danej strefy, RSS — cađkowita iloħè pamiúci rezydentnej dla danej strefy (uľycie pamiúci operacyjnej), MEMORY — zuľycie pamiúci operacyjnej podane jako wartoħè procentowa zasobów na poziomie systemu, CPU — zuľycie procesora podane jako wartoħè procentowa zasobów na poziomie systemu, ZONE — nazwa strefy.

Analizowany komputer jest uľywany w ħrodowisku przetwarzania w chmurze (nosi nazwú wúzđa obliczeniowego) i zawiera dziesiætki dynamicznie tworzonych stref. Kaľda strefa posiada automatycznie wygenerowany identyfikator UUID, búdæcy jednoczeħnie nazwæ strefy (na przykđad b8b2464c…). Polecenie zonememstat umoľliwia wyħwietlenie informacji o zuľyciu pamiúci przez poszczególne strefy: global# zonememstat ZONE global 8bbc4000-5abd-4373-b599-b9fdc9155bbf d305ee44-ffaf-47ca-a558-890c0bbef508 361f610e-605a-4fd3-afa4-94869aeb55c0 476afc21-2751-4dcb-ae06-38d91a70b386 9f68c2c8-75f8-4f51-8a6b-a894725df5d8 9d219ce8-cf52-409f-a14a-b210850f3231 b8b2464c-55ed-455e-abef-bd1ea7c42020 [...]

RSS(MB) 156 242 2082 1057 1055 1056 1151 48

CAP(MB) 2048 2048 2048 2048 2048 2048 1024

NOVER 0 369976 0 0 0 0 0

POUT(MB) 0 9833581 0 0 0 0 0

Dane wyjħciowe zawierajæ miúdzy innymi nastúpujæce kolumny: 

CAP(MB) — skonfigurowany limit mechanizmu kontroli zasobów;



NOVER — liczba wskazujæca, ile razy strefa przekroczyđa przydzielony jej limit;



POUT(MB) — cađkowita liczba danych zapisanych w trakcie procesu page-out, aby strefa nie przekroczyđa przydzielonego jej limitu.

Zwiúkszajæca siú wartoħè w kolumnie POUT(MB) to zwykle sygnađ wskazujæcy na bđúdnæ konfiguracjú aplikacji goħcia, które próbujæ wykorzystaè wiúkszæ iloħè pamiúci, niľ jest dostúpna. Dochodzi wiúc do operacji page-out przeprowadzanej przez rcapd lub zoneadmd.

622

Rozdział 11



Przetwarzanie w chmurze

Informacje dotyczæce innych mechanizmów kontroli zasobów (procesora, ograniczenia operacji wejħcia-wyjħcia i sieci) moľna otrzymaè za pomocæ poleceē kstat i prctl. Jeľeli zachodzi potrzeba, dalszæ analizú moľna przeprowadziè z poziomu komputera gospodarza, sprawdzajæc miúdzy innymi stos wywođaē aplikacji oraz komponenty wewnútrzne goħcia. Administrator gospodarza moľe zidentyfikowaè przyczynú dowolnych problemów zwiæzanych z wydajnoħciæ i nie musi w tym celu logowaè siú do systemu goħcia.

Gość System goħcia powinien mieè dostúp jedynie do informacji szczegóđowych o jego procesach i aktywnoħci. Przeznaczone do tego celu narzúdzia monitorowania sæ okreħlane jako przygotowane do obsđugi stref. System plików /proc, uľywany przez polecenia ps i prstat, zawiera jedynie procesy dla danej strefy, a wiúc wymienione polecenia sæ przystosowane do obsđugi stref. Wspóđdzielone zasoby systemowe moľna monitorowaè z poziomu systemów goħci, o ile nie zostanæ przy tym ujawnione ľadne informacje prywatne. System goħcia na przykđad moľe bezpoħrednio monitorowaè wszystkie fizyczne procesory i dyski (za pomocæ poleceē mpstat i iostat), a takľe uľycie pamiúci na poziomie cađego systemu (polecenie vmstat). Poniľsze polecenie pokazuje, jak sprawdziè dyskowe operacje wejħcia-wyjħcia w bezczynnej strefie: zone# iostat -xnz 1 r/s 526.4 r/s 963.0 [...]

extended device statistics w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 3.0 65714.8 27.7 0.0 0.9 0.0 1.7 1 88 sd5 extended device statistics w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 1.0 75528.5 8.1 0.0 1.1 0.0 1.1 1 89 sd5

Otrzymane dane wyjħciowe mogæ zaskakiwaè uľytkowników, którzy dopiero zetknúli siú z wirtualizacjæ systemu operacyjnego — dlaczego dyski sæ zajúte? Polecenie iostat analizuje fizyczne dyski i uwzglúdnia aktywnoħè innych tenantów. Tego rodzaju polecenia sæ nazywane dziađajæcymi na poziomie cađego systemu (nie sæ przystosowane do obsđugi strefy). Aby sprawdziè uľycie dysków spowodowane jedynie przez okreħlonæ strefú, naleľy przeanalizowaè dane statystyczne na poziomie VFS: zone# vfsstat 1 r/s w/s kr/s 1.2 1.4 6.8 45.3 0.0 4.5 45.3 0.0 4.5 [...]

kw/s ractv wactv read_t writ_t 17.7 0.0 0.0 0.0 0.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

%r %w 0 0 0 0 0 0

d/s del_t zone 0.8 81.6 b8b2464c (21) 0.0 0.0 b8b2464c (21) 0.0 0.0 b8b2464c (21)

11.2. Wirtualizacja systemu operacyjnego

623

Uzyskujemy w ten sposób potwierdzenie, ľe strefa jest (prawie) bezczynna — odczyt danych na poziomie 4,5 KB/s (prawdopodobnie buforowany przez system plików i niepowodujæcy ľadnych dyskowych operacji wejħcia-wyjħcia). Polecenie mpstat równieľ dziađa na poziomie cađego systemu: zone# mpstat 1 CPU minf mjf xcal 0 1 0 0 1 0 0 4 2 0 0 1 3 1 0 1 4 1 0 0 [...]

intr ithr csw icsw migr smtx srw syscl usr sys wt idl 456 177 564 10 32 17777 0 99347 53 20 0 27 1025 437 4252 155 185 28337 0 62321 42 19 0 40 5169 2547 3457 34 74 7037 0 28110 14 8 0 78 400 161 798 102 127 47442 0 82525 63 23 0 14 308 138 712 23 52 31552 0 49330 38 15 0 48

Wyħwietlone dane wyjħciowe dotyczæ wszystkich fizycznych procesorów, a wiúc uwzglúdniajæ aktywnoħè powodowanæ przez inne tenanty. Podsumowanie generowane przez wywođanie prstat -Z to jedyny sposób na wyħwietlenie danych o uľyciu procesora tylko przez danego goħcia (inne systemy goħci nie búdæ wyħwietlone po wydaniu tego polecenia z poziomu strefy innej niľ globalna): zone# prstat -Zc 1 [...] ZONEID NPROC SWAP 21 22 147M

RSS MEMORY 72M 0.1%

TIME CPU ZONE 0:26:16 0.0% b8b2464c-55ed-455e-abef-bd...

Dostúpne sæ równieľ liczniki narzúdzia kstat, pokazujæce poziom uľycia procesora oraz nađoľone ograniczenia. Ostatecznie, wymienione narzúdzia monitorowania zasobów fizycznych pozwalajæ systemowi goħcia uzyskaè uľyteczne dane statystyczne, przydatne podczas analizy wydajnoħci. Dziúki wspomnianym danym moľna wyeliminowaè pewne rodzaje problemów, na przykđad hađaħliwych sæsiadów. To jest bardzo waľna róľnica w stosunku do wirtualizacji sprzútowej, która ukrywa zasoby fizyczne przed systemami goħci.

Strategia W poprzednich rozdziađach przedstawiono techniki analizy fizycznych zasobów systemowych. Omówiono wiele róľnych metodologii. Mogæ byè one stosowane przez operatorów komputerów gospodarzy, a do pewnego stopnia równieľ w systemach goħci. Trzeba jedynie pamiútaè o wspomnianych wczeħniej ograniczeniach. W przypadku goħci z reguđy moľna monitorowaè ogólne uľycie zasobów, przejħcie na bardziej szczegóđowy poziom (jædra) jest niemoľliwe. Oprócz zasobów fizycznych naleľy sprawdziè takľe ograniczenia chmury nakđadane przez mechanizmy kontroli zasobów, zarówno przez operatorów komputera gospodarza, jak i tenanty goħci. Poniewaľ ograniczenia te (jeħli sæ stosowane) pojawiæ siú znacznie wczeħniej niľ ograniczenia fizyczne, a tym samym búdæ miađy wpđyw na wydajnoħè, naleľy je sprawdziè w pierwszej kolejnoħci.

624

Rozdział 11



Przetwarzanie w chmurze

Wiele tradycyjnych narzúdzi przeznaczonych do monitorowania zostađo utworzonych przed opracowaniem mechanizmów kontroli zasobów (na przykđad top i prstat), a wiúc domyħlnie nie zawierajæ one informacji o kontroli zasobów. Uľytkownicy z kolei mogæ zapomnieè o sprawdzeniu tych danych za pomocæ innych narzúdzi. Oto niektóre komentarze i strategie w zakresie sprawdzania mechanizmów kontroli zasobów: 











Procesor. W przypadku ograniczenia bieľæce uľycie procesora moľna porównaè do przydzielonego limitu. Napotkanie ograniczenia powoduje, ľe wætki znajdujæce siú w stanie dziađania muszæ czekaè, co moľna zaobserwowaè jako opóļnienie szeregowania. Na poczætku moľe to wydawaè siú dziwne, poniewaľ fizyczny komputer posiada duľæ iloħè wolnych zasobów procesora. Pamiúè. W przypadku pamiúci operacyjnej naleľy sprawdziè jej aktualny poziom uľycia wzglúdem przydzielonego limitu. Po osiægniúciu limitu wystæpiæ operacje page-out przeprowadzane przez zoneadmd. To búdzie moľna zaobserwowaè w postaci anonimowego stronicowania, w którym wætek búdzie marnowađ czas na awarie danych. Na poczætku moľe to wydawaè siú dziwne, poniewaľ stronicowanie na poziomie systemu moľe nie wystúpowaè (wartoħè 0 w kolumnie sr danych wyjħciowych vmstat), a fizyczny komputer moľe mieè duľæ iloħè wolnej pamiúci. Operacje wejħcia-wyjħcia systemu plików. Wysoki wspóđczynnik operacji wejħcia-wyjħcia moľe byè ograniczony, co spowoduje niewielkie zwiúkszenie ħredniej wartoħci opóļnienia. To búdzie moľna zaobserwowaè za pomocæ narzúdzia vfsstat. Pojemnoħè systemu plików. Tú wartoħè moľna obserwowaè, podobnie jak w przypadku dowolnego systemu plików. Dostúpne sæ róľne polecenia, miúdzy innymi df. Dyskowe operacje wejħcia-wyjħcia. Zobacz operacje wejħcia-wyjħcia systemu plików. Sieciowe operacje wejħcia-wyjħcia. Sprawdļ bieľæcæ przepustowoħè sieci i porównaj jæ z ograniczeniem, o ile takie zostađo skonfigurowane. Osiægniúcie limitu powoduje zwiúkszenie opóļnienia sieciowych operacji wejħcia-wyjħcia, poniewaľ tenanty muszæ zostaè ograniczone do przydzielonych im limitów.

W przypadku stref systemu SmartOS opracowana zostađa metoda USE w postaci listy rzeczy do sprawdzenia. W pierwszej kolejnoħci naleľy przeanalizowaè mechanizm kontroli zasobów, a dopiero póļniej zasoby fizyczne (patrz odwođanie [6] na koēcu rozdziađu).

Oprogramowanie służące do monitorowania Warto w tym miejscu wspomnieè, ľe wiele narzúdzi monitorowania przeznaczonych dla samodzielnych systemów nie zostađo jeszcze przystosowanych do wirtualizacji systemu operacyjnego. Klienci próbujæ ich uľywaè w systemach goħci. Te narzúdzia oczywiħcie dziađajæ, ale dostarczajæ danych dotyczæcych fizycznych zasobów systemowych, poniewaľ

11.3. Wirtualizacja sprzętowa

625

opierajæ siú na tych samych licznikach, na podstawie których dziađajæ od zawsze. Bez obsđugi monitorowania zasobów ograniczanych przez chmurú wspomniane narzúdzia bđúdnie informujæ o wolnych zasobach systemu, gdy tak naprawdú system goħcia maksymalnie wykorzystuje przydzielone mu zasoby. Narzúdzia mogæ ponadto pokazywaè wysoki poziom uľycia zasobów, wynikajæcy na przykđad z dziađalnoħci innych tenantów.

11.3. Wirtualizacja sprzętowa Wirtualizacja sprzútowa powoduje utworzenie egzemplarzy maszyn wirtualnych, które mogæ uruchamiaè cađe systemy operacyjne wraz z jædrami. W tym miejscu wymieniono rodzaje wirtualizacji sprzútowej: 





Peđna wirtualizacja — translacja binarna. Oznacza peđny system wirtualny skđadajæcy siú z wirtualnych komponentów sprzútowych, w których moľe zostaè zainstalowany niezmodyfikowany system operacyjny. Pionierem tego rodzaju wirtualizacji jest firma VMware, która w 1998 roku przygotowađa rozwiæzanie dla platformy x86. Opiera siú ono na pođæczeniu bezpoħredniego dziađania procesora i translacji binarnej instrukcji, gdy zachodzi potrzeba (patrz odwođanie [7] na koēcu rozdziađu). Obciæľenie i wpđyw na wydajnoħè sæ najczúħciej akceptowane, zwđaszcza bioræc pod uwagú oszczúdnoħci, jakie daje konsolidacja serwerów. Peđna wirtualizacja — wspomagana sprzútowo. Oznacza peđny system wirtualny skđadajæcy siú z wirtualnych komponentów sprzútowych, w których moľe zostaè zainstalowany niezmodyfikowany system operacyjny. Takie rozwiæzanie uľywa procesora w celu efektywnego dziađania maszyn wirtualnych. W szczególnoħci dotyczy to rozszerzeē AMD-V i Intel VT-x, wprowadzonych w latach 2005 – 2006. Parawirtualizacja. Oznacza system wirtualny, który dla systemów operacyjnych goħcia zawiera interfejs pozwalajæcy na efektywne uľywanie zasobów gospodarza (za pomocæ hiperwywođaē), bez koniecznoħci stosowania peđnej wirtualizacji wszystkich komponentów. Na przykđad uzbrojenie zegara zwykle wymaga wielu instrukcji uprzywilejowanych, które muszæ byè emulowane przez hipernazdorcú. To moľna uproħciè, sprowadzajæc do postaci pojedynczego hiperwywođania dla parawirtualizowanego systemu goħcia. Parawirtualizacja moľe uľywaè parawirtualnego sterownika urzædzenia sieciowego w celu efektywniejszego przekazywania pakietów z systemu goħcia do fizycznych interfejsów sieciowych w komputerze gospodarza. Wprawdzie rozwiæzanie w postaci parawirtualizacji charakteryzuje siú lepszæ wydajnoħciæ, ale wymaga zapewnienia obsđugi ze strony systemu operacyjnego goħcia (system Windows nigdy nie dawađ takiej moľliwoħci).

Innym rodzajem wirtualizacji sprzútowej jest wirtualizacja hybrydowa, która opiera siú na wirtualizacji wspomaganej sprzútowo oraz na pewnych wywođaniach parawirtualizacji, gdy sæ znacznie efektywniejsze. Celem tego rodzaju rozwiæzania jest

626

Rozdział 11



Przetwarzanie w chmurze

zapewnienie najlepszej wydajnoħci. Najczústszymi celami dla parawirtualizacji sæ urzædzenia wirtualne, takie jak karty sieciowe i kontrolery pamiúci masowej. Maszyny wirtualne sæ tworzone i uruchamiane przez hipernadzorcú, który moľe byè zaimplementowany w oprogramowaniu, firmwarze lub sprzútowo. Systemy goħci obsđugiwane przez wirtualizacjú sprzútowæ pokazano na rysunku 11.6.

Rysunek 11.6. Wirtualizacja sprzętowa

Na rysunku pokazano dwa rodzaje hipernazdorców (patrz odwođanie [Goldberg 72] na koēcu rozdziađu): 



Typ 1. Dziađanie bezpoħrednio w procesorach, a nie jako oprogramowanie na poziomie jædra lub uľytkownika w innym komputerze. Administracja przez hipernazdorcú moľe byè przeprowadzana za pomocæ uprzywilejowanego systemu goħcia (na rysunku to pierwszy system, o numerze 0), który ma moľliwoħè tworzenia i uruchamiania nowych systemów goħci. Typ 1., nazywany równieľ rodzimym hipernadzorcæ, zawiera wđasny algorytm szeregowania w procesorze przeznaczony dla maszyn wirtualnych goħci. Typ 2. Ten typ maszyny wirtualnej jest uruchamiany przez jædro systemu operacyjnego gospodarza i moľe skđadaè siú z moduđów na poziomie jædra oraz procesów na poziomie uľytkownika. System operacyjny gospodarza ma uprawnienia do administrowania hipernadzorcæ i uruchamiania nowych goħci. Szeregowanie hipernadzorcy odbywa siú za pomocæ szeregowania w jædrze systemu gospodarza.

Istnieje wiele róľnych implementacji wirtualizacji sprzútowej. Wymieniono jedynie kilka waľniejszych przykđadów: 

VMware ESX. Po raz pierwszy wydane w 2001 roku oprogramowanie VMware ESX to produkt klasy przemysđowej przeznaczony do konsolidacji serwerów, búdæcy kluczowym komponentem VMware vSphere, czyli rozwiæzania

11.3. Wirtualizacja sprzętowa

627

przetwarzania w chmurze. Jego hipernadzorca jest mikrojædrem dziađajæcym w komputerze gospodarza, a pierwsza maszyna wirtualna nosi nazwú konsoli serwisowej — za jej pomocæ moľna administrowaè hipernadzorcæ i nowymi maszynami wirtualnymi. 



Xen. Ten wydany po raz pierwszy w 2003 roku produkt na poczætku byđ projektem University of Cambridge, a póļniej zostađ przejúty przez firmú Citrix. Xen to hipernadzorca typu 1., który uruchamia parawirtualizowanych goħci, aby w ten sposób zapewniè wysokæ wydajnoħè. Nieco póļniej dodano obsđugú goħci wspomaganych sprzútowo w celu zapewnienia moľliwoħci uruchamiania niezmodyfikowanych systemów operacyjnych (Windows). Maszyny wirtualne sæ nazywane domenami; najwiúksze uprawnienia ma dom0, za pomocæ której administrowany jest hipernadzorca i uruchamiane sæ nowe domeny. Xen to oprogramowanie typu open source, dziađajæce w systemie Linux. (Istniađy równieľ wersje dla systemu Solaris, ale obecnie Oracle preferuje Oracle VM Server). EC2 (ang. Elastic Compute Cloud) firm Amazon i Rackspace Cloud to rozwiæzania oparte wđaħnie na Xen. KVM. To rozwiæzanie zostađo poczætkowo opracowane przez firmú Qumranet, a nastúpnie — jako tak zwany start-up — kupione przez firmú Red Hat w 2008 roku. KVM to hipernadzorca typu 2., dziađajæcy jako moduđ dla jædra. Obsđuguje rozszerzenia wirtualizacji wspomaganej sprzútowo. Aby zapewniè wysokæ wydajnoħè, korzysta z parawirtualizacji dla pewnych urzædzeē, o ile odpowiednia obsđuga jest oferowana przez system operacyjny goħcia. W celu utworzenia peđnego egzemplarza maszyny wirtualnej wspomaganej sprzútowo KVM bardzo czústo dziađa w pođæczeniu z procesem uľytkownika o nazwie QEMU (ang. Quick Emulator). Wspomniany QEMU to utworzony przez Fabrice Bellarda, niegdyħ oferowany jako open source, wysokiej jakoħci hipernadzorca typu 2., wykorzystujæcy translacjú binarnæ. Z kolei KVM to produkt open source, którego wersjú opracowano takľe dla jædra illumos oraz dla systemu FreeBSD. Egzemplarze systemów Linux i Windows publicznej chmury Joyent uľywajæ KVM-u (egzemplarze SmartOS stosujæ wirtualizacjú systemu operacyjnego). Firma Google równieľ uľywa KVM-u w Google Compute Engine (patrz odwođanie [8] na koēcu rozdziađu).

W kolejnych punktach omówione búdæ tematy zwiæzane z wirtualizacjæ sprzútowæ: obciæľenie, kontrola zasobów i monitorowanie. Róľniæ siú w zaleľnoħci od implementacji, których jest znacznie wiúcej niľ trzy wymienione wczeħniej. Informacje szczegóđowe znajdziesz w dokumentacji wykorzystywanego produktu.

11.3.1. Obciążenie Wirtualizacja sprzútowa jest przeprowadzana na wiele róľnych sposobów przez hipernadzorcú. Wspomniane techniki wirtualizacji sprzútowej wiæľæ siú z pewnym obciæľeniem dla systemu operacyjnego goħcia, gdy próbuje on uzyskaè dostúp do sprzútu: polecenia muszæ byè przeksztađcane z urzædzeē wirtualnych na fizyczne. Tego rodzaju translacje trzeba poznaè podczas analizy wydajnoħci, mogæ siú róľniè w zaleľnoħci

628

Rozdział 11



Przetwarzanie w chmurze

od rodzaju i implementacji wirtualizacji sprzútowej. Róľnice moľna podsumowaè w kategoriach procesora, mapowania pamiúci, przeprowadzania operacji wejħcia-wyjħcia i efektu powodowanego przez inne tenanty.

Procesor Ogólnie rzecz bioræc, aplikacje goħcia sæ wykonywane bezpoħrednio w procesorach, a programy intensywnie wykorzystujæce procesor osiægajæ takæ samæ wydajnoħè jak uruchomione w systemie gospodarza. Obciæľenie powstaje podczas wykonywania wywođaē uprzywilejowanych, dostúpu do sprzútu oraz mapowania pamiúci operacyjnej. Poniľej wymieniono róľne rodzaje wirtualizacji sprzútowej: 





Translacja binarna. Operujæce na zasobach fizycznych instrukcje jædra systemu goħcia sæ identyfikowane i poddawane translacji. Omawiana tutaj translacja binarna byđa stosowana jeszcze przed opracowaniem wirtualizacji wspomaganej sprzútowo. Bez obsđugi sprzútowej dla wirtualizacji schemat uľywany przez VMware zakđadađ uruchomienie VMM-u (ang. Virtual Machine Monitor) w ringu 0 procesora i przeniesienie jædra systemu goħcia do ringu 1, który wczeħniej byđ nieuľywany (aplikacje dziađajæ w ringu 3, a wiúkszoħè procesorów dostarcza czterech ringów). Poniewaľ pewne instrukcje jædra systemu goħcia przyjmujæ zađoľenie, ľe sæ wykonywane w ringu 0, to ich uruchomienie z ringu 1 wymaga przeprowadzenia translacji i wywođania VMM-u, aby moľna byđo zastosowaè wirtualizacjú. Wspomniana translacja odbywa siú w trakcie dziađania wirtualizacji. Parawirtualizacja. Instrukcje w systemie operacyjnym goħcia, które muszæ byè wirtualizowane, zostajæ zastæpione hiperwywođaniami kierowanymi do hipernadzorcy. Wydajnoħè moľna poprawiè, jeľeli system operacyjny goħcia zostađ zoptymalizowany pod kætem hiperwywođaē i przystosowany do dziađania w maszynie wirtualnej. Wirtualizacja wspomagana sprzútowo. Niezmodyfikowane instrukcje jædra systemu goħcia operujæce w sprzúcie sæ obsđugiwane przez hipernadzorcú, który uruchamia VMM w ringu innym niľ 0. Zamiast przeprowadzaè translacjú binarnæ instrukcji, uprzywilejowane instrukcje jædra systemu goħcia sæ przechwytywane przez posiadajæcy wiúksze uprawnienia VMM. Wspomniany VMM potrafi emulowaè uprawnienia, aby zapewniè obsđugú wirtualizacji (patrz odwođanie [Adams 06] na koēcu rozdziađu).

Ogólnie rzecz bioræc, w zaleľnoħci od implementacji i obciæľenia preferowanym rozwiæzaniem jest wirtualizacja wspomagana sprzútowo. Natomiast parawirtualizacja jest uľywana do poprawy wydajnoħci w przypadku niektórych rodzajów obciæľenia (zwđaszcza wejħcia-wyjħcia), o ile system operacyjny goħcia obsđuguje tú moľliwoħè. Jako przykđad róľnic w implementacji moľna wskazaè model translacji binarnej VMware, który byđ intensywnie optymalizowany na przestrzeni lat. Prezentowany akapit pochodzi z 2007 roku (patrz odwođanie [7] na koēcu rozdziađu):

11.3. Wirtualizacja sprzętowa

629

Ze wzglúdu na obciæľenie zwiæzane z translacjæ hipernadzorcy na goħcia i nieelastyczny model programowania w wiúkszoħci przypadków podejħcie oparte na translacji binarnej VMware oferuje lepszæ wydajnoħè niľ rozwiæzania pierwszej generacji w postaci wirtualizacji wspomaganej sprzútowo. Sztywny model programowania w pierwszej generacji implementacji pozostawia niewiele miejsca na elastycznoħè oprogramowania w zakresie zarzædzania czústotliwoħciæ lub kosztem translacji hipernadzorcy na goħcia.

Czústotliwoħè translacji miúdzy goħciem i hipernadzorcæ, jak równieľ czas spúdzany w hipernadzorcy moľna przestudiowaè jako metrykú obciæľenia procesora. Wspomniane zdarzenia sæ czústo okreħlane mianem wyjħcia goħcia, poniewaľ wirtualny procesor musi wstrzymaè dziađanie goħcia, gdy wystæpi tego rodzaju sytuacja. Na rysunku 11.7 pokazano obciæľenie procesora zwiæzane w wyjħciem goħcia w KVM-ie.

Rysunek 11.7. Obciążenie procesora powodowane przez wirtualizację sprzętową

Na rysunku pokazano przepđyw operacji wyjħcia goħcia miúdzy procesem uľytkownika, jædrem systemu gospodarza i systemem goħcia. Czas spúdzony poza systemem goħcia, przeznaczony na obsđugú wyjħcia, to obciæľenie procesora zwiæzane z wirtualizacjæ sprzútowæ. Im wiúcej czasu przeznaczanego na obsđugú wyjħè, tym wiúksze obciæľenie. W przypadku wyjħcia goħcia pewien podzbiór zdarzeē moľe byè obsđuľony bezpoħrednio w jædrze. Natomiast te zdarzenia, których nie moľna obsđuľyè w jædrze, muszæ je opuħciè i powróciè do procesu uľytkownika. W ten sposób powstaje jeszcze wiúksze obciæľenie w porównaniu z wyjħciem obsđugiwanym przez jædro. Na przykđad w uľywanej przez firmú Joyent implementacji KVM-u wspomniane obciæľenia moľna przestudiowaè za pomocæ wyjħè goħcia, które sæ mapowane w kodzie ļródđowym na nastúpujæce funkcje (pochodzæ z pliku kvm_vmx.c): static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) = { [EXIT_REASON_EXCEPTION_NMI] = handle_exception, [EXIT_REASON_EXTERNAL_INTERRUPT] = handle_external_interrupt,

630

Rozdział 11

[EXIT_REASON_TRIPLE_FAULT] [EXIT_REASON_NMI_WINDOW] [EXIT_REASON_IO_INSTRUCTION] [EXIT_REASON_CR_ACCESS] [EXIT_REASON_DR_ACCESS] [EXIT_REASON_CPUID] [EXIT_REASON_MSR_READ] [EXIT_REASON_MSR_WRITE] [EXIT_REASON_PENDING_INTERRUPT] [EXIT_REASON_HLT] [EXIT_REASON_INVLPG] [EXIT_REASON_VMCALL] [EXIT_REASON_VMCLEAR] [EXIT_REASON_VMLAUNCH] [EXIT_REASON_VMPTRLD] [EXIT_REASON_VMPTRST] [EXIT_REASON_VMREAD] [EXIT_REASON_VMRESUME] [EXIT_REASON_VMWRITE] [EXIT_REASON_VMOFF] [EXIT_REASON_VMON] [EXIT_REASON_TPR_BELOW_THRESHOLD] [EXIT_REASON_APIC_ACCESS] [EXIT_REASON_WBINVD] [EXIT_REASON_TASK_SWITCH] [EXIT_REASON_MCE_DURING_VMENTRY] [EXIT_REASON_EPT_VIOLATION] [EXIT_REASON_EPT_MISCONFIG] [EXIT_REASON_PAUSE_INSTRUCTION] [EXIT_REASON_MWAIT_INSTRUCTION] [EXIT_REASON_MONITOR_INSTRUCTION]

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =



Przetwarzanie w chmurze

handle_triple_fault, handle_nmi_window, handle_io, handle_cr, handle_dr, handle_cpuid, handle_rdmsr, handle_wrmsr, handle_interrupt_window, handle_halt, handle_invlpg, handle_vmcall, handle_vmx_insn, handle_vmx_insn, handle_vmx_insn, handle_vmx_insn, handle_vmx_insn, handle_vmx_insn, handle_vmx_insn, handle_vmx_insn, handle_vmx_insn, handle_tpr_below_threshold, handle_apic_access, handle_wbinvd, handle_task_switch, handle_machine_check, handle_ept_violation, handle_ept_misconfig, handle_pause, handle_invalid_op, handle_invalid_op,

};

Wprawdzie nazwy funkcji sæ lapidarne, ale dostarczajæ ogólnych informacji o powodach ich wywođania w hipernadzorcy przez goħcia i tym samym o powodach obciæľenia procesora. Jednym z najczúħciej spotykanych wyjħè goħcia jest instrukcja halt, zwykle wywođywana przez wætek bezczynnoħci, gdy jædro nie moľe znaleļè kolejnych zadaē do wykonania (wtedy, aľ do wystæpienia przerwania, procesor moľe przejħè do dziađania w trybie charakteryzujæcym siú mniejszym zuľyciem pamiúci). Wymieniona instrukcja jest obsđugiwana przez funkcjú handle_halt(), zaimplementowanæ w pliku kvm_vmx.c. Poniľej przedstawiono kod funkcji handle_halt(), aby pokazaè wywođywane przez niæ polecenia: static int handle_halt(struct kvm_vcpu *vcpu) { skip_emulated_instruction(vcpu); return (kvm_emulate_halt(vcpu)); }

11.3. Wirtualizacja sprzętowa

631

Wymieniona funkcja wywođuje kolejnæ, o nazwie kvm_emulate_halt(), która zostađa zdefiniowana w pliku kvm_x86.c: int kvm_emulate_halt(struct kvm_vcpu *vcpu) { KVM_VCPU_KSTAT_INC(vcpu, kvmvs_halt_exits); if (irqchip_in_kernel(vcpu->kvm)) { vcpu->arch.mp_state = KVM_MP_STATE_HALTED; return (1); } else { vcpu->run->exit_reason = KVM_EXIT_HLT; return (0); } }

Podobnie jak w przypadku wielu rodzajów wyjħè goħcia, iloħè kodu w funkcji jest zbyt mađa, aby minimalizowaè obciæľenie procesora. Omawiany przykđad rozpoczyna siú od makra KVM_VCPU_KSTAT_INC(), które powoduje ustawienie licznika kstat, co pozwala na monitorowanie liczby wywođaē instrukcji halt. (Kod zostađ przeniesiony z systemu Linux, w którym do tego samego celu byđ ustawiony wbudowany licznik). Pozostađa czúħè kodu przeprowadza emulacjú sprzútowæ wymaganæ dla danej instrukcji uprzywilejowanej. Wspomniane funkcje moľna przeanalizowaè w hipernadzorcy za pomocæ narzúdzia DTrace, sprawdzajæc rodzaj oraz czas trwania operacji wyjħcia goħcia. Wirtualizacja urzædzeē sprzútowych, takich jak kontroler przerwaē i dokđadne zegary, równieľ moľe wprowadziè pewne obciæľenie procesora (i niewielkie obciæľenie pamiúci operacyjnej).

Mapowanie pamięci Jak omówiono w rozdziale 7. „Pamiúè”, system operacyjny wspóđpracuje z jednostkæ MMU w celu utworzenia mapowaē strony z pamiúci wirtualnej na pamiúè fizycznæ oraz buforuje je w TLB, aby tym samym poprawiè wydajnoħè. W przypadku wirtualizacji mapowanie nowej strony pamiúci (awaria strony) z systemu goħcia na sprzút fizyczny obejmuje wykonanie dwóch poniľszych kroków: 1. Translacja adresu wirtualnego goħcia na adres fizyczny przeprowadzana przez jædro systemu goħcia. 2. (Rzeczywista) translacja adresu fizycznego goħcia na adres fizyczny gospodarza przeprowadzana przez VMM w hipernadzorcy. Mapowanie przeprowadzane z adresu wirtualnego goħcia na adres fizyczny komputera gospodarza moľe byè buforowane w TLB, aby kolejne operacje dostúpu byđy wykonywane z normalnæ szybkoħciæ i nie wymagađy dodatkowej translacji. Nowoczesne procesory obsđugujæ wirtualizacjú MMU, a wiúc mapowanie znajdujæce siú w buforze TLB moľe byè przeprowadzone znacznie szybciej i przy tym jedynie w sprzúcie (dostúp do strony), bez koniecznoħci odwođywania siú do hipernadzorcy. Funkcja obsđugujæca

632

Rozdział 11



Przetwarzanie w chmurze

takæ moľliwoħè nosi nazwú EPT (ang. Extended Page Tables) w procesorach Intel i NPT (ang. Nested Page Tables) w procesorach AMD (patrz odwođanie [9] na koēcu rozdziađu). W przypadku braku funkcji EPT/NPT innym podejħciem poprawiajæcym wydajnoħè jest przygotowanie tabel SPT (ang. Shadow Page Tables) mapowaē adresu wirtualnego goħcia na adres fizyczny w komputerze gospodarza. Tabele te sæ zarzædzane przez hipernadzorcú, stosuje siú je w trakcie dziađania goħcia wskutek nadpisania jego rejestru CR3. W takiej strategii jædro goħcia zawiera wđasne tabele, które sæ odpowiedzialne za mapowanie adresu wirtualnego na adres fizyczny goħcia w standardowy sposób. Hipernadzorca przechwytuje zmiany wprowadzane we wspomnianych tabelach i tworzy odpowiadajæce im mapowania dla stron gospodarza w tabelach SPT. Nastúpnie, podczas dziađania systemu goħcia, hipernadzorca nadpisuje rejestr CR3 i wskazuje tabelú SPT.

Wielkość pamięci W przeciwieēstwie do wirtualizacji systemu operacyjnego istniejæ pewni dodatkowi konsumenci pamiúci podczas stosowania wirtualizacji sprzútowej. Kaľdy goħè uruchamia wđasne jædro, co oznacza zuľycie pewnej iloħci pamiúci. Architektura pamiúci masowej równieľ moľe prowadziè do powstawania podwójnego buforowania, czyli sytuacji, w której zarówno goħè, jak i gospodarz buforujæ te same dane.

Operacje wejścia-wyjścia Kluczowym kosztem wirtualizacji jest obciæľenie zwiæzane z przeprowadzaniem operacji wejħcia-wyjħcia w urzædzeniach. W przeciwieēstwie do operacji wejħcia-wyjħcia procesora i pamiúci, gdzie ħcieľki kodu mogæ byè wykonywane jak w komputerze gospodarza, kaľda operacja wejħcia-wyjħcia w urzædzeniu musi byè poddawana translacji przez hipernadzorcú. W przypadku duľej liczby operacji wejħcia-wyjħcia, na przykđad w sieci 10 Gb/s, mađe obciæľenie kaľdej operacji wejħcia-wyjħcia (pakietu) moľe oznaczaè znaczny spadek wydajnoħci. Obciæľenie zwiæzane z operacjami wejħcia-wyjħcia moľna do pewnego stopnia ograniczyè dziúki uľyciu parawirtualizacji, w której sterowniki jædra systemu goħcia zostađy zmodyfikowane w celu efektywnego dziađania w ħrodowisku wirtualnym. Oznacza to gromadzenie operacji wejħcia-wyjħcia i przeprowadzanie mniejszej iloħci przerwaē, co zmniejsza tym samym obciæľenie hipernadzorcy. Inna technika nosi nazwú PCI pass-through i powoduje przypisanie urzædzenia PCI bezpoħrednio goħciowi, który uľywa danego urzædzenia jak komputera gospodarza. Omawiana technika zapewnia najlepszæ wydajnoħè ze wszystkich dostúpnych opcji, ale jednoczeħnie zmniejsza elastycznoħè podczas konfiguracji systemu z wieloma tenantami, poniewaľ pewne urzædzenia naleľæ do goħci i nie mogæ byè wspóđdzielone. Tego rodzaju rozwiæzanie komplikuje takľe migracjú (patrz odwođanie [10] na koēcu rozdziađu). Istniejæ pewne techniki poprawy elastycznoħci podczas uľywania urzædzeē PCI wraz z wirtualizacjæ. Do wspomnianych technik zaliczamy SR-IOV (ang. Single Root I/O Virtualization) i MR-IOV (ang. Multi Root I/O Virtualization). Wymienione pojúcia odnoszæ siú do liczby gđównych, skomplikowanych topologii PCI, zapewniajæcych wirtualizacjú sprzútu na róľne sposoby.

11.3. Wirtualizacja sprzętowa

633

Przykđadami operacji wejħcia-wyjħcia urzædzeē sæ Xen (hipernadzorca typu 1.) i KVM (hipernadzorca typu 2.) — pokazano je na rysunku 11.8.

Rysunek 11.8. Ścieżka operacji wejścia-wyjścia w Xen i KVM

Skrót JG oznacza „jædro systemu goħcia”, natomiast domU w Xen to uruchomiony system operacyjny goħcia. Strzađki umieszczone na rysunku wskazujæ ħcieľki kontrolne, gdzie komponenty wzajemnie informujæ siú, synchronicznie lub asynchronicznie, o dostúpnoħci kolejnych danych do transferu. Tak zwana ħcieľka danych moľe byè w pewnych przypadkach zaimplementowana za pomocæ pamiúci wspóđdzielonej i buforów cyklicznych. Istniejæ róľne odmiany wymienionych technologii. Na rysunku 11.8 pokazano rozwiæzanie oparte na procesach proxy operacji wejħcia-wyjħcia (zwykle oprogramowanie QEMU), które sæ tworzone dla poszczególnych maszyn wirtualnych goħci. Liczba kroków w ħcieľce operacji wejħcia-wyjħcia, zarówno kontroli, jak i danych, ma znaczenie krytyczne dla wydajnoħci: im mniej, tym lepiej. W 2006 roku programiħci tworzæcy KVM przeprowadzili porównanie systemu goħcia uprzywilejowanego, takiego jak Xen, z KVM-em i odkryli, ľe KVM moľe przeprowadzaè operacje wejħcia-wyjħcia, wykonujæc o pođowú mniej kroków niľ Xen — 5 kontra 10. Test zostađ przeprowadzony bez uľycia parawirtualizacji, a wiúc nie odzwierciedla nowoczesnych konfiguracji (patrz odwođanie [11] na koēcu rozdziađu). Xen poprawia wydajnoħè operacji wejħcia-wyjħcia na skutek uľycia tak zwanego kanađu urzædzenia, czyli asynchronicznego transportu pamiúci wspóđdzielonej miúdzy dom0 i domenami goħci (domU). Takie rozwiæzanie pozwala wyeliminowaè obciæľenie procesora i szyny w postaci przeprowadzania dokđadnej kopii danych operacji wejħcia-wyjħcia, jakie sæ przekazywane miúdzy domenami. Pozwala takľe na uľycie oddzielnych domen do przeprowadzania operacji wejħcia-wyjħcia, jak to zostađo omówione w punkcie 11.3.2, zatytuđowanym „Kontrola zasobów”. Sterownik goħcia w parawirtualizacji moľna wykorzystaè w celu poprawy wydajnoħci operacji wejħcia-wyjħcia, co oznacza zastosowanie optymalnego buforowania i gromadzenia operacji wejħcia-wyjħcia dla ħcieľki operacji w maszynie wirtualnej.

634

Rozdział 11



Przetwarzanie w chmurze

Inne tenanty Podobnie jak w przypadku wirtualizacji systemu operacyjnego, obecnoħè innych tenantów moľe zmniejszyè rozgrzanie pamiúci podrúcznych procesora, a przerwania goħcia mogæ wystúpowaè, gdy inne tenanty sæ szeregowane i obsđugiwane; dotyczy to równieľ przerwaē urzædzeē. Rywalizacjæ o dostúp do zasobów moľna zarzædzaè za pomocæ kontroli zasobów.

11.3.2. Kontrola zasobów Konfiguracja systemu goħcia z reguđy zawiera pewne ograniczenia dotyczæce zasobów. Oprogramowanie hipernadzorcy równieľ moľe zarzædzaè kontrolæ zasobów w zakresie sieciowych i dyskowych operacji wejħcia-wyjħcia. W przypadku hipernadzorców typu 2. system operacyjny gospodarza posiada ostatecznæ kontrolú nad zasobami fizycznymi. Kontrola zasobów (o ile taka istnieje) dostúpna dla systemu operacyjnego moľe byè zastosowana równieľ wzglúdem goħci i wtedy búdzie dodatkowæ kontrolæ, oprócz stosowanej przez hipernadzorcú. Na przykđad Joyent konfiguruje goħci KVM-u jako dziađajæcych w strefach systemu operacyjnego SmartOS. Moľliwe jest stosowanie mechanizmów kontroli zasobów wymienionych w podrozdziale 11.2 „Wirtualizacja systemu operacyjnego”, miúdzy innymi operacji wejħcia-wyjħcia systemu plików ZFS. Obok ograniczeē KVM-u daje to wiúkszæ liczbú opcji i elastycznoħè podczas kontrolowania poziomu uľycia zasobów. Kaľdy egzemplarz KVM-u jest hermetyzowany we wđasnej, niezwykle bezpiecznej strefie i zapewnia wiele poziomów ochrony — taka technika nosi nazwú double-hull virtualization. To, co konkretnie jest dostúpne, zaleľy od oprogramowania hipernadzorcy, jego typu oraz — w przypadku typu 2. — od systemu operacyjnego gospodarza. Rodzaje mechanizmów kontroli zasobów, które mogæ byè dostúpne z poziomu systemu operacyjnego gospodarza, wymieniono w podrozdziale 11.2 „Wirtualizacja systemu operacyjnego”. W kolejnych fragmentach rozdziađu omówiono mechanizmy kontroli zasobów dostúpne w hipernadzorcach Xen i KVM.

Procesor Zasoby procesora sæ zwykle alokowane dla goħci jako wirtualne procesory (vCPU). Szeregowaniem zajmuje siú hipernadzorca. Liczba przypisanych procesorów wirtualnych ogranicza poziom uľycia zasobów procesora. W przypadku Xen dokđadna kontrola zasobów procesora dla goħci moľe byè przeprowadzana za pomocæ szeregowania przez hipernadzorcú. Poniľej wymieniono dostúpne rodzaje szeregowania (patrz odwođania [Cherkasova 07] i [Matthews 08] na koēcu rozdziađu): 



BVT. Szeregowanie oparte na alokacji czasu wirtualnego, który moľna wczeħniej poľyczyè, aby zapewniè mađe opóļnienie dziađania aplikacjom interaktywnym i funkcjonujæcym w czasie rzeczywistym. SEDF. Szeregowanie w czasie rzeczywistym gwarantujæce konfiguracjú czasu dziađania; algorytm przydziela priorytet zadaniu, które ma najwczeħniejszy deadline.

11.3. Wirtualizacja sprzętowa



635

Oparte na uznaniu. Szeregowanie obsđuguje priorytety (wagi) i ograniczenia uľycia zasobów procesora, a ponadto równowaľy obciæľenie miúdzy wieloma procesorami.

W przypadku KVM-u dokđadna kontrola zasobów procesora moľe byè stosowana przez system operacyjny gospodarza, na przykđad za pomocæ wymienionego wczeħniej szeregowania BVT. W systemie Linux ten sam efekt moľna osiægnæè, uľywajæc mechanizmu kontroli przepustowoħci procesora grup cgroups. Istniejæ pewne ograniczenia dotyczæce tego, jak wymienione technologie respektujæ priorytety goħci. Uľycie procesora przez system goħcia jest zwykle niewidoczne dla hipernadzorcy, a tym samym priorytety wætków jædra goħcia pozostajæ niewidoczne i nierespektowane. Na przykđad jædro systemu Solaris okresowo przeprowadza operacjú skanowania pamiúci, uľywajæc dziađajæcego w tle demona fsflush, który moľe mieè ten sam priorytet hipernadzorcy co aplikacja serwera o znaczeniu krytycznym znajdujæca siú w innym goħciu. W przypadku Xen kontrola uľycia zasobów procesora moľe byè jeszcze bardziej skomplikowana na skutek obciæľeē charakteryzujæcych siú duľæ iloħciæ operacji wejħcia-wyjħcia, które zuľywajæ dodatkowe zasoby procesora w domenie dom0. Sterowniki back-end i proxy operacji wejħcia-wyjħcia w domenie goħcia mogæ zuľywaè wiúcej zasobów procesora niľ przeznaczono dla nich (patrz odwođanie [Cherkasova 05] na koēcu rozdziađu). Rozwiæzaniem jest utworzenie odizolowanego sterownika domen (ang. Isolated Driver Domains), który oddziela operacje wejħcia-wyjħcia, poprawiajæc tym samym bezpieczeēstwo, oraz zapewnia izolacjú wydajnoħci i lepsze moľliwoħci zliczania. Tego rodzaju rozwiæzanie pokazano na rysunku 11.9.

Rysunek 11.9. Rozwiązanie Xen z izolowanymi sterownikami domen

Poziom uľycia procesora przez IDD moľna monitorowaè, a systemy goħci mogæ byè podliczane za wykorzystanie wspomnianych zasobów. Poniľszy akapit pochodzi z pozycji wymienionej w odwođaniu [Gupta 06] na koēcu rozdziađu:

636

Rozdział 11



Przetwarzanie w chmurze

Nasz zmodyfikowany algorytm szeregowania, SEDF-DC dla SEDF-Debt Collector, w ustalonych przedziađach czasu otrzymuje informacje z XenMon, dotyczæce poziomu zasobów procesora zuľywanych przez IDD do przetwarzania operacji wejħcia-wyjħcia w imieniu domen goħci. Dziúki wspomnianym informacjom algorytm SEDF-DC ogranicza alokacjú zasobów procesora w domenach goħci, aby zmieħciè siú w podanym limicie.

Znacznie nowszæ technikæ uľywanæ w Xen jest stub domain, która polega na uruchamianiu minisystemu operacyjnego.

Pojemność pamięci Ograniczenia pamiúci sæ nakđadane jako czúħè konfiguracji goħcia, tak ľe goħè widzi jedynie przydzielonæ mu wielkoħè pamiúci. Jædro systemu goħcia przeprowadza wđasne operacje (stronicowanie, wymianú) w celu zmieszczenia siú w zdefiniowanym limicie. Aby zwiúkszyè elastycznoħè konfiguracji statycznej, firma VMware opracowađa rozwiæzanie nazwane balloon driver (patrz odwođanie [Waldspurger 02] na koēcu rozdziađu). Pozwala ono na zmniejszenie iloħci pamiúci zuľywanej przez dziađajæcego goħcia. Odbywa siú to w wyniku „nadmuchania” moduđu balonu w systemie goħcia, co powoduje zuľycie jego pamiúci. Ta pamiúè jest nastúpnie odzyskiwana przez hipernadzorcú i przeznaczana do uľycia przez inne systemy goħci. Balon moľe byè równieľ zmniejszony, zwracajæc tym samym pamiúè do jædra goħcia. W trakcie wspomnianego procesu jædro goħcia wykonuje standardowe procedury zarzædzania pamiúciæ w celu jej zwolnienia (na przykđad stronicowanie). Produkty VMware, Xen i KVM posiadajæ obsđugú balloon driver.

Pojemność systemu plików Goħcie otrzymujæ w systemie gospodarza utworzone za pomocæ ZFS woluminy dysków wirtualnych o wybranej wielkoħci z puli dysków pamiúci masowej podczas konfiguracji goħcia. We wspomnianych woluminach dysków system goħcia tworzy systemy plików i samodzielnie zarzædza nimi. Ograniczeniem jest zdefiniowana wielkoħè woluminu. Szczegóđy dotyczæce zarzædzania zaleľæ od oprogramowania wirtualizacji oraz konfiguracji pamiúci masowej.

Operacje wejścia-wyjścia urządzenia Mechanizmy kontroli zasobów stosowane przez oprogramowanie wirtualizacji sprzútowej koncentrowađy siú od zawsze na poziomie uľycia procesora, co moľe poħrednio wpđywaè na operacje wejħcia-wyjħcia. Przepustowoħè sieci moľe byè ograniczana przez zewnútrzne, dedykowane urzædzenia, natomiast w hipernadzorcach typu 2. — przez funkcje jædra systemu gospodarza. Na przykđad jædro illumos obsđuguje mechanizm kontroli przepustowoħci sieci, który teoretycznie moľe byè stosowany wzglúdem wirtualnych interfejsów sieciowych systemu goħcia. W systemie Linux mechanizm kontroli przepustowoħci sieci ma postaè grup cgroups, których moľna uľywaè w podobny sposób. Po przestudiowaniu izolacji wydajnoħci w Xen moľna dojħè do nastúpujæcego wniosku (patrz odwođanie [Adamczyk 12] na koēcu rozdziađu):

11.3. Wirtualizacja sprzętowa

637

…rozwaľajæc wirtualizacjú sieci, naleľy stwierdziè, ľe sđabym punktem Xen jest brak prawidđowej izolacji wydajnoħci.

Autorzy pozycji wymienionej w odwođaniu [Adamczyk 12] na koēcu rozdziađu proponujæ rozwiæzanie dla szeregowania sieciowych operacji wejħcia-wyjħcia w Xen, polegajæce na dodaniu modyfikowanych parametrów umoľliwiajæcych definiowanie priorytetu i czústotliwoħci sieciowych operacji wejħcia-wyjħcia. Jeľeli korzystasz z Xen, sprawdļ dostúpnoħè wspomnianej technologii lub podobnych do niej. Techniki dotyczæce dysku i operacji wejħcia-wyjħcia systemu plików sæ opracowywane takľe dla wirtualizacji sprzútowej. Sprawdļ, jakie rozwiæzania sæ dostúpne dla uľywanej przez Ciebie wersji oprogramowania. Ponadto w przypadku hipernadzorcy typu 2. sprawdļ równieľ oferowane przez system operacyjny gospodarza mechanizmy kontroli zasobów. Na przykđad systemy goħci KVM-u tworzonych przez Joyent majæ ograniczenia operacji wejħcia-wyjħcia nakđadane na system plików ZFS.

11.3.3. Monitorowanie Moľliwoħci w zakresie monitorowania zaleľæ od rodzaju hipernadzorcy, a takľe miejsca, z którego nastæpiđo uruchomienie narzúdzi monitorowania. Ogólnie rzecz bioræc, monitorowanie moľe byè prowadzone: 



Z poziomu uprzywilejowanego goħcia (typ 1.) lub systemu gospodarza (typ 2.). Wszystkie zasoby fizyczne powinny byè moľliwe do monitorowania za pomocæ standardowych narzúdzi systemu operacyjnego, a operacje wejħcia-wyjħcia — za pomocæ proxy operacji wejħcia-wyjħcia. Dane statystyczne dotyczæce uľycia zasobów przez poszczególnych goħci powinny byè dostúpne z poziomu systemu operacyjnego lub oprogramowania wirtualizacji. Nie ma moľliwoħci bezpoħredniego monitorowania wewnútrznych komponentów systemu goħcia oraz dziađajæcych w nim procesów. Z poziomu goħci. Nie moľna monitorowaè zasobów fizycznych oraz poziomu ich uľycia. Natomiast moľna monitorowaè zasoby oferowane goħciowi przez oprogramowanie wirtualizacji oraz poziom ich uľycia.

Z poziomu uprzywilejowanego goħcia lub systemu gospodarza uľycie zasobów fizycznych moľna obserwowaè na ogólnym poziomie: wykorzystanie, nasycenie, bđúdy, IOPS, przepustowoħè i rodzaj operacji wejħcia-wyjħcia. Wymienione wartoħci mogæ byè udostúpniane dla poszczególnych goħci, co pozwala na szybkæ identyfikacjú uľytkowników wykorzystujæcych duľo zasobów. Nie ma moľliwoħci bezpoħredniego monitorowania informacji szczegóđowych wskazujæcych procesy goħcia przeprowadzajæce operacje wejħcia-wyjħcia lub ich stosy wywođaē aplikacji. Wspomniane dane moľna monitorowaè po zalogowaniu siú do systemu goħcia (o ile jesteħ upowaľniony do zalogowania siú, a sama moľliwoħè logowania, na przykđad za pomocæ SSH, zostađa odpowiednio skonfigurowana). Oczywiħcie system goħcia musi zawieraè narzúdzia przeznaczone do monitorowania.

638

Rozdział 11



Przetwarzanie w chmurze

Aby ustaliè gđównæ przyczynú problemów zwiæzanych z wydajnoħciæ systemu goħcia, operator chmury byè moľe búdzie musiađ siú zalogowaè jako uprzywilejowany goħè lub gospodarz i goħè, a takľe w obu systemach uruchomiè narzúdzia przeznaczone do monitorowania. Monitorowanie ħcieľek operacji wejħcia-wyjħcia staje siú skomplikowane ze wzglúdu na kroki konieczne do podjúcia — moľe obejmowaè takľe analizú hipernadzorcy i proxy operacji wejħcia-wyjħcia. Z punktu widzenia goħcia moľe nie byè moľliwe monitorowanie zasobów fizycznych. Z tego powodu klienci korzystajæcy z systemów goħci zwykle winú za problemy z wydajnoħciæ zrzucajæ na zasoby fizyczne uľywane przez niewidocznych hađaħliwych sæsiadów. Aby wspomnianym klientom zapewniè spokój (i zmniejszyè liczbú zgđoszeē w ramach pomocy technicznej), pewne ograniczone informacje dotyczæce poziomu uľycia zasobów fizycznych moľna dostarczaè w innej postaci, na przykđad przez SNMP lub API chmury. W dalszej czúħci rozdziađu przedstawiono narzúdzia monitorowania, których moľna uľywaè z róľnych miejsc. Omówiono takľe strategie w zakresie analizy wydajnoħci. Do prezentacji rodzaju informacji, jakie mogæ byè dostarczane przez oprogramowanie wirtualizacji, wykorzystamy produkty Xen i KVM.

Uprzywilejowany gość lub gospodarz Wszystkie zasoby systemowe (procesor, pamiúè, system plików, dysk, sieè) powinny byè moľliwe do monitorowania za pomocæ narzúdzi omówionych w poprzednich rozdziađach.

KVM W przypadku hipernadzorcy typu 2. egzemplarze systemu goħcia sæ widoczne w systemie operacyjnym gospodarza. Na przykđad poniľsze dane wyjħciowe dotyczæ KVM-u w systemie SmartOS: global# prstat -c 1 PID USERNAME SIZE 46478 root 1163M 4440 root 9432K 15041 103 2279M 37494 root 1069M 37088 root 1069M 37223 root 1067M 36954 root 1066M [...]

RSS 1150M 4968K 2091M 1055M 1057M 1055M 1054M

STATE cpu6 sleep sleep sleep sleep sleep cpu7

PRI NICE TIME CPU PROCESS/NLWP 1 0 9:40:15 5.2% qemu-system-x86/5 50 0 136:10:38 1.1% zoneadmd/5 60 0 168:40:09 0.4% beam.smp/87 59 0 105:35:52 0.3% qemu-system-x86/4 1 0 107:16:27 0.3% qemu-system-x86/4 59 0 94:19:31 0.3% qemu-system-x86/7 59 0 104:28:53 0.3% qemu-system-x86/4

Procesy QEMU to goħcie KVM-u, którzy zawierajæ wætki dla kaľdego procesora wirtualnego oraz dla proxy operacji wejħcia-wyjħcia. Uľycie zasobów procesora przez goħci moľna sprawdziè za pomocæ polecenia prstat, natomiast uľycie poszczególnych procesorów wirtualnych — za pomocæ innych opcji polecenia prstat, na przykđad -mL. Mapowanie procesów QEMU na ich egzemplarze goħci to zwykle kwestia przeanalizowania argumentów procesu (pargs) i odczytania wartoħci opcji -name. Inny waľny obszar analizy to wyjħcia procesora wirtualnego goħcia. Rodzaj operacji wyjħcia moľe wskazaè aktywnoħè goħcia: procesor wirtualny jest bezczynny, przeprowadza operacje wejħcia-wyjħcia lub teľ wykonuje obliczenia. W systemie Linux tego rodzaju

11.3. Wirtualizacja sprzętowa

639

informacje sæ zbierane i mogæ byè udostúpniane przez system plików debugfs za pomocæ narzúdzi takich jak perf. Z kolei w systemie SmartOS wspomniane informacje sæ zbierane przez kstat i moľna je podsumowaè za pomocæ polecenia kvmstat. host# kvmstat 1 pid vcpu | exits : 12484 0 | 8955 : 12484 1 | 2328 : 12484 2 | 2591 : 12484 3 | 3226 : 28275 0 | 196 : [...]

haltx 551 253 262 244 12

irqx 2579 738 579 1551 75

irqwx 316 17 14 19 1

iox 1114 248 638 239 0

mmiox 0 0 0 0 82

| | | | | |

irqs 1764 348 358 343 14

emul 3510 876 837 960 107

eptv 0 0 0 0 0

Dwie pierwsze kolumny identyfikujæ procesor wirtualny wewnætrz okreħlonej maszyny wirtualnej. Kolejne kolumny zawierajæ informacje o cađkowitej liczbie wyjħè; dane sæ podzielone na ogólne kategorie. Ostatnie kilka kolumn wskazuje pozostađæ aktywnoħè w procesorze wirtualnym. Znaczenie poszczególnych kolumn zostađo wyjaħnione w komunikacie pomocy polecenia kvmstat: 

pid. Identyfikator procesu kontrolujæcego wirtualny procesor.



vcpu. Identyfikator procesora wirtualnego wzglúdem jego maszyny wirtualnej.



exits. Maszyna wirtualna zakoēczyđa dziađanie wirtualnego procesora.



haltx. Maszyna wirtualna zakoēczyđa dziađanie ze wzglúdu na instrukcjú HLT.









irqx. Maszyna wirtualna zakoēczyđa dziađanie ze wzglúdu na oczekujæce przerwanie zewnútrzne. irqwx. Maszyna wirtualna zakoēczyđa dziađanie ze wzglúdu na otwarte okno przerwania. iox. Maszyna wirtualna zakoēczyđa dziađanie ze wzglúdu na instrukcjú wejħcia-wyjħcia. mmiox. Maszyna wirtualna zakoēczyđa dziađanie ze wzglúdu na operacje wejħcia-wyjħcia mapowania pamiúci.



irqs. Przerwanie zostađo przekazane wirtualnemu procesorowi.



emul. Instrukcje emulowane w jædrze.



eptv. Bđæd tabeli stron.

Wprawdzie uzyskanie bezpoħredniego wglædu do maszyny wirtualnej goħcia moľe nie byè đatwym zadaniem dla operatora, ale analiza wyjħè pozwala przygotowaè charakterystykú obciæľenia wirtualizacji sprzútowej, jakie moľe (choè nie musi) mieè wpđyw na tenant. Jeľeli widzisz mađæ liczbú wyjħè i wysoki odsetek instrukcji haltx, to wiadomo, ľe procesor goħcia jest najczúħciej bezczynny. Z drugiej strony, duľa liczba operacji wejħcia-wyjħcia, przerwania generowane i „wstrzykiwane” do goħcia prawdopodobnie oznaczajæ, ľe przeprowadza on operacje wejħcia-wyjħcia w swoich wirtualnych kartach sieciowych i dyskach.

640

Rozdział 11



Przetwarzanie w chmurze

Xen W przypadku hipernadzorcy typu 1. procesor wirtualny istnieje w hipernadzorcy i nie jest widoczny z poziomu uprzywilejowanego systemu goħcia (dom0) za pomocæ standardowych narzúdzi systemu operacyjnego. W rozwiæzaniu opartym na Xen moľna uľyè polecenia xentop: # xentop xentop - 02:01:05 Xen 3.3.2-rc1-xvm 2 domains: 1 running, 1 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown Mem: 50321636k total, 12498976k used, 37822660k free CPUs: 16 @ 2394MHz NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR SSID Domain-0 -----r 6087972 2.6 9692160 19.3 no limit n/a 16 0 0 0 0 0 0 0 0 Doogle_Win --b--172137 2.0 2105212 4.2 2105344 4.2 1 2 0 0 2 0 0 0 0 [...]

Kolumny w danych wyjħciowych wyħwietlajæ nastúpujæce informacje: 

CPU(%). Wyraľony w procentach poziom uľycia procesora (suma wielu procesorów).



MEM(k). Wyraľony w kilobajtach poziom uľycia pamiúci.



 

MEM(%). Wartoħè procentowa wskazujæca, jakæ czúħè pamiúci systemowej stanowi pamiúè operacyjna. MAXMEM(k). Wyraľony w kilobajtach limit pamiúci operacyjnej. MAXMEM(%).Wartoħè procentowa wskazujæca, jakæ czúħè pamiúci systemowej stanowi limit pamiúci operacyjnej.



VCPUS. Liczba przypisanych procesorów wirtualnych.



NETS. Liczba wirtualnych interfejsów sieciowych.



NETTX(k). Wyraľona w kilobajtach iloħè danych wysđanych przez sieè.



NETRX(k). Wyraľona w kilobajtach iloħè danych otrzymanych przez sieè.



VBDS. Liczba wirtualnych urzædzeē blokowych.



VBD_OO. Ľædania kierowane do wirtualnego urzædzenia blokowego (kolejkowane na skutek nasycenia).



VBD_RD. Ľædania odczytu wirtualnego urzædzenia blokowego.



VBD_WR. Ľædania zapisu wirtualnego urzædzenia blokowego.

Domyħlnie dane wyjħciowe polecenia xentop sæ uaktualniane co trzy sekundy, a czústotliwoħè uaktualnieē moľna zdefiniowaè za pomocæ opcji -d czas.

11.3. Wirtualizacja sprzętowa

641

Monitorowanie zaawansowane W celu przeprowadzenia zaawansowanej analizy hipernadzorcy moľna skorzystaè z wielu róľnych opcji. W systemie Linux polecenie perf dostarcza punktów instrumentacji zarówno dla KVM-u, jak i Xen. Wspomniane punkty moľna wykorzystaè do monitorowania róľnych zdarzeē. Poniľsze polecenie wyħwietla punkty dostúpne dla Xen: # perf list [...] xen:xen_mc_batch xen:xen_mc_issue xen:xen_mc_entry xen:xen_mc_entry_alloc xen:xen_mc_callback xen:xen_mc_flush_reason xen:xen_mc_flush xen:xen_mc_extend_args xen:xen_mmu_set_pte [...]

[Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint [Tracepoint

event] event] event] event] event] event] event] event] event]

Istnieje równieľ polecenie xentrace, które potrafi pobraè od hipernadzorcy dziennik zdarzeē zdefiniowanego typu zdarzeē. Wspomniany dziennik moľna nastúpnie przejrzeè za pomocæ xenanalyze. Informacje znajdujæce siú w dzienniku zdarzeē pomogæ w rozwiæzywaniu problemów zwiæzanych z szeregowaniem w hipernadzorcy oraz uľytym algorytmem szeregowania. W przypadku KVM-u narzúdzie DTrace moľna wykorzystaè do przeanalizowania na wiele róľnych sposobów komponentów wewnútrznych hipernadzorcy, miúdzy innymi sterownika kvm jædra gospodarza i procesu QEMU, szeregowania w jædrze gospodarza, sterowników urzædzeē gospodarza oraz interakcji z innymi tenantami. Przedstawione dane wyjħciowe skryptu DTrace o nazwie kvmexitlatency.d (patrz odwođanie [12] na koēcu rozdziađu) pokazujæ monitorowane opóļnienie wyjħcia goħcia KVM-u oraz jego rozkđad dla poszczególnych typów: # ./kvmexitlatency.d Tracing KVM exits (ns)... Hit Ctrl-C to stop ^C EXIT_REASON_CPUID value ------------- Distribution ------------1024 | 2048 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 4096 |@ 8192 | [...] EXIT_REASON_APIC_ACCESS value ------------- Distribution ------------2048 | 4096 | 8192 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 16384 |@@ 32768 |

count 0 31 1 0 count 0 125 11416 687 3

642

Rozdział 11

65536 | EXIT_REASON_IO_INSTRUCTION value ------------- Distribution ------------2048 | 4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 8192 |@ 16384 | 32768 |



Przetwarzanie w chmurze

0 count 0 32623 987 7 0

W przedstawionym przykđadzie wszystkie wyjħcia trwađy maksymalnie 64 μs, czas trwania wiúkszoħci zawiera siú w przedziale od 2 μs do 16 μs. Monitorowanie zaawansowane hipernadzorcy to nieustanny proces za pomocæ poleceē takich jak perf, a narzúdzie DTrace jeszcze bardziej zwiúksza zakres tego, co moľna monitorowaè. Przykđadem moľe byè profilowanie CR3.

Profilowanie CR3 Dziúki zbiorowi instrukcji VT-x w procesorach Intel, przeznaczonemu do wirtualizacji wspomaganej sprzútowo, kaľdy procesor wirtualny posiada strukturú kontrolnæ VMCS (ang. Virtual Machine Control Structure). Wymieniona struktura przechowuje kopiú rejestru stanu procesora wirtualnego, do którego narzúdzie DTrace moľe uzyskaè dostúp. Kaľdy proces w systemie ma wđasnæ przestrzeē adresowæ i zestaw tabel stron opisujæcych translacjú wirtualnego adresu pamiúci na fizyczny. Czúħè gđówna tabel stron jest przechowywana w rejestrze CR3. Za pomocæ dostawcy profilowania w DTrace moľna z poziomu maszyny wirtualnej goħcia próbkowaè rejestr CR3. Jeľeli konkretna wartoħè CR3 pojawia siú czústo, wówczas wiadomo, ľe powiæzany z niæ proces jest bardzo aktywny w procesorze goħcia. Wprawdzie wartoħè CR3 obecnie nie moľe byè mapowana na postaè czytelnæ dla czđowieka, takæ jak nazwa procesu, ale przedstawiona w postaci liczbowej unikalnie identyfikuje proces w systemie goħcia i moľna jæ wykorzystaè do poznania ogólnego trendu systemu. Rysunek 11.10 pochodzi z aplikacji Joyent Cloud Analytics i jest przykđadem wizualizacji sond CRS. Pokazuje aktywnoħè szeregowania jædra systemu goħcia dla dwóch procesów intensywnie korzystajæcych z procesora. Przedstawiona wizualizacja jest rodzajem mapy cieplnej, na której kolumny pionowe pokazujæ dane pobrane w trakcie kolejnych sekund. Po prawej stronie widzimy wzór wskazujæcy na dwa róľne rejestry CR3 pojawiajæce siú na przemian w procesorze, co wynika z dziađania dwóch odmiennych procesów w systemie goħcia.

Gość Z perspektywy goħcia widoczne sæ jedynie urzædzenia wirtualne. Najbardziej interesujæcæ metrykæ jest opóļnienie pokazujæce, jak urzædzenie udziela odpowiedzi w danej wirtualizacji, jakie sæ ograniczenia i wpđyw innych tenantów. Metryki, takie jak wartoħè procentowa okreħlajæca zajútoħè, sæ trudne do interpretacji bez dokđadnej wiedzy o urzædzeniu, którego dotyczy dana metryka.

11.3. Wirtualizacja sprzętowa

643

Rysunek 11.10. Wizualizacja rejestrów CR3 procesora wirtualnego systemu gościa

W systemie Linux dane wyjħciowe polecenia vmstat zawierajæ kolumnú wskazujæcæ procent skradzionego procesora (st), co jest rzadkim przykđadem danych statystycznych uwzglúdniajæcych wirtualizacjú: $ vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 107500 141348 301680 0 0 0 0 1006 9 99 0 0 0 1 1 0 0 107500 141348 301680 0 0 0 0 1006 11 97 0 0 0 3 1 0 0 107500 141348 301680 0 0 0 0 978 9 95 0 0 0 5 3 0 0 107500 141348 301680 0 0 0 4 912 15 99 0 0 0 1 2 0 0 107500 141348 301680 0 0 0 0 33 7 3 0 0 0 97 3 0 0 107500 141348 301680 0 0 0 0 34 6 100 0 0 0 0 5 0 0 107500 141348 301680 0 0 0 0 35 7 1 0 0 0 99 2 0 0 107500 141348 301680 0 0 0 48 38 16 2 0 0 0 98 [...]

W zaprezentowanym przykđadzie przetestowany zostađ goħè Xen, podczas gdy zastosowano agresywnæ politykú ograniczania zasobów procesora. W ciægu pierwszych czterech sekund ponad 90% czasu procesora goħè spúdzađ w trybie uľytkownika, a kilka procent zostađo skradzionych innym tenantom. Nastúpnie wspomniane zachowanie ulegđo agresywnej zmianie, tak ľe wiúkszoħè czasu procesora stanowiđ czas skradziony innym tenantom.

Strategia W poprzednich rozdziađach przedstawiono techniki analizy fizycznych zasobów komputera, które mogæ byè stosowane do wyszukiwania bđúdów i wæskich gardeđ przez administratorów odpowiedzialnych za fizyczne komputery. Mechanizmy kontroli zasobów

644

Rozdział 11



Przetwarzanie w chmurze

w systemach goħci równieľ moľna sprawdziè, aby przekonaè siú, czy goħcie wykorzystujæ limit. Tym samym warto ich o tym poinformowaè i zaproponowaè uaktualnienie specyfikacji. Bez zalogowania siú do systemu goħcia administrator nie moľe identyfikowaè niczego wiúcej; wspomniane logowanie moľe okazaè siú konieczne do przeprowadzenia powaľnej analizy wydajnoħci. W przypadku goħci przedstawione w poprzednich rozdziađach narzúdzia i strategie analizy zasobów moľna zastosowaè — oczywiħcie naleľy pamiútaè o tym, ľe tutaj zasoby sæ wirtualne. Niektóre zasoby mogæ nie byè wykorzystywane w peđni ze wzglúdu na niewidoczne mechanizmy kontroli zasobów stosowane przez hipernadzorcú lub wystúpowanie rywalizacji z innymi tenantami. W najlepszej sytuacji oprogramowanie chmury lub jej dostawca zapewnia klientom moľliwoħè przeglædania ograniczonych informacji o poziomie uľycia zasobów fizycznych, aby tym samym pozwoliè im na prowadzenie samodzielnej analizy problemów wydajnoħci. W przeciwnym razie istnienie rywalizacji i osiægniúcie limitów moľna okreħliè na podstawie wiúkszego opóļnienia operacji wejħcia-wyjħcia i szeregowania w procesorze. Wspomniane opóļnienie moľna zmierzyè na warstwie wywođaē systemowych lub w jædrze systemu goħcia.

11.4. Porównania Porównanie technologii pomaga w ich lepszym zrozumieniu i jest uľyteczne, nawet jeħli nie jesteħ upowaľniony do zmiany technologii stosowanej przez Twojæ firmú. Porównanie trzech technologii omawianych w tym rozdziale przedstawiono w tabeli 11.2. Wprawdzie tabela stanie siú nieaktualna po wprowadzeniu nowych funkcji w omówionych technologiach wirtualizacji, ale nadal búdzie uľyteczna, pokazujæc rodzaje informacji, które warto sprawdziè, nawet jeħli opracowane búdæ zupeđnie nowe technologie wirtualizacji, niemieszczæce siú w ľadnej z powyľszych kategorii. Technologie wirtualizacji sæ bardzo czústo porównywane za pomocæ mikrotestów wydajnoħci, aby sprawdziè, która dziađa najlepiej. Niestety w ten sposób przeocza siú moľliwoħci w zakresie monitorowania, dziúki któremu moľna osiægnæè najwiúkszy wzrost wydajnoħci (identyfikacjú i eliminacjú niepotrzebnie wykonywanej pracy). Rozwaľ nastúpujæcy scenariusz, z którym czústo moľna siú spotkaè. Nowy klient chmury bđúdnie konfiguruje aplikacjú, co prowadzi do nadmiernego zuľycia pamiúci operacyjnej i powstania operacji stronicowania bædļ wymiany. W przypadku wirtualizacji systemu operacyjnego ten problem moľe byè đatwo wychwycony przez administratorów chmury (przypomnij sobie omówione wczeħniej polecenie zonememstat). Administratorzy búdæ widzieli procesy odpowiedzialne za problem, stos wywođaē aplikacji, a czústo nawet pliki konfiguracyjne — identyfikacja problemu búdzie moľliwa bez koniecznoħci logowania siú do systemu goħcia. Natomiast w przypadku wirtualizacji sprzútowej administrator chmury zobaczy jedynie operacje wejħcia-wyjħcia wykonywane przez goħcia; mogæ one wyglædaè jak typowe dyskowe operacje wejħcia-wyjħcia i zostaè bđúdnie uznane za zwykđæ dziađalnoħè. Wykorzystanie cađej przydzielonej pamiúci przez system goħcia i pojawienie siú operacji stronicowania oraz wymiany búdzie niemoľliwe do identyfikacji bez zalogowania siú do systemu goħcia, co wymaga upowaľnienia.

11.4. Porównania

645

Tabela 11.2. Porównanie atrybutów wydajności technologii wirtualizacji Wirtualizacja systemu operacyjnego

Wirtualizacja sprzętowa, typ 1.

Wirtualizacja sprzętowa, typ 2.

Wydajność procesora

wysoka

wysoka (przy wsparciu ze strony procesora)

wysoka (przy wsparciu ze strony procesora)

Alokacja procesora

elastyczna (FFS + bursting)

na stałe określona liczba procesorów wirtualnych

na stałe określona liczba procesorów wirtualnych

Przepustowość wejścia-wyjścia

wysoka (brak wewnętrznego obciążenia)

niska lub średnia (w przypadku parawirtualizacji)

niska lub średnia (w przypadku parawirtualizacji)

Opóźnienie wejścia-wyjścia

niskie (brak wewnętrznego obciążenia)

zwykle występuje (obciążenie związane z proxy operacji wejścia-wyjścia)

zwykle występuje (obciążenie związane z proxy operacji wejścia-wyjścia)

Obciążenie związane z dostępem do pamięci

brak

pewne (EPT/NPT lub tabele stron shadow)

pewne (EPT/NPT lub tabele stron shadow)

Straty pamięci

brak

pewne (dodatkowe jądro, tabele pamięci)

pewne (dodatkowe jądro, tabele pamięci)

Alokacja pamięci

elastyczna (nieużywana pamięć gościa jest wykorzystywana jako bufor systemu plików)

stała (istnieje prawdopodobieństwo wystąpienia podwójnego buforowania)

stała (istnieje prawdopodobieństwo wystąpienia podwójnego buforowania)

Kontrola zasobów

wiele (w zależności od systemu operacyjnego)

pewne (w zależności od hipernadzorcy)

większość (system operacyjny i hipernadzorca)

Możliwość monitorowania z poziomu gospodarza

największa (widoczne jest wszystko)

mała (użycie zasobów, dane statystyczne hipernadzorcy)

średnia (użycie zasobów, dane statystyczne hipernadzorcy, analiza systemu operacyjnego hipernadzorcy)

Możliwość monitorowania z poziomu gościa

średnia (widoczne jest to, co gość może zobaczyć, w tym między innymi pewne dane statystyczne dotyczące zasobów fizycznych)

niska (jedynie gość)

niska (jedynie gość)

Złożoność hipernadzorcy

niska (partycje systemu operacyjnego)

wysoka (złożony hipernadzorca)

średnia

Różne systemy operacyjne gości

najczęściej nie (czasami istnieje taka możliwość dzięki translacji wywołań systemowych)

tak

tak

Atrybut

646

Rozdział 11



Przetwarzanie w chmurze

Inny czynnik, który warto wziæè pod uwagú, to poziom skomplikowania obsđugi. Najniľszy jest w przypadku wirtualizacji systemu operacyjnego, poniewaľ wówczas jest tylko jedno jædro, którym trzeba siú zajmowaè. W parawirtualizacji poziom skomplikowania obsđugi jest wysoki — system operacyjny goħcia musi oferowaè obsđugú parawirtualizacji, co oznacza koniecznoħè wprowadzenia zmian w jædrze. W publicznej chmurze Joyent preferowana jest wirtualizacja systemu operacyjnego (strefy), co zapewnia wysokæ wydajnoħè dziađania i moľliwoħè monitorowania. Oczywiħcie ten rodzaj wirtualizacji moľna zastosowaè, jeħli aplikacje klienta dziađajæ w systemie SmartOS. Technologie KVM i parawirtualizacja sæ stosowane, gdy system operacyjny goħcia ma byè inny niľ SmartOS, na przykđad Linux lub Windows. W takiej sytuacji wydajnoħè dziađania búdzie niľsza, co wynika z ograniczenia zwiæzanego z operacjami wejħcia-wyjħcia. Firma Joyent próbowađa rozwiæzania opartego na Xen, ale ostatecznie zastæpiđa je technologiæ KVM.

11.5. Ćwiczenia 1. Odpowiedz na pytania zwiæzane z terminologiæ wirtualizacji: 

Jaka jest róľnica miúdzy systemem gospodarza i goħcia?



Co to jest tenant?



Co to jest hipernadzorca?

2. Odpowiedz na nastúpujæce pytania dotyczæce koncepcji:  







Jaka jest rola izolacji wydajnoħci? Jak moľesz opisaè obciæľenie wydajnoħci zwiæzane z wirtualizacjæ sprzútowæ (dowolnego typu)? Jak moľesz opisaè obciæľenie wydajnoħci zwiæzane z wirtualizacjæ systemu operacyjnego? Jaka jest moľliwoħè monitorowania systemu fizycznego z poziomu goħcia w wirtualizacji sprzútowej (dowolnego rodzaju)? Jaka jest moľliwoħè monitorowania systemu fizycznego z poziomu gospodarza w wirtualizacji systemu operacyjnego?

3. Wybierz technologiú wirtualizacji, a nastúpnie odpowiedz na poniľsze, dokđadniejsze pytania dotyczæce goħcia: 







Jak moľesz opisaè sposób stosowania ograniczenia pamiúci i dlaczego jest widoczny z poziomu goħcia? Co zobaczy administrator, gdy system goħcia wykorzysta przydzielonæ mu pamiúè? Jaki jest sposób stosowania limitu nađoľonego na zasoby procesora? Jak búdzie siú przejawiađ na poziomie goħcia? Jaki jest sposób stosowania limitu nađoľonego na dyskowe operacje wejħcia-wyjħcia? Jak búdzie siú przejawiađ na poziomie goħcia? Jaki jest sposób stosowania limitu nađoľonego na sieciowe operacje wejħcia-wyjħcia? Jak búdzie siú przejawiađ na poziomie goħcia?

11.6. Odwołania

647

4. Opracuj metodú USE w postaci listy rzeczy do zrobienia dotyczæcych kontroli. Uwzglúdnij sposób pobrania poszczególnych metryk (podaj konkretne polecenia do wykonania) i wskaľ, jak moľna interpretowaè otrzymane wyniki. Przed instalacjæ lub uľyciem dodatkowego oprogramowania spróbuj wykorzystaè narzúdzia monitorowania oferowane przez uľywany system operacyjny

11.6. Odwołania [Goldberg 72]

R.P. Goldberg, Architectural Principles for Virtual Computer Systems (praca naukowa), Harvard University, 1972.

[Waldspurger 02]

C. Waldspurger, Memory Resource Management in VMware ESX Server, Proceedings of the 5th Symposium on Operating Systems Design and Implementation, grudzieē 2002.

[Cherkasova 05]

L. Cherkasova, R. Gardner, Measuring CPU Overhead for I/O Processing in the Xen Virtual Machine Monitor, USENIX ATEC, 2005.

[Adams 06]

K. Adams, O. Agesen, A Comparison of Software and Hardware Techniques for x86 Virtualization, ASPLOS XII, ACM Press, 2006.

[Gupta 06]

D. Gupta, L. Cherkasova, R. Gardner, A. Vahdat. Enforcing Performance Isolation across Virtual Machines in Xen, ACM/IFIP/USENIX Middleware, 2006.

[Cherkasova 07]

L. Cherkasova, D. Gupta, A. Vahdat, Comparison of the Three CPU Schedulers in Xen, ACM SIGMETRICS, 2007.

[Matthews 08]

J. Matthews i in., Running Xen: A Hands-On Guide to the Art of Virtualization, Prentice Hall, 2008.

[Adamczyk 12]

B. Adamczyk, A. Chydzinski, Performance Isolation Issues in Network Virtualization in Xen, „International Journal on Advances in Networks and Services”, 2012.

[1]

http://highscalability.com/blog/2012/12/12/ pinterest-cut-costs-from-54-to-20-per-hour-by-automatically.html

[2]

https://linuxcontainers.org/

[3]

http://openvz.org/

[4]

http://lwn.net/Articles/524952/

[5]

http://illumos.org/man/5/resource_controls

[6]

http://www.brendangregg.com/USEmethod/use-smartos.html

[7]

http://www.vmware.com/files/pdf/VMware_paravirtualization.pdf

[8]

https://developers.google.com/compute/docs/faq#whatis

648

Rozdział 11



Przetwarzanie w chmurze

[9]

http://corensic.wordpress.com/2011/12/05/ virtual-machines-virtualizing-virtual-memory/

[10]

http://wiki.xen.org/wiki/Xen_PCI_Passthrough

[11]

KVM: Kernel-based Virtualization Driver, 2006.

[12]

https://github.com/brendangregg/dtrace-cloud-tools

12 Testy wydajności

„Mamy kđamstwa, przeklúte kđamstwa i pomiary wydajnoħci”. — Anon i inni, A Measure of Transaction Processing Power (patrz odwođanie [Anon 85] na koēcu rozdziađu). Przeprowadzanie testów wydajnoħci w kontrolowany sposób pozwala na porównywanie dostúpnych rozwiæzaē oraz na poznanie ograniczeē w zakresie wydajnoħci, zanim pojawiæ siú w ħrodowisku produkcyjnym. Wspomniane ograniczenia mogæ byè zasobami systemowymi, limitami oprogramowania w ħrodowisku wirtualnym (przetwarzania w chmurze) lub ograniczeniami w aplikacji docelowej. W poprzednich rozdziađach omówiono wymienione komponenty, rodzaje ograniczeē oraz narzúdzia uľywane do ich analizy. We wczeħniejszych rozdziađach wprowadzono takľe narzúdzia przeznaczone do wykonywania mikrotestów wydajnoħci, które umoľliwiajæ przeprowadzanie analizy limitów za pomocæ prostych, sztucznych obciæľeē. Inne rodzaje testów wydajnoħci obejmujæ symulacjú obciæľenia klienta, czyli próbú powielenia wzorca uľycia stosowanego przez klienta i monitorowanie tego wzorca. Niezaleľnie od wybranego rodzaju konieczne jest przeanalizowanie testu wydajnoħci i potwierdzenie tego, co búdzie mierzone. Testy wydajnoħci pokazujæ jedynie, jak szybko dany system moľe przeprowadziè wskazany test wydajnoħci. Do Ciebie naleľy interpretacja wyniku i ustalenie, jak on siú ma do uľywanego ħrodowiska. W tym rozdziale ogólnie koncentrujemy siú na testach wydajnoħci. Znajdziesz tutaj wskazówki i metodologie pozwalajæce na unikniúcie najczúħciej popeđnianych bđúdów 649

650

Rozdział 12



Testy wydajności

i wđaħciwe przetestowanie systemu. Przedstawiony w rozdziale materiađ to jednoczeħnie uľyteczne wprowadzenie, gdy búdziesz musiađ interpretowaè wyniki uzyskane przez innych, na przykđad wyniki testów wydajnoħci przeprowadzanych przez producentów sprzútu.

12.1. Wprowadzenie W tym podrozdziale zostanæ omówione dziađania prowadzone podczas testów wydajnoħci. Dowiesz siú, jak przeprowadzaè efektywne testy wydajnoħci. Znajdziesz tutaj takľe podsumowanie najczúħciej popeđnianych bđúdów, czyli „grzechy testów wydajnoħci”.

12.1.1. Działania Test wydajnoħci moľe byè przeprowadzany z wymienionych powodów: 











Projekt systemu. Porównywanie róľnych systemów, komponentów lub aplikacji. W produktach komercyjnych testy wydajnoħci mogæ dostarczaè danych pomagajæcych klientom w podjúciu decyzji o zakupie, zwđaszcza na podstawie wspóđczynnika cena/wydajnoħè dla dostúpnych opcji. W pewnych przypadkach moľna wykorzystaè wyniki opublikowanych biznesowych testów wydajnoħci, dziúki którym klienci nie muszæ samodzielnie przeprowadzaè testów wydajnoħci. Dostrajanie. Testowanie modyfikowalnych parametrów i opcji konfiguracyjnych w celu identyfikacji tych, które warto poddaè dalszej analizie wraz z obciæľeniem produkcyjnym. Programowanie. W przypadku zarówno testów nieregresyjnych, jak i sprawdzania ograniczeē podczas prac nad produktem. Testy nieregresyjne mogæ byè skđadnikiem zautomatyzowanych testów wydajnoħci przeprowadzanych regularnie, aby jak najszybciej wykryè kaľdæ regresjú wydajnoħci i powiæzaè jæ ze zmianæ wprowadzonæ w produkcie. W przypadku sprawdzania ograniczeē testy wydajnoħci moľna zastosowaè po to, aby maksymalnie wykorzystaè produkt na granicy jego moľliwoħci. To pozwala okreħliè obszary, na których moľna wprowadziè zmiany zmierzajæce do najwiúkszej poprawy wydajnoħci dziađania produktu. Planowanie pojemnoħci. Okreħlenie limitów systemu i aplikacji podczas planowania pojemnoħci w celu dostarczenia danych do modelowania wydajnoħci lub bezpoħredniego ustalenia ograniczenia w zakresie pojemnoħci. Rozwiæzywanie problemów. W celu potwierdzenia, ľe komponenty nadal mogæ dziađaè z maksymalnæ wydajnoħciæ — na przykđad testowanie maksymalnej przepustowoħci sieci miúdzy komputerami i sprawdzenie, czy wystúpuje jakikolwiek problem z sieciæ. Marketing. Okreħlenie maksymalnej wydajnoħci produktu w celu uľycia tego rodzaju informacji w dziađaniach marketingowych (te testy wydajnoħci sæ równieľ okreħlane mianem benchmarketing).

12.1. Wprowadzenie

651

W ħrodowiskach biznesowych przeprowadzenie testu wydajnoħci dowodu koncepcji moľe byè waľnym zadaniem przed podjúciem decyzji o zakupie drogiego sprzútu. Sam proces testowania moľe zajæè nawet kilka tygodni. Obejmuje to takľe czas potrzebny na dostarczenie sprzútu, jego montaľ, a nastúpnie instalacjú systemów operacyjnych przed przystæpieniem do testowania. W ħrodowiskach przetwarzania w chmurze zasoby sæ dostúpne na ľædanie, bez koniecznoħci ponoszenia poczætkowych wysokich kosztów zwiæzanych z zakupem sprzútu. Wspomniane ħrodowiska jednak wymagajæ pewnych inwestycji podczas wyboru uľywanego júzyka programowania aplikacji, bazy danych, serwera WWW i sposobu równowaľenia obciæľenia. Po dokonaniu wyboru niektórych z wymienionych komponentów ich póļniejsza zmiana moľe byè trudna. Przeprowadzenie testów wydajnoħci umoľliwia sprawdzenie, jak wybrane rozwiæzanie búdzie skalowane, gdy zajdzie potrzeba. Model przetwarzania w chmurze równieľ uđatwia testy wydajnoħci: ħrodowiska o ogromnej skali mogæ byè tworzone w ciægu minut, wykorzystane do przeprowadzenia testów wydajnoħci, a nastúpnie usuniúte. To wszystko odbywa siú stosunkowo mađym kosztem.

12.1.2. Efektywne testy wydajności To moľe byè zaskakujæce, ale wđaħciwe przeprowadzenie testów wydajnoħci jest trudne, poniewaľ istnieje wiele moľliwoħci popeđnienia bđúdów i przeoczenia pewnych kwestii. Poniľsze podsumowanie pochodzi z ksiæľki A Nine Year Study of File System and Storage Benchmarking (patrz odwođanie [Traeger 08] na koēcu rozdziađu): Przeanalizowaliħmy 415 testów wydajnoħci systemów plików i pamiúci masowej ze 106 ostatnio wydanych pozycji. Odkryliħmy, ľe wiúkszoħè popularnych testów wydajnoħci jest nieprawidđowa, a wielu autorów nie dostarcza jasnych informacji dotyczæcych rzeczywistej wydajnoħci.

W wymienionej ksiæľce znalazđy siú rekomendacje, co powinno byè zrobione. Autorzy testów wydajnoħci powinni w szczególnoħci dokđadnie wyjaħniè, co byđo testowane i dlaczego, a takľe przeprowadziè analizú oczekiwanego zachowania systemu. Esencja dobrego testu wydajnoħci zostađa podsumowana w pozycji wymienionej w odwođaniu [Smaalders 06] na koēcu rozdziađu:  









Moľliwy do powtórzenia. To ma umoľliwiè porównania. Moľliwy do monitorowania. Dziúki temu búdzie moľna przeanalizowaè wydajnoħè. Przenoħny. Pozwala na przeprowadzanie testów wydajnoħci róľnych produktów. Đatwy do prezentacji. Wyniki testu wydajnoħci powinny byè zrozumiađe dla kaľdego. Rzeczywisty. Przeprowadzone pomiary majæ odzwierciedlaè rzeczywiste wraľenia klienta. Moľliwy do przeprowadzenia. Programiħci powinni mieè moľliwoħè szybkiego testowania wprowadzanych zmian.

652

Rozdział 12



Testy wydajności

Inna cecha charakterystyczna musi byè uwzglúdniona podczas porównywania róľnych systemów w celu dokonania zakupu: wspóđczynnik cena/wydajnoħè. Cenú moľna okreħliè jako piúcioletni koszt kapitađu danego wyposaľenia (patrz odwođanie [Anon 85] na koēcu rozdziađu). Efektywne testy wydajnoħci to równieľ sposób ich stosowania: analiza i wyciægniúte wnioski.

Analiza testu wydajności Podczas przeprowadzania testu wydajnoħci konieczne jest okreħlenie: 

co jest testowane,



jakie wystúpujæ czynniki ograniczajæce,



czy jakiekolwiek perturbacje mogæ mieè wpđyw na wyniki,



jakie wnioski moľna wyciægnæè na podstawie otrzymanych wyników.

Dlatego teľ niezbúdne jest poznanie sposobu dziađania oprogramowania przeznaczonego do przeprowadzania testów wydajnoħci oraz reakcji systemu, jak równieľ umiejútnoħè powiæzania otrzymanych wyników z docelowym ħrodowiskiem. Majæc narzúdzie przeznaczone do wykonywania testów wydajnoħci i system, w którym búdæ one uruchamiane, moľna przeprowadziè analizú wydajnoħci systemu podczas wykonywania testów wydajnoħci, co búdzie najlepszym rozwiæzaniem. Doħè czústo popeđnianym bđúdem jest zlecanie wykonania testów wydajnoħci personelowi o mniejszym doħwiadczeniu, a nastúpnie zlecanie ekspertom wyjaħnienia otrzymanych wyników. O wiele lepszym podejħciem búdzie zaangaľowanie ekspertów juľ na etapie przeprowadzania testów wydajnoħci, aby mogli oni analizowaè system w trakcie ich wykonywania. Moľe to obejmowaè analizú dræľæcæ w celu wyjaħnienia i oceny czynnika ograniczajæcego wydajnoħè. Poniľej przedstawiono interesujæcy przykđad analizy: Jako eksperyment podczas analizy wydajnoħci otrzymanej implementacji TCP/IP przeprowadziliħmy transmisjú 4 MB danych miúdzy dwoma procesami uľytkownika w róľnych komputerach. Transfer zostađ podzielony na rekordy o wielkoħci 1024 bajtów hermetyzowane w pakietach Ethernet o wielkoħci 1068 bajtów. Wysđanie danych z 11/750 do 11/780 przez protokóđ TCP/IP zabrađo 28 sekund. Ten czas obejmuje cađoħè transmisji đæcznie z nawiæzaniem i zerwaniem pođæczenia, przepustowoħè wynosi 1,2 megaboda. W tym czasie procesor w 11/750 zostađ nasycony, podczas gdy w 11/780 byđ bezczynny przez 30% czasu. Czas poħwiúcony przez system na przetworzenie danych zostađ rozđoľony miúdzy obsđugú sieci Ethernet (30%), przetwarzanie pakietów IP (10%), przetwarzanie TCP (30%), sprawdzanie sum kontrolnych (25%) i obsđugú wywođaē systemowych uľytkownika (15%). Ľadne z wymienionych dziađaē nie zabrađo znacznie wiúkszej iloħci czasu niľ pozostađe.

W opisie znajdujæ siú informacje o czynnikach ograniczajæcych („procesor w 11/750 zostađ nasycony”1), a nastúpnie przedstawione sæ komponenty jædra odpowiedzialne za ograniczenie. Przy okazji warto tutaj dodaè, ľe przeprowadzanie tego rodzaju analizy 1

11/750 to skrót od VAX-11/750, czyli minikomputera opracowanego przez DEC w 1980 roku.

12.1. Wprowadzenie

653

i eleganckie podsumowanie czasu jædra sæ obecnie nietypowymi umiejútnoħciami, nawet pomimo istnienia zaawansowanych narzúdzi, takich jak DTrace. Autorem przedstawionej analizy jest Bill Joy, a pochodzi ona z czasów, gdy Bill pracowađ nad oryginalnym stosem TCP/IP dla BSD w 1981 roku! (Patrz odwođanie [1] na koēcu rozdziađu). Pomijajæc uľycie danego narzúdzia do testów wydajnoħci, znacznie efektywniejsze moľe okazaè siú opracowanie wđasnego oprogramowania przeznaczonego do przeprowadzania testów wydajnoħci lub co najmniej opracowanie wđasnych generatorów obciæľenia. To mogæ byè niewielkie programy koncentrujæce siú na tych aspektach, które musisz przetestowaè. Dziúki temu búdziesz je mógđ szybko wykorzystaè do analizy i debugowania. W pewnych sytuacjach nie búdziesz miađ dostúpu do narzúdzia testów wydajnoħci lub systemu, a jedynie moľliwoħè odczytania wyników testów wydajnoħci przeprowadzonych przez innych. Wówczas na podstawie dostúpnych materiađów rozwaľ poprzednie elementy i zadaj sobie nastúpujæce pytania: Jak wyglæda ħrodowisko systemu? Jak zostađo skonfigurowane? Te pytania moľesz równieľ zadaè producentowi produktu. Wiúcej przykđadowych pytaē do producentów produktów znajdziesz w podrozdziale 12.4 „Pytania dotyczæce testu wydajnoħci”.

12.1.3. Grzechy testów wydajności W dalszej czúħci znajdziesz informacje w postaci listy wskazujæcej problemy, których naleľy unikaè, a takľe sposoby ich unikniúcia. Metody przeprowadzania testów wydajnoħci zostađy omówione w podrozdziale 12.3, zatytuđowanym „Metodologia”.

Przypadkowe testy wydajności Prawidđowe przeprowadzenie testu wydajnoħci to nie jest zadanie typu „uruchom i zapomnij”. Narzúdzia testów wydajnoħci generujæ wartoħci liczbowe, ale one niekoniecznie odzwierciedlajæ to, co Ci siú wydaje. Dlatego teľ wnioski, które wyciægniesz na ich podstawie, mogæ byè nieprawidđowe. Przypadkowy test wydajnoħci: sædzisz, ľe sprawdzasz wydajnoħè komponentu A, w rzeczywistoħci dokonujesz pomiaru komponentu B, a wyciægasz wniosek dotyczæcy pomiaru komponentu C.

Testy wydajnoħci wymagajæ rygorystycznego sprawdzenia, co tak naprawdú zostađo zmierzone. Ponadto trzeba dokđadnie poznaè, co jest mierzone, aby móc wyciægnæè prawidđowe wnioski. Na przykđad wiele narzúdzi próbuje wskazaè pomiar wydajnoħci dysku lub wskazuje na ten pomiar, podczas gdy tak naprawdú sprawdzana jest wydajnoħè systemu plików. Róľnica miúdzy wydajnoħciæ dysku i systemu plików moľe byè kolosalna, poniewaľ systemy plików stosujæ buforowanie w celu zastæpienia dyskowych operacji wejħcia-wyjħcia operacjami z pamiúci. Nawet jeħli narzúdzie testów wydajnoħci dziađa prawidđowo i przeprowadza test systemu plików, wyciægniúte przez Ciebie wnioski dotyczæce dysków mogæ byè cađkowicie nieprawidđowe. Dokđadne poznanie sposobu przeprowadzania testu wydajnoħci jest szczególnie trudne dla osoby poczætkujæcej, która nie ma jeszcze instynktu pozwalajæcego na wyđapanie

654

Rozdział 12



Testy wydajności

podejrzanych wartoħci. Jeľeli kupisz termometr pokazujæcy temperaturú 100°C w pokoju, wówczas búdziesz wiedziađ, ľe dziađa on nieprawidđowo. Niestety nie búdzie to takie proste w przypadku testów wydajnoħci, jeħli otrzymane wartoħci nic Ci nie powiedzæ.

Zbyt duża wiara w testy wydajności Kuszæce moľe byè przyjúcie zađoľenia, ľe popularne narzúdzie przeznaczone do przeprowadzania testów wydajnoħci jest warte zaufania, zwđaszcza jeħli jest rozpowszechniane jako oprogramowanie typu open source i obecne na rynku od dđuľszego czasu. Bđúdne uznanie popularnoħci za gwarancjú prawidđowego dziađania to logika noszæca đaciēskæ nazwú argumentum ad populum (pol. argument odwođujæcy siú do upodobaē ludu). Prawidđowa analiza przeprowadzanych testów wydajnoħci jest zadaniem czasochđonnym i wymagajæcym duľej wiedzy. W przypadku popularnych testów wydajnoħci analiza ich wyników moľe wydawaè siú zbúdna z powodu przekonania, ľe na pewno muszæ byè one prawidđowe. Problem niekoniecznie musi byè zwiæzany z oprogramowaniem testów wydajnoħci — bđúdy jednak siú zdarzajæ — ale raczej z interpretacjæ otrzymanych wyników.

Wartości bez analizy Same wyniki testów wydajnoħci bez ľadnej analizy mogæ byè sygnađem, ľe przeprowadzajæca je osoba nie posiada doħwiadczenia. Tego rodzaju osoba najczúħciej przyjmuje zađoľenie, ľe wyniki sæ godne zaufania i ostateczne. Bardzo czústo to dopiero poczætek analizy, a osoba analizujæca wyniki po prostu siú pomyliđa. Kaľda wartoħè uzyskana podczas testu wydajnoħci powinna byè opisana, naleľy wskazaè napotkane ograniczenie i przeprowadziè analizú. Ryzyko mógđbym podsumowaè nastúpujæco: Jeľeli na studiowanie wyników testu wydajnoħci poħwiúciđeħ mniej niľ tydzieē, prawdopodobnie popeđniđeħ bđæd.

Wiúksza czúħè niniejszej ksiæľki koncentruje siú na analizie wydajnoħci, któræ naleľy przeprowadzaè podczas testów wydajnoħci. Gdy nie masz wystarczajæcej iloħci czasu na dokđadnæ analizú, dobrym rozwiæzaniem jest przygotowanie listy przyjútych zađoľeē, które nie zostađy sprawdzone z braku czasu. Tú listú trzeba dođæczyè do wyników, na przykđad: 







Przyjúto zađoľenie, ľe narzúdzie przeznaczone do przeprowadzania testów wydajnoħci nie zawiera zbyt wielu bđúdów. Przyjúto zađoľenie, ľe test dyskowych operacji wejħcia-wyjħcia naprawdú mierzy dyskowe operacje wejħcia-wyjħcia. Przyjúto zađoľenie, ľe narzúdzie przeznaczone do przeprowadzania testów wydajnoħci zgodnie z zađoľeniami wykorzystađo dysk do maksimum jego moľliwoħci. Przyjúto zađoľenie, ľe dyskowe operacje wejħcia-wyjħcia sæ odpowiednie dla danej aplikacji.

12.1. Wprowadzenie

655

Zađoľenia mogæ mieè postaè listy rzeczy do zrobienia, o ile otrzymane póļniej wyniki testu wydajnoħci búdæ wystarczajæco waľne, aby uzasadniè wiúkszy wysiđek wđoľony w opracowanie listy.

Skomplikowane narzędzia testów wydajności Bardzo waľne jest, aby narzúdzie testów wydajnoħci nie uniemoľliwiađo przeprowadzenia analizy otrzymanych wyników na skutek jego poziomu skomplikowania. Najlepiej jeħli program búdzie typu open source, co pozwoli na przestudiowanie jego kodu ļródđowego, a takľe wystarczajæco krótki, aby moľna byđo szybko siú z nim zapoznaè. W przypadku mikrotestów wydajnoħci zaleca siú wybór programów utworzonych w júzyku C. Do symulowania testów wydajnoħci klienta zaleca siú uľywanie tego samego júzyka programowania, w którym zostađ utworzony klient. Takie podejħcie minimalizuje róľnice. Doħè czústo popeđniany bđæd polega na przeprowadzaniu testu wydajnoħci samego testu, poniewaľ otrzymany wynik jest ograniczony przez samo oprogramowanie sđuľæce do wykonywania testów wydajnoħci. Skomplikowane narzúdzia testów wydajnoħci znacznie utrudniajæ identyfikacjú takiej sytuacji, co wynika z ogromnej iloħci kodu do poznania i analizy.

Testowanie nieprawidłowej rzeczy Wprawdzie istnieje wiele róľnych narzúdzi testów wydajnoħci przeznaczonych do testowania róľnorodnych obciæľeē, ale wiele z nich nie ma zwiæzku z aplikacjæ docelowæ. Najczúħciej popeđniany bđæd dotyczy testowania wydajnoħci dysku za pomocæ dostúpnych narzúdzi przeznaczonych do sprawdzania wydajnoħci dysku — nawet jeħli obciæľenie w ħrodowisku docelowym ma pochodziè cađkowicie z bufora systemu plików i nie ma zwiæzku z dyskowymi operacjami wejħcia-wyjħcia. Podobnie zespóđ programistów pracujæcych nad projektem moľe stosowaè okreħlone narzúdzie testów wydajnoħci i cađy czas przeznaczony na poprawú wydajnoħci poħwiúcaè na usprawnienie wydajnoħci mierzonej przez wspomniany test. Jeħli jednak nie odzwierciedla on faktycznego obciæľenia stosowanego przez klientów, dziađania zespođu majæce na celu optymalizacjú produktu zmierzajæ w zđym kierunku (patrz odwođanie [Smaalders 06] na koēcu rozdziađu). Test wydajnoħci mógđ kiedyħ mierzyè odpowiednie obciæľenie, ale jeħli nie byđ uaktualniany od lat, to obecnie na pewno testuje nieprawidđowæ rzecz. Artykuđ zatytuđowany Eulogy for a Benchmark opisuje, jak wersja testu przemysđowego SPEC SFS, powszechnie cytowanego na poczætku XXI wieku, byđa oparta na przeprowadzonej w 1986 roku analizie sposobu uľycia produktu przez klienta (patrz odwođanie [2] na koēcu rozdziađu).

Ignorowanie błędów Nawet jeħli narzúdzie testów wydajnoħci wygeneruje wynik, nie oznacza to, ľe dany wynik odzwierciedla test zakoēczony sukcesem. Niektóre lub nawet wszystkie ľædania mogđy zakoēczyè siú bđúdami. Wprawdzie wspomniany problem zostađ omówiony wczeħniej, ale ten konkretny jest tak czústo spotykany, ľe warto go zasygnalizowaè.

656

Rozdział 12



Testy wydajności

Przypomniađem sobie o tym podczas przeprowadzania ostatnio testu wydajnoħci serwera WWW. Osoba przeprowadzajæca test poinformowađa mnie, ľe ħrednie opóļnienie serwera WWW jest zbyt duľe jak na jej potrzeby, wyniosđo bowiem ponad jednæ sekundú (ħrednio). Szybka analiza umoľliwiđa wykrycie problemu: serwer WWW w ogóle nie brađ udziađu w teħcie, poniewaľ wszystkie ľædania zostađy zablokowane przez zaporú sieciowæ. Na opóļnienie wyħwietlane klientowi zđoľyđ siú czas utraty waľnoħci ľædania i czas wygenerowania bđúdu.

Ignorowanie odchyleń Narzúdzia testów wydajnoħci, zwđaszcza mikrotestów wydajnoħci, bardzo czústo stosujæ stađe i niezmienne obciæľenie oparte na ħredniej serii pomiarów rzeczywistych cech charakterystycznych, na przykđad róľnych czasów dnia lub wielkoħci przedziađu czasu. Przykđadowo obciæľenie dysku moľe byè okreħlone jako ħrednio 500 operacji odczytu na sekundú i 50 operacji zapisu na sekundú. Narzúdzie testów wydajnoħci moľe wiúc symulowaè obciæľenie w postaci podanej czústotliwoħci bædļ teľ zachowaè wspóđczynnik 10:1 dla operacji odczytu i zapisu, aby moľna byđo przetestowaè wiúkszæ iloħè operacji. Takie podejħcie ignoruje odchylenie: czústotliwoħè operacji moľe byè zmienna. Ponadto rodzaje operacji równieľ mogæ siú róľniè, a pewne mogæ wystúpowaè ortogonalnie. Na przykđad operacje zapisu mogæ pojawiaè siú w duľej iloħci co 10 sekund (asynchroniczny zapis na skutek opróľniania bufora), podczas gdy synchroniczne pojawiajæ siú równomiernie. Nagđy skok liczby operacji zapisu moľe powodowaè prawdziwe problemy w ħrodowisku produkcyjnym, na przykđad ze wzglúdu na kolejkowanie operacji odczytu. To jednak nie búdzie symulowane, jeħli test wydajnoħci opiera siú na wartoħci ħredniej.

Ignorowanie perturbacji Rozwaľ, jak zewnútrzne perturbacje mogæ wpđynæè na wyniki testu wydajnoħci. Czy pewna zaplanowana aktywnoħè systemu, na przykđad tworzenie kopii zapasowej, byđa wykonywana podczas przeprowadzania testów wydajnoħci? W przypadku chmury perturbacje mogæ byè spowodowane przez niewidoczne tenanty dziađajæce w tym samym systemie. Powszechnæ strategiæ w zakresie ignorowania perturbacji jest przeprowadzanie testu wydajnoħci przez dđuľszy czasu, czyli minuty zamiast sekund. Ogólnie rzecz bioræc, dđugoħè trwania testu wydajnoħci nie powinna byè krótsza niľ jedna sekunda. Krótsze testy mogæ byè zakđócane przez wystúpujæce przerwania urzædzeē (wstrzymanie wætku podczas wykonywania procedury obsđugi przerwania), decyzje jædra dotyczæce szeregowania w procesorze (wstrzymanie siú z migracjæ kolejkowanych wætków, aby zachowaè powiæzanie z procesorem) i efekt zwiæzany z rozgrzaniem pamiúci podrúcznej procesora. Warto wielokrotnie uruchomiè test wydajnoħci, a nastúpnie przeanalizowaè odchylenie standardowe. Powinno byè moľliwie jak najmniejsze, aby zapewniè powtarzalnoħè. Ponadto naleľy zbieraè dane, aby ewentualne perturbacje moľna byđo przeanalizowaè. Przykđadem moľe byè zbieranie danych o rozkđadzie opóļnienia operacji — a nie jedynie o cađkowitym czasie trwania testu wydajnoħci — co pozwala na wykrycie elementów odstajæcych i okreħlenie ich charakterystyki.

12.1. Wprowadzenie

657

Zmiana wielu czynników Podczas porównywania wyników testów wydajnoħci otrzymanych w dwóch oddzielnie przeprowadzonych testach trzeba zachowaè ostroľnoħè i poznaè wszystkie czynniki, jakimi wspomniane testy sæ róľniđy. Na przykđad jeħli dwa komputery byđy sprawdzane przez sieè, wówczas powstaje pytanie, czy sieè miúdzy nimi jest identyczna. Co w sytuacji, gdy na drodze do jednego z komputerów znajduje siú wiúcej przeskoków, sieè jest wolniejsza lub bardziej obciæľona? Wspomniane czynniki dodatkowe mogæ spowodowaè, ľe wyniki testu wydajnoħci okaľæ siú nieprawidđowe. W przypadku ħrodowiska chmury testy wydajnoħci sæ czasami przeprowadzane w wyniku utworzenia egzemplarzy, przetestowania ich, a nastúpnie usuniúcia. W ten sposób powstaje pole dla wielu niewidocznych czynników, takich jak moľliwoħè utworzenia egzemplarzy w szybszych lub wolniejszych komputerach, w systemach o wiúkszym lub mniejszym poziomie rywalizacji miúdzy tenantami. Dobrym rozwiæzaniem búdzie przetestowanie wielu egzemplarzy i obliczenie wartoħci ħredniej lub (jeszcze lepiej) przygotowanie rozkđadu. Dziúki temu moľna uniknæè elementów odstajæcych spowodowanych na skutek przeprowadzenia testu w znacznie szybszym lub wolniejszym systemie.

Test wydajności produktu konkurencji Departament marketingu búdzie chciađ otrzymaè wyniki testów wydajnoħci pokazujæce, ľe produkt firmy bije na gđowú produkty konkurencyjne. To najczúħciej zđy pomysđ z powodów, które zamierzam teraz wyjaħniè. Kiedy klient wybiera produkt, robi to z zamiarem uľywania go nie przez kilka minut, ale przez kilka miesiúcy. W tym czasie przeprowadzi analizú i dostroi produkt pod wzglúdem wydajnoħci, prawdopodobnie zmagajæc siú z najgorszymi problemami w ciægu pierwszych kilku tygodni. Nie masz kilku tygodni, które trzeba poħwiúciè na analizú i dostrajanie produktu konkurencji. W dostúpnym czasie moľesz jedynie zebraè niedostrojone — a tym samym nierzeczywiste — wyniki. Klienci, który zakupili produkt Twojego konkurenta — docelowy dla danych dziađaē marketingowych — mogæ doskonale wiedzieè, ľe zamieszczone wyniki dotyczæ niedostrojonego produktu. Twoja firma traci wiúc wiarygodnoħè w oczach osób, które próbowađa zachwyciè. Jeľeli juľ koniecznie musisz przeprowadziè test wydajnoħci produktu konkurencji, to powinieneħ poħwiúciè duľo czasu na jego dostrojenie. Przeanalizuj wydajnoħè za pomocæ technik omówionych we wczeħniejszych rozdziađach. Wyszukaj ponadto informacje o najlepszych praktykach, przejrzyj fora klientów i bazy danych ze zgđoszeniami bđúdów. Podczas dostrajania produktu byè moľe búdziesz musiađ nawet skorzystaè z pomocy zewnútrznego eksperta. Nastúpnie, przed przeprowadzeniem porównawczych testów wydajnoħci, powtórz te same czynnoħci dla produktu oferowanego przez Twojæ firmú.

Przyjacielski ogień Podczas przeprowadzania testów wydajnoħci wđasnych produktów dođóľ wszelkich staraē, aby zagwarantowaè, ľe przetestowany zostađ system i konfiguracja o najlepszej wydajnoħci oraz ľe osiægniúto rzeczywiste granice ich moľliwoħci. Przed publikacjæ

658

Rozdział 12



Testy wydajności

wyników naleľy przedstawiè je inľynierom odpowiedzialnym za przygotowanie produktu, poniewaľ mogæ wychwyciè elementy konfiguracji, które przeoczyđeħ. Jeľeli jesteħ czđonkiem zespođu inľynierów, zwracaj uwagú na testy wydajnoħci przeprowadzane zarówno przez pracowników Twojej firmy, jak i firm trzecich oraz pomóľ im w analizie. Rozwaľ nastúpujæcæ, hipotetycznæ sytuacjú. Zespóđ inľynierów ciúľko pracuje nad produktem o wysokiej wydajnoħci dziađania. Kluczem wysokiej wydajnoħci jest nowa technologia, opracowana, choè pozbawiona dokumentacji. Przed wydaniem produktu zespóđ przeprowadzajæcy testy wydajnoħci zostađ poproszony o dostarczenie wyników. Poniewaľ czđonkowie zespođu nie znajæ nowej technologii (brak dokumentacji), to bđúdnie skonfigurowali produkt, tak ľe otrzymane wyniki sæ niľsze niľ rzeczywista wydajnoħè produktu. Czasami zdarza siú, ľe system jest skonfigurowany poprawnie, ale tak naprawdú nie zostađ wykorzystany do granic swoich moľliwoħci. Zadaj sobie pytanie: co jest wæskim gardđem w danym teħcie wydajnoħci? To mogæ byè: zasób fizyczny, na przykđad procesor, dyski lub magistrala wykorzystane w 100% — tego rodzaju sytuacjú moľna zidentyfikowaè za pomocæ analizy. Zapoznaj siú z punktem 12.3.2, noszæcym tytuđ „Aktywne testy wydajnoħci”. Z innæ postaciæ przyjacielskiego ognia mamy do czynienia, gdy test wydajnoħci dotyczy starszej wersji oprogramowania zawierajæcej bđúdy zwiæzane z wydajnoħciæ, które zostađy usuniúte w póļniejszych wydaniach. Kolejna przyczyna to ograniczenia dostúpnego sprzútu, w wyniku czego otrzymane wyniki nie sæ najlepsze z moľliwych (a takich wđaħnie, najlepszych wyników moľna by oczekiwaè po testach wydajnoħci przeprowadzonych przez firmú).

Mylące testy wydajności Mylæce testy wydajnoħci sæ niestety doħè czústo spotykane w biznesie. Zwykle to skutek niezamierzonego braku wystarczajæcej iloħci informacji o sposobie dziađania danego testu wydajnoħci i wykonywanych przez niego pomiarach lub teľ skutek celowego pominiúcia pewnych informacji. Czústo zdarza siú równieľ, ľe wynik jest prawidđowy pod wzglúdem technicznym, ale bđúdnie interpretowany przez klienta. Rozwaľ nastúpujæcæ hipotetycznæ sytuacjú. Producent uzyskuje fantastyczny wynik dziúki zbudowaniu wđasnego produktu, który jest niezwykle drogi i prawdopodobnie nigdy nie zostanie sprzedany ľadnemu rzeczywistemu klientowi. Cena nie jest podana w wynikach testu wydajnoħci, nacisk pođoľono na metryki inne niľ cena/wydajnoħè. Dziađ marketingu z dumæ ogđasza niejednoznaczne podsumowanie wyniku („Jesteħmy dwukrotnie szybsi!”), co klienci tđumaczæ sobie jako slogan ogólnie dotyczæcy firmy lub cađej linii produktu. To jest przykđad pominiúcia pewnych informacji szczegóđowych w celu przedstawienia produktu w korzystniejszym ħwietle. Wprawdzie tego nie moľna uznaè za oszustwo — otrzymane wyniki sæ prawdziwe — ale jest to na pewno kđamstwo na skutek pominiúcia istotnych informacji. Tego rodzaju testy wydajnoħci nadal mogæ byè uľyteczne, gdy chcesz okreħliè górne granice wydajnoħci. To wartoħci, których przekroczenia nie powinieneħ oczekiwaè (chyba ľe z wyjætkiem przyjaznego ognia). Rozwaľ nastúpujæcæ hipotetycznæ sytuacjú. Departament marketingu posiada budľet na kolejnæ kampaniú reklamowæ i chce otrzymaè dobre wyniki testów wydajnoħci, które mogđyby zostaè wykorzystane. Wynajmuje kilka firm trzecich do przeprowadzenia testów

12.1. Wprowadzenie

659

wydajnoħci produktu, a nastúpnie wybiera najlepszy wynik z grupy. Firmy trzecie nie zostađy wybrane ze wzglúdu na doħwiadczenie, ale pod kætem moľliwoħci dostarczenia szybkiego i taniego wyniku. W rzeczywistoħci brak doħwiadczenia moľe byè uznany za zaletú: im bardziej wynik búdzie odstawađ od rzeczywistoħci, tym lepiej. W idealnej sytuacji jeden z nich búdzie znacznie odstawađ od pozostađych, oczywiħcie w pozytywnym tego sđowa znaczeniu. Korzystajæc z wyników dostarczanych przez producenta, dokđadnie sprawdļ (przedstawione zwykle czcionkæ o bardzo mađej wielkoħci) informacje o testowanym sprzúcie, rodzaju i liczbie dysków, uľytych interfejsach sieciowych, konfiguracji oraz o innych czynnikach. W przypadku interesujæcej Ciú specyfikacji zajrzyj do podrozdziađu 12.4 „Pytania dotyczæce testu wydajnoħci”.

Specjalne testy wydajności Rodzajem podstúpnej dziađalnoħci — w oczach innych uznawanej za grzech, a tym samym zabronionej — jest opracowanie specjalnych testów wydajnoħci. Tego rodzaju sytuacja ma miejsce, gdy producent analizuje popularne lub stosowane w biznesie testy wydajnoħci, a nastúpnie tworzy produkt w taki sposób, aby uzyskađ jak najlepszy wynik w teħcie, i nie zwraca uwagi na rzeczywistæ wydajnoħè produktu u klientów. Takie dziađanie okreħlane jest równieľ jako optymalizacja pod kætem testu wydajnoħci. Specjalne testy wydajnoħci stađy siú znane w 1993 roku wraz z testem TPC-A, co zostađo opisane na stronie TPC (ang. Transaction Processing Performance) — patrz odwođanie [3] na koēcu rozdziađu: Dziađajæca w stanie Massachusetts firma konsultingowa The Standish Group oskarľyđa firmú Oracle, ľe w oferowanym przez niæ oprogramowaniu bazy danych umieħciđa opcjú specjalnæ (oddzielne transakcje) wyđæcznie w celu zwiúkszenia wyniku Oracle w teħcie TPC-A. Firma konsultingowa The Standish Group utrzymywađa, ľe firma Oracle „zđamađa ducha testu TPC”, poniewaľ wspomniana opcja oddzielnych transakcji nie jest uľywana przez typowego klienta, a tym samym zostađa wprowadzona jedynie ze wzglúdu na chúè uzyskania lepszego wyniku w teħcie wydajnoħci. Oracle odrzuciđo oskarľenia, twierdzæc (nie bez racji), ľe nie zđamađo prawa i dokđadnie zastosowađo siú do specyfikacji testu wydajnoħci. Firma Oracle stwierdziđa, ľe poniewaľ w specyfikacji testu wydajnoħci TPC nie byđo ani sđowa o specjalnych testach wydajnoħci, to oskarľanie jej o zđamanie czegokolwiek jest niesprawiedliwe.

Firma TCP dodađa klauzulú skierowanæ przeciw specjalnym testom wydajnoħci: Wszystkie implementacje „specjalnych testów wydajnoħci” majæce na celu poprawú wyniku uzyskiwanego w teħcie wydajnoħci, a nie rzeczywistej wydajnoħci lub polityki cenowej, sæ zabronione.

Test wydajnoħci TPC jest skoncentrowany na wspóđczynniku cena/wydajnoħè. Innym sposobem poprawy wyniku byđo zastosowanie cen specjalnych, czyli duľych zniľek, których tak naprawdú klienci nigdy nie dostawali. Podobnie jak w przypadku zmian wprowadzanych w oprogramowaniu, otrzymany wynik testu wydajnoħci nie odpowiadađ rzeczywistoħci, a wiúc sytuacji, gdy klient chciađ kupiè system. Firma TPC zajúđa siú i tym aspektem, umieszczajæc wymagania dotyczæce ceny (patrz odwođanie [4] na koēcu rozdziađu):

660

Rozdział 12



Testy wydajności

Specyfikacja TPC wymaga, aby cena cađkowita nie mogđa róľniè siú wiúcej niľ o 2% od ceny, któræ klient musi zapđaciè za danæ konfiguracjú

Wprawdzie omówione przykđady mogæ pomóc w przedstawieniu zagadnienia specjalnych testów wydajnoħci, ale firma TPC zajúđa siú nimi wiele lat temu, wprowadziđa odpowiednie zmiany w specyfikacji, a wiúc specjalne testy wydajnoħci nie powinny obecnie stanowiè juľ problemu.

Oszustwa Ostatnim grzechem testów wydajnoħci sæ oszustwa, czyli podawanie nieprawdziwych wyników. Na szczúħcie takie sytuacje zdarzajæ siú bardzo rzadko lub prawie wcale. Nie spotkađem siú z celowym podawaniem nieprawdziwych wyników, nawet w najbardziej krwawych bitwach na testy wydajnoħci.

12.2. Rodzaje testów wydajności Cađe spektrum rodzajów testów wydajnoħci pokazano na rysunku 12.1 na bazie testowanego obciæľenia. W tym spektrum ujúte zostađo równieľ obciæľenie produkcyjne.

Rysunek 12.1. Rodzaje testów wydajności

W kolejnych punktach znajdziesz omówienie trzech rodzajów testów wydajnoħci: mikrotestów wydajnoħci, symulacji i monitorowania/powtórzeē. Poruszony búdzie równieľ temat testów wydajnoħci w biznesie.

12.2.1. Mikrotesty wydajności Mikrotesty wydajnoħci uľywajæ sztucznego obciæľenia w celu przetestowania okreħlonego typu operacji, na przykđad przeprowadzajæ jeden rodzaj operacji wejħcia-wyjħcia w systemie plików, zapytania do bazy danych, instrukcji procesora lub wywođania systemowego. Zaletæ mikrotestów wydajnoħci jest ich prostota: zawúľenie liczby komponentów i ħcieľek kodu uđatwia analizú sprawdzanego komponentu i pozwala na szybkie odkrycie róľniè w wydajnoħci. Tego rodzaju testy sæ zwykle powtarzalne, poniewaľ odchylenie wzglúdem innych komponentów jest maksymalnie wykluczone. Mikrotesty wydajnoħci moľna zwykle szybko przeprowadziè w róľnych systemach. Poniewaľ sæ niewætpliwie sztuczne, nie moľna ich đatwo pomyliè z symulacjami rzeczywistego obciæľenia. Aby wykorzystaè wyniki mikrotestów wydajnoħci, konieczne jest ich mapowanie na obciæľenie docelowe. Mikrotest wydajnoħci moľe przetestowaè wiele wymiarów, ale tylko jeden lub dwa búdæ miađy znaczenie. Analiza wydajnoħci lub modelowanie systemu docelowego mogæ pomóc w ustaleniu, które wyniki mikrotestów wydajnoħci sæ odpowiednie i do jakiego stopnia.

12.2. Rodzaje testów wydajności

661

Przykđady narzúdzi sđuľæcych do mikrotestów wydajnoħci wymieniono w poprzednich rozdziađach — narzúdzia zostađy podzielone wedđug rodzaju zasobu: 

procesor — UnixBench, SysBench,



operacje wejħcia-wyjħcia pamiúci — lmbench (w rozdziale 6. „Procesory”),



system plików — Bonnie, Bonnie++, SysBench, fio,



dysk — hdparm,



sieè — iperf.

Oczywiħcie istnieje znacznie wiúcej dostúpnych narzúdzi przeznaczonych do przeprowadzania testów wydajnoħci. Pamiútaj jednak o ostrzeľeniu (patrz odwođanie [Traeger 08] na koēcu rozdziađu): „Wiúkszoħè popularnych testów wydajnoħci jest wadliwa”. Moľesz równieľ opracowaè wđasne testy wydajnoħci. Postaraj siú zachowaè ich maksymalnæ prostotú i zidentyfikuj atrybuty obciæľenia, które moľna przetestowaè oddzielnie. (Wiúcej informacji na ten temat znajdziesz w punkcie 12.3.6 w dalszej czúħci rozdziađu).

Przykład projektu Przyjmujemy zađoľenie o tworzeniu mikrotestu wydajnoħci dla systemu plików. Mikrotest ten przeznaczony jest do przetestowania nastúpujæcych atrybutów: sekwencyjnych i losowych operacji wejħcia-wyjħcia, wielkoħci operacji wejħcia-wyjħcia, a takľe kierunku operacji (odczyt, zapis). W tabeli 12.1 wymieniono piúè przykđadowych próbek testów pozwalajæcych na przetestowanie wspomnianych atrybutów. W tabeli podano takľe przyczyny przeprowadzenia poszczególnych testów. Tabela 12.1. Przykładowy mikrotest wydajności systemu plików Lp.

Test

Przyczyna testu

1

sekwencyjne odczyty o wielkości 512 B

sprawdzenie maksymalnej (rzeczywistej) wartości IOPS

2

sekwencyjne odczyty o wielkości 128 KB

sprawdzenie maksymalnej przepustowości odczytu

3

sekwencyjne zapisy o wielkości 128 KB

sprawdzenie maksymalnej przepustowości zapisu

4

losowe odczyty o wielkości 512 B

sprawdzenie efektu losowych operacji wejścia-wyjścia

5

losowe zapisy o wielkości 512 B

sprawdzenie efektu operacji ponownego zapisu

Moľna dodaè wiúkszæ liczbú testów, jeħli zachodzi potrzeba. Wszystkie testy trzeba pomnoľyè przez dwa wymienione czynniki: 

Wielkoħè zbioru roboczego. Wielkoħè danych, do których test uzyskuje dostúp (na przykđad cađkowita wielkoħè pliku): 

Duľo mniejsza niľ iloħè pamiúci operacyjnej — dane sæ cađkowicie buforowane przez system plików, co pozwala na przeanalizowanie wydajnoħci oprogramowania systemu plików.

662

Rozdział 12







Testy wydajności

Duľo wiúksza niľ iloħè pamiúci operacyjnej — w celu minimalizacji efektu stosowania buforowania przez system plików i przetestowania dyskowych operacji wejħcia-wyjħcia.

Liczba wætków. Przyjmujemy zađoľenie, ľe zbiór roboczy jest mađy: 



Pojedynczy wætek umoľliwia przetestowanie wydajnoħci systemu plików na podstawie aktualnej czústotliwoħci zegara procesora. Wiele wætków wystarczy do nasycenia wszystkich procesorów i pozwala na przetestowanie maksymalnej wydajnoħci systemu — systemu plików i procesorów.

Bardzo szybko cađoħè moľe staè siú ogromnæ macierzæ testów. Istniejæ pewne techniki analizy statystycznej umoľliwiajæce zmniejszenie wymaganej liczby testów. Testy wydajnoħci koncentrujæce siú na maksymalnej szybkoħci noszæ nazwú testów wydajnoħci sđonecznego dnia. Aby problemy nie zostađy przeoczone, konieczne jest równieľ przeprowadzenie testów wydajnoħci pochmurnego dnia, które obejmujæ nieidealne sytuacje, takie jak wystúpowanie rywalizacji, perturbacji i zmian w obciæľeniu.

12.2.2. Symulacja Wiele testów wydajnoħci symuluje obciæľenie aplikacji klienta (czasami sæ nazywane makrotestami wydajnoħci). Mogæ siú opieraè na charakterystyce obciæľenia ħrodowiska produkcyjnego (patrz rozdziađ 2. „Metodologia”) w celu okreħlenia symulowanej charakterystyki. Na przykđad moľe siú okazaè, ľe obciæľenie produkcyjnego serwera NFS przedstawia siú nastúpujæco: 40% operacje odczytu, 7% operacje zapisu, 19% operacje getattr, 1% operacje readdir itd. Inne cechy charakterystyczne równieľ mogæ byè zmierzone i symulowane. Symulacja moľe dostarczyè wyników pokazujæcych, jak klienci radzæ sobie z rzeczywistym obciæľeniem. Byè moľe nie búdzie to wierne odzwierciedlenie, ale bliskie. W trakcie symulacji mogæ pojawiè siú pewne czynniki, których analiza za pomocæ mikrotestów wydajnoħci zajmie duľo czasu. Poza tym symulacje mogæ uwzglúdniaè efekt skomplikowanych interakcji systemu pomijanych podczas stosowania mikrotestów wydajnoħci. Wprowadzone w rozdziale 6. „Procesory” testy wydajnoħci Whetstone i Dhrystone dla procesora sæ przykđadami symulacji. Test Whetstone zostađ opracowany w 1972 roku i miađ na celu symulacjú obciæľenia naukowego w danej chwili. Z kolei test Dhrystone, opracowany w 1984 roku, symuluje obciæľenie oparte na liczbach cađkowitych. Wspomniany wczeħniej w tym rozdziale test wydajnoħci SPEC SFS to kolejna symulacja obciæľenia. Symulacja obciæľenia moľe byè bezstanowa — w takiej sytuacji ľadne ľædanie serwera nie jest powiæzane z poprzednim. Na przykđad wspomniane wczeħniej obciæľenie serwera NFS moľe byè symulowane za pomocæ ľædania serii operacji, przy czym kaľda z nich búdzie wybierana losowo na podstawie zmierzonego prawdopodobieēstwa. Symulacja moľe byè teľ stanowa — w takiej sytuacji kaľde ľædanie zaleľy od stanu klienta, czyli minimum od poprzedniego ľædania. Moľe siú okazaè, ľe operacje odczytu i zapisu serwera NFS pojawiajæ siú w grupach. Dlatego teľ gdy poprzedniæ operacjæ

12.2. Rodzaje testów wydajności

663

byđ zapis, wtedy prawdopodobieēstwo wystæpienia kolejnej operacji zapisu búdzie znacznie wiúksze niľ operacji odczytu. Tego rodzaju obciæľenie moľna znacznie lepiej symulowaè za pomocæ modelu Markowa przez przedstawienie ľædaē jako stanów i pomiar prawdopodobieēstwa zmiany stanu (patrz odwođanie [Jain 91] na koēcu rozdziađu). Problem z symulacjami polega na tym, ľe mogæ one ignorowaè odchylenie, jak to omówiono w punkcie 12.1.3 we wczeħniejszej czúħci rozdziađu. Wzorzec uľycia równieľ moľe ulec zmianie na przestrzeni czasu i wymagaè uaktualnienia symulacji oraz dostosowania do bieľæcej sytuacji. Tutaj moľe pojawiè siú opór, zwđaszcza jeħli opublikowane juľ wyniki sæ oparte na starszej wersji narzúdzia testów wydajnoħci i nie búdæ dđuľej uľyteczne podczas porównywania ich z wynikami wygenerowanymi przez nowæ wersjú.

12.2.3. Powtarzalność Trzeci rodzaj testów wydajnoħci obejmuje próbú uľycia dziennika zdarzeē do odtworzenia zdarzeē w systemie docelowym i przetestowanie jego wydajnoħci za pomocæ przechwyconych rzeczywistych operacji klienta. Takie rozwiæzanie moľe wydawaè siú idealne, prawie tak dobre jak testowanie w ħrodowisku produkcyjnym, prawda? Jest jednak problematyczne: gdy charakterystyka i opóļnienie dorúczenia ulegajæ zmianie w serwerze, istnieje znikome prawdopodobieēstwo, aby obciæľenie klienta w sposób naturalny odpowiadađo na wspomniane róľnice. Ostatecznie wiúc nie otrzymujemy nic lepszego poza symulowanym obciæľeniem klienta. Kiedy omawianemu rozwiæzaniu da siú zbyt duľæ wiarú, efekt koēcowy moľe byè gorszy od symulacji. Przeanalizujmy nastúpujæcæ hipotetycznæ sytuacjú. Klient rozwaľa uaktualnienie infrastruktury pamiúci masowej. Obecne obciæľenie produkcyjne jest monitorowane i zostaje zastosowane w nowym sprzúcie. Niestety, wydajnoħè okazuje siú gorsza, a przychody ze sprzedaľy oferowanych produktów spadajæ. Problem: dziennik zdarzeē operowađ na poziomie dyskowych operacji wejħcia-wyjħcia. W starym systemie zastosowano dyski obracajæce siú z szybkoħciæ 10 000 obrotów na minutú, natomiast w nowszym — wolniejsze, o szybkoħci 7200 obrotów na minutú. Jednak w nowym systemie znajduje siú szesnastokrotnie wiúkszy bufor systemu plików i szybsze procesory. Rzeczywiste obciæľenie produkcyjne zostađo poprawione, poniewaľ w wiúkszoħci przypadków jest obsđugiwane przez bufor — nie byđo to symulowane na skutek wczytania zdarzeē zapisanych w dzienniku. Wprawdzie jest to przypadek pokazujæcy przetestowanie niewđaħciwej rzeczy, ale inne elementy równieľ mogæ mieè wpđyw na cađoħè, nawet na odpowiedni poziom monitorowania i poziom powtarzalnoħci. Podobnie jak w przypadku wszystkich testów wydajnoħci, znaczenie krytyczne ma poznanie i przeanalizowanie sposobu dziađania testu.

12.2.4. Standardy biznesowe Biznesowe testy wydajnoħci sæ oferowane przez niezaleľne organizacje, których celem jest pomoc przy tworzeniu uczciwych i odpowiednich testów wydajnoħci. To najczúħciej zbiór róľnych mikrotestów wydajnoħci i symulatorów obciæľenia, doskonale zdefiniowanych i udokumentowanych. Muszæ byè wykonywane wedđug okreħlonych wskazówek, aby wyniki byđy zgodne z oczekiwaniami. Producenci (zwykle za opđatæ) mogæ uczestniczyè

664

Rozdział 12



Testy wydajności

w przygotowywaniu tego rodzaju standardów, co zapewnia im dostúp do oprogramowania umoľliwiajæcego przeprowadzanie testów wydajnoħci. Otrzymane wyniki zwykle wymagajæ podania peđnej konfiguracji ħrodowiska, aby moľliwe byđo przeprowadzenie audytu. Z perspektywy klienta wspomniane testy wydajnoħci pozwalajæ oszczúdziè duľæ iloħè czasu, poniewaľ wyniki testów mogæ byè juľ dostúpne dla wielu róľnych producentów i produktów. Zadaniem klienta jest wyszukanie testu wydajnoħci najdokđadniej odzwierciedlajæcego bieľæce obciæľenie produkcyjne. W przypadku bieľæcego obciæľenia moľna to ustaliè na podstawie charakterystyki obciæľenia. Koniecznoħè opracowania standardów biznesowych dla testów wydajnoħci stađa siú oczywista w 1985 roku, kiedy to zostađa przedstawiona w ksiæľce A Measure of Transaction Processing Power, napisanej przez Jima Graya i innych autorów (patrz odwođanie [Anon 85] na koēcu rozdziađu). W ksiæľce przedstawiono potrzebú pomiaru wspóđczynnika cena/wydajnoħè oraz dokđadnie omówiono trzy testy wydajnoħci, które mogæ byè wykonywane przez producentów. Wspomniane testy nosiđy nazwy: Sort, Scan i DebitCredit. Zasugerowano równieľ standard przemysđowy dla pomiaru liczby transakcji na sekundú (ang. Transactions Per Second, TPS), opartego na teħcie DebitCredit. Wartoħci TPS moľna uľywaè podobnie jak paliwa w liczbie litrów zuľywanej przez samochód podczas jazdy na odcinku stu kilometrów. Jim Gray i jego praca doprowadzili do powstania TPC (patrz odwođanie [DeWitt 08] na koēcu rozdziađu). Poza pomiarem wartoħci TPS do tego samego celu mogæ sđuľyè jeszcze inne pomiary: 



MIPS (ang. Millions of Instructions Per Second). Miliony instrukcji na sekundú — wprawdzie to jest pomiar wydajnoħci, ale wykonanie zadania zaleľy od typu instrukcji. Dlatego teľ za pomocæ otrzymanych wyników trudno jest porównaè róľne architektury procesorów. FLOPS (ang. Floating-Point Operations Per Second). Liczba operacji zmiennoprzecinkowych na sekundú — peđni podobnæ rolú jak MIPS, ale przeznaczony jest dla obciæľeē, w których intensywnie sæ uľywane obliczenia zmiennoprzecinkowe.

Biznesowe testy wydajnoħci zwykle tworzæ wđasne metryki na podstawie testów wydajnoħci, które sđuľæ jedynie do porównywania miúdzy sobæ.

TPC TPC tworzy róľne biznesowe testy wydajnoħci i administruje nimi, koncentrujæc siú na wydajnoħci baz danych. Oto dostúpne testy wydajnoħci: 





TPC-C. Symulacja peđnego ħrodowiska obliczeniowego, w którym populacja uľytkowników przeprowadza transakcje w bazie danych. TPC-DS. Symulacja systemu wspomagajæcego podejmowanie decyzji, obejmuje zapytania i obsđugú danych. TPC-E. Obciæľenie OLTP (ang. Online Transaction Processing), modeluje bazú danych firmy brokerskiej wraz z klientami, którzy generujæ transakcje powiæzane z gieđdæ, dotyczæce zapytaē ksiúgowych i rozpoznania rynku.

12.3. Metodologia





665

TPC-H. Test wydajnoħci dotyczæcy wspomagania podejmowania decyzji, symuluje zapytania ad hoc i wspóđbieľne modyfikacje danych. TPC-VMS. System The TPC Virtual Measurement Single System pozwala na zbieranie wyników innych testów wydajnoħci dla wirtualnych baz danych.

Wyniki TPC sæ dostúpne w internecie (patrz odwođanie [5] na koēcu rozdziađu) i zawierajæ wspóđczynnik cena/wydajnoħè.

SPEC Organizacja SPEC (ang. The Standard Performance Evaluation Corporation) opracowađa i opublikowađa zestaw standaryzowanych biznesowych testów wydajnoħci, miúdzy innymi: 







SPEC CPU2006. Pomiar obciæľenia zwiæzanego z obliczeniami. Obejmuje test CINT2006 sprawdzajæcy wydajnoħè liczb cađkowitych i test CFP2006 sprawdzajæcy wydajnoħè liczb zmiennoprzecinkowych. SPECjEnterprise2010. Pomiar wydajnoħci cađego systemu dla aplikacji serwera Java EE (Java Enterprise Edition) w wersji 5 lub nowszej, baz danych i wspomagajæcej je infrastruktury. SPECsfs2008. Symulacja obciæľenia w postaci klienta uzyskujæcego dostúp do plików w serwerach NFS i CIFS (patrz odwođanie [2] na koēcu rozdziađu). SPECvirt_sc2010. Przeznaczony dla ħrodowisk wirtualnych; test ten sprawdza wydajnoħè wirtualnego sprzútu, platformy, systemu operacyjnego goħcia i aplikacji.

Wyniki SPEC sæ dostúpne w internecie (patrz odwođanie [6] na koēcu rozdziađu) i dostarczajæ informacji szczegóđowych o sposobie dostrojenia systemu oraz listú komponentów. Najczúħciej nie zawierajæ informacji o cenie.

12.3. Metodologia W tym podrozdziale zostanæ przedstawione róľne metodologie i èwiczenia dotyczæce przeprowadzania testów wydajnoħci, niezaleľnie od ich rodzaju (mikrotesty wydajnoħci, symulacje, powtarzalnoħè). Poruszone tematy podsumowano w tabeli 12.2.

12.3.1. Pasywne testy wydajności To jest strategia „uruchom i zapomnij” podczas przeprowadzania testów wydajnoħci — po uruchomieniu testów sæ one ignorowane aľ do ukoēczenia. Gđównym celem jest zebranie danych testu wydajnoħci. To najczústszy sposób przeprowadzania testów wydajnoħci, opisany tutaj jako oddzielna metodologia w celu jej porównania z aktywnym wykonywaniem testów wydajnoħci. Poniľej wymieniono kroki wykonywane w trakcie przykđadowego pasywnego testu wydajnoħci:

666

Rozdział 12



Testy wydajności

Tabela 12.2. Metodologie analizy testów wydajności Metodologia

Opis

Pasywne testy wydajności

Analiza oparta na eksperymentach.

Aktywne testy wydajności

Analiza oparta na obserwacji.

Profilowanie procesora

Analiza oparta na obserwacji.

Metoda USE

Analiza oparta na obserwacji.

Charakterystyka obciążenia

Analiza oparta na obserwacji.

Własne testy wydajności

Tworzenie oprogramowania.

Stopniowa zmiana obciążenia

Analiza oparta na eksperymentach.

Sprawdzenie poprawności

Analiza oparta na obserwacji.

Analiza statystyczna

Analiza statystyczna.

1. Wybór narzúdzia przeznaczonego do przeprowadzania testów wydajnoħci. 2. Uruchomienie narzúdzia z róľnymi opcjami. 3. Przygotowanie slajdów z wynikami testu wydajnoħci. 4. Przedstawienie slajdów kierownictwu. Problemy zwiæzane z tego rodzaju podejħciem zostađy juľ wczeħniej wymienione. Podsumowujæc, otrzymane wyniki mogæ byè: 







nieprawidđowe ze wzglúdu na bđúdy w oprogramowaniu sđuľæcym do przeprowadzania testów wydajnoħci; ograniczone przez oprogramowanie testu wydajnoħci (na przykđad tylko jednowætkowe); ograniczone przez komponent niepowiæzany z celem testu wydajnoħci (na przykđad obciæľonæ sieè); ograniczone przez konfiguracjú (funkcje wydajnoħci nie zostađy wđæczone, konfiguracja nie jest maksymalna);



podatne na perturbacje (i niepowtarzalne);



przeprowadzajæce test wydajnoħci wzglúdem zupeđnie nieprawidđowej rzeczy.

Pasywne testy wydajnoħci sæ bardzo đatwe do przeprowadzenia, ale podatne na bđúdy. Kiedy sæ wykonywane przez producenta, skutkiem moľe byè wywođanie fađszywych alarmów marnujæcych zasoby inľynierów lub powodujæcych spadek sprzedaľy. Natomiast przeprowadzane przez klienta prowadzæ do kiepskiego wyboru produktu, co uderza w firmú nieco póļniej.

12.3. Metodologia

667

12.3.2. Aktywne testy wydajności W przypadku aktywnych testów wydajnoħci analizæ wydajnoħci zajmujesz siú podczas przeprowadzania testu, a nie po jego zakoēczeniu, i uľywasz do tego celu innych narzúdzi. Dziúki temu moľesz potwierdziè, ľe test wydajnoħci dziađa zgodnie z przeznaczeniem, a takľe dokđadnie poznaè sposób przeprowadzania testu. Aktywne testy wydajnoħci pozwalajæ ponadto zidentyfikowaè rzeczywiste czynniki ograniczajæce testowany system lub teľ sam test wydajnoħci. Podczas przekazywania wyników testu wydajnoħci bardzo pomocne búdzie dođæczenie informacji szczegóđowych o wykrytych czynnikach ograniczajæcych. Cennym dodatkiem moľe byè to, ľe aktywne testy wydajnoħci stanowiæ doskonađy czas na zdobycie umiejútnoħci w zakresie pracy z narzúdziami monitorowania. W teorii analizujesz znane obciæľenie i moľesz sprawdziè, w jaki sposób jest ono widziane z poziomu wspomnianych narzúdzi monitorowania. W idealnej sytuacji test wydajnoħci moľna skonfigurowaè do dziađania i pozostawiè go niezmiennie dziađajæcy, aby analizú przeprowadziè po pewnym czasie, po kilku godzinach lub dniach.

Przykład Jako na przykđad spójrzmy na pierwszy test w narzúdziu Bonnie++, sđuľæcym do przeprowadzania mikrotestów wydajnoħci. Przeznaczenie tego narzúdzia zostađo przedstawione na jego stronie gđównej (patrz odwođanie [7] na koēcu rozdziađu): Bonnie++ to zestaw testów wydajnoħci, których celem jest przeprowadzenie pewnej liczby prostych testów sprawdzajæcych wydajnoħè dysku twardego i systemu plików.

Pierwsze testy, o nazwach Sequential Output i Per Chr, zostađy przeprowadzone w dwóch róľnych systemach operacyjnych, co pozwoli nam na porównanie wyników. Fedora/Linux (za pomocæ wirtualizacji KVM): # bonnie++ [...] Version 1.03e

------Sequential Output------Per Chr- --Block-- -RewriteMachine Size K/sec %CP K/sec %CP K/sec %CP 9d219ce8-cf52-40 2G 52384 23 47334 3 31938 3 [...]

--Sequential Input- --Random-Per Chr- --Block-- --Seeks-K/sec %CP K/sec %CP /sec %CP 74866 67 1009669 61 +++++ +++

SmartOS/illumos (za pomocæ wirtualizacji systemu operacyjnego): # bonnie++ Version 1.03e

------Sequential Output------ --Sequential Input- --Random-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP smartos1.local 2G 162464 99 72027 86 65222 99 251249 99 2426619 99 +++++ +++ [...]

668

Rozdział 12



Testy wydajności

Jak moľesz siú przekonaè, system SmartOS jest ponad trzykrotnie szybszy. Jeľeli na tym zakoēczymy, to búdzie pasywny test wydajnoħci. Bioræc pod uwagú fakt, ľe Bonnie++ to test wydajnoħci dysku twardego i systemu plików, rozpoczynamy sprawdzenie obciæľenia zastosowanego podczas testu. Poniľej pokazano wynik uruchomienia polecenia iostat w systemie SmartOS w celu sprawdzenia dyskowych operacji wejħcia-wyjħcia: $ iostat -xnz 1 [...] r/s w/s r/s

w/s

r/s 0.0

w/s 668.9

r/s 0.0 [...]

w/s 419.0

kr/s kw/s wait actv wsvc_t asvc_t extended device statistics kr/s kw/s wait actv wsvc_t asvc_t extended device statistics kr/s kw/s wait actv wsvc_t asvc_t 0.0 82964.3 0.0 6.0 0.0 8.9 extended device statistics kr/s kw/s wait actv wsvc_t asvc_t 0.0 53514.5 0.0 10.0 0.0 23.8

%w

%b device

%w

%b device

%w

%b device 60 c0t1d0

1 %w

%b device 0 100 c0t1d0

Dane wyjħciowe pokazujæ, ľe na poczætku dyski sæ bezczynne, a nastúpnie pojawiajæ siú pewne operacje zapisu o zmiennej przepustowoħci (kw/s), ale o czústotliwoħci niľszej niľ zgđaszana przez Bonnie++ jako wynik K/sec. Poniľej przedstawiono wynik uruchomienia polecenia vfsstat w systemie SmartOS w celu sprawdzenia operacji wejħcia-wyjħcia systemu plików (na poziomie VFS): $ vfsstat 1 r/s w/s kr/s kw/s ractv wactv read_t writ_t [...] 45.3 1514.7 4.5 193877.3 0.0 0.1 0.0 0.0 45.3 1343.6 4.5 171979.4 0.0 0.1 0.0 0.1 45.3 1224.8 4.5 156776.9 0.0 0.1 0.0 0.1 45.3 1224.8 4.5 156776.9 0.0 0.1 0.0 0.1

%r %w 0 0 0 0

d/s del_t zone

6 412.4 7 1343.6 6 1157.9 6 1157.9

5.5 14.0 12.2 12.2

b8b2464c b8b2464c b8b2464c b8b2464c

Dane wyjħciowe pokazujæ przepustowoħè zgodnæ z wynikami przedstawianymi przez Bonnie++. Nie zgadza siú jednak wartoħè IOPS — polecenie vfsstat podaje, ľe zapisy sæ wielkoħci 128 KB kaľdy (kw/s, w/s), a nie „Per Chr”. Za pomocæ polecenia truss w systemie SmartOS przeprowadzamy analizú operacji zapisu w systemie plików (w tym momencie ignorujemy obciæľenie powodowane przez polecenie truss): write(4, "\001020304050607\b\t\n\v".., 131072) write(4, "\001020304050607\b\t\n\v".., 131072) write(4, "\001020304050607\b\t\n\v".., 131072)

= 131072 = 131072 = 131072

W ten sposób uzyskujemy potwierdzenie o przeprowadzaniu przez narzúdzie Bonnie++ w systemie plików operacji zapisu o wielkoħci 128 KB.

12.3. Metodologia

669

W celu porównania pokazano poniľej wynik uruchomienia polecenia strace w systemie Fedora: write(3, "\0\1\2\3\4\5\6\7\10\t\n\v\f\r\16\17\20\21\22\23\24"..., 4096) = 4096 write(3, "\0\1\2\3\4\5\6\7\10\t\n\v\f\r\16\17\20\21\22\23\24"..., 4096) = 4096 write(3, "\0\1\2\3\4\5\6\7\10\t\n\v\f\r\16\17\20\21\22\23\24"..., 4096) = 4096

Jak widzisz, Fedora przeprowadza w systemie plików operacje zapisu o wielkoħci 4 KB, podczas gdy wielkoħè operacji w systemie SmartOS wynosi 128 KB. Po wykonaniu dodatkowej analizy (za pomocæ narzúdzia DTrace) moľna zauwaľyè buforowanie wywođania putc() w bibliotece systemowej, podczas gdy poszczególne systemy operacyjne majæ domyħlnie ustawionæ innæ wielkoħè buforowania. Przeprowadzono wiúc eksperyment i narzúdzie Bonnie++ w systemie Fedora oraz za pomocæ setbuffer() przystosowano do uľycia bufora o wielkoħci 128 KB, co poprawiđo wydajnoħè o 18%. Aktywna analiza wydajnoħci ujawniđa jeszcze inne cechy charakterystyczne dotyczæce sposobu przeprowadzania testu, co pozwala lepiej zrozumieè otrzymany wynik (patrz odwođanie [8] na koēcu rozdziađu). Wniosek jest taki: test zdecydowanie jest ograniczony na skutek uľycia jednego wætku procesora, 85% czasu procesora to czas spúdzany w trybie uľytkownika. Bonnie++ to niekoniecznie zđe narzúdzie do przeprowadzania testów wydajnoħci. Dobrze sđuľyđo wielu osobom przy róľnych okazjach. Wybrađem je w omawianym przykđadzie (i jednoczeħnie wybrađem najbardziej podejrzany test do analizy), poniewaľ jest doskonale znane, wczeħniej je przeanalizowađem, a odkrycia — takie jak przedstawione — nie sæ niczym niezwykđym. To tylko jeden przykđad. Warto wspomnieè, ľe nowsze, eksperymentalne wersje narzúdzia Bonnie++ majæ zmieniony test „Per Chr”, aby rzeczywiħcie przeprowadzaè jednobajtowe operacje wejħcia-wyjħcia systemu plików. Porównujæc wyniki otrzymane przez róľne wersje Bonnie++ dla wymienionego testu, otrzymamy znaczne róľnice. Wiúcej informacji na temat analizy wydajnoħci za pomocæ Bonnie++ znajdziesz w artykule Rocha Bourbonnais’go, zatytuđowanym Decoding Bonnie++ (patrz odwođanie [9] na koēcu rozdziađu).

12.3.3. Profilowanie procesora Profilowanie procesora zarówno w testowanym sprzúcie, jak i za pomocæ oprogramowania przeznaczonego do przeprowadzania testów wydajnoħci to warta zasygnalizowania metodologia, poniewaľ pozwala na szybkie dokonanie pewnych odkryè. Czústo jest stosowana jako czúħè aktywnych testów wydajnoħci. Celem jest szybkie sprawdzenie, co tak naprawdú robi oprogramowanie, aby przekonaè siú, czy pojawi siú coħ ciekawego. Ewentualne odkrycia pozwalajæ na zawúľenie liczby komponentów oprogramowania wartych poddania dalszej analizie do tych, które odgrywajæ rolú w teħcie wydajnoħci. Profilowaè moľna stosy na poziomie uľytkownika i jædra. Profilowanie procesora na poziomie uľytkownika omówiono w rozdziale 5., zatytuđowanym „Aplikacje”. Oba rodzaje profilowania zostađy przedstawione równieľ w rozdziale 6. „Procesory”, a przykđady (w tym wykresy typu flame) w podrozdziale 6.6.

670

Rozdział 12



Testy wydajności

Przykład W zaproponowanym nowym systemie przeprowadzono dyskowy mikrotest wydajnoħci i otrzymano pewne rozczarowujæce wyniki: przepustowoħè dysku okazađa siú mniejsza niľ w starym systemie. Zostađem poproszony o sprawdzenie, na czym polega problem. Zasugerowano, ľe problem dotyczy dysków lub kontrolera dyskowego i wspomniane komponenty powinny byè wymienione. Analizú zaczæđem od zastosowania metody USE (wprowadzona w rozdziale 2. „Metodologia”). Okazađo siú, ľe dyski wcale nie sæ bardzo obciæľone, pomimo ľe to wđaħnie one miađy byè uľywane przez test wydajnoħci. Zwróciđem uwagú na pewien poziom uľycia procesora w czasie systemowym (jædra). W przypadku testu wydajnoħci przeprowadzanego wzglúdem dysków procesor moľe nie byè uznawany za interesujæcy komponent z punktu widzenia analizy. Z powodu pewnego poziomu uľycia procesora przez jædro uznađem, ľe warto szybko sprawdziè, czy znajdú tam coħ ciekawego, choè tak naprawdú wcale tego nie oczekiwađem. Przeprowadziđem profilowanie i uzyskađem wykres typu flame pokazany na rysunku 12.2.

Rysunek 12.2. Wykres typu flame pokazujący dane uzyskane podczas profilowania czasu jądra

Przejrzenie stosu ramek ujawniđo, ľe 62,17% próbek procesora zawierađo wywođanie funkcji o nazwie zfs_zone_io_throttle(). Nie musiađem nawet spoglædaè do kodu ļródđowego wymienionej funkcji, jej nazwa bowiem byđa wystarczajæcæ wskazówkæ: kontrola zasobów. Aktywny byđ mechanizm ograniczania liczby operacji wejħcia-wyjħcia w systemie plików ZFS i sztucznie ograniczađ test wydajnoħci! To ustawienie domyħlne w nowym systemie (ale nie w starym), dlatego zostađo przeoczone podczas przeprowadzania testów wydajnoħci.

12.3. Metodologia

671

12.3.4. Metoda USE Metoda USE zostađa wprowadzona w rozdziale 2. „Metodologia”, a omówiona w rozdziađach poħwiúconych analizie poszczególnych zasobów. Zastosowanie metody USE podczas testów wydajnoħci moľe zagwarantowaè odkrycie ograniczeē. Komponent, sprzút lub oprogramowanie moľe osiægnæè 100-procentowy poziom wykorzystania, w przeciwnym razie nie uľywasz systemu do granic jego moľliwoħci. Przykđad zastosowania metody USE zaprezentowano w punkcie 12.3.2, w którym pomogđa ona w wykryciu, ľe dyskowy test wydajnoħci nie dziađađ zgodnie z zađoľeniami.

12.3.5. Charakterystyka obciążenia Charakterystykú obciæľenia równieľ wprowadzono w rozdziale 2. „Metodologia”, a omówiono w nastúpnych rozdziađach. Wspomniana metodologia moľe byè uľyta do okreħlenia, jak bardzo dany test wydajnoħci jest powiæzany z bieľæcym ħrodowiskiem produkcyjnym. Odbywa siú to w wyniku przygotowania charakterystyki obciæľenia produkcyjnego do celów porównawczych.

12.3.6. Własne testy wydajności W przypadku prostych testów wydajnoħci poľædane moľe byè przygotowanie wđasnego oprogramowania sđuľæcego do tego celu. Staraj siú utworzyè jak najkrótszy program, aby uniknæè skomplikowania utrudniajæcego analizú. Júzyk programowania C to zwykle dobry wybór, poniewaľ jest ħciħle mapowany na to, co wykonuje. Pamiútaj jednak, ľe optymalizacje stosowane przez kompilator búdæ miađy wpđyw na utworzony kod. Kompilator moľe pominæè proste procedury testu wydajnoħci, jeħli uzna, ľe dane wyjħciowe búdæ nieuľyte, a tym samym sæ zbúdne do wygenerowania. Warto wiúc zapoznaè siú ze skompilowanym plikiem binarnym, aby przekonaè siú, jakie tak naprawdú jest jego dziađanie. Júzyki wykorzystujæce maszyny wirtualne, asynchroniczne mechanizmy usuwania nieuľytków i dynamicznæ kompilacjú w trakcie dziađania búdæ znacznie trudniejsze do debugowania i kontroli z odpowiedniæ dokđadnoħciæ. Mimo wszystko moľe byè konieczne uľycie tego rodzaju júzyków programowania, gdy zajdzie potrzeba symulacji oprogramowania klienta utworzonego za pomocæ takiego wđaħnie júzyka. Tworzone wđasne testy wydajnoħci mogæ ujawniè takľe pewne informacje szczegóđowe dotyczæce sprawdzanego systemu, które búdæ uľyteczne w póļniejszym czasie. Na przykđad opracowujæc test wydajnoħci bazy danych, moľesz odkryè, ľe API zapewnia obsđugú róľnych opcji poprawiajæcych wydajnoħè. Wspomniane opcje mogæ obecnie nie byè stosowane w Twoim ħrodowisku produkcyjnym, jeħli na przykđad powstađo ono przed ich wprowadzeniem. Przygotowane przez Ciebie oprogramowanie moľe po prostu symulowaè obciæľenie (generator obciæľenia) i pozostawiè pomiar innym narzúdziom. Jednym z moľliwych rozwiæzaē jest wówczas stopniowa zmiana obciæľenia.

672

Rozdział 12



Testy wydajności

12.3.7. Stopniowa zmiana obciążenia Ta prosta metoda pozwala na ustalenie maksymalnej przepustowoħci, jakæ moľe obsđuľyè badany system. Obejmuje dodawanie obciæľenia w mađych iloħciach i pomiar aktualnej przepustowoħci, aľ do osiægniúcia wartoħci granicznej. Wynik moľna przedstawiè graficznie, pokazujæc w ten sposób profil skalowania. Nastúpnie wspomniany profil moľna przestudiowaè wizualnie lub za pomocæ modeli skalowalnoħci (patrz rozdziađ 2. „Metodologia”). Na przykđad na rysunku 12.3 pokazano skalowanie systemu i systemu plików wraz ze zmianæ liczby wætków. Kaľdy wætek wykonuje losowe operacje odczytu o wielkoħci 8 KB dotyczæce buforowanego pliku. Podczas testu po kolei dodawane byđy kolejne wætki.

Rysunek 12.3. Stopniowa zmiana obciążenia systemu plików

Analizowany system osiægnæđ przepustowoħè wynoszæcæ prawie póđ miliona operacji odczytu na sekundú. Wyniki zostađy sprawdzone za pomocæ danych statystycznych zebranych na poziomie VFS, które potwierdziđy wielkoħè operacji wejħcia-wyjħcia (8 KB) i maksymalny transfer wynoszæcy ponad 3,5 GB/s. Dla omawianego testu generator obciæľenia zostađ utworzony w Perlu. To wystarczajæco krótki kod, tak ľe moľna go tutaj zamieħciè w cađoħci jako przykđad: #!/usr/bin/perl -w # # randread.pl - losowy odczyt danych wskazanego pliku. use strict; my $IOSIZE = 8192; my $QUANTA = $IOSIZE;

# WyraĪona w bajtach wielkoĞü operacji wejĞcia-wyjĞcia. # WyraĪona w bajtach dokáadnoĞü wyszukiwania.

die "U¿YCIE: randread.pl nazwa_pliku\n" if @ARGV != 1 or not -e $ARGV[0]; my $file = $ARGV[0]; my $span = -s $file; # Losowe odczyty. my $junk;

12.3. Metodologia

673

open FILE, "$file" or die "B’kD: odczyt pliku $file: $!\n"; while (1) { seek(FILE, int(rand($span / $QUANTA)) * $QUANTA, 0); sysread(FILE, $junk, $IOSIZE); } close FILE;

Funkcjú sysread() wykorzystano w celu bezpoħredniego uľycia wywođania systemowego read() i tym samym unikniúcia buforowania. Kod zostađ przygotowany jako mikrotest wydajnoħci serwera NFS i uruchomiony jednoczeħnie z poziomu zbioru klientów, z których kaľdy wykonywađ losowe operacje odczytu w zamontowanym serwerze NFS. Wyniki tego mikrotestu wydajnoħci (odczyty na sekundú) zostađy zmierzone w serwerze NFS za pomocæ polecenia nfsstat oraz innych narzúdzi. Liczba uľytych plików i ich đæczna wielkoħè byđy kontrolowane (w ten sposób okreħlamy wielkoħè zbioru roboczego), aby pewne testy dotyczyđy operacji cađkowicie obsđugiwanych przez bufor, a inne — przez dysk. (Zapoznaj siú z przykđadem przedstawionym w punkcie 12.2.1 we wczeħniejszej czúħci rozdziađu). Liczba egzemplarzy uruchomionych w zbiorze klientów byđa zwiúkszana o jeden, co powodowađo stopniowe zwiúkszanie obciæľenia aľ do osiægniúcia limitu. Uzyskane dane zamieszczono na wykresie, w ten sposób powstađ profil skalowalnoħci. W pođæczeniu z poziomem wykorzystania zasobów (metoda USE) otrzymano potwierdzenie maksymalnego wykorzystania zasobów. W omawianym przypadku w cađoħci zuľyto zasoby procesora, co zainicjowađo dalszæ analizú majæcæ na celu poprawú jego wydajnoħci. Omawiany program i podejħcie wykorzystađem do ustalenia ograniczeē w Oracle ZFS Storage Appliance (a dokđadnie Sun ZFS Storage Appliance — patrz odwođanie [10] na koēcu rozdziađu). Ustalone ograniczenia zostađy podane w oficjalnych wynikach i wedđug naszej wiedzy ustanowiđy one rekord ħwiata. Podobne oprogramowanie utworzyđem w júzyku C, ale w omawianym przypadku okazađo siú to zbúdne. Dysponowađem duľæ iloħciæ zasobów procesora po stronie klienta — przejħcie na program w júzyku C spowodowađo zmniejszenie poziomu ich uľycia; to nie wpđynúđo na wynik, poniewaľ wæskie gardđo wystæpiđo w serwerze. Wypróbowano takľe inne, bardziej zaawansowane testy wydajnoħci i inne júzyki programowania, ale nie poprawiđo to uzyskanych wyników. Jeľeli chcesz zastosowaè omówione podejħcie, poza pomiarem przepustowoħci przeprowadļ takľe pomiar opóļnienia, a zwđaszcza jego rozkđadu. Kiedy system osiægnie swoje maksimum, opóļnienie zwiæzane z kolejkowaniem moľe byè znaczne i spowoduje zwiúkszenie opóļnienia. Jeľeli obciæľenie búdzie zbyt duľe, opóļnienie moľe staè siú na tyle wysokie, ľe otrzymane wyniki nie búdæ mogđy byè dđuľej uznawane za prawidđowe. Zadaj sobie pytanie, czy zmierzone opóļnienie búdzie do zaakceptowania przez klienta. Obsđugujesz na przykđad duľæ liczbú klientów generujæcych 990 000 IOPS w analizowanym systemie, który udziela odpowiedzi ze ħrednim opóļnieniem operacji wejħcia-wyjħcia wynoszæcym 5 ms. Naprawdú chcesz osiægnæè ponad milion IOPS, ale system znajduje siú na granicy nasycenia. Dodajæc kolejnych klientów, przekraczasz upragnionæ wartoħè miliona IOPS, ale wszystkie operacje sæ obecnie kolejkowane i ħrednie opóļnienie wynosi ponad 50 ms (co jest absolutnie nie do zaakceptowania!). Który z podanych wyników przekaľesz dziađowi marketingu? (Odpowiedļ: 990 000 IOPS).

674

Rozdział 12



Testy wydajności

12.3.8. Sprawdzenie poprawności To jest èwiczenie pozwalajæce sprawdziè wyniki testu wydajnoħci na skutek ustalenia, czy charakterystyka ma sens. Obejmuje sprawdzenie, czy wynik zawiera pewien komponent, który przekroczyđ znane ograniczenia, na przykđad przepustowoħè sieci, przepustowoħè kontrolera, przepustowoħè magistrali, wartoħè IOPS dla dysku. Jeľeli przekroczono jakikolwiek limit, warto przeprowadziè dalszæ analizú. W wiúkszoħci przypadków to èwiczenie pozwala ostatecznie odkryè, ľe wyniki testu wydajnoħci sæ nieprawidđowe. Oto przykđad. Serwer NFS jest poddawany testowi wydajnoħci wykonujæcemu operacje odczytu o wielkoħci 8 KB. Wynik wskazuje na osiægniúcie wartoħci 50 000 IOPS. Serwer jest podđæczony do sieci za pomocæ pojedynczego portu Ethernet o przepustowoħci 1 Gb/s. Przepustowoħè sieci wymagana do osiægniúcia 50 000 IOPSŧ8 KB = 400 000 KB/s plus nagđówki protokođu. To daje nam ponad 3,2 Gb/s, czyli wartoħè znacznie przekraczajæcæ znany limit 1 Gb/s. Nie ma wætpliwoħci, ľe coħ jest nie tak z przeprowadzonym testem wydajnoħci! Wyniki, takie jak wspomniany, zwykle oznaczajæ, ľe test wydajnoħci sprawdziđ buforowanie po stronie klienta, a nie obciæľenie serwera NFS. Przedstawione obliczenie wykorzystađem do wykrycia wielu nieprawidđowych testów wydajnoħci, które wskazywađy na wymienionæ poniľej przepustowoħè osiægniútæ przez interfejs 1 Gb/s (patrz odwođanie [11] na koēcu rozdziađu): 

120 MB/s,



200 MB/s,



350 MB/s,



800 MB/s,



1,15 GB/s.

Wymienione wartoħci wskazujæ na przepustowoħè w jednym kierunku. Wynik 120 MB/s jest prawidđowy — interfejs 1 Gb/s powinien osiægnæè przepustowoħè okođo 119 MB/s. Wynik 200 MB/s jest moľliwy do osiægniúcia, tylko jeħli wystæpi intensywny ruch w obu kierunkach i zostanie on zsumowany. Wyniki dotyczæ jednak tylko jednego kierunku. Wartoħè 350 MB/s znacznie wykracza poza limit i jest nieprawidđowa. Kiedy masz wyniki testu wydajnoħci do sprawdzenia, wyszukaj wartoħci, które moľna zsumowaè, i spróbuj odkryè wspomniane limity. Jeľeli masz dostúp do systemu, moľesz wówczas uzyskaè kolejne wyniki testów, przeprowadzajæc nowe obserwacje lub eksperymenty. Nastúpnie moľna zastosowaè metodú naukowæ. Pytanie, które naleľy sobie zadaè, brzmi: czy wynik testu wydajnoħci jest prawidđowy? Kolejnym krokiem jest przygotowanie hipotez i przewidywaē, a nastúpnie przeprowadzenie testów w celu ich weryfikacji.

12.3.9. Analiza statystyczna Analiza statystyczna to proces zbierania i analizy danych uzyskanych podczas testu wydajnoħci. Skđada siú z trzech faz:

12.3. Metodologia

675

1. Wyboru. Wybranie narzúdzia testów wydajnoħci, jego konfiguracji i przechwytywanych metryk wydajnoħci systemu. 2. Wykonania. Wykonanie testu wydajnoħci, zebranie ogromnego zbioru wyników i metryk. 3. Interpretacji. Interpretacja danych za pomocæ analizy statycznej i przygotowanie raportu. W przeciwieēstwie do aktywnych testów wydajnoħci, koncentrujæcych siú na analizie systemu podczas przeprowadzania testu, analiza statystyczna jest ukierunkowana na analizú otrzymanych wyników. Ponadto róľni siú od pasywnych testów wydajnoħci, w których nie jest przeprowadzana ľadna analiza. Omawiane tutaj podejħcie jest stosowane w ħrodowiskach, w których dostúp do ogromnych systemów moľe byè ograniczony czasowo lub ze wzglúdu na koszt. Na przykđad moľe byè dostúpna tylko jedna maszyna w „maksymalnej konfiguracji”, ale w tym samym czasie wiele zespođów chce uzyskaè do niej dostúp i przeprowadziè testy: 









Sprzedaľ. W trakcie sprawdzania dowodu koncepcji, w celu zastosowania symulowanego obciæľenia klienta do ustalenia maksymalnej wydajnoħci, jakæ moľe zaoferowaè dany system. Marketing. W celu uzyskania najlepszych wyników do wykorzystania ich w kampanii reklamowej. Pomoc techniczna. W celu analizy patologii pojawiajæcych siú jedynie w systemie o maksymalnej konfiguracji i pod ogromnym obciæľeniem. Inľynieria. W celu przetestowania wydajnoħci nowych funkcji i zmian wprowadzonych w kodzie. Jakoħè. W celu przeprowadzenia testów nieregresyjnych i certyfikacji.

Kaľdy zespóđ búdzie miađ jedynie ograniczonæ iloħè czasu na przeprowadzenie testów wydajnoħci w systemie, ale znacznie wiúcej czasu na póļniejszæ analizú otrzymanych wyników. Poniewaľ zebranie wyników jest kosztowne, naleľy poczyniè dodatkowe wysiđki i upewniè siú, ľe búdæ one niezawodne i warte zaufania, aby uniknæè koniecznoħci powtarzania testów wydajnoħci po wykryciu ewentualnych problemów. Poza sprawdzeniem sposobu ich generowania pod wzglúdem technicznym warto równieľ zebraè nieco wiúcej wđaħciwoħci statystycznych, aby problemy mogđy zostaè wykryte jak najwczeħniej. To moľe obejmowaè dane statystyczne dla odchyleē, peđne rozkđady, marginesy bđúdu i inne (patrz podrozdziađ 2.8 w rozdziale 2. „Metodologia”). W trakcie przeprowadzania testów wydajnoħci zwiæzanych ze zmianami wprowadzonymi w kodzie lub testami nieregresyjnymi znaczenie krytyczne ma peđne poznanie i zrozumienie odchylenia oraz marginesu bđúdu, aby w sposób sensowny wykorzystaè zebrane wyniki. Warto takľe zebraè maksymalnæ iloħè danych dotyczæcych wydajnoħci dziađajæcego systemu (bez negatywnego wpđywania na wyniki ze wzglúdu na obciæľenie zwiæzane ze zbieraniem danych). Dziúki temu analizú búdzie moľna przeprowadziè póļniej na zebranych danych. Operacjú zbierania danych moľna przeprowadziè za pomocæ polecenia

676

Rozdział 12



Testy wydajności

takiego jak sar, produktów opracowanych przez firmy trzecie lub wđasnych narzúdzi przeznaczonych do pobierania wszystkich dostúpnych danych statystycznych. Na przykđad w systemie Linux wđasny skrypt powđoki moľe kopiowaè zawartoħè plików danych statystycznych interfejsu /proc przed przeprowadzeniem i po przeprowadzeniu testu wydajnoħci. Skopiowaè naleľy wszystkie moľliwe dane na wypadek, gdyby okazađy siú potrzebne. Wspomniany skrypt moľe byè uruchamiany w zdefiniowanych odstúpach czasu podczas testu wydajnoħci, o ile obciæľenie zwiæzane z dziađaniem skryptu jest akceptowalne. Inne narzúdzia statystyczne moľna równieľ wykorzystaè, na przykđad do tworzenia dzienników zdarzeē. W systemie Solaris wywođanie polecenia kstat -p spowoduje pobranie wszystkich danych statystycznych jædra, które moľna zapisaè przez przeprowadzeniem i po przeprowadzeniu testu wydajnoħci oraz w zdefiniowanych odstúpach czasu. Dane wyjħciowe wymienionego polecenia sæ đatwe do przetwarzania, a poza tym mogæ byè importowane do bazy danych w celu przeprowadzania analizy zaawansowanej. Analiza statystyczna wyników i metryk moľe obejmowaè analizú skalowalnoħci i teorii kolejek, aby tym samym przygotowaè model systemu w postaci sieci kolejek. Te zagadnienia zostađy poruszone w rozdziale 2. „Metodologia” oraz sæ tematem innych ksiæľek — patrz odwođania [Jain 91], [Gunther 97] i [Gunther 07] na koēcu rozdziađu.

12.4. Pytania dotyczące testu wydajności Jeľeli producent dostarcza wyników testów wydajnoħci, istnieje wówczas wiele pytaē, na które udzielenie odpowiedzi pozwala jeszcze lepiej zrozumieè wyniki i przeđoľyè je na wđasne ħrodowisko. Celem jest ustalenie, co tak naprawdú zostađo zmierzone w teħcie wydajnoħci oraz jak rzeczywisty lub powtarzalny jest wynik. Najtrudniejsze pytanie moľe brzmieè: czy jestem w stanie samodzielnie powtórzyè dany wynik? Dany wynik testu wydajnoħci mógđ zostaè uzyskany na skutek uľycia ekstremalnej konfiguracji sprzútowej (na przykđad dysków SSD), specjalnego dostrojenia (na przykđad macierzy RAID 0), odrobiny szczúħcia (braku moľliwoħci powtórzenia) lub bđúdu w samym pomiarze. Istnienie wymienionych czynników moľna ustaliè, jeľeli test wydajnoħci uda siú przeprowadziè we wđasnym centrum danych, a nastúpnie poddaè analizie: to aktywne testy wydajnoħci. Tego rodzaju procedura wymaga jednak poħwiúcenia duľej iloħci czasu. Oto pytania, które warto sobie zadaè: 

Ogólne: 

Jaka byđa konfiguracja testowanego systemu?



Czy testowany byđ pojedynczy system, czy klaster?



Jaki jest koszt testowanego systemu?



Jak przedstawiađa siú konfiguracja klientów testu wydajnoħci?



Jak dđugo trwađ test?

12.4. Pytania dotyczące testu wydajności





 

 

 



Jak przedstawia siú rozkđad wartoħci (odchylenie standardowe, percentyle lub peđny rozkđad)? Jaki czynnik ograniczađ test wydajnoħci? Jaki byđ wspóđczynnik wyraľajæcy stosunek operacji zakoēczonych sukcesem do operacji zakoēczonych niepowodzeniem? Jak przedstawiađy siú atrybuty operacji? Czy atrybuty operacji zostađy wybrane w celu symulacji obciæľenia? W jaki sposób zostađy wybrane? Czy test wydajnoħci symuluje odchylenie, czy ħrednie obciæľenie? Czy wynik testu wydajnoħci moľna potwierdziè za pomocæ innych narzúdzi analizy? (Dostarcz odpowiednich zrzutów ekranu). Czy margines bđúdu moľe byè wyraľony w wyniku testu wydajnoħci?



Czy wynik testu wydajnoħci moľna powtórzyè?

Dotyczæce testów wydajnoħci zwiæzanych z procesorem i pamiúciæ: 

Jakie procesory zostađy uľyte?



Czy jakiekolwiek procesory byđy wyđæczone?



Ile pamiúci operacyjnej byđo zainstalowane w komputerze? Jaki to byđ rodzaj pamiúci? Czy uľyto jakichkolwiek wđasnych ustawieē w BIOS-ie?

Dotyczæce testów wydajnoħci zwiæzanych z pamiúciæ masowæ: 





Czy wynik przedstawia wartoħè ħredniæ, czy maksymalnæ? Jaka jest wartoħè ħrednia?







677

Jak przedstawia siú konfiguracja urzædzeē pamiúci masowej (ile ich jest, jakiego sæ typu, czy uľywana jest macierz RAID)? Jaka jest konfiguracja systemu plików (ile systemów zostađo uľytych, czy byđy dostrajane)?



Jaka jest wielkoħè zbioru roboczego?



Do jakiego stopnia zbiór roboczy jest buforowany? Gdzie jest buforowany?



Ile plików byđo uľywanych w trakcie testu wydajnoħci?

Dotyczæce testów wydajnoħci zwiæzanych z sieciæ: 



Jak przedstawia siú konfiguracja sieci (liczba uľywanych interfejsów, ich typ i konfiguracja)? Czy dostrojono ustawienia TCP?

Podczas analizy biznesowych testów wydajnoħci udzielenie odpowiedzi na przedstawione pytania moľe wymagaè poznania pewnych szczegóđów dotyczæcych przeprowadzonych testów.

678

Rozdział 12



Testy wydajności

12.5. Ćwiczenia 1. Odpowiedz na nastúpujæce pytania dotyczæce koncepcji:  



Co to jest mikrotest wydajnoħci? Co to jest wielkoħè zbioru roboczego oraz w jaki sposób moľe wpđywaè na wyniki testów wydajnoħci pamiúci masowej? Jaki jest powód analizy wspóđczynnika cena/wydajnoħè?

2. Wybierz mikrotest wydajnoħci, a nastúpnie wykonaj wymienione poniľej zadania: 

 

Przeskaluj wielkoħè (wætki, wielkoħè operacji wejħcia-wyjħcia, …) i przeprowadļ pomiar wydajnoħci. Przedstaw wyniki w sposób graficzny (skalowalnoħè). Za pomocæ mikrotestów wydajnoħci sprawdļ maksymalnæ wydajnoħè urzædzenia docelowego i przeanalizuj ograniczajæcy jæ czynnik.

12.6. Odwołania [Anon 85]

Anon i in., A Measure of Transaction Processing Power, „Datamation”, 1 kwietnia 1985.

[Jain 91]

R. Jain, The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling, Wiley, 1991.

[Gunther 97]

N. Gunther, The Practical Performance Analyst, McGraw-Hill, 1997.

[Smaalders 06] B. Smaalders, Performance Anti-Patterns, „ACM Queue” 4, nr 1, luty 2006. [Gunther 07]

N. Gunther, Guerrilla Capacity Planning, Springer, 2007.

[DeWitt 08]

D. DeWitt, C. Levine, Not Just Correct, but Correct and Fast, SIGMOD Record, 2008.

[Traeger 08]

A. Traeger, E. Zadok, N. Joukov, C. Wright, A Nine Year Study of File System and Storage Benchmarking, „ACM Transactions on Storage”, 2008.

[1]

http://www.rfc-editor.org/rfc/museum/tcp-ip-digest/ tcp-ip-digest.v1n6.1

[2]

http://dtrace.org/blogs/bmc/2009/02/02/eulogy-for-a-benchmark/

[3]

http://www.tpc.org/information/about/history.asp

[4]

http://www.tpc.org/information/other/pricing_guidelines.asp

[5]

http://www.tpc.org/

[6]

http://www.spec.org/

12.6. Odwołania

679

[7]

http://www.coker.com.au/bonnie++/

[8]

http://www.brendangregg.com/activebenchmarking.html

[9]

https://blogs.oracle.com/roch/entry/decoding_bonnie

[10]

http://dtrace.org/blogs/brendan/2009/05/26/ performance-testing-the-7000-series-part-3-of-3/

[11]

http://www.beginningwithi.com/2009/11/11/ brendan-gregg-at-frosug-oct-2009/

680

Rozdział 12



Testy wydajności

13 Studium przypadku

Ten rozdziađ dotyczy studium przypadku wydajnoħci systemu, czyli prawdziwej historii problemu zwiæzanego z wydajnoħciæ, która zostanie w peđni przedstawiona, od poczætkowego zgđoszenia problemu aľ do jego ostatecznego rozwiæzania. Omawiany tutaj problem wystæpiđ w produkcyjnym ħrodowisku przetwarzania w chmurze, wybrađem go jako przykđad pokazujæcy procedurú analizy wydajnoħci systemu. W tym rozdziale moim celem nie jest prezentacja nowego materiađu pod wzglúdem technicznym, ale opowiedzenie historii oraz pokazanie, jak narzúdzia i metodologie mogæ byè zastosowane w praktyce, w rzeczywistym ħrodowisku. Powinno to byè szczególnie uľyteczne dla osób poczætkujæcych, które jeszcze nie spotkađy siú z prawdziwymi problemami zwiæzanymi z wydajnoħciæ systemu. Dziúki przedstawionemu tutaj materiađowi mogæ podglædaè eksperta w trakcie pracy, dowiedzieè siú, co myħli podczas analizy i dlaczego wđaħnie w taki sposób. To niekoniecznie búdzie najlepsza forma dokumentacji, ale raczej wyjaħnienie wybranego podejħcia. Wszystkie imiona zostađy zmienione, aby chroniè toľsamoħè uľytkowników. Wszelkie podobieēstwo do rzeczywistych serwerów online lub offline jest cađkowicie niezamierzone.

13.1. Studium przykładu: czerwony wieloryb Otrzymujesz wiadomoħè! Czeħè Brendan. Jeľeli búdziesz miađ moľliwoħè, to czy moľesz spojrzeè na serwer NiftyFy? Zgđoszony problem moľe byè zwiæzany z pewnymi Twoimi odkryciami dotyczæcymi wydajnoħci. Nathan juľ przeanalizowađ serwer, ale nie znalazđ przyczyny problemu. 681

682

Rozdział 13



Studium przypadku

Wszystko rozpoczúđo siú od wiadomoħci e-mail otrzymanej przeze mnie od handlowca Jamesa, który do wiadomoħci skopiowađ zgđoszenie, jakie napđynúđo do dziađu pomocy technicznej. Byđem nieco poirytowany, poniewaľ próbowađem wówczas rozwiæzaè dwa inne problemy i absolutnie nie chciađem byè odrywany od pracy. Jestem zatrudniony w firmie Joyent, búdæcej dostawcæ usđug przetwarzania w chmurze. Wprawdzie zajmujú siú inľynieriæ, ale jednoczeħnie jestem ostatniæ osobæ, której przez zespođy pomocy technicznej i operacyjny zgđaszane sæ problemy zwiæzane z wydajnoħciæ. Klient moľe mieè problem z dowolnæ aplikacjæ lub bazæ danych dziađajæcæ w strefie SmartOS lub egzemplarzem KVM-u z systemem Linux lub Windows. Postanowiđem od razu przyjrzeè siú nowo zgđoszonemu problemowi, przeanalizowaè go przez kwadrans w nadziei na szybkie znalezienie odpowiedzi. Jeľeli analiza problemu miađaby potrwaè dđuľej, to jego priorytet musiađbym porównaè z dwoma innymi problemami, którymi siú zajmowađem. Pierwszym krokiem byđo zapoznanie siú ze zgđoszeniem do dziađu pomocy i przeczytanie informacji o problemie.

13.1.1. Zdefiniowanie problemu W opisie problemu znajdujæ siú informacje o wersjach oprogramowania, konfiguracji i zmianach w poziomie uľycia procesora. Klient, który ostatnio zaczæđ korzystaè z Joyent SmartMachines (strefy SmartOS), byđ zaskoczony moľliwoħciæ uľycia narzúdzi systemowych do monitorowania fizycznych procesorów, miúdzy innymi poziomu wykorzystania komputera przez wszystkie tenanty. Przejrzađem opis problemu, szukajæc nastúpujæcych danych:  

Co skđoniđo klienta do uznania, ľe wystúpuje problem zwiæzany z wydajnoħciæ? Czy jego problem (o ile istnieje) moľna wyraziè w kategoriach opóļnienia lub dziađania?

Odpowiedļ na pierwsze pytanie wskaľe, na ile rzeczywisty moľe byè zgđoszony problem. Natomiast udzielenie odpowiedzi na drugie pytanie pozwoli mi samodzielnie sprawdziè istnienie problemu. Wiele zgđoszeē okazuje siú byè wynikiem nieprawidđowego zrozumienia metryk systemowych, a nie rzeczywistymi problemami z aplikacjami. Dlatego teľ weryfikacja na wczesnym etapie pozwala zaoszczúdziè czas. Niestety nie zawsze juľ na samym poczætku pracy moľna udzieliè odpowiedzi na postawione wczeħniej pytania. Z opisu przedstawionego przez klienta dowiedziađem siú, ľe uľywa on aplikacji o nazwie Redis oraz ľe: 



polecenie traceroute zostađo wykorzystane do przetestowania trasy sieci i sprawdzenia opóļnienia — dane wyjħciowe polecenia wskazujæ na gubione pakiety; czasami opóļnienie w aplikacji Redis przekracza jednæ sekundú.

13.1. Studium przykładu: czerwony wieloryb

683

Klient podejrzewađ, ľe oba dokonane odkrycia sæ ze sobæ powiæzane. W pierwszej chwili jednak uznađem, ľe tak naprawdú problem nie istnieje. We wspomnianych systemach polecenie traceroute domyħlnie dotyczy protokođu UDP, który z zađoľenia jest zawodny i dlatego infrastruktura sieci moľe gubiè te pakiety, aby zapewniè moľliwoħè dostarczenia znacznie waľniejszych pakietów TCP. Jeľeli test dotyczyđby pakietów TCP, wówczas gubienie pakietów nie powinno wystúpowaè. Podana przez klienta informacja dotyczæca opóļnienia to coħ, co mogđem samodzielnie zmierzyè. Opierajæc siú na poprzednich przypadkach o podobnej charakterystyce, mogđem przypuszczaè, ľe mój ostateczny wniosek búdzie jednym z poniľszych. Mađo tego, mogđem nawet przewidzieè prawdopodobieēstwo sformuđowania poszczególnych wniosków: 





60% — pakiety gubione przez traceroute to fađszywy trop, a jednosekundowe opóļnienie aplikacji Redis okazuje siú cađkowicie normalne z pewnych powodów zwiæzanych z aplikacjæ. 30% — pakiety gubione przez traceroute to fađszywy trop, zupeđnie inny problem powoduje powstanie jednosekundowego opóļnienia aplikacji Redis. 10% — gubienie pakietów przez traceroute ma zwiæzek z problemem, sieè faktycznie gubi pewne pakiety.

Jak moľesz siú przekonaè, najbardziej prawdopodobna sytuacja koēczy siú stwierdzeniem w stylu „Rzeczywiħcie tak moľe byè”. To moľe byè nowoħè dla osoby, która dopiero poznaje aplikacjú Redis, ale búdzie zupeđnie oczywiste dla eksperta dobrze znajæcego tú aplikacjú.

13.1.2. Pomoc techniczna Historia zgđoszenia zawierađa informacje szczegóđowe o tym, jak dziađ pomocy technicznej Joyent przeanalizowađ dany problem. Kiedy pracownik dziađu pomocy dowiedziađ siú, ľe klient do analizy wydajnoħci aplikacji Redis uľywa narzúdzia monitorowania opracowanego przez firmú trzeciæ, poprosiđ o uzyskanie dostúpu do niego i potwierdziđ wystúpowanie czasami duľego opóļnienia. Nastúpnie pracownik dziađu pomocy próbowađ takľe powtórzyè gubienie pakietów zgđaszane przez polecenie traceroute, ale to siú nie udađo. Zanotowano, ľe lokalizacja ļródđowa moľe mieè znaczenie, jeħli polecenie traceroute wybiera róľne ħcieľki sieciowe, niektóre mniej niezawodne od innych (co akurat jest dobrym zađoľeniem). Dziađ pomocy wypróbowađ róľne lokalizacje, ale nie byđ w stanie potwierdziè gubienia pakietów. Nathan z zespođu operacyjnego zajæđ siú problemem. Za pomocæ polecenia curl spróbowađ zmierzyè opóļnienie, uľywajæc komputera umieszczonego najbliľej klienta, aby maksymalnie zmniejszyè liczbú komponentów sieciowych znajdujæcych siú po drodze. Dziúki wywođaniu wymienionego polecenia w pútli ostatecznie udađo mu siú osiægnæè opóļnienie siúgajæce 200 ms. Wprawdzie wartoħè ta nie odpowiadađa zgđoszonej sekundzie, ale jednoczeħnie byđa znacznie wiúksza niľ normalna, która podczas testów zwykle wynosiđa poniľej 1 ms. Innymi sđowy: element odstajæcy.

684

Rozdział 13



Studium przypadku

Nathan wykorzystađ takľe wđasnæ listú rzeczy do sprawdzenia, aby szybko przeanalizowaè system. Ustaliđ, ľe procesor nie jest ļródđem problemu — duľa iloħè jego zasobów pozostawađa bezczynna. Wielkoħè sieciowych operacji wejħcia-wyjħcia byđa ħrednia, ale nie stađa siú przyczynæ problemu. Z wielu powodów coraz mniej prawdopodobne byđo, ľe problem mógđ byè spowodowany przez gubienie pakietów sieciowych: 



Nathan przeprowadziđ test z uľyciem najbliľszego klienta znajdujæcego siú w tym samym centrum danych. Jeľeli przyczynæ powstania elementu odstajæcego o opóļnieniu 200 ms byđoby gubienie pakietów lub nasycenie sprzútu sieciowego, to problem dotyczyđby przeđæczników sieciowych i routerów w naszym centrum danych. Taka ewentualnoħè — bioræc pod uwagú ich niezawodnoħè — wydawađa siú mađo prawdopodobna. We wspomnianych systemach 200 ms to zbyt mađa wartoħè, aby wystæpiđa retransmisja TCP.

Tak na marginesie, wystæpiđy dwa opóļnienia wskazujæce na retransmisjú TCP: 1,125 s i 3,375 s. Podane opóļnienia powstađy na skutek dziađania „cudacznego” fragmentu kodu TCP w jædrze (a dokđadnie w funkcji tcp_init_values() jædra illumos), zwiúkszajæcego nieco wartoħci 1 s i 3 s. Prawdopodobnie powinniħmy poprawiè ten kod, poniewaľ w przeszđoħci wprowadzađ trochú zamieszania u klientów, co oczywiħcie nie jest poľædane. Z drugiej strony, wymienione wartoħci czústo sæ uľyteczne i szybko sugerujæ retransmisje TCP: „uzyskađem nasze elementy odstajæce o opóļnieniu rzúdu 3,4 s…”. Jednak w omawianym przykđadzie retransmisje TCP to fađszywy trop, poniewaľ wartoħè 200 ms jest zbyt mađa na ich wystæpienie. Wprawdzie dotychczasowe ustalenia prawdopodobnie wyeliminowađy retransmisje TCP (o ile nie wystæpiđy nieznane niewiadome), ale zupeđnie nie wyeliminowađy sieci jako przyczyny problemu. Przeprowadzony przez Nathana test centrum danych znacznie zmniejszyđ prawdopodobieēstwo, ľe problem dotyczy sieci, ale wedđug mnie nie moľna cađkowicie wykluczyè takiej moľliwoħci.

13.1.3. Rozpoczęcie pracy Wysđađem Jamesowi wiadomoħè na czacie, ľe od razu zajmú siú wskazanym problemem. James odpowiedziađ, przekazujæc oczekiwania wzglúdem moich dziađaē: na tym etapie podejrzanym byđa sama aplikacja Redis, a nasze serwery wydawađy siú dziađaè prawidđowo. James byđ gotowy powiedzieè o tym klientowi, ale poprosiđ mnie o potwierdzenie prawidđowego dziađania naszych systemów, najlepiej za pomocæ pewnych nowych skryptów DTrace, które ostatnio opracowađem i z powodzeniem stosowađem. Podobnie jak wczeħniej, swoje odkrycia przekazywađem Jamesowi, który prowadziđ komunikacjú z klientem, pozwalajæc mi skoncentrowaè siú na problemie. Nie dokoēczyđem lektury informacji dotyczæcych zgđoszonego problemu, ale zalogowađem siú do docelowego systemu (SmartOS) w celu wydania kilku poleceē, tak na wszelki wypadek, aby wyeliminowaè oczywistæ przyczynú problemu. Pierwszym wydanym poleceniem byđo tail /var/adm/messages, uľyteczny nawyk z czasów, gdy zajmowađem siú administracjæ systemami. Wymienione polecenie pozwala praktycznie

13.1. Studium przykładu: czerwony wieloryb

685

od razu wykryè pewne problemy. Tym razem dane wyjħciowe polecenia tail nie zawierađy niczego alarmujæcego. Nastúpnie postanowiđem wydaè polecenie wyħwietlajæce dane statystyczne. Poniewaľ klient zgđaszađ gubienie pakietów, wydađem polecenie netstat -s 1 | grep tcp. Na ekranie zostađy wyħwietlone uľyteczne dane statystyczne pokazujæce wartoħci od chwili uruchomienia systemu, a nastúpnie kolejne dane co sekundú. Oto podsumowanie od chwili uruchomienia systemu: TCP

tcpRtoAlgorithm = 4 tcpRtoMax = 60000 tcpActiveOpens = 31326 tcpAttemptFails = 36 tcpCurrEstab = 474 tcpOutDataSegs =1502467280 tcpRetransSegs = 10573 tcpOutAck =89303926 tcpOutUrg = 0 tcpOutWinProbe = 0 tcpOutRsts = 9543 tcpInSegs =6142268941 tcpInAckSegs = 0 tcpInDupAck =1916922 tcpInInorderSegs =904589648 tcpInUnorderSegs = 0 tcpInDupSegs = 3916 tcpInPartDupSegs = 0 tcpInPastWinSegs = 0 tcpInWinProbe = 0 tcpInClosed = 3201 tcpRttUpdate =909252730 tcpTimRetransDrop = 351 tcpTimKeepaliveProbe= 3300 tcpListenDrop = 127 tcpHalfOpenDrop = 0 tcpInErrs = 0

tcpRtoMin tcpMaxConn tcpPassiveOpens tcpEstabResets tcpOutSegs tcpOutDataBytes tcpRetransBytes tcpOutAckDelayed tcpOutWinUpdate tcpOutControl tcpOutFastRetrans

= 400 = -1 =1886858 = 6999 =4822435795 =320023296 =3223066 =43086430 = 1677 =3842327 = 0

tcpInAckBytes tcpInAckUnsent tcpInInorderBytes tcpInUnorderBytes tcpInDupBytes tcpInPartDupBytes tcpInPastWinBytes tcpInWinUpdate tcpRttNoUpdate tcpTimRetrans tcpTimKeepalive tcpTimKeepaliveDrop tcpListenDropQ0 tcpOutSackRetrans udpNoPorts

=300546783 = 0 =3680776830 = 0 =175475 = 0 = 0 = 0 = 0 = 10513 =107692 = 0 = 0 = 15 = 579

Przez wiele sekund przyglædađem siú wyħwietlanym danym, przede wszystkim wartoħciom tcpListenDrop, tcpListenDropQ0 i tcpRetransSegs. Nie pokazywađy one jednak niczego niepokojæcego. Pozostawiđem dziađajæce polecenie, wyħwietlajæce podsumowanie pewnych przedziađów czasu, a sam zajæđem siú dalszæ lekturæ zgđoszenia problemu przez klienta (te informacje obejmowađy kilka stron tekstu). Uderzyđ mnie fakt, ľe nie wiedziađem, czy powinienem od razu dostrzec problem, czy teľ nie. Zapytađem wiúc Jamesa, jak czústo wystúpowađo duľe opóļnienie ľædaē aplikacji Redis. James odpowiedziađ: „zawsze”. To nie byđa odpowiedļ, której siú spodziewađem! Chciađem otrzymaè nieco dokđadniejsze informacje, które pomogđyby mi zrozumieè dane wyjħciowe polecenia netstat. Czy powinienem oczekiwaè opóļnieē co sekundú, minutú czy godzinú? James równieľ tego nie wiedziađ, ale obiecađ, ľe siú dowie i przekaľe mi te informacje. Zakoēczyđem lekturú zgđoszenia i otworzyđem kilka dodatkowych okien terminala, aby równoczeħnie zalogowaè siú do systemu, i wtedy kilka myħli przyszđo mi do gđowy:

686

Rozdział 13









Studium przypadku

„To nie jest dobry sposób na wykorzystanie mojego czasu”. Nathan jest weteranem, jeħli chodzi o analizú wydajnoħci, a inni w dziale pomocy technicznej przeprowadzili rozsædne dziađania. Nadzieja, ľe jedno z moich narzúdzi specjalnych opartych na DTrace búdzie w stanie wychwyciè rzeczywiste ļródđo problemu, wydaje siú byè loteriæ. Poħwiúcú, powiedzmy, kwadrans na powaľnæ analizú systemu i jeħli niczego nie znajdú, przekaľú sprawú ponownie Jamesowi. „Z drugiej strony, moje oparte na DTrace narzúdzia mogú wykorzystaè do rozwiæzania kolejnego rzeczywistego problemu, a nastúpnie mogú jeszcze bardziej je rozbudowaè dziúki nowo zdobytym doħwiadczeniom. W kwestii monitorowania TCP chciađbym rozbudowaè narzúdzia jeszcze bardziej, a to doskonađa okazja, aby wreszcie siú tym zajæè. Jednak praca nad rozbudowæ narzúdzi nie jest waľniejsza niľ rozwiæzanie innych zgđoszonych przez klientów problemów, nad którymi wđaħnie pracujú. Moľe wiúc powinienem siú z tym wstrzymaè?”. „Ups, co to jest Redis?”.

Zupeđnie zapomniađem, co to jest Redis. Sđyszađem o tym wczeħniej, ale absolutnie nie mogđem sobie przypomnieè, do czego sđuľy. Czy to serwer aplikacji, bazy danych, a moľe narzúdzie do równowaľenia obciæľenia? Czuđem siú jak idiota. Koniecznie chciađem siú ogólnie dowiedzieè, czym jest Redis. Ta wiedza stanowiđaby doskonađy kontekst dla róľnych danych statystycznych, które miađem zamiar przeanalizowaè. W pierwszej kolejnoħci spojrzađem na system, uľywajæc do tego polecenia ps, aby dowiedzieè siú nieco wiúcej o procesie Redis i poznaè jego argumenty. Znalazđem proces o nazwie redis-server, ale to niewiele mi rozjaħniđo w gđowie. Szybkie przejrzenie zasobów internetu (wyszukiwarka Google) dostarczyđo mi w czasie poniľej minuty informacji o procesie Redis (pochodzæ one z Wikipedii): Redis to mechanizm przechowywania danych w postaci klucz-wartoħè, przeznaczony do szybkiego dziađania jedynie z poziomu pamiúci operacyjnej (patrz odwođanie [1] na koēcu rozdziađu). W tym momencie problem stađ siú powaľniejszy. Skoro dane sæ przechowywane w pamiúci, to jaki problem moľe spowodowaè, ľe wydajnoħè czasami drastycznie spada i opóļnienie przekracza sekundú? To przypomniađo mi nietypowe problemy zwiæzane z algorytmem szeregowania w jædrze, które powodowađy blokowanie dziađajæcych wætków przez dđuľszy czas. Wprawdzie za pomocæ narzúdzia DTrace mógđbym ponownie monitorowaè szeregowanie w jædrze, ale to wymaga duľej iloħci czasu. Powinienem wiúc sprawdziè, czy system zawiera wersjú jædra, w której poprawiono wspomniane bđúdy.

13.1.4. Wybierz własną drogę Na tym etapie istniađo kilka kierunków, w których mogđem podæľyè: 

Przeanalizowanie danych statystycznych polecenia netstat, z których wiúkszoħè jeszcze nie przejrzađem. W danej chwili polecenie netstat dziađađo od kilku minut i wyħwietliđo okođo 10 000 danych statystycznych. Dane byđy wyħwietlane szybciej, niľ mogđem je czytaè. Rozwiæzaniem mogđo byè poħwiúcenie na przykđad

13.1. Studium przykładu: czerwony wieloryb

687

10 minut na próbú odczytania jak najwiúkszej liczby wspomnianych danych w nadziei na odkrycie czegoħ nietypowego, co moľna poddaè dalszej analizie. 











Wykorzystanie mojego narzúdzia opartego na DTrace i rozbudowanie go. Mógđbym wybraè interesujæce mnie zdarzenia w jædrze, miúdzy innymi retransmisje i utratú pakietów, a nastúpnie wyħwietliè informacje szczegóđowe o nich. To na pewno byđoby szybsze niľ przeglædanie danych wyjħciowych polecenia netstat i mogđoby dostarczyè pewnych informacji dotyczæcych obszarów pominiútych przez dane statystyczne wygenerowane za pomocæ wspomnianego polecenia. Ponadto zyskađbym moľliwoħè dalszej rozbudowy moich narzúdzi, co búdzie przydatne podczas rozwiæzywania problemów innych klientów, a takľe po prostu pozwoli na udostúpnienie nowych wersji. Przeglædanie bazy danych bđúdów poprzednich wersji jædra pod kætem problemów zwiæzanych z szeregowaniem oraz ustalenie wersji jædra, w których bđúdy zostađy usuniúte, a nastúpnie sprawdzenie wersji jædra w naszym systemie. Poza tym za pomocæ narzúdzia DTrace mógđbym sprawdziè jædro pod kætem nowych bđúdów zwiæzanych z szeregowaniem. Tego rodzaju bđæd w przeszđoħci prowadziđ do powstawania jednosekundowego opóļnienia podczas wykonywania zapytaē do bazy danych. Zrobienie kroku wstecz i sprawdzenie ogólnego stanu systemu, aby na poczætku wyeliminowaè inne moľliwe wæskie gardđa. Do tego celu naleľy wykorzystaè metodú USE, a sprawdzenie kluczowych kombinacji zajmie jedynie kilka minut. Przygotowanie teoretycznego modelu aplikacji Redis za pomocæ teorii kolejek i uľycie go do utworzenia modelu opóļnienie kontra obciæľenie. W ten sposób zyskađbym moľliwoħè okreħlenia, czy jednosekundowe opóļnienia mogæ powstawaè naturalnie na skutek oczekiwania w kolejce. To interesujæce rozwiæzanie, ale moľe byè bardzo czasochđonne. Poszukanie dostúpnej w internecie bazy bđúdów aplikacji Redis, a nastúpnie wyszukanie w niej zgđoszonych bđúdów zwiæzanych z wydajnoħciæ, zwđaszcza z jednosekundowymi opóļnieniami. Prawdopodobnie istnieje równieľ forum spođecznoħci lub kanađ IRC, na którym mógđbym zadaè odpowiednie pytanie. Wykorzystanie narzúdzia DTrace do zagđúbienia siú w komponenty aplikacji Redis. Na poczætek zajúcie siú opóļnieniem odczytu, a nastúpnie przejħcie dalej. Do tego celu mógđbym posđuľyè siú skryptem w stylu mojego zfsslower.d i monitorowaè Redis za pomocæ dostawcy pid w DTrace. W ten sposób mógđbym podaè argument w postaci opóļnienia i monitorowaè tylko odczyty wolniejsze niľ — powiedzmy — 500 ms. To doskonađy punkt wyjħcia do dalszej analizy.

Rozwiæzaniem, którego nie brađem pod uwagú, byđo przygotowanie charakterystyki obciæľenia aplikacji Redis na wypadek, gdyby jednosekundowe opóļnienia byđy po prostu duľymi operacjami odczytu, a tym samym wymagajæcymi wiúkszego czasu. Na przykđad nieznany klientowi uľytkownik bazy danych moľe czasami przeprowadzaè operacje odczytu o wielkoħci 1 GB, które w stosowanym przez klienta oprogramowaniu monitorujæcym pojawiajæ siú jako wzrost wartoħci opóļnienia. Wykluczyđem tú moľliwoħè, poniewaľ Nathan przeprowadziđ test za pomocæ polecenia curl i odkryđ, ľe opóļnienie moľe powstaè podczas odczytów o mađej wielkoħci.

688

Rozdział 13



Studium przypadku

Zdecydowađem siú na uľycie metody USE. W przeszđoħci okazywađa siú dobrym punktem wyjħcia podczas rozwiæzywania problemów zwiæzanych z wydajnoħciæ. To równieľ pomoľe Jamesowi w wyjaħnieniu klientowi, ľe zgđoszony problem potraktowaliħmy powaľnie i w peđni sprawdziliħmy stan naszego systemu.

13.1.5. Metoda USE Jak wspomniano w rozdziale 2. „Metodologia”, metoda USE umoľliwia sprawdzenie stanu systemu, wykrycie wæskich gardeđ i ewentualnych bđúdów. W przypadku kaľdego zasobu sprawdzam trzy metryki: poziom wykorzystania, nasycenie i bđúdy. Dla zasobów o znaczeniu kluczowym (procesor, pamiúè, dyski i sieè) dostúpne sæ dziesiætki metryk do sprawdzenia, które spokojnie pobijæ wygenerowane dotæd przez netstat 10 000 wierszy koniecznych do przejrzenia.

Procesor Uruchomiđem polecenie fmdump, aby przekonaè siú, czy wystæpiđy jakiekolwiek bđúdy w procesorze. Ľadnych bđúdów nie stwierdzono. Nastúpnie sprawdziđem poziom wykorzystania i nasycenie procesora na poziomie systemu. W tym celu skorzystađem z polecenia vmstat. Te same dane, ale dla poszczególnych procesorów sprawdziđem za pomocæ mpstat. Wszystkie dane przedstawiađy siú ħwietnie, mnóstwo wolnych zasobów procesora i ani jednego obciæľonego w duľym stopniu. Na wypadek, gdyby klient osiægnæđ limit nađoľony przez chmurú, za pomocæ polecenia kstat sprawdziđem takľe i tú wartoħè. Podobnie jak wczeħniej, takľe tutaj wszystko byđo w porzædku.

Pamięć Bđúdy fizyczne powinny byè wychwycone juľ przez wczeħniejsze wywođanie polecenia fmdump, a wiúc od razu przeszedđem do poziomu wykorzystania i nasycenia pamiúci. Poprzednio wydađem polecenie vmstat 1 podczas sprawdzania poziomu uľycia procesora na poziomie systemu i zwróciđem uwagú na ogromnæ iloħè wolnej pamiúci operacyjnej oraz wirtualnej, a takľe na brak dziađajæcego skanera stron (pomiar nasycenia). Wydađem polecenie vmstat -p 1 w celu sprawdzenia wystúpowania anonimowego skanowania, które mogđo byè skutkiem ograniczeē nakđadanych przez chmurú, nawet jeħli komputer ma duľæ iloħè wolnej pamiúci. Wartoħci w kolumnie api (anonimowe operacje page-in) okazađy siú niezerowe! $ vmstat -p 1 memory page swap free re mf fr 60222344 10272672 331 756 48966364 1023432 208 1133 48959268 1016308 335 1386 [...]

executable de sr epi epo epf 2728 688 27 0 0 0 2047 608 0 0 0 0 3981 528 0 0 0 0

anonymous api apo apf 2 5 5 168 0 0 100 0 0

filesystem fpi fpo fpf 4 2723 2723 0 2047 2047 0 3981 3981

13.1. Studium przykładu: czerwony wieloryb

689

Anonimowe operacje page-in wystúpujæ, poniewaľ aplikacja rozrosđa siú zbyt bardzo, przestađa mieħciè siú w pamiúci operacyjnej (lub nađoľonym limicie) i jej dane zostađy umieszczone w fizycznym urzædzeniu wymiany (w systemie Linux ten proces jest nazywany wymianæ). Kiedy aplikacja búdzie potrzebowađa zapisanej strony pamiúci, wtedy trzeba búdzie jæ odczytaè z urzædzenia wymiany. To oznacza spore opóļnienie, zamiast operacji wejħcia-wyjħcia w pamiúci konieczne jest wykonanie dyskowej operacji wejħcia-wyjħcia, co powoduje znaczny spadek wydajnoħci dziađania aplikacji. Jednosekundowe lub nawet dđuľsze odczyty mogæ byè wđaħnie skutkiem wspomnianych anonimowych operacji page-in. Pojedyncza metryka najczúħciej nie stanowi potwierdzenia istnienia problemu zwiæzanego z wydajnoħciæ (wyjætkiem jest tutaj wiele rodzajów bđúdów). Jednak anonimowe operacje page-in to bardzo dobry sygnađ wskazujæcy na prawdziwy problem, potwierdzony niemal natychmiastowo. Poniewaľ chciađem mieè absolutnæ pewnoħè, wydađem polecenie prstat -mLc w celu sprawdzenia mikrostanów wætków (wspomniađem o tym w metodologii analizy stanu wætku): $ prstat -mLcp `pgrep redis-server` 1 PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 28168 103 0.2 0.7 0.0 0.0 0.0 0.0 99 0.0 41 0 434 0 redis-server/1 28168 103 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 redis-server/3 28168 103 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 redis-server/2 Total: 1 processes, 3 lwps, load averages: 5.01, 4.59, 4.39 PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 28168 103 0.0 0.0 0.0 0.0 98 0.0 1.8 0.0 15 0 183 0 redis-server/1 28168 103 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 redis-server/3 28168 103 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 1 0 0 0 redis-server/2 Total: 1 processes, 3 lwps, load averages: 5.17, 4.66, 4.41 PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 28168 103 0.2 0.3 0.0 0.0 75 0.0 24 0.0 24 0 551 0 redis-server/1 28168 103 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 redis-server/3 28168 103 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 redis-server/2 [...]

Wysoka wartoħè procentowa w kolumnie DFL pokazuje, ľe przez kilka sekund wætek serwera Redis oczekuje na zakoēczenie operacji wczytania stron z dysku — w normalnej sytuacji te operacje wejħcia-wyjħcia byđyby przeprowadzane w pamiúci. Poniľsze polecenie pokazuje sprawdzenie limitu pamiúci: $ zonememstat -z 1a8ba189ba ZONE 1a8ba189ba

RSS 5794MB

CAP 8192MB

NOVER POUT 45091 974165MB

Wprawdzie bieľæce uľycie pamiúci (RSS) jest poniľej limitu (CAP), ale pozostađe kolumny wskazujæ na czúste przekraczanie limitu: 45 091 razy (NOVER), co skutkowađo zapisem na dysku 974,165 MB danych (POUT).

690

Rozdział 13



Studium przypadku

To wyglædađo na standardowy przypadek bđúdnej konfiguracji serwera, zwđaszcza z powodu przeniesienia przez klienta serwera Redis do chmury. Prawdopodobnie klient nie uaktualniđ pliku konfiguracyjnego, aby uwzglúdniè nowy limit pamiúci. Wysđađem odpowiedniæ wiadomoħè do Jamesa. Wprawdzie problem zwiæzany z pamiúciæ rzeczywiħcie wystúpowađ, ale chciađem siú upewniè, ľe to wđaħnie ten konkretny problem powodowađ jednosekundowe opóļnienia. W najlepszej sytuacji dokonađbym pomiaru czasu odczytu danych z serwera Redis i wyraziđbym czas synchronicznej blokady w DFL jako wspóđczynnik. Jeľeli jednosekundowe opóļnienie spúdza 99% czasu zablokowane w DFL, to otrzymujemy potwierdzenie powodu wolnego odczytu. To pozwala przeanalizowaè konfiguracjú pamiúci Redisa w celu znalezienia prawdziwej przyczyny. Jednak wczeħniej chciađem dokoēczyè stosowanie metody USE. Problemy zwiæzane z wydajnoħciæ czústo pojawiajæ siú w wielu miejscach.

Dyski Polecenie iostat -En nie pokazađo ľadnych bđúdów. Z kolei polecenie iostat -xnz 1 wskazađo, ľe poziom wykorzystania dysków byđ niski (%b) i nie wystúpowađo nasycenie (wait). Polecenie iostat pozostawiđem dziađajæce przez chwilú, aby móc zobaczyè odchylenia. Po chwili dostrzegđem wiúkszæ liczbú operacji zapisu: $ iostat -xnz 1 [...] r/s 42.6

w/s 3.0

r/s w/s 62.2 2128.1 r/s w/s 3.0 2170.6 r/s w/s 8.0 2596.4 r/s 251.1

w/s 1.0

extended device statistics kr/s kw/s wait actv wsvc_t asvc_t %w %b device 27.4 28.4 0.0 0.0 0.0 0.5 0 2 sd1 extended device statistics kr/s kw/s wait actv wsvc_t asvc_t %w %b device 60.7 253717.1 0.0 7.7 0.0 3.5 3 87 sd1 extended device statistics kr/s kw/s wait actv wsvc_t asvc_t %w %b device 2.5 277839.5 0.0 9.9 0.0 4.6 2 100 sd1 extended device statistics kr/s kw/s wait actv wsvc_t asvc_t %w %b device 10.0 295813.9 0.0 9.0 0.0 3.4 3 100 sd1 extended device statistics kr/s kw/s wait actv wsvc_t asvc_t %w %b device 217.0 8.0 0.0 0.7 0.0 2.9 0 66 sd1

W przypadku systemu plików ZFS gromadzæcego operacje zapisu z grupy transakcji (TXG) zaobserwowane przeze mnie zachowanie jest normalne. Operacje wejħciawyjħcia w systemie plików sæ przez aplikacjú przeprowadzane asynchronicznie i zajúty dysk nie wpđywa na nie, przynajmniej nie zawsze. Istniejæ sytuacje, w których operacje wejħcia-wyjħcia aplikacji sæ zablokowane w TXG. Zaobserwowane tutaj dyskowe operacje wejħcia-wyjħcia nie musiađy byè spowodowane przez aplikacjú Redis. W systemie sæ jeszcze inne tenanty, które mogđy przeprowadzaè operacje wejħcia-wyjħcia. Redis to ponadto baza danych znajdujæca siú w pamiúci.

13.1. Studium przykładu: czerwony wieloryb

691

Sieć Wyglædađo na to, ľe interfejsy sieciowe dziađajæ prawidđowo. Sprawdziđem je za pomocæ poleceē netstat -i oraz nicstat: ľadnych bđúdów, niski poziom wykorzystania sieci i brak nasycenia.

13.1.6. Czy to już koniec? Majæc bardzo silny ħlad w postaci uľycia pamiúci i búdæc zmuszonym do powrotu do pozostađych zadaē, odpisađem Jamesowi w nastúpujæcy sposób: „To zdaje siú jest problem zwiæzany z konfiguracjæ pamiúci — opóļnienia powstajæ na skutek anonimowych operacji page-in” i dođæczyđem zrzuty ekranu. Wyglædađo na to, ľe udađo siú szybko rozwiæzaè problem. Nieco póļniej otrzymađem od Jamesa wiadomoħè pochodzæcæ od klienta: 

 

„Czy jesteħ pewien, ľe problem jest zwiæzany z pamiúciæ? Konfiguracja pamiúci wydaje siú prawidđowa”. „Jednosekundowe opóļnienia nadal wystúpujæ”. „Wystúpujæ mniej wiúcej co 5 minut”. (To odpowiedļ na pytanie, które wczeħniej sobie zadawađem).

Czy jestem pewien? Jeľeli klient znajdowađby siú ze mnæ w jednym pomieszczeniu, musiađbym bardzo powstrzymywaè oburzenie. Dla mnie byđo oczywiste, ľe mieliħmy do czynienia z powaľnym problemem zwiæzanym z pamiúciæ. Niezerowa wartoħè kolumny api i wartoħè 98% w kolumnie DFL — systemowi brakuje pamiúci. Tak, jestem pewien! Cóľ, zastanówmy siú nad tym… Byđem pewien, ľe mamy do czynienia z powaľnym problemem zwiæzanym z pamiúciæ. Nie udađo mi siú jednak udowodniè, ľe ten problem powodowađ opóļnienia odczytu. Odkrycie wielu problemów wcale nie jest tak niezwykđe w mojej pracy. Czy to moľliwe, ľe istniađ jeszcze inny problem rzeczywiħcie powodujæcy opóļnienia odczytu, a stronicowanie pamiúci okazađo siú fađszywym tropem? To jak czerwony wieloryb! Pochodzæca od klienta informacja o piúciominutowych odstúpach czasu nie dotyczyđa problemu zwiæzanego z pamiúciæ. Kiedy wczeħniej analizowađem dane, podana wartoħè kolumny DFL byđa taka sama przez cađy czas. To zasugerowađo, ľe istotnie moľe istnieè jeszcze inny problem.

13.1.7. Podejście drugie Potrzebowađem narzúdzia, które pokazađoby nastúpujæce informacje:  

opóļnienie odczytu w serwerze Redis, komponenty czasu synchronizacji (to pozwoliđoby na sprawdzenie, co zabiera najwiúcej czasu podczas operacji odczytu).

692

Rozdział 13



Studium przypadku

Uruchomiđbym takie narzúdzie, wyszukađbym operacje odczytu wolniejsze niľ jedna sekunda, a nastúpnie sprawdziđbym, co zabierađo najwiúcej czasu w trakcie operacji. Jeľeli winna byđaby pamiúè, narzúdzie pokazađoby, ľe najwiúcej czasu jest poħwiúcane na oczekiwanie zakoēczenia anonimowej operacji page-in. Mógđbym zaczæè czytaè dostúpnæ w internecie dokumentacjú serwera Redis, aby sprawdziè, czy narzúdzie, którego potrzebujú, rzeczywiħcie istnieje. Jeľeli zdecydowađbym siú na taki krok, wyszukanie narzúdzia i uzyskanie zgody klienta na jego uruchomienie zabrađoby sporo czasu. Zwykle szybszym rozwiæzaniem jest wykorzystanie narzúdzia DTrace z poziomu strefy globalnej. DTrace potrafi zmierzyè opóļnienie odczytu Redisa. Omawiana sytuacja miađa miejsce, zanim jeszcze opracowano dostawcú Redisa dla narzúdzia DTrace, a wiúc musiađem przygotowaè wđasnæ technikú na podstawie wewnútrznego sposobu dziađania Redisa. Problem polegađ na tym, ľe zupeđnie nie wiedziađem, jaki jest wewnútrzny sposób dziađania Redisa — tak naprawdú nieco wczeħniej nawet nie pamiútađem o jego istnieniu. Wiedzy o wewnútrznym sposobie dziađania Redisa moľna oczekiwaè od jego programisty lub eksperta. Jak wiúc moľna szybko ustaliè wspomniany sposób dziađania? Trzy moľliwoħci przyszđy mi do gđowy: 





Przeanalizowanie wywođaē systemowych za pomocæ dostawcy syscall narzúdzia DTrace i podjúcie próby okreħlenia opóļnienia odczytu Redisa na podstawie tak zebranych danych. Istnieje jeszcze sprytniejszy sposób na zdobycie tego rodzaju informacji, na przykđad monitorowanie zdarzeē od accept() do close() w celu okreħlenia opóļnienia w gnieļdzie lub przeanalizowanie danych send() i recv(). Wszystko zaleľy od uľywanych wywođaē systemowych. Przeanalizowanie wewnútrznych komponentów Redisa za pomocæ dostawcy pid narzúdzia DTrace. To búdzie jednak wymagađo monitorowania wewnútrznych komponentów Redisa, o którym nic nie wiem. Wprawdzie mógđbym zapoznaè siú z kodem ļródđowym Redisa, ale to wymagađoby poħwiúcenia znacznej iloħci czasu. Duľo szybszym sposobem jest zwykle przejrzenie stosu: rozpocznij od operacji wejħcia-wyjħcia klienta i wyħwietl stosy na poziomie uľytkownika (akcja ustack() w DTrace), aby poznaè ħcieľkú kodu. Zamiast tysiúcy wierszy kodu otrzymasz informacje o funkcjach rzeczywiħcie uľytych do wykonywania pewnych zadaē i búdziesz mógđ przeanalizowaè tylko te funkcje. Przeanalizowanie wewnútrznych komponentów Redisa za pomocæ dostawcy pid narzúdzia DTrace, ale przejrzenie stosów w wyniku profilowania stosów uľytkownika z czústotliwoħciæ 97 Hz (na przykđad za pomocæ dostawcy profile narzúdzia DTrace) zamiast na podstawie operacji wejħcia-wyjħcia. Wygenerowane dane moľna wykorzystaè do utworzenia wykresu typu flame, aby ogólnie poznaè najczúħciej wybierane ħcieľki kodu.

13.1. Studium przykładu: czerwony wieloryb

693

13.1.8. Podstawy Na poczætek zdecydowađem siú sprawdziè, czy dostúpne sæ wywođania systemowe: # dtrace -n 'syscall:::entry /execname == "redis-server"/ { @[probefunc] = count(); }' dtrace: description 'syscall:::entry ' matched 238 probes CPU ID FUNCTION:NAME ^C brk fdsync forksys lwp_self rename rexit times waitsys accept setsockopt llseek lwp_sigmask fcntl ioctl open64 getpid close fstat64 read write pollsys gtime

1 1 1 1 1 1 1 1 2 2 2 2 3 3 3 8 11 12 2465 3504 15854 183171

Mamy mnóstwo wywođaē gtime(), pollsys() i write(). Wywođania pollsys() pokazujæ, ľe Redis nie uľywa portów zdarzeē, poniewaľ w takim przypadku mielibyħmy wywođania portfs(). To byđ dla mnie dzwonek alarmowy. Inny inľynier spotkađ siú z tym juľ wczeħniej, a programiħci tworzæcy aplikacjú Redis wydali odpowiedniæ đatkú poprawiajæcæ wydajnoħè. Powiedziađem o tym Jamesowi i przypomniađem mu, ľe zdarzenia portów poprawiajæ wydajnoħè okođo w 20%, podczas gdy ja szukađem elementów odstajæcych o opóļnieniu jednosekundowym. Pojedyncze wywođanie forksys() wyglædađo dziwnie, ale jeħli coħ nie wystúpuje czústo, to moľe byè monitorowane (tworzenie procesu, a nastúpnie wykonania systemowych poleceē dotyczæcych danych statystycznych). Wywođania fdstat() i fdsync() w danych wyjħciowych byđy jeszcze bardziej podejrzane. To najczúħciej wywođania systemu plików, a przecieľ Redis ma dziađaè jedynie w pamiúci. Do gry wszedđ system plików, a tym samym dyski, które niewætpliwie powodujæ duľe opóļnienie.

694

Rozdział 13



Studium przypadku

13.1.9. Zignorowanie czerwonego wieloryba Aby potwierdziè wejħcie do gry dysków i jednoczeħnie ignorujæc na chwilú problem zwiæzany z pamiúciæ, postanowiđem sprawdziè typ systemu plików oraz wywođania systemowe. Wspomniane wywođania mogæ byè skierowane do pseudosystemu plików, takiego jak sockfs, a nie opartego na dysku, na przykđad ZFS. Potwierdzenie, ľe dyski mogæ prowadziè do powstania duľego opóļnienia przekraczajæcego sekundú wymagađo pomiaru ich opóļnienia. Szybko przygotowađem pewnæ liczbú jednowierszowych wywođaē DTrace, miúdzy innymi nastúpujæcych: 

zliczanie typu systemu plików, powiedzmy, wywođaē systemowych write() dla procesów o nazwie redis-server (tylko jeden istniađ w systemie): syscall::write:entry /execname == "redis-server"/ { @[fds[arg0].fi_fs] = count(); }



pomiar opóļnienia wszystkich wywođaē systemowych jako wyraľona w nanosekundach suma: syscall:::entry /execname == "redis-server"/ { self->ts = timestamp; } syscall:::return /self->ts/ { @[probefunc] = sum(timestamp - self->ts); self->ts = 0; }

Pierwsze wywođanie pokazađo, ľe wiúkszoħè wywođaē zapisu dotyczyđa sockfs, czyli sieci. Czasami rzeczywiħcie prowadziđy do zfs. Natomiast drugie wywođanie pokazađo, ľe czasami w wywođaniach systemowych write(), fdsync() i poll() zdarzađo siú opóļnienie rzúdu setek milisekund. Opóļnienie w przypadku wywođania poll() moľe byè normalne (oczekiwanie na zadanie do wykonania — trzeba jednak sprawdziè deskryptory plików i stosy na poziomie uľytkownika), ale pozostađe, zwđaszcza fdsync(), byđy podejrzane.

13.1.10. Sprawdzenie jądra Na tym etapie uruchomiđem seriú szybkich, samodzielnie przygotowanych jednowierszowych wywođaē narzúdzia DTrace, aby znaleļè odpowiedzi na pytania dotyczæce jædra. Wywođania te obejmowađy przejħcia z warstwy wywođaē systemowych na warstwú VFS monitorowanæ za pomocæ dostawcy fbt. Na wspomnianej warstwie mogđem przeanalizowaè inne wewnútrzne komponenty jædra, uľywajæc do tego argumentów sond. To jest jednowierszowe wywođanie, które bardzo szybko zwiúkszyđo siú na tyle, ľe warto na jego podstawie utworzyè skrypt: # dtrace -n 'fbt::fop_*:entry /execname == "redis-server"/ { self->ts = timestamp; } fbt::fop_*:return /self->ts/ { @[probefunc] = sum(timestamp - self->ts); self->ts = 0; } fbt::fop_write:entry /execname == "redis-server"/ { @w[stringof(args[0]->v_op->vnop_name)] = count(); } tick-15s { printa(@); trunc(@); printa(@w); trunc(@w); }'

13.1. Studium przykładu: czerwony wieloryb

[...] 7 69700 fop_addmap fop_open fop_rwlock fop_rwunlock fop_read fop_write fop_poll sockfs [...]

695

:tick-15s 4932 8870 1444580 1447226 2557201 9157132 42784819 323

Przedstawione wywođanie wyħwietla co 15 s kilka podsumowaē. Pierwsze z nich pokazuje wywođania na poziomie VFS, uľywane przez aplikacjú Redis — ich opóļnienie wyraľone w nanosekundach zostađo zsumowane. W piútnastosekundowym podsumowaniu tylko 42 ms zostađy spúdzone w fop_poll(), a 9 ms — w fop_write(). Drugie podsumowanie wyħwietla typ zapisów do systemu plików — dla wspomnianego przedziađu czasu wszystkie zapisy dotyczyđy sockfs. Co 5 minut otrzymywađem poniľsze dane: 7 69700 fop_ioctl fop_open fop_close fop_getsecattr fop_getattr fop_lookup fop_addmap fop_create fop_read fop_rwunlock fop_rwlock fop_getpage fop_poll fop_write

:tick-15s 1980 2230 2825 2850 7198 24663 32611 80478 2677245 6707275 12485682 16603402 44540898 317532328

sockfs zfs 7 69700 fop_delmap fop_lookup fop_realvp fop_dispose fop_close fop_read fop_getpage fop_poll fop_rwunlock fop_rwlock

320 2981 :tick-15s 4886 7879 8806 30618 95575 289778 2939712 4729929 6996488 14266786

696

Rozdział 13

fop_inactive fop_write fop_fsync



Studium przypadku

15197222 493655969 625164797

sockfs zfs

35 3868

Dane wyjħciowe pierwszego przedziađu czasu pokazađy wzrost czasu spúdzonego w fop_write() do 317 ms w trakcie 15 s oraz 2981 operacji zapisu do zfs. Drugi przedziađ czasu pokazađ 493 ms w write() i 625 ms w fsync(). Na podstawie przedstawionych danych moľna stwierdziè, ľe nastúpuje zapis i synchronizacja pliku ZFS. To odkryđem juľ za pomocæ jednego z moich ulubionych skryptów DTrace: # zfsslower.d 1 TIME PROCESS 2012 Jul 21 04:01:12 redis-server redis/temp-10718.rdb

D W

KB 128

ms FILE 1 /zones/1a8ba189ba/root/var/db/

Dane wyjħciowe wskazujæ wiele operacji zapisu o wielkoħci 128 KB do pliku temp-10718.rdb. Przed usuniúciem wspomnianego pliku wydađem polecenie ls, aby sprawdziè jego wielkoħè: # ls -lh /zones/1a8ba189ba/root/var/db/redis/ total 3473666 -rw-r--r-1 103 104 856M Jul 21 04:01 dump.rdb -rw-r--r-1 103 104 6 Jul 18 01:28 redis.pid -rw-r--r-1 103 104 856M Jul 21 04:07 temp-10718.rdb

Jeľeli czas istnienia pliku byđby zbyt krótki dla polecenia ls, to moľna uľyè narzúdzia DTrace do monitorowania informacji o pliku. (Do tego celu utworzyđem skrypt o nazwie sollife.d, przedstawiony w 5. rozdziale ksiæľki DTrace — patrz odwođanie [Gregg 11] na koēcu rozdziađu). Nazwy plików zawierajæ czđony dump i temp-, a ich wielkoħè przekracza 800 MB. Wymienione pliki sæ przedmiotem wywođania fsync().Wyglæda na to, ľe pođæczenie jest naprawdú kiepskie.

13.1.11. Dlaczego? Zapis pliku tymczasowego o wielkoħci ponad 800 MB, nastúpnie wywođanie fsync(), a do tego opóļnienie przekraczajæce sekundú — wszystko zaczyna siú ukđadaè w logicznæ cađoħè i wyjaħniaè przyczynú opóļnienia w aplikacji Redis. Czústotliwoħè wynoszæca 5 minut odpowiada informacjom dostarczonym przez klienta. Przeszukujæc zasoby internetu, moľna znaleļè nastúpujæce objaħnienie dotyczæce plików tymczasowych, przygotowane przez Didiera Speziú (patrz odwođanie [2] na koēcu rozdziađu):

13.1. Studium przykładu: czerwony wieloryb

697

RDB to migawka pamiúci zapisana na dysku. W trakcie operacji BGSAVE Redis zapisuje plik tymczasowy. Po zakoēczeniu zapisu i wykonaniu fsync() jego nazwa jest zmieniana na rzeczywistæ nazwú pliku tymczasowego. W przypadku awarii podczas operacji zapisu pamiúci istniejæcy plik nigdy nie zostanie zmodyfikowany. Wszystkie ostatnio wprowadzone zmiany zostanæ utracone, ale sam plik pozostanie bezpieczny i nigdy nie búdzie uszkodzony.

Dowiedziađem siú, ľe Redis moľe wywođaè fork() dla wspomnianej operacji BGSAVE, a wiúc przeprowadzaè jæ w tle. Wczeħniej zauwaľyđem wywođania forksys(), ale tego nie sprawdziđem. Strona Wikipedii poħwiúcona narzúdziu Redis rzuca nieco wiúcej ħwiatđa (patrz odwođanie [3] na koēcu rozdziađu): Trwađoħè danych moľna osiægnæè na dwa sposoby. Pierwszy to utworzenie migawki. To póđtrwađy tryb, w którym od czasu do czasu zbiór danych jest asynchronicznie przenoszony z pamiúci na dysk. Poczæwszy od wersji 1.1 bezpieczniejszæ alternatywæ (i zarazem drugim sposobem) jest uľycie pliku pozwalajæcego tylko na dođæczanie danych (ksiúgowanie), zapisywanego podczas przetwarzania w pamiúci operacji modyfikujæcych zbiór danych. Redis oferuje moľliwoħè ponownego zapisu w tle wspomnianego pliku pozwalajæcego tylko na dođæczanie danych, aby tym samym uniknæè nadmiernego zwiúkszenia ksiúgowania.

Zasugerowano wiúc, ľe zachowanie moľe zostaè diametralnie zmienione, od peđnego zapisu pliku do ksiúgowania. Rzut oka na plik konfiguracyjny aplikacji Redis: ################################ SNAPSHOTTING ################################# # # Zapis bazy danych na dysku: # # save # # Spowoduje zapis bazy danych, jeĞli upáynĊáa podana liczba sekund i wykonano # wskazaną liczbĊ operacji zapisu. # # W poniĪszym przykáadzie zapis nastąpi w podanych przypadkach: # po 900 s (15 min), o ile zmieniono choü jeden klucz; # po 300 s (5 min), o ile zmieniono przynajmniej 10 kluczy; # po 60 s, o ile zmieniono przynajmniej 10 000 kluczy. # # Uwaga: istnieje moĪliwoĞü wyáączenia zapisu przez umieszczenie znaku # komentarza na początku wszystkich wierszy "save". save 900 1 save 300 10 save 60 10000 [...]

A wiúc mamy piúciominutowy odstúp czasu.

698

Rozdział 13



Studium przypadku

To jednak nie wszystko: ############################## APPEND ONLY MODE ############################### [...] # Wywoïanie fsync() nakazuje systemowi operacyjnemu przeprowadzenie rzeczywistej # operacji zapisu danych na dysku zamiast oczekiwaü na pojawienie siĊ wiĊkszej # iloĞci danych w buforze. Niektóre systemy operacyjne od razu zapiszą dane na dysku, # podczas gdy inne wykonają tĊ operacjĊ przy najbliĪszej okazji. # # Redis obsáuguje trzy róĪne tryby dziaáania: # # no: nie uĪywa wywoáania fsync(), system operacyjny zapisze dane w wybranym momencie. # Ten tryb jest najszybszy. # always: wywoáanie fsync() po kaĪdej operacji zapisu w dzienniku zdarzeĔ. # Ten tryb jest najwolniejszy, ale równoczeĞnie najbezpieczniejszy. # everysec: wywoáanie fsync() tylko gdy od poprzedniego wywoáania fsync() # upáynĊáa co najmniej sekunda. # Ten tryb to rodzaj kompromisu. # # DomyĞlnie stosowany jest tryb "everysec", bĊdący odpowiednim kompromisem miĊdzy szybkoĞcią # dziaáania a zapewnieniem bezpieczeĔstwa danych. Od Ciebie zaleĪy, czy moĪesz wybraü # tryb "no", który pozwoli systemowi operacyjnemu na wybór momentu zapisu danych na # dysku. To zapewnia lepszą wydajnoĞü (jeĪeli jednak moĪesz siĊ pogodziü z utratą # pewnych danych, rozwaĪ moĪliwoĞü uĪycia trybu domyĞlnego). Wybór trybu "always" # oznacza najwolniejsze dziaáanie, ale za to wiĊksze bezpieczeĔstwo niĪ w przypadku # uĪycia trybu everysec. # # JeĪeli nie jesteĞ pewien, którego trybu uĪyü, to wybierz "everysec". # appendfsync always appendfsync everysec # appendfsync no

Informacje przekazađem klientowi za poħrednictwem Jamesa i ten problem juľ nigdy nie powróciđ.

13.1.12. Epilog Podczas rozpatrywania omówionego tutaj zgđoszenia znalazđem trzy problemy dotyczæce wydajnoħci i byđem w stanie przekazaè klientowi uľyteczne sugestie: 



Stronicowanie pamiúci. Rozwiæzaniem jest ponowna konfiguracja aplikacji, aby zmieħciè siú w limicie pamiúci (moľna póļniej odkryè, ľe problem z pamiúciæ byđ spowodowany przez wywođanie fork() i operacjú BGSAVE). Wywođania pollsys(). Rozwiæzaniem jest uaktualnienie oprogramowania Redis do wersji uľywajæcej zdarzeē portu, co przekđada siú na poprawú wydajnoħci.

13.2. Komentarze



699

Konfiguracja BGSAVE. Oprogramowanie Redis co 5 minut wywođuje fsync() wzglúdem pliku o wielkoħci ponad 800 MB w celu zapisania danych. To prawdopodobna przyczyna powstawania elementów odstajæcych. Rozwiæzaniem jest inna konfiguracja oprogramowania Redis.

Nadal jestem zaskoczony, ľe istniađ jeszcze powaľniejszy problem niľ stronicowanie pamiúci. Zwykle, gdy odkryjú duľæ wartoħè kolumny DFL, klient poprawia konfiguracjú i nigdy nie zgđasza ponownie tego samego problemu. Komunikowađem siú takľe z innymi inľynierami firmy Joyent odnoħnie omówionego problemu, aby wszyscy byli na bieľæco w kwestiach dotyczæcych wydajnoħci. Jeden z nich juľ wczeħniej spotkađ siú z oprogramowaniem Redis i stwierdziđ: „To jest po prostu bđúdna konfiguracja. Serwer Redis zostađ przeznaczony do obsđugi niewielkich magazynów — na przykđad usđugi nazw — a nie baz danych o wielkoħci 800 MB”. Mój wczeħniejszy strzađ dotyczæcy 60-procentowego prawdopodobieēstwa okazađ siú trafny: „Rzeczywiħcie, tak moľe byè”. Mam teraz wiúcej informacji i kiedy kolejnym razem natknú siú na Redis, wtedy prawdopodobnie búdú dziađađ wedđug jednego z wczeħniejszych schematów. Obejmuje to miúdzy innymi utworzenie skryptu do monitorowania czasu odpowiedzi oprogramowania Redis i do podawania wartoħci komponentów skđadajæcych siú na opóļnienie synchronizacji. (Uaktualnienie: Stađo siú, ja i Redis znów razem. Utworzyđem wiúc wspomniane skrypty: redislat.d do podsumowania opóļnienia oprogramowania Redis i redisslower.d do monitorowania elementów odstajæcych — patrz odwođanie [4] na koēcu rozdziađu).

13.2. Komentarze Omówione tutaj studium przypadku pokazađo mój tok postúpowania podczas analizy problemu zwiæzanego z wydajnoħciæ. Przekonađeħ siú, ľe najczúħciej stosujú narzúdzia i metodologie omówione we wczeħniejszych rozdziađach, a takľe zobaczyđeħ, w jakiej to robiú kolejnoħci. Zaprezentowađem takľe pewne ogólne zasady wynikajæce z praktyki w zakresie analizy wydajnoħci, miúdzy innymi: 







Normalne jest, ľe na poczætku moľesz mieè niewielkæ wiedzú na temat aplikacji wskazanej przez klienta. Szybko jednak moľesz dowiedzieè siú wiúcej i opracowaè skuteczne rozwiæzanie. Popeđnianie bđúdów, pójħcie w zđym kierunku, a nastúpnie powrót na wđaħciwe tory — to równieľ norma podczas analizy problemów z wydajnoħciæ. Odkrycie wielu problemów, zanim trafisz na wđaħciwy, takľe jest czymħ normalnym. Wszystko dzieje siú pod presjæ czasu!

Z punktu widzenia osób poczætkujæcych zagubienie siú podczas analizy problemu zwiæzanego z wydajnoħciæ moľe byè zniechúcajæce. Takie uczucie równieľ jest normalne: gdy czujesz siú zagubiony, wtedy czústo siú mylisz. W tym miejscu zacytujú duēskiego fizyka Nielsa Bohra:

700

Rozdział 13



Studium przypadku

Ekspert to taki czđowiek, który popeđniđ wszystkie moľliwe bđúdy w bardzo wæskiej dziedzinie.

Dziúki przedstawieniu Ci historii, takiej jak w tym rozdziale, mam nadziejú utwierdziè Ciú w przekonaniu, ľe popeđnianie bđúdów i pójħcie w zđym kierunku jest cađkiem normalne (zdarza siú nawet najlepszym). Zaprezentowađem takľe pewne techniki i metodologie, za pomocæ których búdziesz mógđ wróciè na wđaħciwe tory.

13.3. Informacje dodatkowe Jeľeli chcesz poznaè wiúcej studiów przypadków w zakresie analizy wydajnoħci, sprawdļ bazú danych bđúdów (lub system zgđoszeē problemów) w firmie i poszukaj tych, powiæzanych z wydajnoħciæ. Warto równieľ przejrzeè tego rodzaju publiczne bazy danych poħwiúcone uľywanemu przez Ciebie systemowi operacyjnemu i aplikacjom. Wspomniane zgđoszenia zwykle zaczynajæ siú od opisu problemu i prowadzæ aľ do ostatecznego jego rozwiæzania. Wiele systemów baz danych bđúdów zawiera takľe znaczniki czasu i komentarze, co pozwala na przeħledzenie postúpu analizy, miúdzy innymi postawionych hipotez i bđúdnie wybranych kierunków dziađania. Od czasu do czasu publikowane sæ pewne studia przypadku dotyczæce wydajnoħci systemów. Znajdziesz je na przykđad na moim blogu (patrz odwođanie [5] na koēcu rozdziađu). Periodyki techniczne koncentrujæce siú na podejħciu praktycznym, na przykđad „ACM Queue” (patrz odwođanie [6] na koēcu rozdziađu), równieľ czústo prezentujæ studia przypadku jako kontekst dla omawianych nowych rozwiæzaē problemów.

13.4. Odwołania [Gregg 11] B. Gregg, J. Mauro, DTrace: Dynamic Tracing in Oracle Solaris, Mac OS X and FreeBSD, Prentice Hall, 2011. [1]

http://redis.io/

[2]

https://groups.google.com/forum/?fromgroups=#!searchin/redis-db/ temporary$20file/redis-db/pE1PloNh20U/4P5Y2WyU9w8J

[3]

http://en.wikipedia.org/wiki/Redis

[4]

https://github.com/brendangregg/dtrace-cloud-tools

[5]

http://dtrace.org/blogs/brendan/

[6]

http://queue.acm.org/

Dodatek A Metoda USE dla systemu Linux

Ten dodatek (patrz odwođanie [1] na koēcu rozdziađu) zawiera listú rzeczy do zrobienia w systemie Linux, opracowanæ dla metody USE. Wymieniona metoda sđuľy do sprawdzania stanu systemu, wykrywania najczúħciej wystúpujæcych wæskich gardeđ w zasobach oraz bđúdów. Jej dokđadne omówienie znajdziesz w rozdziale 2., zatytuđowanym „Metodologia”. W póļniejszych rozdziađach (5., 6., 7., 9. i 10.) zostađa przedstawiona w konkretnych kontekstach — zaprezentowano takľe narzúdzia, których moľna uľywaè podczas jej stosowania. Narzúdzia sđuľæce do analizy wydajnoħci czústo sæ rozbudowywane, a ponadto co jakiħ czas powstajæ zupeđnie nowe. Dlatego teľ przedstawionæ tutaj listú powinieneħ traktowaè jako punkt wyjħcia i uaktualniaè jæ, gdy zajdzie potrzeba. Byè moľe zostanæ opracowane nowe frameworki i narzúdzia monitorowania, dziúki którym stosowanie metody USE stanie siú jeszcze đatwiejsze.

701

702

Dodatek A



Metoda USE dla systemu Linux

Zasoby fizyczne Komponent

Rodzaj

Metryka

Procesor

poziom wykorzystania

Dla poszczególnych procesorów: mpstat -P ALL 1, odwrotność %idle; sar -P ALL, %idle. Dla całego systemu: vmstat 1, id; sar -u, %idle; dstat -c, idl. Dla poszczególnych procesów: top, %CPU; htop, CPU%; ps -o pcpu; pidstat 1, %CPU.

Dla poszczególnych wątków jądra: top/htop (K przełącza), gdzie VIRT == 0 (heurystyka). Procesor

nasycenie

Dla całego systemu: vmstat 1, r > liczba procesorów1; sar -q, runq-sz > liczba procesorów; dstat -p, run > liczba procesorów. Dla poszczególnych procesów: 2. kolumna /proc/PID/schedstat (sched_info.run_delay); getdelays.c, CPU2; perf sched latency (pokazuje średnie i maksymalne opóźnienie szeregowania); monitorowanie dynamiczne — na przykład SystemTap schedtimes.stp queued(us)3.

Procesor

błędy

perf (LPE) w przypadku występowania charakterystycznych

dla procesora zdarzeń błędów (CPC), na przykład 04Ah Single-bit ECC Errors Recorded by Scrubber4 w przypadku AMD64. Pojemność pamięci

poziom wykorzystania

Dla całego systemu: free -m, Mem: (pamięć operacyjna), Swap: (ilość pamięci wirtualnej); vmstat 1, free (ilość pamięci operacyjnej), swap (ilość pamięci wirtualnej); sar -r, %memused; dstat -m, free; slabtop -s c w celu sprawdzenia danych dotyczących użycia alokatora slab. Dla poszczególnych procesów: top/htop, RES (rezydentna pamięć operacyjna), VIRT (pamięć wirtualna), Mem (podsumowanie dla całego systemu).

1

Kolumna r podaje wætki oczekujæce oraz wætki dziađajæce w procesorze. Zapoznaj siú z opisem polecenia vmstat w rozdziale 6. „Procesory”.

2

Stosuje zliczanie opóļnieē, patrz rozdziađ 4. „Narzúdzia monitorowania”.

3

Istnieje równieľ punkt monitorowania sched:sched_process_wait dla narzúdzia perf. Uwaľaj na obciæľenie zwiæzane z monitorowaniem, poniewaľ zdarzenia szeregowania wystúpujæ bardzo czústo.

4

W ostatnich podrúcznikach procesorów Intel i AMD zamieszczono informacje o niewielu zdarzeniach zwiæzanych z bđúdami.

Zasoby fizyczne

703

Komponent

Rodzaj

Metryka

Pojemność pamięci

nasycenie

Dla całego systemu: vmstat 1, si/so (wymiana); sar -B, pgscank + pgscand (skanowanie); sar -W. Dla poszczególnych procesów: getdelays.c, SWAP2; 10. kolumna (min_flt) z /proc/PID/stat wskazuje ilość mniejszych awarii, monitorowanie dynamiczne5; dmesg | grep killed (OOM killer).

Pojemność pamięci

błędy

dmesg w celu sprawdzenia fizycznych awarii; monitorowanie

dynamiczne, na przykład pod kątem nieudanych wywołań malloc() (DTrace/SystemTap).

Interfejsy sieciowe

poziom wykorzystania

ip -s link, ilość danych wysyłanych (TX) i odbieranych (RX) / maksymalna przepustowość; sar -n DEV, rx/tx (kB/s) / maksymalna przepustowość; /proc/net/dev, bytes RX/TX tput/max.

Interfejsy sieciowe

nasycenie

ifconfig, overruns, dropped6; netstat -s, segments retransmited; sar -n EDEV, *drop/s, *fifo/s; /proc/net/dev, RX/TX drop;

monitorowanie dynamiczne innego kolejkowania stosu TCP/IP. Interfejsy sieciowe

błędy

ifconfig, errors, dropped6; netstat -i, RX-ERR/TX-ERR; ip -s link, errors; sar -n EDEV all; /proc/net/dev, errs, drop;

dodatkowe liczniki mogą znajdować się w /sys/ class/net/…; monitorowanie dynamiczne funkcji sterownika. Operacje wejścia-wyjścia urządzenia pamięci masowej

poziom wykorzystania

Dla całego systemu: iostat -xz 1, %util; sar -d, %util.

Operacje wejścia-wyjścia urządzenia pamięci masowej

nasycenie

Po wydaniu polecenia iostat -xnz 1 wartość kolumny avgqu-sz wynosi 1 lub więcej, a ponadto wysoka wartość w kolumnie await; sar -d tak samo; sondy LPE dla długości/opóźnienia kolejki; monitorowanie dynamiczne/statyczne podsystemu wejścia-wyjścia (obejmuje sondy LPE).

Operacje wejściawyjścia urządzenia pamięci masowej

błędy

/sys/devices/…/ioerr_cnt; smartctl; monitorowanie dynamiczne/statyczne kodów odpowiedzi podsystemu wejścia-wyjścia7.

Pojemność pamięci masowej

poziom wykorzystania

Przestrzeń wymiany: swapon -s; free; wartość SwapFree/SwapTotal w /proc/meminfo; systemy plików: df -h.

Dla poszczególnych procesów: iotop; wartość se.statistics.iowait_sum w /proc/PID/sched.

5

Moľna wykorzystaè w celu pokazania, kto zuľywa pamiúè i prowadzi do nasycenia — odbywa siú to w wyniku sprawdzenia, kto odpowiada za mniejsze awarie. Wspomniane informacje sæ podawane jako MINFLT przez polecenie htop.

6

Informacje o zagubionych pakietach sæ zawarte zarówno we wskaļnikach nasycenia, jak i bđúdów, poniewaľ gubienie pakietów nastúpuje w obu wymienionych rodzajach zdarzeē.

7

Obejmuje funkcje monitorowania na róľnych warstwach podsystemu operacji wejħcia-wyjħcia: urzædzenie blokowe, SCSI, SATA, IDE, … Dostúpne sæ pewne sondy statyczne (LEP scsi i zdarzenia punktu instrumentacji block), w pozostađych przypadkach naleľy skorzystaè z monitorowania dynamicznego.

704

Dodatek A



Metoda USE dla systemu Linux

Komponent

Rodzaj

Metryka

Pojemność pamięci masowej

nasycenie

Nie jest pewne, czy to ma sens. W przypadku zapełnienia występuje błąd typu ENOSPC.

Pojemność pamięci masowej

systemy plików: błędy

strace dla błędów typu ENOSPC; monitorowanie dynamiczne

Kontroler pamięci masowej

poziom wykorzystania

iostat -xz 1, zsumowanie urządzeń i porównanie ze znanymi ograniczeniami IOPS/tput dla poszczególnych kart.

Kontroler pamięci masowej

nasycenie

Patrz nasycenie operacji wejścia-wyjścia urządzeń pamięci masowej.

Kontroler pamięci masowej

błędy

Patrz błędy operacji wejścia-wyjścia urządzeń pamięci masowej.

Kontroler sieci

poziom wykorzystania

Wywnioskuj na podstawie ip -s link (lub sar bądź też /proc/net/dev) oraz znanych wartości maksymalnych tput dla interfejsów.

Kontroler sieci

nasycenie

Patrz nasycenie interfejsu sieciowego.

Kontroler sieci

błędy

Patrz błędy interfejsu sieciowego.

Magistrala procesora

poziom wykorzystania

LPE (CPC) dla portów magistrali procesora, tput/max.

Magistrala procesora

nasycenie

LPE (CPC) dla cykli bezczynności.

Magistrala procesora

błędy

LPE (CPC) dla wszystkiego, co można sprawdzić.

Magistrala pamięci

poziom wykorzystania

LPE (CPC) dla szyn pamięci, tput/max; ewentualnie wartość CPI większa niż, powiedzmy, 10; CPC może mieć także liczniki lokalne i zdalne.

Magistrala pamięci

nasycenie

LPE (CPC) dla cykli bezczynności.

Magistrala pamięci

błędy

LPE (CPC) dla wszystkiego, co można sprawdzić.

Magistrala wejścia-wyjścia

poziom wykorzystania

LPE (CPC) dla tput/max, o ile te wartości są dostępne; wywnioskuj na podstawie znanej tput odczytanej z iostat/ip/….

Magistrala wejścia-wyjścia

nasycenie

LPE (CPC) dla cykli bezczynności.

Magistrala wejścia-wyjścia

błędy

LPE (CPC) dla wszystkiego, co można sprawdzić.

błędów typu ENOSPC; błędy w /var/ log/messages w zależności od systemu plików; błędy w dzienniku zdarzeń aplikacji.

Informacje ogólne: Polecenia uptime i zgđaszanych przez nie „wartoħci ħrednich” (lub /proc/loadavg) nie uwzglúdniono w metrykach dla procesora, poniewaľ podawane w systemie Linux wartoħci ħrednie uwzglúdniajæ zadania w stanie niemoľliwych do przerwania operacji wejħcia-wyjħcia.

Zasoby programowe

705

LPE: Linux Performance Events to zestaw narzúdziowy przeznaczony do monitorowania, oferujæcy potúľne moľliwoħci. Odczytuje wartoħci liczników wydajnoħci procesora (CPC), a ponadto ma moľliwoħè stosowania monitorowania dynamicznego i statycznego. Interfejsem dla wymienionego zestawu jest polecenie perf, które zostađo wprowadzone w rozdziale 6. „Procesory”. CPC: liczniki wydajnoħci procesora. Patrz rozdziađ 6. „Procesory”, w którym przedstawiono przykđady ich uľycia za pomocæ perf. Magistrala wejħcia-wyjħcia: obejmuje szyny kontrolera od procesora do urzædzeē wejħcia-wyjħcia, kontrolery wejħcia-wyjħcia, a takľe szyny urzædzeē (na przykđad PCIe). Monitorowanie dynamiczne: pozwala na opracowanie wđasnych metryk. Przykđady znajdziesz w rozdziale 4. „Narzúdzia monitorowania” oraz kolejnych. W systemie Linux monitorowanie dynamiczne odbywa siú za pomocæ LPE, DTrace, SystemTap i LTTng. W dowolnym ħrodowisku uľywajæcym kontroli zasobów (na przykđad w ħrodowiskach przetwarzania w chmurze) metodú USE naleľy zastosowaè wzglúdem kaľdego ograniczenia zasobów. Wspomniane ograniczenia — a takľe limity uľycia — mogæ wystæpiè wczeħniej niľ peđne wykorzystanie zasobów sprzútowych.

Zasoby programowe Komponent

Rodzaj

Metryka

Muteks jądra

poziom wykorzystania

Przy ustawieniu CONFIG_LOCK_STATS=y, /proc/lock_stat holdtime-total/ acquisitions (sprawdź również holdtime-min, holdtime-max)8; monitorowanie dynamiczne funkcji blokad lub (ewentualnie) instrukcji.

8

Muteks jądra

nasycenie

Przy ustawieniu CONFIG_LOCK_STATS=y, /proc/lock_stat waittimetotal/contentions (sprawdź również waittime-min, waittime-max); monitorowanie dynamiczne funkcji blokad lub (ewentualnie) instrukcji; spinning pojawia się też w profilowaniu (perf record -a -g -F 997…, oprofile, DTrace, SystemTap).

Muteks jądra

błędy

Monitorowanie dynamiczne (na przykład wejścia rekurencyjnego muteksu), inne błędy mogą spowodować blokadę lub awarię jądra, przeprowadź debugowanie za pomocą kdump/crash.

Muteks użytkownika

poziom wykorzystania

valgrind --tool=drd --exclusive- threshold=... (czas

Muteks użytkownika

nasycenie

valgrind --tool=drd w celu wywnioskowania rywalizacji na podstawie

Muteks użytkownika

błędy

wstrzymania); monitorowanie dynamiczne czasu funkcji od blokady do jej zwolnienia. czasu wstrzymania; monitorowanie dynamiczne funkcji synchronizacji dla czasu oczekiwania; profilowanie (oprofile, PEL, …) stosów użytkownika. algrind --tool=drd pod kątem różnych błędów; monitorowanie dynamiczne pthread_mutex_lock() pod kątem EAGAIN, EINVAL, EPERM, EDEADLK, ENOMEM, EOWNERDEAD, ...

Analiza blokad jædra jest zwykle przeprowadzana za pomocæ narzúdzia lockmeter, które ma interfejs o nazwie lockstat.

706

Dodatek A



Metoda USE dla systemu Linux

Komponent

Rodzaj

Metryka

Pojemność zadania

poziom wykorzystania

top/htop, Tasks (wartość bieżąca); sysctl kernel.threads-max,

Pojemność zadania

nasycenie

Blokowanie wątków w trakcie alokacji pamięci; na tym etapie skaner stron powinien działać (sar -B, pgscan*); ponadto monitorowanie dynamiczne.

Pojemność zadania

błędy

Deskryptory plików

poziom wykorzystania

/proc/sys/kernel/threads-max (wartość maksymalna).

Błędy typu can't fork(); wątki na poziomie użytkownika: awarie pthread_create() z EAGAIN, EINVAL, ...; jądro: monitorowanie dynamiczne kernel_thread() pod kątem błędów typu ENOMEM.

Dla całego systemu: sar -v, file-nr kontra /proc/sys/fs/ file-max; dstat --fs, files; lub po prostu /proc/sys/fs/file-nr. Dla poszczególnych procesów: ls /proc/PID/fd | wc -l vs ulimit -n.

Deskryptory plików

nasycenie

To może nie mieć sensu.

Deskryptory plików

błędy

strace errno == EMFILE w wywołaniach systemowych zwracających deskryptory plików (na przykład open(), accept(), …).

Odwołania [1] http://www.brendangregg.com/USEmethod/use-linux.html

Dodatek B Metoda USE dla systemu Solaris

Ten dodatek (patrz odwođanie [1] na koēcu rozdziađu) zawiera listú rzeczy do zrobienia w systemie Solaris, opracowanæ dla metody USE. Zastosowanie majæ te same zastrzeľenia, które przedstawiono w dodatku A.

Zasoby fizyczne Komponent

Rodzaj

Metryka

Procesor

poziom wykorzystania

Dla poszczególnych procesorów: mpstat 1, idl. Dla całego systemu: vmstat 1, id. Dla poszczególnych procesów: prstat -c 1 (CPU == recent), prstat -mLc 1 (USR + SYS). Dla poszczególnych wątków jądra: lockstat -Ii rate, profil DTrace stack().

Procesor

nasycenie

Dla całego systemu: uptime, wartości średnie; vmstat 1, r; DTrace dispqlen.d (DTT) jako lepsza wersja vmstat r. Dla poszczególnych procesów: prstat -mLc 1, LAT.

Procesor

błędy

fmadm faulty; cpustat (liczniki wydajności procesora) dla

wszystkich obsługiwanych liczników błędów (na przykład ograniczenie termiczne).

707

708

Dodatek B



Metoda USE dla systemu Solaris

Komponent

Rodzaj

Metryka

Pojemność pamięci

poziom wykorzystania

Dla całego systemu: vmstat 1, free (pamięć operacyjna), swap (pamięć wirtualna). Dla poszczególnych procesów: prstat -c, RSS (rezydentna pamięć operacyjna), SIZE (pamięć wirtualna).

Pojemność pamięci

nasycenie

Dla całego systemu: vmstat 1, sr (skanowanie: oj niedobrze), w (doszło do operacji wymiany: bardzo niedobrze); vmstat -p 1, api (anonimowe operacje page-in — to oznacza ból), apo. Dla poszczególnych procesów: prstat -mLc 1, DFL; DTrace anonpgpid.d (DTT), vminfo:::anonpgin w execname.

1

Pojemność pamięci

błędy

fmadm faulty i prtdiag pod kątem awarii fizycznych; fmstat -s -m cpumem-retire (zdarzenia ECC); DTrace pod kątem nieudanych wywołań malloc().

Interfejsy sieciowe

poziom wykorzystania

nicstat1; kstat; dladm show-link -s -i 1 interface.

Interfejsy sieciowe

nasycenie

nicstat; kstat pod kątem wszystkich dostępnych danych statystycznych (na przykład nocanputs, defer, norcvbuf, noxmtbuf); netstat -s, retransmits.

Interfejsy sieciowe

błędy

netstat -I, liczniki błędów; dladm show-phys; kstat pod kątem rozbudowanych błędów, szukaj w interfejsie oraz danych statystycznych link (dla karty bardzo często są dostępne własne liczniki); DTrace do monitorowania dynamicznego funkcji sterownika.

Operacje wejścia-wyjścia urządzenia pamięci masowej

poziom wykorzystania

Dla całego systemu: iostat -xnz 1, %b.

Operacje wejścia-wyjścia urządzenia pamięci masowej

nasycenie

iostat -xnz 1, wait; DTrace iopending (DTT), sdqueue.d (DTB).

Operacje wejścia-wyjścia urządzenia pamięci masowej

błędy

iostat -En; DTrace podsystem wejścia-wyjścia, na przykład ideerr.d (DTB), satareasons.d (DTB), scsireasons.d (DTB), sdretry.d (DTB).

Pojemność pamięci masowej

poziom wykorzystania

przestrzeń wymiany: swap -s; systemy plików: df -h plus inne polecenia, w zależności od typu systemu plików.

Pojemność pamięci masowej

nasycenie

Nie jest pewne, czy to ma sens. W przypadku zapełnienia występuje błąd typu ENOSPC.

Pojemność pamięci masowej

błędy

DTrace monitorowanie dynamiczne; wymienione w /var/adm/messages błędy dotyczące systemu plików.

Dla poszczególnych procesów: iotop (DTT).

https://blogs.oracle.com/timc/entry/nicstat_the_solaris_and_linux

Zasoby fizyczne

709

Komponent

Rodzaj

Metryka

Kontroler pamięci masowej

poziom wykorzystania

iostat -Cxnz 1, porównanie ze znanymi ograniczeniami IOPS/tput dla poszczególnych kart.

Kontroler pamięci masowej

nasycenie

Szukaj kolejkowania w jądrze: sd (ponownie iostat wait), potok zio dla ZFS.

Kontroler pamięci masowej

błędy

DTrace monitorowanie sterownika, na przykład mptevents.d (DTB); komunikaty w /var/adm/messages.

Kontroler sieci

poziom wykorzystania

Wywnioskuj na podstawie nicstat oraz znanych wartości maksymalnych tput dla interfejsów.

Kontroler sieci

nasycenie

Patrz nasycenie interfejsu sieciowego.

Kontroler sieci

błędy

kstat dla wszystkiego, co można sprawdzić, oraz DTrace.

Magistrala procesora

poziom wykorzystania

cpustat dla portów magistrali procesora, tput/max (na przykład zobacz skrypt amd64htcpu)2.

Magistrala procesora

nasycenie

cpustat dla cykli bezczynności.

Magistrala procesora

błędy

cpustat dla wszystkiego, co można sprawdzić.

Magistrala pamięci

poziom wykorzystania

cpustat dla szyn pamięci, tput/max; ewentualnie wartość CPI większa niż, powiedzmy, 10; CPC może mieć także liczniki lokalne i zdalne.

Magistrala pamięci

nasycenie

cpustat dla cykli bezczynności.

Magistrala pamięci

błędy

cpustat dla wszystkiego, co można sprawdzić.

Magistrala wejścia-wyjścia

poziom wykorzystania

busstat (tylko SPARC); cpustat dla tput/max, o ile te wartości są

Magistrala wejścia-wyjścia

nasycenie

cpustat dla cykli bezczynności.

Magistrala wejścia-wyjścia

błędy

cpustat dla wszystkiego, co można sprawdzić.

dostępne; wywnioskuj na podstawie znanej tput odczytanej z iostat/nicstat/….

Informacje ogólne: Od systemu Solaris 10 FCS polecenia lockstat i plockstat sæ oparte na narzúdziu DTrace; patrz rozdziađ 5. „Aplikacje”. Kolumna r w danych wyjħciowych polecenia vmstat: ta wartoħè jest uaktualniana tylko raz na sekundú. CPC: liczniki wydajnoħci procesora. Patrz rozdziađ 6. „Procesory”, w którym przedstawiono przykđady ich uľycia za pomocæ cpustat. Poziom wykorzystania pojemnoħci pamiúci: interpretacja kolumny free danych wyjħciowych polecenia vmstat jest nieco utrudniona w róľnych wersjach systemu Solaris ze wzglúdu na odmienny sposób jej obliczania (patrz odwođanie [McDougall 06b] na koēcu rozdziađu). Z reguđy búdzie mniejsza, poniewaľ nieuľywanæ pamiúè jædro wykorzystuje do buforowania systemu plików (ZFS ARC). Patrz rozdziađ 7., zatytuđowany „Pamiúè”. 2

http://dtrace.org/blogs/brendan/2009/09/22/7410-hardware-update-and-analyzing-thehypertransport/

710

Dodatek B



Metoda USE dla systemu Solaris

DTT: skrypty DTrace Toolkit (patrz odwođanie [2] na koēcu rozdziađu). DTB: skrypty omówione w ksiæľce DTrace (patrz odwođanie [3] na koēcu rozdziađu). Magistrala wejħcia-wyjħcia: obejmuje szyny kontrolera od procesora do urzædzeē wejħciawyjħcia, kontrolery wejħcia-wyjħcia, a takľe szyny urzædzeē (na przykđad PCIe). Monitorowanie dynamiczne (DTrace): pozwala na opracowanie wđasnych metryk — do zastosowania równieľ w systemach produkcyjnych. Przykđady znajdziesz w rozdziale 4. „Narzúdzia monitorowania” oraz kolejnych. W dowolnym ħrodowisku stosujæcym kontrolú zasobów (na przykđad w ħrodowiskach przetwarzania w chmurze) metodú USE naleľy zastosowaè wzglúdem kaľdego ograniczenia zasobów. Wspomniane ograniczenia — a takľe limity uľycia — mogæ wystæpiè wczeħniej niľ peđne wykorzystanie zasobów sprzútowych.

Zasoby programowe Komponent

Rodzaj

Metryka

Muteks jądra

poziom wykorzystania

lockstat -H (czas wstrzymania); dostawca lockstat w DTrace.

Muteks jądra

nasycenie

lockstat -C (rywalizacja); dostawca lockstat w DTrace; spinning pokazuje również dtrace -n 'profile-997 { @[stack()] = count(); }'.

Muteks jądra

błędy

lockstat -E, wejścia rekurencyjnego muteksu (inne błędy

mogą spowodować blokadę lub awarię jądra; przeprowadź debugowanie za pomocą mdb -k). Muteks użytkownika

poziom wykorzystania

plockstat -H (czas wstrzymania); dostawca plockstat w DTrace.

Muteks użytkownika

nasycenie

plockstat -C (rywalizacja); prstat -mLc 1, LCK; dostawca plockstat w DTrace.

Muteks użytkownika

błędy

Dostawcy plockstat i pid w DTrace, sprawdzenie pod kątem EAGAIN, EINVAL, EPERM, EDEADLK, ENOMEM, EOWNERDEAD ...; patrz pthread_mutex_lock(3C).

Pojemność procesu

poziom wykorzystania

sar -v, proc-sz; kstat, unix:0:var:v_proc pod kątem wartości maksymalnej, unix:0:system_misc:nproc pod kątem wartości bieżącej; DTrace (`nproc kontra `max_nprocs).

Pojemność procesu

nasycenie

Nie jest pewne, czy to ma sens; można otrzymać kolejkowanie w pidlinklock w pid_allocate(), ponieważ skanowanie pod kątem dostępnych slotów następuje po zapełnieniu tabeli.

Pojemność procesu

błędy

Błędy typu can’t fork().

Pojemność wątku

poziom wykorzystania

Poziom użytkownika: kstat, unix:0:lwp_cache:buf_inuse pod kątem wartości bieżącej, prctl -n zone.max-lwps -i zone STREFA pod kątem wartości maksymalnej. Jądro: mdb -k lub DTrace, nthread pod kątem wartości bieżącej, pojemność wątku ograniczona przez pamięć.

Odwołania

711

Komponent

Rodzaj

Metryka

Pojemność wątku

nasycenie

Wątki zablokowane na skutek alokacji pamięci; na tym etapie powinien działać skaner pamięci (kolumna sr w danych wyjściowych vmstat), w przeciwnym razie przeanalizuj za pomocą DTrace/mdb.

Pojemność wątku

błędy

Poziom użytkownika: awarie pthread_create() na skutek EAGAIN, EINVAL, ... Jądro: thread_create() zablokowane w pamięci, ale nie ulega awarii.

Deskryptory plików

poziom wykorzystania

Dla całego systemu: jedynym ograniczeniem jest dostępna ilość pamięci operacyjnej. Dla poszczególnych procesów: pfiles kontra ulimit lub prctl -t basic -n process.max-file-descriptor PID; szybszym rozwiązaniem niż pfiles jest ls /proc/PID/fd | wc -l.

Deskryptory plików

nasycenie

To może nie mieć sensu.

Deskryptory plików

błędy

truss lub (lepiej) DTrace w celu wyszukania errno == EMFILE

w wywołaniach systemowych zwracających deskryptory plików (na przykład open(), accept(), …). Informacje ogólne: Polecenia lockstat/plockstat mogæ gubiè zdarzenia ze wzglúdu na obciæľenie. Spróbuj uľyè ograniczonej liczby sond bezpoħrednio w narzúdziu DTrace. Poziom wykorzystania deskryptorów plików: wprawdzie systemy operacyjne majæ ograniczenie ich liczby dla cađego systemu, ale Solaris nie ma tego rodzaju ograniczenia.

Odwołania [McDougall 06b] R. McDougall, J. Mauro, B. Gregg, Solaris Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris, Prentice Hall, 2006. [1]

http://www.brendangregg.com/USEmethod/use-solaris.html

[2]

http://www.brendangregg.com/dtrace.html#DTraceToolkit

[3]

http://www.dtracebook.com/

712

Dodatek B



Metoda USE dla systemu Solaris

Dodatek C Polecenie sar

W tym dodatku znajdziesz podsumowanie kluczowych opcji i metryk polecenia sar, które wyħwietla informacje o aktywnoħci systemu. Ten dodatek moľesz wykorzystaè w celu odħwieľenia wiadomoħci o dostúpnych metrykach. Peđnæ listú znajdziesz na stronie podrúcznika man. Polecenie sar zostađo wprowadzone w rozdziale 4. „Narzúdzia monitorowania”, a niektóre jego opcje byđy wykorzystywane w póļniejszych rozdziađach (6., 7., 8., 9. i 10.).

Linux Opcja

Metryka

Opis

-P ALL

%user %nice %system %iowait %steal %idle

Poziom wykorzystania dla poszczególnych procesorów.

-u

%user %nice %system %iowait %steal %idle

Poziom wykorzystania dla procesorów.

-q

runq-sz

Wielkość kolejki działania procesorów.

-B

pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff

Dane statystyczne dotyczące stronicowania.

-H

hbhugfree hbhugused

Ogromne strony.

-r

kbmemfree kbmemused kbbuffers kbcached kbcommit %commit kbactive kbinact

Poziom wykorzystania pamięci.

-R

frpg/s bufpg/s campg/s

Dane statystyczne dotyczące pamięci.

713

714

Dodatek C



Polecenie sar

Opcja

Metryka

Opis

-S

kbswpfree kbswpused kbswpcad

Poziom wykorzystania przestrzeni wymiany.

-W

pswpin/s pswpout/s

Dane statystyczne dotyczące przestrzeni wymiany.

-v

dentused file-nr inode-nr

Tabele jądra.

-d

tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util

Dane statystyczne o dysku.

-n DEV

rxpck/s txpck/s rxkB/s txkB/s

Dane statystyczne o interfejsie sieciowym.

-n EDEV

rxerr/s txerr/s coll/s rxdrop/s txdrop/s rxfifo/s txfifo/s

Błędy interfejsu sieciowego.

-n IP

irec/s fwddgm/s orq/s

Dane statystyczne dotyczące IP.

-n EIP

idisc/s odisc/s

Błędy dotyczące IP.

-n TCP

active/s passive/s iseg/s oseg/s

Dane statystyczne dotyczące TCP.

-n ETCP

atmptf/s retrans/s

Błędy dotyczące TCP.

-n SOCK

totsck ip-frag tcp-tw

Dane statystyczne dotyczące gniazda.

Niektóre opcje polecenia sar wymagajæ wđæczonych pewnych funkcji jædra (przykđadem mogæ byè ogromne strony). Ponadto niektóre metryki zostađy dodane w póļniejszych wersjach polecenia sar (tutaj omówiono opcje dostúpne w wersji 10.0.2).

Solaris Opcja

Metryka

Opis

-u

%usr %sys %idl

Poziom wykorzystania dla procesora.

-q

runq-sz %runocc

Dane statystyczne dotyczące kolejki działania.

-g

pgout/s pgpgout/s pgfree/s pgscan/s

Pierwsze dane statystyczne dotyczące stronicowania.

-p

atch/s pgin/s pgpgin/s pflt/s vflt/s slock/s

Drugie dane statystyczne dotyczące stronicowania.

-k

sml_mem lg_mem ovsz_alloc

Pamięć jądra.

-r

freemem freeswap

Nieużywana pamięć.

-w

swpin/s swpout/s

Dane statystyczne dotyczące wymiany.

-v

inod-sz

Wielkość i-węzła.

-d

%busy avque r+w/s blks/s avwait avserv

Dane statystyczne dotyczące dysku.

Polecenie sar dla systemu Solaris juľ dawno temu powinno zostaè uaktualnione. Mam nadziejú, ľe uaktualnienie pojawi siú, zanim ta ksiæľka trafi do Twoich ræk.

Dodatek D Polecenie DTrace

W tym dodatku znajdziesz wiele uľytecznych, jednowierszowych wywođaē narzúdzia DTrace. Poza tym, ľe sæ uľyteczne, pomagajæ w poznawaniu sposobu pracy ze wspomnianym narzúdziem. Czúħè wymienionych tutaj wywođaē zademonstrowano juľ w poprzednich rozdziađach. Wiele z nich moľe nie dziađaè w przedstawionej postaci, poniewaľ moľe wymagaè istnienia pewnych dostawców lub uľycia konkretnej wersji jædra. Wprowadzenie do narzúdzia DTrace przedstawiono w rozdziale 4. „Narzúdzia monitorowania”.

Dostawca syscall Wyħwietlenie wszystkich sond dostawcy syscall: dtrace -ln syscall:::entry

Zliczenie wywođaē systemowych wedđug nazw procesów: dtrace -n 'syscall:::entry { @[execname] = count(); }'

Zliczenie wywođaē systemowych wedđug nazw wywođaē systemowych: dtrace -n 'syscall:::entry { @[probefunc] = count(); }'

715

716

Dodatek D



Polecenie DTrace

Zliczenie wywođaē systemowych wedđug nazw wywođaē systemowych dla procesu o identyfikatorze 123: dtrace -n 'syscall:::entry /pid == 123/ { @[probefunc] = count(); }'

Zliczenie wywođaē systemowych wedđug nazw wywođaē systemowych dla wszystkich procesów zawierajæcych w nazwie httpd: dtrace -n 'syscall:::entry /execname == "httpd"/ { @[probefunc] = count(); }'

Monitorowanie zakoēczenia exec() wedđug czasu i nazwy procesu: dtrace -n 'syscall::exec*:return { printf("%Y %s", walltimestamp, execname); }'

Monitorowanie wywođaē open() wedđug nazw procesów i ħcieľki: dtrace -n 'syscall::open:entry { printf("%s %s", execname, copyinstr(arg0)); }'

Monitorowanie wywođaē open() wedđug nazw procesów i ħcieľki (Oracle Solaris 11): dtrace -n 'syscall::openat:entry { printf("%s %s", execname, copyinstr(arg1)); }'

Zliczenie uľywanych odmian wywođania systemowego read(): dtrace -n 'syscall::*read*:entry { @[probefunc] = count(); }'

Zliczenie wywođaē systemowych read() wedđug typu systemu plików: dtrace -n 'syscall::read:entry { @[fds[arg0].fi_fs] = count(); }'

Zliczenie wywođaē systemowych write() wedđug typu systemu plików: dtrace -n 'syscall::write:entry { @[fds[arg0].fi_fs] = count(); }'

Zliczenie wywođaē systemowych read() wedđug nazwy ħcieľki deskryptora pliku: dtrace -n 'syscall::read:entry { @[fds[arg0].fi_pathname] = count(); }'

Podsumowanie wielkoħci ľædania read() jako rozkđadu potúgi liczby 2 — wedđug nazwy procesu: dtrace -n 'syscall::read:entry { @[execname, "req (bytes)"] = quantize(arg2); }'

Podsumowanie wielkoħci zwrotnej read() jako rozkđadu potúgi liczby 2 — wedđug nazwy procesu: dtrace -n 'syscall::read:return { @[execname, "rval (bytes)"] = quantize(arg1); }'

Dostawca syscall

717

Podsumowanie cađkowitej liczby bajtów zwróconych przez read()— wedđug nazwy procesu: dtrace -n 'syscall::read:return { @[execname] = sum(arg1); }'

Podsumowanie opóļnienia wywođania read() jako rozkđadu potúgi liczby 2 dla procesu o nazwie mysqld: dtrace -n 'syscall::read:entry /execname == "mysqld"/ { self->ts = timestamp; } syscall::read:return /self->ts/ { @["ns"] = quantize(timestamp - self->ts); self->ts = 0; }'

Podsumowanie czasu procesora read() dla procesów majæcych w nazwie mysqld: dtrace -n 'syscall::read:entry /execname == "mysqld"/ { self->v = vtimestamp; } syscall::read:return /self->v/ { @["on-CPU (ns)"] = quantize(vtimestamp - self->v); self->v = 0; }'

Podsumowanie opóļnienia wywođania read() jako rozkđadu liniowego od 0 ms do 10 ms z krokiem co 1 ms — dla procesów majæcych w nazwie mysqld: dtrace -n 'syscall::read:entry /execname == "mysqld"/ { self->ts = timestamp; } syscall::read:return /self->ts/ { @["ms"] = lquantize((timestamp - self->ts) / 1000000, 0, 10, 1); self->ts = 0; }'

Podsumowanie opóļnienia wywođania read() jako rozkđadu potúgi liczby 2 — dla odczytów plików w systemie ZFS: dtrace -n 'syscall::read:entry /fds[arg0].fi_fs == "zfs"/ { self->ts = timestamp; } syscall::read:return /self->ts/ { @["ns"] = quantize(timestamp - self->ts); self->ts = 0; }'

Zliczenie wywođaē accept() wedđug nazw procesów: dtrace -n 'syscall::accept:return { @[execname] = count(); }'

Zliczenie wywođaē connect() wedđug nazw procesów: dtrace -n 'syscall::connect:entry { @[execname] = count(); }'

Monitorowanie wywođaē accept() wraz z nazwami procesów i stosem na poziomie uľytkownika: dtrace -n 'syscall::connect:entry { trace(execname); ustack(); }'

718

Dodatek D



Polecenie DTrace

Zliczenie operacji odczytu gniazda za pomocæ wywođaē read() lub recv()— wedđug nazw procesów: dtrace -n 'syscall::read:entry,syscall::recv:entry /fds[arg0].fi_fs == "sockfs"/ { @[execname] = count(); }'

Zliczenie operacji zapisu gniazda za pomocæ wywođaē write() lub send()— wedđug nazw procesów: dtrace -n 'syscall::write:entry,syscall::send:entry /fds[arg0].fi_fs == "sockfs"/ { @[execname] = count(); }'

Zliczenie wywođaē brk() na poziomie stosów uľytkownika — dla procesu o nazwie mysqld: dtrace -n 'syscall::brk:entry /execname == "mysqld"/ { @[ustack()] = count(); }'

Dostawca proc Monitorowanie nowych procesów wraz z nazwæ procesu i argumentami: dtrace -n 'proc:::exec-success { trace(curpsinfo->pr_psargs); }'

Zliczenie zdarzeē na poziomie procesu: dtrace -n 'proc::: { @[probename] = count(); }'

Monitorowanie sygnađów procesu: dtrace -n 'proc:::signal-send /pid/ { printf("%s -%d %d", execname, args[2], args[1]->pr_pid); }'

Dostawca profile Monitorowanie stosów jædra z czústotliwoħciæ 997 Hz: dtrace -n 'profile-997 /arg0/ { @[stack()] = count(); }'

Monitorowanie stosów jædra z czústotliwoħciæ 997 Hz, tylko 10 pierwszych: dtrace -n 'profile-997 /arg0/ { @[stack()] = count(); } END { trunc(@, 10); }'

Monitorowanie stosów jædra z czústotliwoħciæ 997 Hz, tylko 5 ramek: dtrace -n 'profile-997 /arg0/ { @[stack(5)] = count(); }'

Dostawca profile

719

Monitorowanie z czústotliwoħciæ 997 Hz funkcji jædra znajdujæcych siú w procesorze: dtrace -n 'profile-997 /arg0/ { @[func(arg0)] = count(); }'

Monitorowanie z czústotliwoħciæ 997 Hz moduđów jædra znajdujæcych siú w procesorze: dtrace -n 'profile-997 /arg0/ { @[mod(arg0)] = count(); }'

Monitorowanie stosów uľytkownika z czústotliwoħciæ 97 Hz — dla procesu o identyfikatorze 123: dtrace -n 'profile-97 /arg1 && pid == 123/ { @[ustack()] = count(); }'

Monitorowanie stosów uľytkownika z czústotliwoħciæ 97 Hz — dla wszystkich procesów zawierajæcych w nazwie sshd: dtrace -n 'profile-97 /arg1 && execname == "sshd"/ { @[ustack()] = count(); }'

Monitorowanie stosów uľytkownika z czústotliwoħciæ 97 Hz — dla wszystkich procesów w systemie (dane wyjħciowe zawierajæ nazwú procesu): dtrace -n 'profile-97 /arg1/ { @[execname, ustack()] = count(); }'

Monitorowanie stosów uľytkownika z czústotliwoħciæ 97 Hz — tylko 10 pierwszych, dla procesu o identyfikatorze 123: dtrace -n 'profile-97 /arg1 && pid == 123/ { @[ustack()] = count(); } END { trunc(@, 10); }'

Monitorowanie stosów uľytkownika z czústotliwoħciæ 97 Hz — tylko 5 ramek, dla procesu o identyfikatorze 123: dtrace -n 'profile-97 /arg1 && pid == 123/ { @[ustack(5)] = count(); }'

Monitorowanie z czústotliwoħciæ 97 Hz funkcji uľytkownika znajdujæcych siú w procesorze — dla procesu o identyfikatorze 123: dtrace -n 'profile-97 /arg1 && pid == 123/ { @[ufunc(arg1)] = count(); }'

Monitorowanie z czústotliwoħciæ 97 Hz moduđów uľytkownika znajdujæcych siú w procesorze — dla procesu o identyfikatorze 123: dtrace -n 'profile-97 /arg1 && pid == 123/ { @[umod(arg1)] = count(); }'

Monitorowanie z czústotliwoħciæ 97 Hz stosów uľytkownika, miúdzy innymi w trakcie czasu systemowego, gdy stos uľytkownika jest zamroľony (najczúħciej podczas wywođania systemowego) — dla procesu o identyfikatorze 123: dtrace -n 'profile-97 /pid == 123/ { @[ustack()] = count(); }'

720

Dodatek D



Polecenie DTrace

Monitorowanie z czústotliwoħciæ 97 Hz w celu ustalenia, w którym procesorze dziađa proces — dotyczy procesu o identyfikatorze 123: dtrace -n 'profile-97 /pid == 123/ { @[cpu] = count(); }'

Dostawca sched Podsumowanie czasu spúdzonego w procesorze, w postaci rozkđadu potúgi liczby 2 — dla procesu sshd: dtrace -n 'sched:::on-cpu /execname == "sshd"/ { self->ts = timestamp; } sched:::off-cpu /self->ts/ { @["ns"] = quantize(timestamp - self->ts); self->ts = 0; }'

Podsumowanie czasu spúdzonego poza procesorem (zablokowany), w postaci rozkđadu potúgi liczby 2 — dla procesu sshd: dtrace -n 'sched:::off-cpu /execname == "sshd"/ { self->ts = timestamp; } sched:::on-cpu /self->ts/ { @["ns"] = quantize(timestamp - self->ts); self->ts = 0; }'

Zliczenie zdarzeē poza procesorem pokazujæcych stos jædra — dla procesu o nazwie sshd: dtrace -n 'sched:::off-cpu /execname == "sshd"/ { @[stack()] = count(); }'

Zliczenie zdarzeē poza procesorem pokazujæcych stos uľytkownika — dla procesu o nazwie sshd: dtrace -n 'sched:::off-cpu /execname == "sshd"/ { @[ustack()] = count(); }'

Dostawca fbt Zliczenie wywođaē VFS (Linux): dtrace -n 'fbt::vfs_*:entry'

Zliczenie wywođaē VFS (Linux) dla procesów zawierajæcych w nazwie mysqld: dtrace -n 'fbt::vfs_*:entry /execname == "mysqld"/ { @[probefunc] = count(); }'

Zliczenie wywođaē VFS (dla systemu Solaris, stabilnoħè zapewni uľycie dostawcy fsinfo): dtrace -n 'fbt::fop_*:entry { @[probefunc] = count(); }'

Dostawca pid

721

Wyħwietlenie wywođaē funkcji ext4_*(): dtrace -ln 'fbt::ext4_*:entry'

Zliczenie wywođaē funkcji ext4_*(): dtrace -n 'fbt::ext4_*:entry { @[probefunc] = count(); }'

Zliczenie wywođaē funkcji ZFS (dopasowanie do moduđu jædra zfs): dtrace -n 'fbt:zfs::entry { @[probefunc] = count(); }'

Podsumowanie opóļnienia zio_checksum_generate() w postaci rozkđadu potúgi liczby 2: dtrace -n 'fbt::zio_checksum_generate:entry { self->ts = timestamp; } fbt::zio_checksum_generate:return /self->ts/ { @["ns"] = quantize(timestamp - self->ts); self->ts = 0; }'

Podsumowanie czasu procesora dla zio_checksum_generate(): dtrace -n 'fbt::zio_checksum_generate:entry { self->v = vtimestamp; } fbt::zio_checksum_generate:return /self->v/ { @["on-CPU (ns)"] = quantize(vtimestamp - self->v); self->v = 0; }'

Podsumowanie opóļnienia wywođania VFS (Solaris) dla procesów zawierajæcych w nazwie mysqld: dtrace -n 'fbt::fop_*:entry /execname == "mysqld"/ { self->ts = timestamp; } fbt::fop_*:return /self->ts/ { @["ns"] = quantize(timestamp - self->ts); self->ts = 0; }'

Podsumowanie monitorowania stosu jædra prowadzæcego do tcp_sendmsg(): dtrace -n 'fbt::tcp_sendmsg:entry { @[stack()] = count(); }'

Podsumowanie alokacji jædra slab wedđug nazwy bufora i stosu jædra (systemy Solaris): dtrace -n 'fbt::kmem_cache_alloc:entry { @[stringof(args[0]->cache_name), stack()] = count(); }'

Dostawca pid Wyħwietlenie wszystkich funkcji z wczytanej biblioteki libsocket — dla procesu o identyfikatorze 123: dtrace -ln 'pid$target:libsocket::entry' -p 123

722

Dodatek D



Polecenie DTrace

Zliczenie wywođaē funkcji biblioteki libsocket — dla procesu o identyfikatorze 123: dtrace -n 'pid$target:libsocket::entry { @[probefunc] = count(); }' -p 123

Podsumowanie wielkoħci wywođania malloc() w postaci rozkđadu potúgi liczby 2 — dla procesu o identyfikatorze 123: dtrace -n 'pid$target::malloc:entry { @["req bytes"] = quantize(arg0); }' -p 123

Podsumowanie wielkoħci wywođania malloc() w postaci rozkđadu potúgi liczby 2 wraz z monitorowaniem stosu uľytkownika — dla procesu o identyfikatorze 123: dtrace -n 'pid$target::malloc:entry { @["req bytes, for:", ustack()] = count(); }' -p 123

Dostawca io Podsumowanie wielkoħci bloku operacji wejħcia-wyjħcia w postaci rozkđadu potúgi liczby 2: dtrace -n 'io:::start { @["bytes"] = quantize(args[0]->b_bcount); }'

Podsumowanie wielkoħci bloku operacji wejħcia-wyjħcia w postaci rozkđadu potúgi liczby 2 z uwzglúdnieniem nazwy procesu (dotyczy jedynie pewnych synchronicznych ħcieľek kodu): dtrace -n 'io:::start { @[execname] = quantize(args[0]->b_bcount); }'

Zliczenie bloków operacji wejħcia-wyjħcia wzglúdem stosu jædra (powód): dtrace -n 'io:::start { @[stack()] = count(); }'

Podsumowanie opóļnienia bloku operacji wejħcia-wyjħcia w postaci rozkđadu potúgi liczby 2: dtrace -n 'io:::start { ts[arg0] = timestamp; } io:::done /this->ts = ts[arg0]/ { @["ns"] = quantize(timestamp - this->ts); ts[arg0] = 0; }'

Dostawca sysinfo Zliczenie wywođaē miúdzy procesorami wedđug nazw procesów: dtrace -n 'sysinfo:::xcalls { @[execname] = count(); }'

Dostawca vminfo

723

Zliczenie wywođaē miúdzy procesorami wedđug stosu jædra: dtrace -n 'sysinfo:::xcalls { @[stack()] = count(); }'

Podsumowanie wielkoħci wywođania systemowego operacji odczytu, w postaci rozkđadu potúgi liczby 2, wedđug nazw procesów: dtrace -n 'sysinfo:::readch { @dist[execname] = quantize(arg0); }'

Podsumowanie wielkoħci wywođania systemowego operacji zapisu, w postaci rozkđadu potúgi liczby 2, wedđug nazw procesów: dtrace -n 'sysinfo:::writech { @dist[execname] = quantize(arg0); }'

Dostawca vminfo Zliczenie mniejszych awarii wedđug nazw procesów: dtrace -n 'vminfo:::as_fault { @[execname] = sum(arg0); }'

Zliczenie mniejszych awarii wedđug stosu uľytkownika — dla procesów zawierajæcych w nazwie mysqld: dtrace -n 'vminfo:::as_fault /execname == "mysqld"/ { @[ustack()] = count(); }'

Zliczenie anonimowych operacji page-in wedđug identyfikatora i nazw procesów: dtrace -n 'vminfo:::anonpgin { @[pid, execname] = count(); }'

Dostawca ip Zliczenie otrzymanych pakietów IP wedđug adresów komputerów: dtrace -n 'ip:::receive { @[args[2]->ip_saddr] = count(); }'

Podsumowanie wielkoħci wysyđanych danych w pakiecie IP, w postaci rozkđadu potúgi liczby 2, wedđug miejsca przeznaczenia: dtrace -n 'ip:::send { @[args[2]->ip_daddr] = quantize(args[2]->ip_plength); }'

Dostawca tcp Monitorowanie przychodzæcych pođæczeē TCP wedđug adresu zdalnego komputera: dtrace -n 'tcp:::accept-established { trace(args[3]->tcps_raddr); }'

724

Dodatek D



Polecenie DTrace

Monitorowanie przychodzæcych pođæczeē TCP wedđug adresu zdalnego komputera i portu lokalnego: dtrace -n 'tcp:::accept-established { @[args[3]->tcps_raddr, args[3]->tcps_lport] = count(); }'

Zliczenie odrzuconych pođæczeē przychodzæcych wedđug adresu zdalnego komputera i portu lokalnego: dtrace -n 'tcp:::accept-refused { @[args[2]->ip_daddr, args[4]->tcp_sport] = count(); }'

Monitorowanie wychodzæcych pođæczeē TCP wedđug adresu zdalnego komputera i portu zdalnego: dtrace -n 'tcp:::connect-established { @[args[3]->tcps_raddr , args[3]->tcps_rport] = count(); }'

Zliczenie otrzymanych pakietów TCP wedđug adresu zdalnego komputera: dtrace -n 'tcp:::receive { @[args[2]->ip_saddr] = count(); }'

Zliczenie wysđanych pakietów TCP wedđug adresu zdalnego komputera: dtrace -n 'tcp:::send { @[args[2]->ip_daddr] = count(); }'

Podsumowanie wielkoħci wysyđanych danych w pakiecie TCP, w postaci rozkđadu potúgi liczby 2: dtrace -n 'tcp:::send { @[args[2]->ip_daddr] = quantize(args[2]->ip_plength); }'

Zliczenie zdarzeē TCP wedđug typu: dtrace -n 'tcp::: { @[probename] = count(); }'

Dostawca UDP Zliczenie otrzymanych pakietów UDP wedđug adresu zdalnego komputera: dtrace -n 'udp:::receive { @[args[2]->ip_saddr] = count(); }'

Zliczenie wysđanych pakietów UDP wedđug adresu zdalnego komputera: dtrace -n 'udp:::send { @[args[4]->udp_dport] = count(); }'

Dodatek E Od DTrace do SystemTap

W tym dodatku znajdziesz krótki poradnik pokazujæcy, jak skonwertowaè skrypty i jednowierszowe wywođania DTrace na SystemTap. Oba wymienione narzúdzia zostađy wprowadzone w rozdziale 4. „Narzúdzia monitorowania”, który powinieneħ przeczytaè, aby zdobyè niezbúdne informacje o DTrace i SystemTap. Przedstawiono tutaj omówienie wybranych róľnic w zakresie funkcjonalnoħci, terminologii, sond, wbudowanych zmiennych i funkcji. Konwersjú kilku jednowierszowych wywođaē DTrace pokazano jako przykđady. Wiúcej informacji znajdziesz w artykule Translating exiting DTrace scripts into SystemTap scripts w SystemTap wiki (patrz odwođanie [1] na koēcu rozdziađu). Wspomniana strona wiki równieľ zawiera przykđady konwersji jednowierszowych wywođaē DTrace na SystemTap (czúħè z nich to moje przykđady).

Funkcjonalność SystemTap oferuje funkcjonalnoħè podobnæ do DTrace. W tabeli wymieniono najwaľniejsze róľnice, z którymi moľesz siú spotkaè podczas konwersji skryptów. DTrace

SystemTap

Opis

nazwa_sondy

proce nazwa_sondy

Wymagane jest słowo kluczowe probe.

global var;

Pewne typy zmiennych, na przykład tablice

nazwa_sondy { var[a] = … }

nazwa_sondy { var[a] = … } asocjacyjne, muszą być zadeklarowane jako

„globalne”.

725

726

Dodatek E



Od DTrace do SystemTap

DTrace

SystemTap

Opis

self->var

var[tid()]

SystemTap nie oferuje zmiennych lokalnych dla wątku (self->). Ta sama funkcjonalność jest uzyskiwana za pomocą tablicy asocjacyjnej, której kluczami są identyfikatory wątków.

/predykat/ { … }

{ if (test) { … }

Zamiast predykatów SystemTap może używać konstrukcji warunkowych w akcji sondy.

@a = count(x);

a