Tytuł oryginału: Systems Performance: Enterprise and the Cloud

Tłumaczenie: Robert Górczyński

ISBN: 978-83-246-9157-9

Authorized translation from the English language edition, entitled: SYSTEMS PERFORMANCE: ENTERPRISE AND THE CLOUD; ISBN 0133390098; by Brendan Gregg; published by Pearson Education, Inc; publishing as Prentice Hall. Copyright © 2014 Pearson Education, Inc.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. Polish language edition published by HELION S.A., Copyright © 2014.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie bierze jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Wydawnictwo HELION nie ponosi również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.

Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: [email protected] WWW: http://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/wysyko Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Printed in Poland.

• Kup książkę • Księgarnia internetowa • Poleć książkę • Lubię to! » Nasza społeczność • Oceń książkę Spis treści

Wstęp 19 Podziękowania 27 O autorze 31

Rozdział 1. Wprowadzenie 33 1.1. Wydajnoħè systemów 33 1.2. Role 34 1.3. Dziađania 35 1.4. Perspektywy 36 1.5. Zapewnienie wydajnoħci to wyzwanie 37 1.5.1. Wydajnoħè jest subiektywna 37 1.5.2. Systemy sæ skomplikowane 37 1.5.3. Moľe istnieè wiele problemów zwiæzanych z wydajnoħciæ 38 1.6. Opóļnienie 39 1.7. Monitorowanie dynamiczne 40 1.8. Przetwarzanie w chmurze 41 1.9. Studium przypadku 42 1.9.1. Wolno dziađajæce dyski 42 1.9.2. Zmiana oprogramowania 44 1.9.3. Co dalej? 46

3 Kup książkę Poleć książkę 4 Spis treści

Rozdział 2. Metodologia 47 2.1. Terminologia 48 2.2. Modele 49 2.2.1. Wydajnoħè systemu podczas testu 49 2.2.2. Systemy kolejkowe 50 2.3. Koncepcje 50 2.3.1. Opóļnienie 50 2.3.2. Skala czasu 52 2.3.3. Kompromisy 52 2.3.4. Dostrajanie wydajnoħci 54 2.3.5. Poziomy trafnoħci 55 2.3.6. Rekomendacje w danym momencie 56 2.3.7. Obciæľenie kontra architektura 56 2.3.8. Skalowalnoħè 57 2.3.9. Znane niewiadome 59 2.3.10. Metryki 59 2.3.11. Poziom wykorzystania 60 2.3.12. Nasycenie 62 2.3.13. Profilowanie 63 2.3.14. Buforowanie 63 2.4. Perspektywy 66 2.4.1. Analiza zasobów 66 2.4.2. Analiza obciæľenia 67 2.5. Metodologia 68 2.5.1. Jawna antymetoda 70 2.5.2. Antymetoda losowej zmiany 70 2.5.3. Antymetoda obwiniania kogoħ innego 71 2.5.4. Metoda przygotowanej ad hoc listy rzeczy do sprawdzenia 71 2.5.5. Opis problemu 72 2.5.6. Metoda naukowa 73 2.5.7. Cykl diagnostyczny 74 2.5.8. Metoda narzúdzi 75 2.5.9. Metoda USE 76 2.5.10. Charakterystyka obciæľenia 83 2.5.11. Analiza dræľæca 84 2.5.12. Analiza opóļnienia 85 2.5.13. Metoda R 87 2.5.14. Monitorowanie zdarzeē 87 2.5.15. Dane statystyczne búdæce punktem odniesienia 89 2.5.16. Statyczne dostosowanie wydajnoħci 89 2.5.17. Dostosowanie bufora 90 2.5.18. Mikrotesty wydajnoħci 91 2.6. Modelowanie 91 2.6.1. Biznes kontra chmura 92 2.6.2. Identyfikacja wizualna 92

Kup książkę Poleć książkę Spis treści 5

2.6.3. Prawo skalowalnoħci Amdahla 94 2.6.4. Prawo skalowalnoħci uniwersalnej 95 2.6.5. Teoria kolejek 96 2.7. Planowanie pojemnoħci 100 2.7.1. Ograniczenia zasobu 100 2.7.2. Analiza wspóđczynnika 102 2.7.3. Skalowanie rozwiæzaē 103 2.8. Statystyka 103 2.8.1. Ocena wydajnoħci 104 2.8.2. Wartoħè ħrednia 105 2.8.3. Odchylenie standardowe, percentyle i mediana 106 2.8.4. Wspóđczynnik zmiennoħci 107 2.8.5. Rozkđad wielomodalny 107 2.8.6. Elementy odstajæce 108 2.9. Monitorowanie 108 2.9.1. Wzorce na podstawie czasu 109 2.9.2. Produkty sđuľæce do monitorowania 110 2.9.3. Podsumowanie od chwili uruchomienia systemu 110 2.10. Wizualizacja 111 2.10.1. Wykres liniowy 111 2.10.2. Wykres punktowy 112 2.10.3. Mapy cieplne 113 2.10.4. Wykres warstwowy 114 2.10.5. Narzúdzia wizualizacji 115 2.11. çwiczenia 115 2.12. Odwođania 116

Rozdział 3. Systemy operacyjne 117 3.1. Terminologia 118 3.2. Ħrodowisko 119 3.2.1. Jædro 119 3.2.2. Stosy 122 3.2.3. Przerwania i wætki przerwaē 123 3.2.4. Poziom priorytetu przerwania 124 3.2.5. Procesy 125 3.2.6. Wywođania systemowe 127 3.2.7. Pamiúè wirtualna 129 3.2.8. Zarzædzanie pamiúciæ 130 3.2.9. Algorytm szeregowania 130 3.2.10. Systemy plików 132 3.2.11. Buforowanie 134 3.2.12. Sieci 134 3.2.13. Sterowniki urzædzeē 135 3.2.14. Wieloprocesorowoħè 136

Kup książkę Poleć książkę 6 Spis treści

3.2.15. Wywđaszczenie 136 3.2.16. Zarzædzanie zasobami 137 3.2.17. Monitorowanie 137 3.3. Jædra systemów 138 3.3.1. UNIX 139 3.3.2. Systemy Solaris 139 3.3.3. Systemy Linux 143 3.3.4. Róľnice 146 3.4. çwiczenia 147 3.5. Odwođania 147

Rozdział 4. Narzędzia monitorowania 149 4.1. Rodzaje narzúdzi 150 4.1.1. Liczniki 150 4.1.2. Monitorowanie 152 4.1.3. Profilowanie 153 4.1.4. Monitorowanie (sar) 154 4.2. Ļródđa danych statystycznych 155 4.2.1. Interfejs /proc 156 4.2.2. Interfejs /sys 161 4.2.3 Framework kstat 162 4.2.4. Zliczanie opóļnienia 165 4.2.5. Zliczanie mikrostanu 166 4.2.6. Inne narzúdzia monitorowania 166 4.3. DTrace 168 4.3.1. Monitorowanie statyczne i dynamiczne 170 4.3.2. Sondy 171 4.3.3. Dostawcy 172 4.3.4. Argumenty 172 4.3.5. Júzyk D 173 4.3.6. Wbudowane zmienne 173 4.3.7. Akcje 173 4.3.8. Typy zmiennych 173 4.3.9. Jednowierszowe wywođania DTrace 177 4.3.10. Skrypty 177 4.3.11. Obciæľenie 178 4.3.12. Dokumentacja i zasoby 179 4.4. SystemTap 180 4.4.1. Sondy 181 4.4.2. Zestawy tapset 181 4.4.3. Akcje i wbudowane zmienne 182 4.4.4. Przykđady 182 4.4.5. Obciæľenie 184 4.4.6. Dokumentacja i zasoby 185

Kup książkę Poleć książkę Spis treści 7

4.5. perf 185 4.6. Obserwowanie monitorowania 186 4.7. çwiczenia 187 4.8. Odwođania 187

Rozdział 5. Aplikacje 189 5.1. Podstawy dotyczæce aplikacji 190 5.1.1. Cele 191 5.1.2. Optymalizacja najczústszego sposobu uľycia aplikacji 192 5.1.3. Monitorowanie 193 5.1.4. Notacja „duľe O” 193 5.2. Techniki sprawdzania wydajnoħci aplikacji 194 5.2.1. Ustalenie wielkoħci operacji wejħcia-wyjħcia 194 5.2.2. Pamiúè podrúczna 195 5.2.3. Buforowanie 195 5.2.4. Technika odpytywania 196 5.2.5. Wspóđbieľnoħè i równolegđoħè 196 5.2.6. Nieblokujæce operacje wejħcia-wyjħcia 199 5.2.7. Powiæzanie z procesorem 200 5.3. Júzyki programowania 200 5.3.1. Júzyki kompilowane 201 5.3.2. Júzyki interpretowane 202 5.3.3. Maszyny wirtualne 203 5.3.4. Mechanizm usuwania nieuľytków 203 5.4. Metodologia i analiza 204 5.4.1. Analiza stanu wætku 205 5.4.2. Profilowanie procesora 208 5.4.3. Analiza wywođaē systemowych 210 5.4.4. Profilowanie operacji wejħcia-wyjħcia 218 5.4.5. Charakterystyka obciæľenia 219 5.4.6. Metoda USE 219 5.4.7. Analiza dræľæca 220 5.4.8. Analiza blokad 221 5.4.9. Statyczne dostosowanie wydajnoħci 223 5.5. çwiczenia 224 5.6. Odwođania 226

Rozdział 6. Procesory 227 6.1. Terminologia 228 6.2. Modele 229 6.2.1. Architektura procesora 229 6.2.2. Pamiúci podrúczne w procesorze 230 6.2.3. Kolejki dziađania w procesorze 230

Kup książkę Poleć książkę 8 Spis treści

6.3. Koncepcje 231 6.3.1. Czústotliwoħè taktowania zegara 231 6.3.2. Instrukcje 232 6.3.3. Potok instrukcji 232 6.3.4. Wielkoħè instrukcji 232 6.3.5. Wartoħci CPI, IPC 233 6.3.6. Poziom wykorzystania 233 6.3.7. Czasy uľytkownika i jædra 234 6.3.8. Poziom nasycenia 234 6.3.9. Wywđaszczenie 235 6.3.10. Odwrócenie priorytetów 235 6.3.11. Wieloprocesowoħè, wielowætkowoħè 236 6.3.12. Dđugoħè sđowa 237 6.3.13. Optymalizacja kodu wynikowego 238 6.4. Architektura 238 6.4.1. Sprzút 238 6.4.2. Oprogramowanie 246 6.5. Metodologia 253 6.5.1. Metoda narzúdzi 254 6.5.2. Metoda USE 255 6.5.3. Charakterystyka obciæľenia 256 6.5.4. Profilowanie 257 6.5.5. Analiza cykli 259 6.5.6. Monitorowanie wydajnoħci 260 6.5.7. Statyczne dostosowanie wydajnoħci 260 6.5.8. Dostrojenie priorytetu 261 6.5.9. Kontrola zasobów 262 6.5.10. Powiæzanie z procesorem 262 6.5.11. Mikrotesty wydajnoħci 262 6.5.12. Skalowanie 263 6.6. Analiza 264 6.6.1. uptime 265 6.6.2. vmstat 267 6.6.3. mpstat 268 6.6.4. sar 270 6.6.5. ps 271 6.6.6. top 272 6.6.7. prstat 273 6.6.8. pidstat 275 6.6.9. time, ptime 276 6.6.10. DTrace 277 6.6.11. SystemTap 284 6.6.12. perf 284 6.6.13. cpustat 292

Kup książkę Poleć książkę Spis treści 9

6.6.14. Inne narzúdzia 293 6.6.15. Wizualizacja 294 6.7. Eksperymenty 297 6.7.1. Ad hoc 297 6.7.2. sysbench 298 6.8. Dostrajanie 298 6.8.1. Opcje kompilatora 299 6.8.2. Klasy i priorytety szeregowania 299 6.8.3. Opcje algorytmu szeregowania 300 6.8.4. Dođæczanie procesu 302 6.8.5. Grupa procesorów na wyđæcznoħè 302 6.8.6. Kontrola zasobów 303 6.8.7. Opcje procesora (dostrajanie BIOS-u) 303 6.9. çwiczenia 303 6.10. Odwođania 305

Rozdział 7. Pamięć 307 7.1. Terminologia 308 7.2. Koncepcje 309 7.2.1. Pamiúè wirtualna 309 7.2.2. Stronicowanie 310 7.2.3. Ľædanie stronicowania 311 7.2.4. Przepeđnienie 313 7.2.5. Wymiana 313 7.2.6. Uľycie bufora systemu plików 314 7.2.7. Poziom wykorzystania i nasycenie 314 7.2.8. Alokatory 315 7.2.9. Dđugoħè sđowa 315 7.3. Architektura 315 7.3.1. Architektura sprzútowa 315 7.3.2. Oprogramowanie 321 7.3.3. Przestrzeē adresowa procesu 328 7.4. Metodologia 332 7.4.1. Metoda narzúdzi 333 7.4.2. Metoda USE 334 7.4.3. Charakterystyka uľycia pamiúci 335 7.4.4. Analiza cykli 337 7.4.5. Monitorowanie wydajnoħci 337 7.4.6. Wykrywanie wycieków pamiúci 337 7.4.7. Statyczne dostrojenie wydajnoħci 338 7.4.8. Kontrola zasobów 339 7.4.9. Mikrotesty wydajnoħci 339 7.5. Analiza 339 7.5.1. vmstat 340 7.5.2. sar 343

Kup książkę Poleć książkę 10 Spis treści

7.5.3. slabtop 345 7.5.4. ::kmastat 347 7.5.5. ps 348 7.5.6. top 350 7.5.7. prstat 350 7.5.8. pmap 351 7.5.9. DTrace 353 7.5.10. SystemTap 357 7.5.11. Inne narzúdzia 358 7.6. Dostrajanie 360 7.6.1. Parametry moľliwe do dostrojenia 360 7.6.2. Róľnej wielkoħci strony 363 7.6.3. Alokatory 364 7.6.4. Kontrola zasobów 364 7.7. çwiczenia 365 7.8. Odwođania 366

Rozdział 8. Systemy plików 369 8.1. Terminologia 370 8.2. Modele 371 8.2.1. Interfejsy systemów plików 371 8.2.2. Bufor systemu plików 371 8.2.3. Bufory poziomu drugiego 372 8.3. Koncepcje 372 8.3.1. Opóļnienie systemu plików 373 8.3.2. Buforowanie 373 8.3.3. Losowe kontra sekwencyjne operacje wejħcia-wyjħcia 374 8.3.4. Mechanizm prefetch 375 8.3.5. Odczyt z wyprzedzeniem 376 8.3.6. Buforowanie operacji zapisu 376 8.3.7. Synchroniczne operacje zapisu 377 8.3.8. Niezmodyfikowane i bezpoħrednie operacje wejħcia-wyjħcia 378 8.3.9. Nieblokujæce operacje wejħcia-wyjħcia 378 8.3.10. Mapowanie plików w pamiúci 379 8.3.11. Metadane 379 8.3.12. Logiczne kontra fizyczne operacje wejħcia-wyjħcia 380 8.3.13. Operacje nie sæ jednakowe 383 8.3.14. Specjalne systemy plików 383 8.3.15. Znaczniki czasu dotyczæce dostúpu 383 8.3.16. Pojemnoħè 384 8.4. Architektura 384 8.4.1. Stos operacji wejħcia-wyjħcia systemu plików 384 8.4.2. VFS 384 8.4.3. Bufory systemu plików 386

Kup książkę Poleć książkę Spis treści 11

8.4.4. Funkcje systemu plików 390 8.4.5. Rodzaje systemów plików 392 8.4.6. Woluminy i pule 399 8.5. Metodologia 401 8.5.1. Analiza dysku 401 8.5.2. Analiza opóļnienia 402 8.5.3. Charakterystyka obciæľenia 404 8.5.4. Monitorowanie wydajnoħci 406 8.5.5. Monitorowanie zdarzeē 407 8.5.6. Statyczne dostosowanie wydajnoħci 408 8.5.7. Dostrajanie bufora 408 8.5.8. Separacja obciæľenia 409 8.5.9. Systemy plików w pamiúci 409 8.5.10. Mikrotesty wydajnoħci 409 8.6. Analiza 411 8.6.1. vfsstat 412 8.6.2. fsstat 413 8.6.3. strace, truss 413 8.6.4. DTrace 414 8.6.5. SystemTap 425 8.6.6. LatencyTOP 425 8.6.7. free 426 8.6.8. top 426 8.6.9. vmstat 426 8.6.10. sar 427 8.6.11. slabtop 428 8.6.12. mdb ::kmastat 429 8.6.13. fcachestat 429 8.6.14. /proc/meminfo 430 8.6.15. mdb ::memstat 430 8.6.16. kstat 431 8.6.17. Inne narzúdzia 432 8.6.18. Wizualizacje 433 8.7. Eksperymenty 434 8.7.1. Ad hoc 435 8.7.2. Narzúdzia mikrotestów wydajnoħci 435 8.7.3. Opróľnienie bufora systemu plików 437 8.8. Dostrajanie 438 8.8.1. Wywođania aplikacji 438 8.8.2. ext3 439 8.8.3. ZFS 440 8.9. çwiczenia 442 8.10. Odwođania 443

Kup książkę Poleć książkę 12 Spis treści

Rozdział 9. Dyski 445 9.1. Terminologia 446 9.2. Modele 447 9.2.1. Prosty dysk 447 9.2.2. Pamiúè podrúczna dysku 447 9.2.3. Kontroler 448 9.3. Koncepcje 449 9.3.1. Pomiar czasu 449 9.3.2. Skale czasu 450 9.3.3. Buforowanie 452 9.3.4. Losowe kontra sekwencyjne operacje wejħcia-wyjħcia 452 9.3.5. Wspóđczynnik odczyt/zapis 453 9.3.6. Wielkoħè operacji wejħcia-wyjħcia 454 9.3.7. Wartoħci IOPS nie sæ równe 454 9.3.8. Polecenie dyskowe niedotyczæce transferu danych 454 9.3.9. Poziom wykorzystania 455 9.3.10. Nasycenie 456 9.3.11. Oczekiwanie na zakoēczenie operacji wejħcia-wyjħcia 456 9.3.12. Operacje synchroniczne kontra asynchroniczne 457 9.3.13. Dyskowe kontra aplikacji operacje wejħcia-wyjħcia 458 9.4. Architektura 458 9.4.1. Rodzaje dysków 458 9.4.2. Interfejsy 465 9.4.3. Rodzaje pamiúci masowej 466 9.4.4. Stos dyskowych operacji wejħcia-wyjħcia w systemie operacyjnym 469 9.5. Metodologia 473 9.5.1. Metoda narzúdzi 473 9.5.2. Metoda USE 474 9.5.3. Monitorowanie wydajnoħci 475 9.5.4. Charakterystyka obciæľenia 476 9.5.5. Analiza opóļnienia 478 9.5.6. Monitorowanie zdarzeē 479 9.5.7. Statyczne dopasowanie wydajnoħci 480 9.5.8. Dostrojenie bufora 481 9.5.9. Kontrola zasobów 481 9.5.10. Mikrotesty wydajnoħci 481 9.5.11. Skalowanie 483 9.6. Analiza 484 9.6.1. iostat 484 9.6.2. sar 493 9.6.3. pidstat 495 9.6.4. DTrace 495 9.6.5. SystemTap 505

Kup książkę Poleć książkę Spis treści 13

9.6.6. perf 505 9.6.7. iotop 506 9.6.8. iosnoop 509 9.6.9. blktrace 512 9.6.10. MegaCli 514 9.6.11. smartctl 515 9.6.12. Wizualizacje 516 9.7. Eksperymenty 520 9.7.1. Ad hoc 520 9.7.2. Wđasne generatory obciæľenia 520 9.7.3. Narzúdzia mikrotestów wydajnoħci 521 9.7.4. Przykđad losowego odczytu 521 9.8. Dostrajanie 522 9.8.1. Modyfikowalne parametry systemu operacyjnego 523 9.8.2. Modyfikowalne parametry urzædzenia dyskowego 525 9.8.3. Modyfikowalne parametry kontrolera dysku 525 9.9. çwiczenia 525 9.10. Odwođania 527

Rozdział 10. Sieć 529 10.1. Terminologia 530 10.2. Modele 530 10.2.1. Interfejs sieciowy 531 10.2.2. Kontroler 531 10.2.3. Stos protokođów 532 10.3. Koncepcje 532 10.3.1. Sieci i routing 532 10.3.2. Protokođy 533 10.3.3. Hermetyzacja 534 10.3.4. Wielkoħè pakietu 534 10.3.5. Opóļnienie 535 10.3.6. Buforowanie 537 10.3.7. Dziennik pođæczeē 537 10.3.8. Negocjacja interfejsu 538 10.3.9. Poziom wykorzystania 538 10.3.10. Pođæczenia lokalne 539 10.4. Architektura 539 10.4.1. Protokođy 539 10.4.2. Sprzút 543 10.4.3. Oprogramowanie 545 10.5. Metodologia 550 10.5.1. Metoda narzúdzi 550 10.5.2. Metoda USE 551 10.5.3. Charakterystyka obciæľenia 552 10.5.4. Analiza opóļnienia 553

Kup książkę Poleć książkę 14 Spis treści

10.5.5. Monitorowanie wydajnoħci 554 10.5.6. Podsđuchiwanie pakietów 555 10.5.7. Analiza TCP 556 10.5.8. Analiza dræľæca 557 10.5.9. Statyczne dostosowanie wydajnoħci 557 10.5.10. Kontrola zasobów 558 10.5.11. Mikrotesty wydajnoħci 559 10.6. Analiza 559 10.6.1. netstat 560 10.6.2. sar 566 10.6.3. ifconfig 568 10.6.4. ip 569 10.6.5. nicstat 569 10.6.6. dladm 570 10.6.7. ping 571 10.6.8. traceroute 572 10.6.9. pathchar 573 10.6.10. tcpdump 573 10.6.11. snoop 575 10.6.12. Wireshark 578 10.6.13. Dtrace 578 10.6.14. SystemTap 592 10.6.15. perf 592 10.6.16. Inne narzúdzia 593 10.7. Eksperymenty 594 10.7.1. iperf 594 10.8. Dostrajanie 595 10.8.1. Linux 595 10.8.2. Solaris 598 10.8.3. Konfiguracja 601 10.9. çwiczenia 602 10.10. Odwođania 603

Rozdział 11. Przetwarzanie w chmurze 605 11.1. Wprowadzenie 606 11.1.1. Wspóđczynnik cena/wydajnoħè 606 11.1.2. Skalowalna architektura 607 11.1.3. Planowanie pojemnoħci 608 11.1.4. Pamiúè masowa 610 11.1.5. Multitenancy 610 11.2. Wirtualizacja systemu operacyjnego 611 11.2.1. Obciæľenie 613 11.2.2. Kontrola zasobów 615 11.2.3. Monitorowanie 619

Kup książkę Poleć książkę Spis treści 15

11.3. Wirtualizacja sprzútowa 625 11.3.1. Obciæľenie 627 11.3.2. Kontrola zasobów 634 11.3.3. Monitorowanie 637 11.4. Porównania 644 11.5. çwiczenia 646 11.6. Odwođania 647

Rozdział 12. Testy wydajności 649 12.1. Wprowadzenie 650 12.1.1. Dziađania 650 12.1.2. Efektywne testy wydajnoħci 651 12.1.3. Grzechy testów wydajnoħci 653 12.2. Rodzaje testów wydajnoħci 660 12.2.1. Mikrotesty wydajnoħci 660 12.2.2. Symulacja 662 12.2.3. Powtarzalnoħè 663 12.2.4. Standardy biznesowe 663 12.3. Metodologia 665 12.3.1. Pasywne testy wydajnoħci 665 12.3.2. Aktywne testy wydajnoħci 667 12.3.3. Profilowanie procesora 669 12.3.4. Metoda USE 671 12.3.5. Charakterystyka obciæľenia 671 12.3.6. Wđasne testy wydajnoħci 671 12.3.7. Stopniowa zmiana obciæľenia 672 12.3.8. Sprawdzenie poprawnoħci 674 12.3.9. Analiza statystyczna 674 12.4. Pytania dotyczæce testu wydajnoħci 676 12.5. çwiczenia 678 12.6. Odwođania 678

Rozdział 13. Studium przypadku 681 13.1. Studium przykđadu: czerwony wieloryb 681 13.1.1. Zdefiniowanie problemu 682 13.1.2. Pomoc techniczna 683 13.1.3. Rozpoczúcie pracy 684 13.1.4. Wybierz wđasnæ drogú 686 13.1.5. Metoda USE 688 13.1.6. Czy to juľ koniec? 691 13.1.7. Podejħcie drugie 691 13.1.8. Podstawy 693 13.1.9. Zignorowanie czerwonego wieloryba 694 13.1.10. Sprawdzenie jædra 694

Kup książkę Poleć książkę 16 Spis treści

13.1.11. Dlaczego? 696 13.1.12. Epilog 698 13.2. Komentarze 699 13.3. Informacje dodatkowe 700 13.4. Odwođania 700

Dodatek A Metoda USE dla systemu Linux 701 Zasoby fizyczne 702 Zasoby programowe 705 Odwođania 706

Dodatek B Metoda USE dla systemu Solaris 707 Zasoby fizyczne 707 Zasoby programowe 710 Odwođania 711

Dodatek C Polecenie sar 713 Linux 713 Solaris 714

Dodatek D Polecenie DTrace 715 Dostawca syscall 715 Dostawca proc 718 Dostawca profile 718 Dostawca sched 720 Dostawca fbt 720 Dostawca pid 721 Dostawca io 722 Dostawca sysinfo 722 Dostawca vminfo 723 Dostawca ip 723 Dostawca tcp 723 Dostawca UDP 724

Dodatek E Od DTrace do SystemTap 725 Funkcjonalnoħè 725 Terminologia 726 Sondy 726 Wbudowane zmienne 727 Funkcje 727 Przykđad 1.: Wyħwietlenie sond syscall:::entry 728 Przykđad 2.: Podsumowanie wielkoħci zwrotnej wywođania read() 728 Przykđad 3.: Zliczanie wywođaē systemowych wedđug nazwy procesu 730

Kup książkę Poleć książkę Spis treści 17

Przykđad 4.: Zliczanie wywođaē systemowych wedđug nazwy wywođania systemowego dla procesu o identyfikatorze 123 731 Przykđad 5.: Zliczanie wywođaē systemowych wedđug nazwy wywođania systemowego dla procesu o nazwie httpd 731 Przykđad 6.: Monitorowanie wywođania open() wraz z nazwæ procesu i ħcieľki 732 Przykđad 7.: Podsumowanie opóļnienia read() dla procesów mysqld 732 Przykđad 8.: Monitorowanie nowych procesów wraz z nazwæ procesu i argumentami 733 Przykđad 9.: Monitorowanie stosów jædra z czústotliwoħciæ 100 Hz 733 Odwođania 733

Dodatek F Odpowiedzi do wybranych ćwiczeń 735 Rozdziađ 2. „Metodologia” 735 Rozdziađ 3. „Systemy operacyjne” 735 Rozdziađ 6. „Procesory” 735 Rozdziađ 7. „Pamiúè” 736 Rozdziađ 8. „Systemy plików” 736 Rozdziađ 9. „Dyski” 737 Rozdziađ 11. „Przetwarzanie w chmurze” 737

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

Słowniczek 743 Bibliografia 749 Skorowidz 755

Kup książkę Poleć książkę 18 Spis treści

Kup książkę Poleć książkę 5

Aplikacje

Najlepsze miejsce dostosowania wydajnoħci znajduje siú w pobliľu wykonywanej pracy, to znaczy w aplikacjach. Obejmujæ one bazy danych, serwery WWW, serwery aplikacji, programy przeznaczone do równowaľenia obciæľenia, serwery plików itd. W kolejnych rozdziađach búdziemy zajmowaè siú aplikacjami z perspektywy konsumowanych przez nie zasobów: procesora, pamiúci, systemów plików, dysków i sieci. Natomiast w tym rozdziale przyjrzymy siú samym aplikacjom. Aplikacje mogæ byè niezwykle skomplikowane, zwđaszcza w ħrodowiskach aplikacji rozproszonych, skđadajæcych siú z wielu komponentów. Analiza wewnútrznych skđadni- ków aplikacji to najczúħciej zadanie dla programistów aplikacji, którzy w tym celu mogæ korzystaè z opracowanych przez firmy trzecie narzúdzi introspekcji. Z kolei dla osób zajmujæcych siú wydajnoħciæ systemów, miúdzy innymi administratorów systemu i analityków wydajnoħci aplikacji, oznacza to przeprowadzenie konfiguracji aplikacji w taki sposób, aby jak najlepiej wykorzystaè zasoby systemowe. Ponadto konieczne jest przygotowanie charakterystyki pokazujæcej, jak aplikacja uľywa systemu, oraz przeprowadzenie analizy najczúħciej wystúpujæcych patologii. W tym rozdziale koncentrujemy siú na podstawach aplikacji, fundamentalnych zasadach dotyczæcych ich wydajnoħci, júzykach programowania, kompilatorach i stra- tegiach stosowanych podczas ogólnej analizy wydajnoħci aplikacji.

189 Kup książkę Poleć książkę 190 Rozdział 5 Aplikacje

5.1. Podstawy dotyczące aplikacji Przed przejħciem do zagadnieē zwiæzanych z wydajnoħciæ aplikacji w pierwszej ko- lejnoħci naleľy poznaè rolú aplikacji, jej podstawowæ charakterystykú oraz ekosystem w przemyħle. W ten sposób powstanie kontekst, w którym búdziesz mógđ poznaè dziađanie aplikacji. Zyskasz ponadto moľliwoħè przybliľenia sobie najczúħciej wystú- pujæcych kwestii z zakresu wydajnoħci, a takľe moľliwoħè dostosowania wydajnoħci aplikacji oraz przeprowadzenia dalszej analizy. Aby dowiedzieè siú, jak wyglæda wspo- mniany kontekst aplikacji, spróbuj udzieliè odpowiedzi na nastúpujæce pytania:

Funkcja. Jaka jest rola aplikacji? Czy to jest serwer bazy danych, serwer WWW, program do równowaľenia obciæľenia, serwer plików itd.? Operacja. Jakiego rodzaju operacje i ľædania sæ wykonywane przez aplikacje? W przypadku baz danych búdæ to zapytania (i polecenia), z kolei serwery WWW wykonujæ ľædania HTTP itd. Operacje mogæ byè mierzone jako czústotliwoħè, co pozwala sprawdziè obciæľenie i zaplanowaè pojemnoħè. Tryb procesora. Na jakim poziomie zostađa zaimplementowana aplikacja: jako oprogramowanie uľytkownika czy jædra? Wiúkszoħè aplikacji jest przeznaczona do dziađania na poziomie uľytkownika, jest uruchamiana jako jeden proces lub wiúcej procesów. Niektóre aplikacje sæ jednak implementowane jako usđugi dla jædra, na przykđad NFS. Konfiguracja. W jaki sposób jest skonfigurowana aplikacja i dlaczego wđaħnie tak? Tego rodzaju informacje moľna znaleļè w pliku konfiguracyjnym lub za pomocæ narzúdzi administracyjnych. Sprawdļ, czy zmianie ulegđy jakiekolwiek modyfikowalne parametry zwiæzane z wydajnoħciæ, miúdzy innymi wielkoħci buforów, pamiúci podrúcznej, moľliwoħè równoczesnego dziađania (procesów lub wætków) bædļ teľ inne opcje. Metryki. Czy aplikacja dostarcza jakichkolwiek metryk, na przykđad czústotliwoħci operacji? Tego rodzaju metryki mogæ byè podawane w postaci dođæczonych narzúdzi, opracowanych przez firmú trzeciæ, ľædaē API lub wskutek przetwarzania dzienników zdarzeē generowanych podczas dziađania aplikacji. Dzienniki zdarzeē. Czy aplikacja tworzy dzienniki zdarzeē? Tworzenie jakich dzienników zdarzeē wđæczono w aplikacji? Jakie metryki dotyczæce wydajnoħci, na przykđad opóļnienie, sæ dostúpne we wspomnianych dziennikach zdarzeē? Na przykđad baza danych MySQL zawiera dziennik zdarzeē rejestrujæcy wolno wykonywane zapytania. Dostarcza on niezwykle cennych informacji szczegóđowych o wydajnoħci kaľdego zapytania, którego wykonanie trwađo dđuľej niľ zdefiniowany czas. Wersja. Czy aplikacja jest w najnowszej wersji? Czy w informacjach o nowym wydaniu znajdujæ siú jakiekolwiek wzmianki o poprawkach lub usprawnieniach w zakresie wydajnoħci jej dziađania? Bđúdy. Czy dla aplikacji istnieje baza danych pozwalajæca na zgđaszanie bđúdów? Czy w tej bazie danych znajdujæ siú informacje o bđúdach „wydajnoħci” w uľywanej wersji aplikacji? Jeľeli uwaľasz, ľe wydajnoħè dziađania aplikacji

Kup książkę Poleć książkę 5.1. Podstawy dotyczące aplikacji 191

jest niezadowalajæca, przejrzyj tego rodzaju bazú bđúdów i zobacz, czy jakakolwiek podobna kwestia zostađa wczeħniej zgđoszona, jak byđa analizowana oraz co zrobiono, aby naprawiè bđæd. Spođecznoħè. Czy dla danej aplikacji istnieje spođecznoħè, z któræ moľna dzieliè siú odkrytymi problemami dotyczæcymi wydajnoħci? Spođecznoħè moľe obejmowaè miúdzy innymi fora, blogi, czaty (IRC), spotkania i konferencje. Po spotkaniach i konferencjach najczúħciej sæ zamieszczane w internecie prezentacje i materiađy wideo, które jeszcze przez wiele lat mogæ stanowiè uľyteczne zasoby. Ponadto moľe istnieè tak zwany menedľer spođecznoħci, który búdzie informowađ o uaktualnieniach i nowoħciach. Ksiæľki. Czy danej aplikacji poħwiúcono jakiekolwiek ksiæľki, na przykđad dotyczæce wydajnoħci? Eksperci. Czy istniejæ jacykolwiek uznani eksperci dla danej aplikacji? Poznanie ich nazwisk moľe pomóc w wyszukaniu przygotowanych przez nich materiađów.

Niezaleľnie od ļródđa Twoim celem jest ogólne poznanie aplikacji — do czego jest przeznaczona, w jaki sposób dziađa oraz jakæ wydajnoħè oferuje. Wrúcz nieocenionym zasobem jest wykres funkcjonalny (o ile búdziesz mógđ taki znaleļè), pokazujæcy we- wnútrzne komponenty aplikacji. W kolejnych punktach zostanæ przedstawione nastúpne podstawowe informacje do- tyczæce aplikacji: definiowania celów, optymalizacji, monitorowania oraz notacji „duľe O”.

5.1.1. Cele Dziúki zdefiniowaniu celów w zakresie wydajnoħci moľna wyznaczyè kierunek pro- wadzonej analizy wydajnoħci oraz wybraè odpowiednie kroki, które trzeba búdzie podjæè. Bez wyraļnego zdefiniowania celów istnieje ryzyko, ľe analiza wydajnoħci zamieni siú w bđædzenie po omacku w nadziei na znalezienie odpowiedniego rozwiæzania. W przypadku wydajnoħci aplikacji pracú moľna rozpoczæè od sprawdzenia operacji wykonywanych przez aplikacjú (jak wczeħniej opisano) oraz zdefiniowania celów wy- dajnoħci. Wspomnianymi celami mogæ byè:

Opóļnienie. Maksymalne skrócenie czasu udzielania odpowiedzi przez aplikacjú. Przepustowoħè. Uzyskanie jak najwiúkszej czústotliwoħci wykonywania operacji lub najwiúkszego moľliwego transferu danych. Wykorzystanie zasobów. Efektywnoħè dla danego obciæľenia aplikacji.

Znacznie lepiej búdzie, jeħli cele wydajnoħci okaľæ siú moľliwe do zmierzenia za pomo- cæ metryk speđniajæcych wymagania biznesowe i dotyczæce jakoħci usđugi, na przykđad:

Ħrednie opóļnienie w udzielaniu odpowiedzi przez aplikacjú wynosi 5 ms. 95% ľædaē jest obsđugiwanych w czasie krótszym niľ 100 ms.

Kup książkę Poleć książkę 192 Rozdział 5 Aplikacje

Eliminacja opóļnienia zwiæzanego z elementami odstajæcymi: 0 ľædaē, których wykonanie zajmuje ponad 1000 ms. Maksymalna przepustowoħè wynosi 10 000 ľædaē aplikacji kierowanych co sekundú do serwera. Ħredni poziom wykorzystania dysku wynosi poniľej 50% dla 10 000 ľædaē wykonywanych przez aplikacjú co sekundú.

Po wybraniu odpowiednich celów moľna przystæpiè do pracy polegajæcej na usuniúciu wszystkich czynników uniemoľliwiajæcych osiægniúcie wyznaczonych celów. W przy- padku opóļnienia czynnikiem ograniczajæcym mogæ byè dyskowe lub sieciowe operacje wejħcia-wyjħcia, natomiast dla celu zwiæzanego z przepustowoħciæ przeszkodæ moľe okazaè siú poziom uľycia procesora. Strategie omówione w tym i kolejnych rozdziađach pomogæ w identyfikacji czynników ograniczajæcych. W przypadku celów zwiæzanych z przepustowoħciæ warto zwróciè uwagú, ľe nie wszystkie operacje sæ równe pod wzglúdem wydajnoħci lub kosztu. Jeľeli celem jest osiægniúcie okreħlonej czústotliwoħ ci wykonywania operacji, bardzo waľne moľe byè okreħlenie rodzaju operacji. Istnieje prawdopodobieēstwo wystæpienia rozbieľnoħci na podstawie obciæľenia oczekiwanego i zmierzonego. W podrozdziale 5.2 „Techniki sprawdzania wydajnoħci aplikacji” búdæ omówione najczúħciej stosowane metody poprawy wydajnoħci dziađania aplikacji. Niektóre z nich mogæ mieè sens dla jednej grupy celów, ale juľ nie dla innej. Na przykđad zwiúkszenie operacji wejħcia-wyjħcia moľe poprawiè przepustowoħè, ale kosztem wiúkszego opóļnie- nia. Podczas dostrajania wydajnoħci aplikacji pamiútaj o zdefiniowanych celach i stosuj odpowiednie rozwiæzania pozwalajæce na ich osiægniúcie.

5.1.2. Optymalizacja najczęstszego sposobu użycia aplikacji Wewnútrzne komponenty aplikacji mogæ byè naprawdú skomplikowane i zawieraè wiele róľnych, moľliwych ħcieľek kodu oraz typów zachowania. To moľe byè szczególnie wi- doczne w trakcie analizy kodu ļródđowego: aplikacje nierzadko skđadajæ siú z dziesiætek tysiúcy wierszy kodu, natomiast w przypadku jædra systemu operacyjnego búdæ to juľ setki tysiúcy. Losowe wybranie obszaru optymalizacji moľe byè przyczynæ ogromnej pracy, której skutkiem búdzie jedynie niewielki wzrost wydajnoħci dziađania aplikacji. Jednym ze sposobów efektywnego poprawienia wydajnoħci aplikacji jest wyszukanie najczúħciej stosowanej ħcieľki kodu dla danego obciæľenia produkcyjnego i przystæ- pienie do jej usprawnienia. Jeľeli czynnikiem ograniczajæcym aplikacjú jest procesor, to moľe oznaczaè, ľe ħcieľki kodu duľæ iloħè czasu przebywajæ w procesorze. Przy ograni- czeniu zwiæzanym z operacjami wejħcia-wyjħcia warto wyszukaè ħcieľki kodu, które najczúħciej prowadzæ do powstania operacji wejħcia-wyjħcia. Wspomniane ħcieľki moľna znaleļè dziúki analizie i profilowaniu aplikacji, miúdzy innymi ħledzeniu stosu, co búdzie omówione w dalszych rozdziađach. Jeszcze lepszæ moľliwoħè poznania najczústszego sposobu uľycia aplikacji dajæ oferowane przez niæ narzúdzia monitorowania.

Kup książkę Poleć książkę 5.1. Podstawy dotyczące aplikacji 193

5.1.3. Monitorowanie Jak zostađo to omówione w wielu rozdziađach niniejszej ksiæľki, najwiúkszy przyrost wydajnoħci w systemie operacyjnym moľna uzyskaè przez eliminacjú niepotrzebnie wykonywanej pracy. Ta sama zasada dotyczy aplikacji. Ten fakt bardzo czústo jest przeoczany podczas wyboru aplikacji na podstawie jej wydajnoħci. Jeľeli przeprowadzone testy wydajnoħci pokazađy, ľe aplikacja A jest o 10% szybsza od B, to kuszæce moľe byè wybranie wđaħnie aplikacji A. Jednak jeħli aplikacja B w przeciwieēstwie do A dostarcza bogatego zestawu narzúdzi monitorowania, to ist- nieje prawdopodobieēstwo, ľe w dđuľszej perspektywie czasu lepszym wyborem búdzie aplikacja B. Dziúki wspomnianym narzúdziom monitorowania búdzie moľna wyszukaè i wyeliminowaè niepotrzebnie wykonywanæ pracú, a ponadto lepiej poznaè i dostosowaè wykonywane operacje. Osiægniúta wtedy poprawa wydajnoħci moľe przekraczaè po- czætkowæ róľnic ú, wynoszæcæ 10%.

5.1.4. Notacja „duże O” Powszechnie traktowana jako dziedzina naukowa, notacja „duľe O” jest wykorzysty- wana do analizy poziomu skomplikowania algorytmów oraz modelowania sposobu ich dziađania, gdy nastæpi wzrost zbioru danych wejħciowych. Podczas tworzenia aplikacji, dziúki wspomnianej analizie, programiħci zyskujæ wiúc moľliwoħè wyboru efektywnych algorytmów (patrz odwođania [Knuth 76] i [Knuth 97] na koēcu rozdziađu). Najczúħciej stosowane algorytmy i notacje „duľe O” zostađy wymienione w tabeli 5.1.

Tabela 5.1. Przykładowe notacje „duże O” Notacja Przykład O(1) Test boolowski. O(log n) Przeszukiwanie binarne posortowanej tablicy. O(n) Przeszukiwanie liniowe listy połączonej. O(n log n) Szybkie sortowanie (przypadek średni). O(n^2) Sortowanie bąbelkowe (przypadek średni). O(2^n) Dzielenie liczb na czynniki pierwsze, wzrost wykładniczy. O(n!) Problem komiwojażera.

Omawiana notacja pozwala programistom oszacowaè poprawú szybkoħci dziađania róľnych algorytmów i ustaliè, które obszary kodu prowadzæ do najwiúkszych przyro- stów w wydajnoħci dziađania. Na przykđad w przypadku posortowanej tablicy 100 ele- mentów róľnica miúdzy operacjami wyszukiwania liniowego i binarnego ma wspóđczyn- nik wynoszæcy 21 (100/log(100)). Wydajnoħè algorytmów wymienionych w tabeli 5.1 pokazano na rysunku 5.1, na którym widaè takľe ich trend podczas skalowania.

Kup książkę Poleć książkę 194 Rozdział 5 Aplikacje

Rysunek 5.1. Czas działania kontra wielkość danych wejściowych w przypadku różnych algorytmów

Tego rodzaju klasyfikacja pomaga analitykowi wydajnoħci systemu przekonaè siú, ľe pewne algorytmy búdæ bardzo kiepsko dziađađy podczas skalowania. Problemy zwiæ- zane z wydajnoħciæ mogæ siú pojawiè, gdy aplikacja búdzie musiađa obsđuľyè wiúkszæ liczbú uľytkowników lub obiektów danych niľ wczeħniej. Na tym etapie algorytm taki jak O(n^2) moľe okazaè siú patologiczny. Rozwiæzania dostúpne dla programistów to miúdzy innymi zastosowanie znacznie efektywniejszego algorytmu lub inne partycjono- wanie danych. Notacja „duľe O” ignoruje pewne stađe koszty zwiæzane z wyborem poszczególnych algorytmów. W przypadkach, gdzie n (wielkoħè danych wejħciowych) jest mađe, wspo- mniane koszty mogæ byè dominujæce.

5.2. Techniki sprawdzania wydajności aplikacji W tym podrozdziale zostanæ przedstawione niektóre najczúħciej stosowane techniki umoľliwiajæce poprawú wydajnoħci dziađania aplikacji: wybór wielkoħci operacji wejħcia- -wyjħcia, stosowanie pamiúci podrúcznej, buforowania, techniki odpytania (ang. polling), wspóđbieľnoħci i jednoczesnego wykonywania operacji, a takľe nieblokujæcych operacji wejħcia-wyjħcia i powiæzania z procesorem. W dokumentacji aplikacji znajdziesz infor- macje, które z wymienionych technik mogæ byè stosowane, a takľe wszelkie funkcje dodatkowe, charakterystyczne dla danej aplikacji.

5.2.1. Ustalenie wielkości operacji wejścia-wyjścia Koszt zwiæzany z przeprowadzaniem operacji wejħcia-wyjħcia obejmuje inicjalizacjú buforów, wykonanie wywođania systemowego, przeđæczenie kontekstu, alokacjú me- tadanych jædra, sprawdzenie ograniczeē i uprawnieē procesu, mapowanie adresów na urzædzenia, wykonanie kodu jædra i sterownika w celu przeprowadzenia operacji wejħcia-wyjħcia i wreszcie zwolnienie metadanych oraz buforów. Wspomniany koszt inicjalizacji dotyczy zarówno mađych, jak i duľych operacji wejħcia-wyjħcia. Z perspek- tywy wydajnoħci — im wiúcej danych jest przekazywanych w trakcie kaľdej operacji wejħcia-wyjħcia, tym lepiej.

Kup książkę Poleć książkę 5.2. Techniki sprawdzania wydajności aplikacji 195

Wzrost wielkoħci operacji wejħcia-wyjħcia to najczúħciej stosowana w aplikacjach strategia poprawy przepustowoħci. Gdy weļmie siú pod uwagú stađy koszt operacji wejħcia-wyjħcia, zwykle znacznie efektywniejsze búdzie przekazanie 128 KB danych w postaci pojedynczej operacji wejħcia-wyjħcia niľ 128 operacji o wielkoħci 1 KB. Dys- kowe operacje wejħcia-wyjħcia charakteryzujæ siú szczególnie wysokim kosztem po- jedynczej operacji, co wiæľe siú z czasem wyszukiwania danych. Istnieje sytuacja, w której aplikacja nie potrzebuje wiúkszych operacji wejħcia- wyjħcia. Baza danych wykonujæca losowy odczyt 8 KB danych búdzie dziađađa wolniej w przypadku operacji wejħcia-wyjħcia o wielkoħci 128 KB, poniewaľ transfer 120 KB búdzie zmarnowany. Tutaj pojawia siú kwestia opóļnienia wejħcia-wyjħcia, które moľna ograniczyè przez zastosowanie mniejszej wielkoħci operacji wejħcia-wyjħcia, bardziej odpowiadajæcej ľædaniu wykonywanemu przez aplikacjú. Niepotrzebnie duľe operacje wejħcia-wyjħcia marnujæ takľe przestrzeē bufora.

5.2.2. Pamięć podręczna System operacyjny stosuje róľne rodzaje pamiúci podrúcznej w celu poprawy wydaj- noħci odczytu danych z systemu plików oraz alokacji pamiúci. Aplikacje bardzo czústo uľywajæ pamiúci podrúcznych z podobnych powodów. Zamiast za kaľdym razem wyko- nywaè kosztownæ operacjú, wyniki najczúħciej przeprowadzanych operacji mogæ byè buforowane lokalnie w celu póļniejszego uľycia. Bardzo dobrym przykđadem búdzie tutaj bufor bazy danych, który przechowuje wyniki najczúħciej wykonywanych zapytaē. Podczas wdraľania aplikacji czústo wykonywanym zadaniem jest okreħlenie do- stúpnych lub wđæczonych pamiúci podrúcznych, a nastúpnie konfiguracja ich wielkoħci w sposób najbardziej dopasowany do systemu. Bardzo waľnym aspektem pamiúci podrúcznej jest sposób zachowania spójnoħci, tak aby operacje wyszukiwania nie zwracađy nieaktualnych danych. Nosi to nazwú kohe- rencji pamiúci podrúcznej i moľe byè operacjæ kosztownæ do wykonania — najlepiej, ľ eby koszt nie przekraczađ korzyħci wynikajæcych z uľycia pamiúci podrúcznej. Pamiúè podrúczna poprawia wydajnoħè odczytu, natomiast do poprawienia wydaj- noħci operacji zapisu bardzo czústo stosowane sæ bufory.

5.2.3. Buforowanie W celu poprawienia wydajnoħci zapisu dane mogæ byè umieszczane w buforze przed ich przekazaniem na nastúpny poziom. Takie rozwiæzanie powoduje zwiúkszenie wielkoħci operacji wejħcia-wyjħcia, a tym samym jej efektywnoħci. W zaleľnoħci od typu operacji zapisu moľe siú to wiæzaè równieľ ze wzrostem opóļnienia, poniewaľ pierwsze dane umieszczone w buforze czekajæ na kolejne i dopiero póļniej búdæ przekazane dalej. Bufor cykliczny jest rodzajem stađego bufora, który moľna wykorzystywaè do nie- ustannych transferów miúdzy komponentami. Dziađa wiúc jak bufor asynchroniczny. Tego rodzaju bufor jest implementowany za pomocæ wskaļników poczætkowego i koē- cowego; sæ one przesuwane o kaľdy komponent, gdy dane sæ dodawane lub usuwane.

Kup książkę Poleć książkę 196 Rozdział 5 Aplikacje

5.2.4. Technika odpytywania Odpytywanie to technika, w której system czeka na wystæpienie zdarzenia, nieustan- nie sprawdzajæc stan zdarzenia w pútli, i stosuje pauzy miúdzy kolejnymi sprawdze- niami. Wraz z technikæ odpytywania pojawiajæ siú pewne potencjalne problemy do- tyczæce wydajnoħci:

kosztowne obciæľenie procesora wynikajæce z regularnie powtarzajæcych siú operacji sprawdzeē, duľe opóļnienie miúdzy wystæpieniami zdarzenia i kolejnymi operacjami sprawdzenia.

Jeľeli to rzeczywiħcie búdzie problem wydajnoħci, w aplikacjach moľna zmieniè za- chowanie na nasđuchiwanie wystúpujæcych zdarzeē. W takiej sytuacji aplikacja jest informowana natychmiast o zdarzeniu i wywođuje ľædanæ procedurú.

Wywołanie systemowe poll() Istnieje wywođanie systemowe poll() przeznaczone do sprawdzania stanu deskryp- torów plików, co peđni funkcjú podobnæ do techniki odpytywania. Poniewaľ rozwiæzanie jest oparte na zdarzeniach, nie dotyczy go koszt wydajnoħci wystúpujæcy w przypadku odpytywania. Interfejs wywođania systemowego poll()obsđuguje wiele deskryptorów plików umieszczonych w tablicy, co wymaga od aplikacji przeprowadzenia operacji skanowa- nia tablicy po wystæpieniu zdarzenia, aby znaleļè powiæzane z nim deskryptory pli- ków. Takie skanowanie moľna uznaè za notacjú „duľe O” typu O(n) — patrz punkt 5.1.4. Obciæľenie zwiæzane ze wspomnianæ operacjæ skanowania moľe staè siú pro- blemem wydajnoħci podczas skalowania. Dostúpne sæ jeszcze inne interfejsy. Linux oferuje wywođanie epoll(), które pozwala na unikniúcie skanowania, a tym samym moľna je okreħliè jako O(1). Z kolei Solaris posiada podobnæ funkcjú o nazwie porty zdarzeē, która uľywa port_get(3C) zamiast poll().

5.2.5. Współbieżność i równoległość Systemy dzielenia czasu (đæcznie ze wszystkimi pochodnymi systemu UNIX) zapew- niajæ wspóđbieľnoħè programów, czyli moľliwoħè jednoczesnego wczytywania i dzia- đania wielu programów. Wprawdzie ich czasy dziađania mogæ wzajemnie na siebie nachodziè, ale programy niekoniecznie búdæ natychmiast wykonywane przez procesor. Kaľdy ze wspomnianych programów moľe byè procesem aplikacji. Poza wspóđbieľnym wykonywaniem róľnych aplikacji poszczególne funkcje w ra- mach aplikacji równieľ mogæ byè wspóđbieľne. Stađo siú to moľliwe dziúki uľyciu wielu procesów (wieloprocesowoħè) lub wætków (wielowætkowoħè), z których kaľdy wy- konuje swoje zadanie. Inne podejħcie to wspóđbieľnoħè oparta na zdarzeniach, w którym aplikacja obsđuguje róľne funkcje i przeđæcza siú miúdzy nimi, gdy wystúpujæ odpowiednie zdarze- nia. Tego rodzaju podejħcie jest uľywane na przykđad w ħrodowisku uruchomieniowym

Kup książkę Poleć książkę 5.2. Techniki sprawdzania wydajności aplikacji 197

Node.js. W ten sposób zapewniona zostaje wspóđbieľnoħè, ale odbywa siú to w ramach pojedynczego wætku lub procesu, co na pewno przyczynia siú do powstania wæskiego gardđa wydajnoħci, poniewaľ moľe byè wykorzystany tylko jeden procesor. Aby wykorzystaè moľliwoħci oferowane przez system wieloprocesorowy, aplikacja musi uľywaè jednoczeħnie wielu procesorów — nosi to nazwú równolegđoħci. W aplikacji moľna osiægnæè równolegđoħè za pomocæ wieloprocesowoħci lub wielowætkowoħci. Z po- wodów przedstawionych w rozdziale 6. „Procesory” wiele wætków (lub odpowiadajæcych im zadaē) oferuje znacznie wiúkszæ efektywnoħè i dlatego preferowane jest zastosowanie wđaħnie takiego rozwiæzania. Oprócz wiúkszej przepustowoħci pracy procesora wiele wætków (lub procesów) po- zwala na równoczesne przeprowadzanie operacji wejħcia-wyjħcia, poniewaľ inne wætki mogæ dziađaè wtedy, gdy zablokowany wætek oczekuje na operacjú wejħcia-wyjħcia. Z tego powodu, ľe w programowaniu wielowætkowym wspóđdzielona jest ta sama przestrzeē adresowa, jakæ ma proces, wætki zyskujæ moľliwoħè bezpoħredniego odczytu i zapisu tej samej pamiúci, bez koniecznoħci korzystania z kosztowych interfejsów, ta- kich jak komunikacja miúdzyprocesowa (ang. Inter-Process Communication, IPC), sto- sowana w programowaniu wieloprocesowym. W celu zachowania spójnoħci uľywana jest synchronizacja poczætkowa, aby dane nie zostađy uszkodzone na skutek ich jednocze- snego odczytu i zapisu. Takie rozwiæzanie moľna zastosowaè w pođæczeniu z tabelami hash, poprawiajæc tym samym wydajnoħè.

Synchronizacja początkowa Synchronizacja poczætkowa pilnuje dostúpu do pamiúci, podobnie jak sygnalizacja ħwietlna reguluje ruch na skrzyľowaniu. Niczym wspomniana sygnalizacja synchro- nizacja poczætkowa wstrzymuje pewien ruch i tym samym zmusza dane do oczekiwania (opóļnienie). Istniejæ trzy rodzaje najczúħciej stosowanej synchronizacji poczætkowej:

Blokady muteksu. Tylko nakđadajæcy blokadú ma prawo do dziađania, pozostali sæ zablokowani i muszæ czekaè na swojæ kolej. Wirujæce blokady (ang. spinlocks). Wirujæca blokada pozwala nakđadajæcemu na dziađanie, podczas gdy pozostali czekajæ na jej zwolnienie, nieustannie w pútli sprawdzajæc stan blokady. Wprawdzie takie rozwiæzanie moľe zapewniè dostúp charakteryzujæcy siú mađym opóļnieniem — zablokowany wætek nigdy nie opuszcza procesora i jest gotowy do dziađania w ciægu dosđownie kilku cykli, ale oznacza to marnowanie zasobów procesora podczas oczekiwania na zwolnienie blokady i sprawdzanie jej stanu. Blokady odczytu i zapisu. Blokady odczytu i zapisu zapewniajæ spójnoħè danych, poniewaľ zezwalajæ na wiele jednoczesnych operacji odczytu lub tylko jednæ operacjú zapisu i ľadnæ odczytu.

Blokady muteksu sæ implementowane przez bibliotekú lub jædro jako adaptacyjne blokady muteksu: hybryda metod muteksu i wirujæcych. Blokada wirujæca wystúpuje wtedy, gdy nakđadajæcy blokadú dziađa aktualnie w innym procesorze, natomiast zwykđa — w przeciwnym razie (lub po osiægniúciu maksymalnej liczby dozwolonych blokad wirujæcych). Adaptacyjne blokady muteksu sæ zoptymalizowane w celu zapewnienia

Kup książkę Poleć książkę 198 Rozdział 5 Aplikacje dostúpu charakteryzujæcego siú mađym opóļnieniem bez marnowania zasobów pro- cesora. Dlatego teľ od wielu lat sæ stosowane w systemach Solaris. W 2009 roku zostađy zaimplementowane równieľ w systemie Linux, gdzie nazwano je adaptacyjnymi wirujæcymi blokadami muteksu (patrz odwođanie [1] na koēcu rozdziađu). Analiza problemów wydajnoħci obejmuje takľe sprawdzanie blokad, co niewætpliwie jest bardzo czasochđonnym zajúciem i wymaga znajomoħci kodu ļródđowego aplikacji. To zwykle jest zajúcie dla programisty.

Tabele hash Tabele hash blokad mogæ byè uľywane w celu zastosowania minimalnej liczby blo- kad dla jak najwiúkszej liczby struktur danych. W tym miejscu przedstawiono jedynie podsumowanie tabel hash — to jest bardzo zaawansowany temat, którego dokđadne poznanie wymaga wiedzy z zakresu programowania. Zapoznaj siú z dwoma nastúpujæcymi podejħciami:

Pojedyncza globalna blokada muteksu dla wszystkich struktur danych. Wprawdzie takie rozwiæzanie jest proste, ale wspóđbieľny dostúp búdzie charakteryzowađ siú wówczas wystúpowaniem rywalizacji i opóļnieniem zwiæzanym z oczekiwaniem na uzyskanie dostúpu. Wiele wætków wymagajæcych nađoľenia blokady búdzie serializowanych, czyli wykonywanych po kolei zamiast jednoczeħnie. Oddzielna blokada muteksu dla poszczególnych struktur danych. Co prawda takie rozwiæzanie ogranicza stan rywalizacji do absolutnego minimum — w trakcie jednoczesnego dostúpu do tej samej struktury danych, ale blokada wiæľe siú z obciæľeniem powodowanym przez pamiúè masowæ i procesor podczas tworzenia i znoszenia blokady dla kaľdej struktury danych.

Tabela hash blokad moľe byè rozwiæzaniem przejħciowym i jest odpowiednia, gdy spodziewasz siú duľej rywalizacji o dostúp do zasobów. Rozwiæzanie polega na utwo- rzeniu stađej liczby blokad i uľyciu algorytmu hash do wyboru blokady, która ma byè stosowana z okreħlonæ strukturæ danych. W ten sposób unika siú kosztu zwiæzanego z tworzeniem i znoszeniem blokady dla struktury danych, a ponadto eliminowane sæ problemy wystúpujæce w przypadku istnienia tylko jednej blokady. Przykđad tabeli hash pokazano na rysunku 5.2 — skđada siú ona z czterech elemen- tów (nazywanych buckets), z których kaľdy zawiera wđasnæ blokadú.

Rysunek 5.2. Przykładowa tabela hash

Kup książkę Poleć książkę 5.2. Techniki sprawdzania wydajności aplikacji 199

Na rysunku pokazano jedno z podejħè w zakresie rozwiæzania kolizji hash, kiedy to dwie struktury danych wejħciowych lub ich wiúksza liczba sæ przydzielone do tego samego elementu. W pokazanym przykđadzie nastúpuje utworzenie đaēcucha struktur danych w celu przechowywania ich wszystkich w tym samym elemencie, do którego zo- stađy przypisane przez funkcjú hash. Jeľeli struktury danych búdæ zbyt dđugie i prze- twarzane szeregowo, wspomniane đaēcuchy mogæ przysporzyè problemów zwiæzanych z wydajnoħciæ. Funkcjú hash i wielkoħè tabeli moľna ustaliè tak, aby równomiernie roz- đoľyè struktury danych w poszczególnych elementach i tym samym do minimum ograni- czyè dđugoħè đaēcuchów. W idealnej sytuacji liczba elementów tabeli hash powinna byè równa liczbie proceso- rów lub wiúksza od niej, aby tym samym zapewniè maksymalnæ wspóđbieľnoħè. Z kolei algorytm funkcji hash moľe byè prosty, na przykđad pobieraè najmniej znaczæcy bit adresu struktury danych i uľyè go jako indeksu tablicy blokad, majæcej wielkoħè równæ potúdze liczby 2. Tego rodzaju prosty algorytm charakteryzuje siú duľæ szybkoħciæ dziađania, a wiúc pozwala na szybkie przydzielanie lokalizacji strukturom danych. W przypadku tabel sæsiadujæcych w pamiúci blokad problem zwiæzany z wydajnoħciæ moľe siú pojawiè, gdy blokady znajdæ siú w tym samym bloku danych pamiúci podrúcz- nej. Dwa procesory uaktualniajæce róľne blokady w tym samym bloku danych napotkajæ obciæľenie zwiæzane z koherencjæ, poniewaľ poszczególne procesory búdæ uniewaľniaè blok danych tego drugiego procesora. Sytuacja taka nosi nazwú bđúdnego wspóđdzie- lenia (ang. false sharing) i jest najczúħciej rozwiæzywana przez dopeđnienie blokad nie- uľywanymi bajtami, aby w okre ħlonym bloku danych w pamiúci znajdowađa siú tylko jedna blokada.

5.2.6. Nieblokujące operacje wejścia-wyjścia Cykl ľyciowy procesu w systemie UNIX, pokazany na rysunku 3.7 w rozdziale 3. „Systemy operacyjne”, wskazywađ na blokowanie procesu i przejħcie do stanu uħpienia w czasie wykonywania operacji wejħcia-wyjħcia. Z tym modelem wiæľe siú kilka pro- blemów dotyczæcych wydajnoħci:

W przypadku wielu jednoczesnych operacji wejħcia-wyjħcia poszczególne operacje w trakcie blokady zabierajæ wætek (lub proces). W celu zapewnienia obsđugi wielu jednoczesnych operacji wejħcia-wyjħcia aplikacja musi utworzyè wiele wætków (zwykle po jednym dla kaľdego klienta), co oznacza koszt zwiæzany z tworzeniem i niszczeniem wætków. W przypadku krótkotrwađych operacji wejħcia-wyjħcia obciæľenie zwiæzane z czústym przeđæczaniem kontekstu moľe zuľywaè zasoby procesora i przyczyniaè siú do zwiúkszania opóļnienia aplikacji.

Model nieblokujæcych operacji wejħcia-wyjħcia powoduje asynchroniczne wy- konywania tych operacji, bez blokowania bieľæcego wætku, który w ten sposób moľna wykorzystaè do innych zadaē. To jest funkcja kluczowa Node.js (patrz odwođanie [2] na koēcu rozdziađu), czyli dziađajæcego po stronie serwera ħrodowiska aplikacji JavaScript, które w nieblokujæcy sposób kieruje kodem do wykonania.

Kup książkę Poleć książkę 200 Rozdział 5 Aplikacje

5.2.7. Powiązanie z procesorem W ħrodowiskach NUMA (ang. Non-Uniform Memory Access) korzystna moľe byè sy- tuacja, gdy proces lub wætek búdzie dziađađ w pojedynczym procesorze oraz w tym samym procesorze, co poprzednio po wykonaniu operacji wejħcia-wyjħcia. W ten sposób popra- wia siú lokalizacjú pamiúci dla aplikacji, zmniejsza liczbú cykli potrzebnych do wykona- nia operacji wejħcia-wyjħcia dla pamiúci oraz ogólnie poprawia wydajnoħè dziađania aplikacji. Oczywiħcie twórcy systemów operacyjnych doskonale o tym wiedzæ i tworzæ je w taki sposób, aby wætki aplikacji dziađađy w tym samym procesorze (tzw. koligacja procesora). Te tematy búdæ poruszane w rozdziale 7., zatytuđowanym „Pamiúè”. Pewne aplikacje wymuszæ zastosowanie przedstawionego zachowania przez powiæ- zanie siú z procesorem. W niektórych systemach moľe to spowodowaè znacznæ poprawæ wydajnoħci dziađania. Z drugiej strony, jeħli powiæzanie búdzie tworzyđo konflikt z innym powiæzaniem procesora, na przykđad urzædzenie búdzie zakđócađo mapowanie na procesor, wówczas wspomniane powiæzanie spowoduje spadek wydajnoħci. O ryzyku dotyczæcym powiæzania z procesorem naleľy pamiútaè szczególnie wtedy, gdy w systemie dziađajæ inne tenanty lub aplikacje. Ten problem moľna napotkaè pod- czas przetwarzania w chmurze dla wirtualizacji systemu operacyjnego, kiedy aplikacja moľe zobaczyè wszystkie procesory i przyđæczyè siú do wybranego, jakby byđa jedynæ aplikacjæ w serwerze. Jeľeli serwer jest wspóđdzielony przez aplikacje róľnych tenantów, które takľe stosujæ powiæzanie z procesorem, to mamy do czynienia z konfliktami i opóļ- nieniami algorytmu szeregowania. Wynika to z faktu, ľe procesor jest zajúty obsđugæ zadaē innych tenantów, nawet pomimo bezczynnoħci pozostađych procesorów.

5.3. Języki programowania Júzyki programowania mogæ byè kompilowane lub interpretowane, a na dodatek wy- konywane za pomocæ maszyny wirtualnej. Wiele júzyków wymienia „optymalizacje w zakresie wydajnoħci” jako jednæ z funkcji, ale szczerze mówiæc, to najczúħciej sæ funkcje oprogramowania wywođujæcego dany júzyk, a nie samego júzyka. Na przykđad oprogramowanie Java HotSpot Virtual Machine zawiera kompilator JIT (ang. Just-In- -Time) w celu dynamicznej poprawy wydajnoħci. Interpretery i maszyny wirtualne júzyków równieľ zapewniajæ róľne poziomy ob- sđugi w zakresie monitorowania za pomocæ wđasnych, specyficznych narzúdzi. Anali- tykowi wydajnoħci systemu przeprowadzenie prostego profilowania przy uľyciu wspo- mnianych narzúdzi moľe przynieħè pewne korzyħci. Na przykđad wysoki poziom zuľycia procesora moľna zidentyfikowaè jako wynik dziađania mechanizmu usuwania nieuľyt- ków (ang. garbage collection), a nastúpnie usunæè problem za pomocæ doskonale zna- nych technik. Obciæľenie moľe byè równieľ skutkiem dziađania ħcieľki kodu w wyniku znanego bđúdu w bazie danych, którego usuniúcie wymaga po prostu uaktualnienia oprogramowania (taka sytuacja zdarza siú doħè czústo). W kolejnych punktach przygotowano omówienie pewnej podstawowej charaktery- styki wydajnoħci w poszczególnych rodzajach júzyków programowania. Wiúcej informacji na temat wydajnoħci tych júzyków programowania znajdziesz w poħwiúconych im ksiæľkach.

Kup książkę Poleć książkę 5.3. Języki programowania 201

5.3.1. Języki kompilowane Kompilacja to proces polegajæcy na zamianie kodu ļródđowego na instrukcje kodu ma- szynowego, umieszczane w plikach wykonywanych nazywanych binarnymi. Odbywa siú to jeszcze przed uruchomieniem programu. Tak powstađe pliki binarne moľna uru- chamiaè póļniej dowolnie, bez koniecznoħci ponownej kompilacji. Do júzyków kompilo- wanych zaliczamy miúdzy innymi C i C++. Niektóre júzyki mogæ byè zarówno inter- pretowane, jak i kompilowane. Ogólnie rzecz bioræc, kod skompilowany charakteryzuje siú wiúkszæ wydajnoħciæ dziađania i nie wymaga dalszej analizy przed jego wykonaniem przez procesor. Jædro systemu operacyjnego zostađo utworzone prawie cađkowicie w júzyku C, poza kilkoma komponentami o znaczeniu krytycznym, które przygotowano w asemblerze. Analiza wydajnoħci júzyków kompilowanych jest zwykle prosta, poniewaľ wyko- nywany kod maszynowy najczúħciej jest mapowany w pobliľu oryginalnego programu (to oczywiħcie zaleľy od optymalizacji zastosowanych w trakcie kompilacji). Podczas kompilacji moľe zostaè wygenerowana tabela symboli przeznaczona do mapowania ad- resów na funkcje programu i nazwy obiektów. Przeprowadzane póļniej profilowanie i monitorowanie dziađania procesora moľe byè mapowane bezpoħrednio na wspomniane nazwy w programie, co pozwala analitykowi analizowaè wykonywanie programu. Stos i zawarte w nim adresy liczbowe równieľ mogæ byè mapowane i przeksztađcane na na- zwy funkcji, aby zapewniè hierarchiú ħcieľki kodu. Kompilator ma moľliwoħè poprawienia wydajnoħci na skutek zastosowania tak zwanej optymalizacji kodu wynikowego, czyli procedur optymalizujæcych wybór, i umieszczenie instrukcji procesora.

Optymalizacja kodu wynikowego Kompilator gcc pozwala na wybór poziomu optymalizacji od 0 do 3, przy czym 3 oznacza najwiúkszæ liczbú optymalizacji. Istnieje moľliwoħè sprawdzenia w gcc, jakie opty- malizacje sæ stosowane na poszczególnych poziomach, na przykđad:

$ gcc -Q -O3 --help=optimizers The following options control optimizations: -O -Ofast -Os -falign-functions [enabled] -falign-jumps [enabled] -falign-labels [enabled] -falign-loops [enabled] -fasynchronous-unwind-tables [enabled] -fbranch-count-reg [enabled] -fbranch-probabilities [disabled] -fbranch-target-load-optimize [disabled] [...] -fomit-frame-pointer [disabled] [...]

Kup książkę Poleć książkę 202 Rozdział 5 Aplikacje

Peđna lista zawiera okođo 180 opcji, czúħè z nich jest wđæczona nawet na poziomie 0 optymalizacji (-O0). Zobaczmy, jak wyglæda dziađanie jednej z tych opcji, -fomit-frame ´-pointer; poniľszy akapit pochodzi ze strony podrúcznika man kompilatora gcc:

Nie przechowuj ramki wskaļnika w rejestrze dla funkcji, które tego nie potrzebujæ. Dziúki temu moľna uniknæè koniecznoħci zachowania instrukcji, konfiguracji i przywracania ramek wskaļników — ponadto dodatkowy rejestr pozostaje dostúpny dla wielu funkcji. W niektórych systemach to uniemoľliwia debugowanie.

Jest to przykđad kompromisu: pominiúcie ramki wskaļnika zwykle uniemoľliwia przeprowadzenie operacji analizatora, który profiluje stos. Bioræc pod uwagú uľytecznoħè profilowania stosu, uľycie omawianej opcji moľe ozna- czaè zbyè duľe poħwiúcenie w kategoriach póļniejszej wydajnoħci, której nie búdzie moľ- na đatwo poprawiè. To zdecydowanie przewyľsza zysk w zakresie wydajnoħci, jaki po- czætkowo moľna uzyskaè dziúki uľyciu tej opcji. W omawianym przypadku rozwiæzaniem moľe byè kompilacja wraz z opcjæ -fno-omit-frame-pointer w celu unikniúcia wy- mienionej wczeħniej optymalizacji kodu. Niebezpieczeēstwo pojawienia siú ewentualnych problemów dotyczæcych wydaj- noħci moľe skđaniaè do przeprowadzenia ponownej kompilacji aplikacji i ustawienia mniejszego poziomu optymalizacji, na przykđad wskutek uľycia opcji -O2 zamiast -O3, w nadziei, ľe zaspokoi to wszystkie wymagania w zakresie debugowania. Takie roz- wiæzanie jednak wcale nie jest proste: zmiany w danych wyjħciowych kompilatora mo- gæ byè ogromne i waľne, a ponadto mogæ mieè wpđyw na zachowanie, które poczætkowo próbujesz poddaè analizie.

5.3.2. Języki interpretowane Júzyki interpretowane wykonujæ program na skutek jego zamiany na odpowiednie akcje w trakcie uruchomienia. Ten proces powoduje powstanie dodatkowego obciæ- ľenia podczas wykonywania programu. Od júzyków interpretowanych nie oczekuje siú wysokiej wydajnoħci. Sæ one uľywane w sytuacjach, gdy inne czynniki majæ duľo wiúksze znaczenie, na przykđad đatwoħè programowania i debugowania. Przykđadem uľycia júzyka interpretowanego sæ skrypty powđoki. Jeľeli nie zostanæ dostarczone odpowiednie narzúdzia monitorowania, analiza wydajnoħci júzyków interpretowanych moľe byè trudna. Profilowanie procesora po- kaľe dziađanie interpretera, miúdzy innymi przetwarzanie, translacjú i wykonywanie dziađaē, ale na pewno nie pokaľe oryginalnych nazw funkcji programu, czyli waľny kontekst programu pozostanie tajemnicæ. Jednak analiza interpretera na pewno nie jest bezowocna, poniewaľ problemy z wydajnoħciæ mogæ dotyczyè samego interpretera, nawet jeħli wykonywany przez niego kod wydaje siú doskonale przygotowany. W zaleľ noħci od interpretera kontekst programu moľe byè đatwy do poħredniego uchwycenia, na przykđad za pomocæ monitorowania dynamicznego analizatora skđadni. Bardzo czústo wykonywana jest analiza programów w wyniku dodania poleceē wyħwie- tlajæcych informacje pomocnicze i znaczniki czasu. Rygorystyczniejsza analiza wydajno- ħci jest rzadziej spotykana, poniewaľ júzyki interpretowane sæ znacznie rzadziej wy- bierane do utworzenia aplikacji, od których wymaga siú duľej wydajnoħci dziađania.

Kup książkę Poleć książkę 5.3. Języki programowania 203

5.3.3. Maszyny wirtualne Maszyna wirtualna júzyka (nazywana równieľ maszynæ wirtualnæ procesu) to oprogramowanie emulujæce komputer. Kod utworzony w pewnych júzykach progra- mowania, na przykđad Java i Erlang, jest najczúħciej uruchamiany w maszynach wir- tualnych, które zapewniajæ im niezaleľne od platformy ħrodowisko programistyczne. Aplikacja zostaje skompilowana na zestaw instrukcji maszyny wirtualnej (kod baj- towy), a nastúpnie jest uruchamiana przez wspomnianæ maszynú wirtualnæ. Takie rozwiæzanie pozwala na zachowanie przenoħnoħci skompilowanych obiektów, oczywiħcie przy zađoľeniu, ľe na platformie docelowej znajduje siú maszyna wirtu- alna, która potrafi uruchamiaè te skompilowane obiekty. Kod bajtowy jest kompilowany na podstawie kodu ļródđowego programu, a nastúp- nie interpretowany przez júzyk maszyny wirtualnej, który tđumaczy go na kod ma- szynowy. Maszyna wirtualna Java HotSpot obsđuguje kompilacjú JIT, co powoduje kompilacjú kodu bajtowego na kod maszynowy przed czasem, a wiúc w trakcie jego wykonywania moľna analizowaè rodzimy kod maszynowy. W ten sposób moľna po- đæczyè zalety kodu kompilowanego z przenoħnoħciæ maszyny wirtualnej. Maszyny wirtualne to z reguđy najtrudniejsze do monitorowania rodzaje júzyków. Zanim program búdzie wykonywany przez procesor, przeprowadzonych musi byè wiele etapów kompilacji lub interpretacji kodu, a informacje o oryginalnym programie nieko- niecznie búdæ đatwo dostúpne. Analiza wydajnoħci zwykle koncentruje siú na zestawie narzúdzi dostarczanych wraz z maszynæ wirtualnæ júzyka. Wiele z nich oferuje sondy DTrace oraz narzúdzia opracowane przez firmy trzecie.

5.3.4. Mechanizm usuwania nieużytków Niektóre júzyki stosujæ automatyczne zarzædzanie pamiúciæ, czyli zaalokowana pa- miúè nie musi byè wyraļnie zwalniana. To zadanie jest pozostawione asynchroniczne- mu procesowi mechanizmu usuwania nieuľytków. Wprawdzie takie rozwiæzanie uđa- twia programiħcie tworzenie aplikacji, ale jednoczeħnie wiæľe siú z pewnymi wadami, do których moľna zaliczyè:

Wzrost zuľycia pamiúci. Mniejsza kontrola nad zuľyciem pamiúci przez aplikacjú oznacza wiúkszy poziom jej uľycia, gdy nie wszystkie obiekty búdæ automatycznie identyfikowane jako moľliwe do usuniúcia z pamiúci. Jeľeli aplikacja stanie siú ogromna, to moľe osiægnæè wđasne ograniczenia lub doħwiadczyè stronicowania pamiúci, co niezwykle negatywnie odbija siú na wydajnoħci. Koszt zwiæzany z wiúkszym uľyciem zasobów procesora. Mechanizm usuwania nieuľytków dziađa nieregularnie i obejmuje operacjú wyszukiwania obiektów w pamiúci. To oczywiħcie oznacza zuľywanie zasobów procesora, a wiúc zmniejszanie na krótki czas iloħci zasobów dostúpnych dla aplikacji. Kiedy wzroħnie iloħè pamiúci zuľywanej przez aplikacjú, równoczeħnie moľe zwiúkszyè siú zapotrzebowanie mechanizmu usuwania nieuľytków na zasoby procesora. W pewnych przypadkach i implementacjach moľe dojħè do sytuacji, ľe wymieniony mechanizm búdzie nieustannie zuľywaè cađæ moc procesora.

Kup książkę Poleć książkę 204 Rozdział 5 Aplikacje

Elementy odstajæce pod wzglúdem opóļnienia. Wykonywanie aplikacji moľe byè wstrzymane podczas dziađania mechanizmu usuwania nieuľytków, co spowoduje chwilowe wydđuľenie czasu reakcji aplikacji. Duľe znaczenie ma tutaj typ implementowanego mechanizmu: stop-the-world, przyrostowy lub wspóđbieľny.

Mechanizm usuwania nieuľytków jest bardzo czústo poddawany modyfikacjom w celu zmniejszenia poziomu zuľycia procesora oraz zmniejszenia opóļnienia elemen- tów odstajæcych. Na przykđad maszyna wirtualna Javy oferuje moľliwoħè zmiany wielu parametrów mechanizmu usuwania nieuľytków, miúdzy innymi jego typu, liczby uľy- wanych wætków, maksymalnej wielkoħci sterty oraz wspóđczynnika zwalniania sterty. Jeľeli dostosowanie parametrów nie przyniesie oczekiwanych wyników, problem moľe polegaè na tworzeniu przez aplikacjú zbyt duľej iloħci nieuľytków bædļ na istnie- niu wycieku pamiúci. To sæ problemy, którymi powinien zajæè siú programista aplikacji.

5.4. Metodologia i analiza W tym podrozdziale zostanæ omówione metodologie wykorzystywane podczas analizy aplikacji i dostosowywania jej wydajnoħci dziađania. Narzúdzia uľywane podczas anali- zy zostanæ wprowadzone tutaj lub w kolejnych rozdziađach. Temat podsumowano w tabeli 5.2.

Tabela 5.2. Metodologie analizy wydajności aplikacji Metodologia Rodzaj Analiza stanu wątku Analiza oparta na monitorowaniu Profilowanie procesora Analiza oparta na monitorowaniu Analiza wywołań systemowych Analiza oparta na monitorowaniu Profilowanie operacji wejścia-wyjścia Analiza oparta na monitorowaniu Charakterystyka obciążenia Analiza oparta na monitorowaniu, planowanie pojemności Metoda USE Analiza oparta na monitorowaniu Analiza drążąca Analiza oparta na monitorowaniu Analiza blokad Analiza oparta na monitorowaniu Statyczne dostosowanie wydajności Analiza oparta na monitorowaniu, dostrojenie

W rozdziale 2., noszæcym tytuđ „Metodologia”, moľesz zapoznaè siú z dodatkowymi informacjami o ogólnych metodologiach oraz z omówieniem wybranych z nich. Ponadto w kolejnych rozdziađach znajdziesz przedstawienie analizy zasobów systemowych i wirtualizacji. Wspomniane metodologie mogæ byè stosowane pojedynczo lub w pođæczeniu z innymi. Sugerujú wypróbowanie ich w kolejnoħci przedstawionej w tabeli 5.2.

Kup książkę Poleć książkę 5.4. Metodologia i analiza 205

Oprócz wymienionych istniejæ jeszcze inne techniki analizy stosowane w konkret- nych aplikacjach i júzykach programowania, w których te aplikacje zostađy utworzone. Techniki takie mogæ uwzglúdniaè zachowania logiczne aplikacji, miúdzy innymi znane problemy, i pozwalaè na osiægniúcie pewnej poprawy wydajnoħci.

5.4.1. Analiza stanu wątku Celem jest ogólne ustalenie, gdzie wætki aplikacji przebywajæ wiúkszoħè czasu. To umoľliwia praktycznie natychmiastowe rozwiæzanie pewnych problemów i skierowanie analizy innych na odpowiednie tory. Operacja odbywa siú przez podziađ czasu poszcze- gólnych wætków aplikacji na pewnæ liczbú stanów.

Dwa stany Absolutne minimum to zastosowanie dwóch stanów wætku:

W procesorze. Wykonywanie wætku. Poza procesorem. Wætek czeka na swojæ kolej dostúpu do procesora, na zakoēczenie operacji wejħcia-wyjħcia, zwolnienie blokady, stronicowanie, wykonanie innego zadania itd.

Jeľeli wætek wiúkszoħè czasu przebywa w procesorze, to profilowanie procesora zwy- kle pozwoli na szybkie wyjaħnienie tego stanu rzeczy (wiúcej o tym znajdziesz w dalszej czúħci rozdziađu). Taka sytuacja zdarza siú w przypadku wielu problemów zwiæzanych z wydajnoħciæ, nie trzeba wiúc poħwiúcaè czasu na przeprowadzanie pomiarów innych stanów wætku. Jeľeli wætek wiúkszoħè czasu przebywa poza procesorem, to moľna zastosowaè róľne metodologie. Jednak bez dobrego punktu wyjħcia zadanie búdzie wymagađo po- ħwiúcenia duľej iloħci czasu.

Sześć stanów W tym miejscu przedstawiono znacznie bardziej rozbudowanæ listú, tym razem zawie- rajæcæ szeħè stanów wætku (i inny schemat nazewnictwa) — w ten sposób moľna otrzy- maè znacznie lepszy punkt wyjħcia, gdy okaľe siú, ľe wætek wiúkszoħè czasu przebywa poza procesorem:

Wykonywanie. W procesorze. Dziađanie. Oczekuje na swojæ kolej dostúpu do procesora. Anonimowe stronicowanie. Dziađa, ale jest zablokowany w oczekiwaniu na zakoēczenie anonimowego stronicowania. Uħpienie. Czeka na zakoēczenie operacji wejħcia-wyjħcia, na przykđad sieciowej, na zwolnienie blokady lub przeniesienie danych bædļ tekstu miúdzy pamiúciæ operacyjnæ i wirtualnæ.

Kup książkę Poleć książkę 206 Rozdział 5 Aplikacje

Blokada. Czeka na nađoľenie blokady synchronizacji (oczekiwanie na inny element). Bezczynnoħè. Oczekuje na zadanie do wykonania.

Powyľszy zestaw zostađ przygotowany w taki sposób, aby byđ minimalny i jedno- czeħnie uľyteczny. Oczywiħcie do listy moľesz dodaè kolejne stany. Na przykđad stan wykonywania moľna podzieliè jeszcze na wykonywanie po stronie uľytkownika i jædra, natomiast stan uħpienia — podzieliè wedđug celu. (Osobiħcie radzú korzystaè z przed- stawionej wczeħniej listy szeħcioelementowej). Poprawa wydajnoħci nastæpi po zmniejszeniu czasu w pierwszych piúciu stanach, co spowoduje zwiúkszenie czasu bezczynnoħci. Gdy pozostađe czynniki sæ takie same, oznacza to, ľe ľædania generowane przez aplikacjú charakteryzujæ siú mniejszym opóļ- nieniem, a tym samym moľe ona obsđuľyè wiúksze obciæľenie. Po ustaleniu, w którym z wymienionych piúciu stanów wætki przebywajæ najwiúcej czasu, moľna przystæpiè do dalszej analizy.

Wykonywanie. Za pomocæ profilowania sprawdļ tryb dziađania wætku (uľytkownika lub jædra), a takľe powód zuľycia procesora. Profilowanie pomaga w ustaleniu, które ħcieľki kodu sæ odpowiedzialne za zuľycie procesora oraz przez jaki czas, obejmujæcy takľe blokady. Zapoznaj siú z punktem 5.4.2. „Profilowanie procesora”. Dziađanie. Spúdzanie czasu w tym stanie oznacza, ľe aplikacja potrzebuje wiúcej zasobów procesora. Przeanalizuj obciæľenie procesora w cađym systemie oraz wszelkie ograniczenia procesora dla danej aplikacji (na przykđad nakđadane przez mechanizm kontroli zasobów). Anonimowe stronicowanie. Brak pamiúci operacyjnej dla aplikacji moľe byè powodem powstania anonimowego stronicowania i opóļnieē. Przeanalizuj zuľycie pamiúci w cađym systemie oraz wszystkie ograniczenia pamiúci dla danej aplikacji. Wiúcej informacji na ten temat znajdziesz w rozdziale 7. „Pamiúè”. Uħpienie. Przeanalizuj zasoby, w których aplikacja jest zablokowana. Zapoznaj siú z punktami 5.4.3 „Analiza wywođaē systemowych” i 5.4.4 „Profilowanie operacji wejħcia-wyjħcia”. Blokada. Zidentyfikuj blokadú, nakđadajæcy jæ wætek oraz powód, dla którego blokada trwa dđugo. Wspomnianym powodem moľe byè oczekiwanie przez nakđadajæcego na zwolnienie innej blokady, co oznacza koniecznoħè kolejnej analizy. To jest zaawansowane dziađanie, zwykle przeprowadzane przez programistú aplikacji, który ma wystarczajæco duľæ wiedzú o aplikacji i stosowanej w niej hierarchii blokad.

Z powodu sposobu, w jaki aplikacje zwykle oczekujæ na zadania, bardzo czústo búdziesz siú przekonywađ, ľe czas w stanach uħpienia i blokady to w rzeczywistoħci czas bezczynnoħci. Wætek roboczy aplikacji moľe oczekiwaè na zakoēczenie dziađania zmiennej warunkowej (stan blokady) lub sieciowej operacji wejħcia-wyjħcia (stan uħpie- nia). Kiedy spotykasz siú z dđugimi czasami uħpienia i blokady, pamiútaj, aby dræľyè dalej ten temat i sprawdziè, czy czas ten nie búdzie rzeczywiħcie czasem bezczynnoħci.

Kup książkę Poleć książkę 5.4. Metodologia i analiza 207

Dalsze podsumowanie pokazuje, jak wspomniane stany wætków moľna zmierzyè w systemach Linux i Solaris. Narzúdzia i technologie uľyte w trakcie pomiarów búdæ dokđadniej omówione w innych miejscach ksiæľki. Sprawdļ je zwđaszcza pod kætem nowych narzúdzi i ich opcji, które mogæ uđatwiè wykonanie zadania pomiaru.

Linux Czas poħwiúcony na wykonywanie nie jest trudny do ustalenia, poniewaľ polecenie top podaje go w kolumnie %CPU danych wyjħciowych. Pomiar czasu w pozostađych sta- nach búdzie wymagađ dodatkowych kroków, które przedstawiono poniľej. Czas dziađania jest mierzony przez funkcjú schedstats jædra i udostúpniony przez pliki /proc/*/schedstats. Wywođanie polecenia perf sched równieľ moľe dostarczyè metryk pozwalajæcych na ustalenie czasu poħwiúconego na dziađanie i oczekiwanie. Czas oczekiwania na anonimowe stronicowanie (w systemie Linux to wymiana) moľna zmierzyè za pomocæ funkcji zliczania opóļnienia, przy zađoľeniu, ľe zostađa ona wđæczona. Wymieniona funkcja przekazuje informacje o oddzielnych stanach wymiany i blokady podczas odzyskiwania pamiúci (a takľe informacje dotyczæce na- cisku wywieranego na pamiúè). Nie ma powszechnie uľywanego narzúdzia do udostúp- niania informacji o wspomnianych stanach. Jednak w dokumentacji jædra znajduje siú przykđ adowy program sđuľæcy do tego celu: getdelays.c, który zademonstrowano w rozdziale 4. „Narzúdzia monitorowania”. Inne podejħcie polega na uľyciu narzúdzi monitorowania, takich jak DTrace lub SystemTap. Czas zablokowania w wætku uħpienia moľna z grubsza oszacowaè, stosujæc inne narzúdzia, na przykđad polecenie pidstat -d, i ustaliè, czy proces przeprowadza dys- kowæ operacjú wejħcia-wyjħcia, a tym samym, czy prawdopodobnie znajduje siú w sta- nie uħpienia. O ile opóļnienia i inne funkcje sprawdzania operacji wejħcia-wyjħcia zostađy wđæczone, podajæ czas oczekiwania na zakoēczenie operacji wejħcia-wyjħcia, który moľna sprawdziè za pomocæ polecenia iotop. Inne powody blokad moľna spraw- dziè, korzystajæc z narzúdzi monitorowania, takich jak DTrace i SystemTap. Sama aplikacja moľe udostúpniaè odpowiednie instrumenty, ewentualnie instrumenty takie moľna dodaè i tym samym monitorowaè czas przeprowadzania operacji wejħcia-wyjħcia (zarówno dyskowej, jak i sieciowej). Jeľeli aplikacja znajduje siú w stanie uħpienia przez bardzo dđugi czas (liczony w sekundach), to powód takiego zachowania moľna spróbowaè ustaliè za pomocæ pole- cenia pstack. Wymienione polecenie pobiera pojedynczæ migawkú wætku i informacje o uľyciu stosu uľytkownika, które powinny zawieraè uħpiony wætek i powód jego uħpie- nia. Pamiútaj, dziađanie polecenia pstack moľe wstrzymaè dziađanie analizowanej apli- kacji i dlatego uľywaj go ostroľnie. Czas blokady moľna sprawdziè za pomocæ narzúdzi monitorowania.

Solaris W systemach Solaris dane statystyczne dotyczæce zliczania mikrostanów (wprowa- dzonego w rozdziale 4. „Narzúdzia monitorowania”) bezpoħrednio dostarczajæ informacji o wiúkszoħci stanów wætku. Wspomniane dane moľna wyħwietliè, stosujæc polecenie prstat:

Kup książkę Poleć książkę 208 Rozdział 5 Aplikacje

$ prstat -mLcp 4937 1 Please wait... PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 4937 root 7.4 7.9 0.0 0.0 15 0.0 69 0.2 239 31 3K 0 redis-server/1 4937 root 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 redis-server/3 4937 root 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.28, 5.36, 5.36 [...]

Osiem kolumn, poczæwszy od USR do LAT, zawiera informacje o wszystkich mikrosta- nach wætku i dzieli czas wætku na procenty. Suma wartoħci wymienionych kolumn wy- nosi 100%. Poniľej przedstawiono mapowanie stanów na odpowiadajæce im kolumny.

wykonywanie — USR + SYS, dziađanie — LAT, anonimowe stronicowanie — DFL, uħpienie — SLP, blokada — LCK, bezczynnoħè — równieľ w SLP + LCK.

Wprawdzie to nie jest doskonađe odwzorowanie, ale mimo wszystko dostarczone in- formacje majæ ogromnæ wartoħè. Czas bezczynnoħci moľna sprawdziè za pomocæ na- rzúdzia DTrace, analizujæc stos, gdy wætek opuszcza procesor, i tym samym przekonaè siú, jaki jest powód oczekiwania. Jeľeli wætek pozostaje w stanie uħpienia przez bardzo dđugi czas (liczony w sekundach), to wypróbuj polecenie pstack. Pamiútaj, dziađanie polecenia pstack moľe wstrzymaè dziađanie analizowanej aplikacji i dlatego uľywaj go ostroľnie. Wiúcej informacji na temat polecenia prstat i wyħwietlanych przez nie kolumn znaj- dziesz w rozdziale 6., zatytuđowanym „Procesory”.

5.4.2. Profilowanie procesora Profilowanie procesora zostanie dokđadnie omówione w punkcie 6.5.4 w rozdziale 6. „Procesory”. Znajdziesz tam równieľ szczegóđowe przykđady uľycia narzúdzi DTrace i perf. Profilowanie to bardzo waľna operacja i dlatego zostađa tutaj podsumowana z perspektywy aplikacji. Celem profilowania jest ustalenie, dlaczego aplikacja zuľywa zasoby procesora. Efektywnæ technikæ jest próbkowanie w procesorze stosu na poziomie uľytkownika i đæczenie wyników. Ħlad stosu pokazuje zastosowanæ ħcieľkú kodu, co moľe wskazaè powody, dla których aplikacja zuľywa zasoby procesora. Próbkowanie stosu moľe wygenerowaè tysiæce wierszy danych wyjħciowych, na- wet podczas tworzenia podsumowania i wyħwietlania jedynie unikalnych stosów. Jednym ze sposobów szybkiego poznania profilu jest uľycie wykresów, co równieľ zostanie przedstawione w rozdziale 6.

Kup książkę Poleć książkę 5.4. Metodologia i analiza 209

Oprócz stosu próbkowaè moľna równieľ aktualnie wykonywanæ funkcjú. W ta- kich przypadkach wystarczajæce jest ustalenie, dlaczego aplikacja uľywa procesora, i wygenerowanie znacznie mniejszej iloħci danych wyjħciowych, co uđatwia odczyt i poznanie profilu. Prezentowany przykđad pochodzi z rozdziađu 6. „Procesory” i wyko- rzystuje narzúdzie DTrace:

# dtrace -n 'profile-997 /arg1 && execname == "beam.smp"/ { @[ufunc(arg1)] = count(); } tick-10s { exit(0); }' [...] innostore_drv.so`os_aio_array_get_nth_slot 80 beam.smp`process_main 127 libc.so.1`mutex_trylock_adaptive 140 innostore_drv.so`os_aio_simulated_handle 158 beam.smp`sched_sys_wait 202 libc.so.1`memcpy 258 innostore_drv.so`ut_fold_binary 1800 innostore_drv.so`ut_fold_ulint_pair 4039

W pokazanym przykđadzie, w trakcie wiúkszoħci operacji próbkowania, w proce- sorze byđa wykonywana funkcja ut_fold_ulint_pair(). Uľyteczne moľe byè równieľ przeanalizowanie komponentu wywođujæcego aktu- alnie wykonywanæ funkcjú, co moľna đatwo zrobiè za pomocæ niektórych programów sđuľæcych do profilowania (miúdzy innymi DTrace). Jeľeli w poprzednim przykđadzie okazađoby siú, ľe w procesorze najwiúcej czasu przebywa funkcja malloc(), taka in- formacja nie dostarczy nam zbyt wielu danych. Komponent wywođujæcy funkcjú malloc() stanie siú znacznie ciekawszym elementem do profilowania, a ponadto nie búdzie wy- magane przechwytywanie stosu. Przeanalizowanie zuľycia procesora przez interpretowany júzyk programowania i maszynú wirtualnæ moľe okazaè siú trudne. Nie istnieje đatwy sposób mapowania wykonywanego oprogramowania na oryginalny program. Konkretne rozwiæzanie zaleľy od ħrodowiska júzyka: moľe oferowaè funkcje debugowania pozwalajæce na wykonanie wymienionego zadania lub do tego celu mogæ byè dostúpne narzúdzia opracowane przez firmy trzecie. Na przykđad narzúdzie DTrace uľywa tak zwanych programów pomocniczych ustack do sprawdzania zawartoħci maszyny wirtualnej i konwersji stosów z powrotem na oryginalny program. Wspomniane programy pomocnicze istniejæ dla Javy, Pythona i Node.js. To jest przykđad próbkowania wykonywanego przez procesor kodu Java za pomocæ jstack() narzúdzia DTrace:

# dtrace -n 'profile-97 /pid == 1742/ { @[jstack(100)] = count(); }' dtrace: description 'profile-97 ' matched 1 probe ^C [...] libc.so.1`_so_send+0x7 libjvm.so`__1cDhpiEsend6Fipcii_i_+0xac libjvm.so`JVM_Send+0x31 libnet.so`Java_java_net_SocketOutputStream_socketWrite0+0x100

Kup książkę Poleć książkę 210 Rozdział 5 Aplikacje

java/net/SocketOutputStream.socketWrite0 java/net/SocketOutputStream.socketWrite java/net/SocketOutputStream.write java/io/DataOutputStream.write TransThread.TransTCP TransThread.run StubRoutines (1) libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJ... libjvm.so`__1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_... libjvm.so`__1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallA... libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsym... libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHan... libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0xd0 libjvm.so`__1cKJavaThreadRthread_main_inner6M_v_+0x51 libjvm.so`__1cKJavaThreadDrun6M_v_+0x105 libjvm.so`__1cG_start6Fpv_0_+0xd2 libc.so.1`_thr_setup+0x4e libc.so.1`_lwp_start 10

Dane wyjħciowe zostađy skrócone, tak ľe przedstawiajæ jedynie najczúħciej wystú- pujæce stosy, które byđy próbkowane dziesiúciokrotnie. Stosy pokazujæ wewnútrzne komponenty wirtualnej maszyny Javy (libjvm), a poszczególne funkcje sæ wyħwie- tlone jako sygnatury C++. Stos Javy zostađ przeksztađcony z wirtualnej maszyny Javy (pogrubione wiersze danych wyjħciowych) i pokazuje klasy oraz metody odpowie- dzialne za zuľycie procesora w trakcie danej ħcieľki kodu. Dla omawianego stosu byđo to java/io/DataOutputStream.write. W rozdziale 6. „Procesory” przygotowano omówienie innych metodologii i narzúdzi, a takľe róľnych sposobów analizowania poziomu zuľycia procesora przez aplikacjú.

5.4.3. Analiza wywołań systemowych Metodologia analizy stanu wætku rozpoczyna siú od opisania dwóch stanów do spraw- dzenia: w procesorze i poza procesorem. Búdzie uľyteczne, a czasami nawet praktyczne, przeanalizowanie wymienionych stanów na podstawie wykonywania wywođaē syste- mowych:

wykonywania — w procesorze (tryb uľytkownika), wywođania systemowego — czas wywođania systemowego (oczekiwanie lub dziađanie w trybie jædra).

Czas wywođania systemowego obejmuje operacje wejħcia-wyjħcia, blokady i inne rodzaje wywođaē systemowych. W pozostađych stanach wætku, na przykđad dziađania (i oczekiwania na procesor) oraz anonimowego stronicowania, nie ma miejsca na takie uproszczenie. Jeľeli mamy do czynienia z nasyceniem procesora lub pamiúci, to takie sytuacje moľna zidentyfikowaè w systemie za pomocæ metody USE.

Kup książkę Poleć książkę 5.4. Metodologia i analiza 211

Stan wykonywania jest moľliwy do przeanalizowania przy uľyciu wspomnianej wczeħniej metody profilowania procesora. Z kolei wywođania systemowe moľna analizowaè na wiele sposobów. Celem jest ustalenie, gdzie wywođanie systemowe przebywa najwiúcej czasu, typu wywođania sys- temowego i powodu jego wywođania.

Monitorowanie punktu kontrolnego Tradycyjny styl monitorowania wywođania systemowego oznacza ustawienie punktu kontrolnego dla wywođania systemowego i jego zakoēczenia. To jest technika inwa- zyjna, w przypadku aplikacji wykonujæcych duľæ liczbú wywođaē systemowych oznacza równieľ wrúcz ogromny spadek wydajnoħci. W zaleľnoħci od stawianych aplikacji wymagaē w zakresie wydajnoħci moľna zaak- ceptowaè stosowanie tego rodzaju stylu monitorowania jedynie w krótkim czasie, aby ustaliè typy wywođaē systemowych. strace W systemie Linux moľna wykorzystaè polecenie strace, na przykđad:

$ strace -ttt -T -p 1884 1356982510.395542 close(3) = 0 <0.000267> 1356982510.396064 close(4) = 0 <0.000293> 1356982510.396617 ioctl(255, TIOCGPGRP, [1975]) = 0 <0.000019> 1356982510.396980 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 <0.000024> 1356982510.397288 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 <0.000014> 1356982510.397365 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED|WCONTINUED, NULL) = 1975 <0.018187> 1356982510.415710 rt_sigprocmask(SIG_BLOCK, [CHLD TSTP TTIN TTOU], [CHLD], 8) = 0 <0.000018> 1356982510.416047 ioctl(255, SNDRV_TIMER_IOCTL_SELECT or TIOCSPGRP, [1884]) = 0 <0.000016> 1356982510.416118 rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 <0.000154> [...]

W przedstawionym przykđadzie uľyto nastúpujæcych opcji (omówienie wszystkich znajdziesz na stronie podrúcznika man):

-ttt. Wyħwietla pierwszæ kolumnú jako czas od poczætku epoki. Czas búdzie podany w sekundach z dokđadnoħciæ do mikrosekund. -T. Wyħwietla ostatniæ kolumnú jako . Kolumna ta wskazuje dđugoħè trwania wywođania systemowego. Czas búdzie podany w sekundach z dokđadnoħciæ do mikrosekund. -p PID. Monitorowanie procesu o podanym identyfikatorze. Istnieje równieľ moľliwoħè podania polecenia, co spowoduje jego uruchomienie przez strace i monitorowanie.

Kup książkę Poleć książkę 212 Rozdział 5 Aplikacje

Funkcje oferowane przez polecenie strace moľna zobaczyè w danych wyjħciowych — przeksztađcenie argumentów wywođania systemowego ma postaè czytelnæ dla czđo- wieka. To búdzie szczególnie uľyteczne podczas próby wykrycia uľycia ioctl(). Omówiona postaè strace wyħwietla wiersz danych wyjħciowych dla kaľdego wy- wođania systemowego. Uľycie opcji -c powoduje przygotowanie podsumowania dotyczæ- cego funkcjonowania wywođania systemowego:

$ strace -c -p 1884 Process 1884 attached - interrupt to quit ^CProcess 1884 detached % time seconds usecs/call calls errors syscall ------83.29 0.007994 9 911 455 wait4 14.41 0.001383 3 455 clone 0.85 0.000082 0 2275 ioctl 0.68 0.000065 0 910 close 0.63 0.000060 0 4551 rt_sigprocmask 0.15 0.000014 0 455 setpgid 0.00 0.000000 0 455 rt_sigreturn 0.00 0.000000 0 455 pipe ------100.00 0.009598 10467 455 total

Przedstawione dane wyjħciowe zawierajæ nastúpujæce kolumny: time — wyraľona w procentach wartoħè pokazujæca, na co zostađ poħwiúcony czas procesora, seconds — wyraľony w sekundach cađkowity czas procesora, usecs/call — wyraľony w mikrosekundach ħredni czas procesora dla wywođania systemowego, calls — liczba wywođaē systemowych w trakcie sesji strace, syscall — nazwa wywođania systemowego.

Jest to doskonađe rozwiæzanie w sytuacji, gdy wiæľæce siú z nim duľe obciæľenie nie stanowi problemu. Aby zilustrowaè problem, polecenie dd wykorzystamy do przeprowadzenia 5 mi- lionów operacji transferu danych o wielkoħci 1 KB. Sprawdzimy wykonanie zadania bez uľycia strace oraz z jego uľyciem. W tym pierwszym przypadku polecenie jest wykony- wane nastúpujæco:

$ dd if=/dev/zero of=/dev/null bs=1k count=5000k 5120000+0 records in 5120000+0 records out 5242880000 bytes (5.2 GB) copied, 1.91247 s, 2.7 GB/s

Dane wyjħciowe polecenia dd podajæ czas trwania operacji oraz przepustowoħè. W omawianym przypadku wykonanie zadania zabrađo okođo dwóch sekund.

Kup książkę Poleć książkę 5.4. Metodologia i analiza 213

W tym miejscu przedstawiono wykonanie tego samego zadania, ale z wykorzystaniem strace do podsumowania uľytych wywođaē systemowych:

$ strace -c dd if=/dev/zero of=/dev/null bs=1k count=5000k 5120000+0 records in 5120000+0 records out 5242880000 bytes (5.2 GB) copied, 140.722 s, 37.3 MB/s % time seconds usecs/call calls errors syscall ------51.46 0.008030 0 5120005 read 48.54 0.007574 0 5120003 write 0.00 0.000000 0 20 13 open 0.00 0.000000 0 10 close 0.00 0.000000 0 5 fstat 0.00 0.000000 0 1 lseek 0.00 0.000000 0 14 mmap 0.00 0.000000 0 8 mprotect 0.00 0.000000 0 2 munmap 0.00 0.000000 0 3 brk 0.00 0.000000 0 6 rt_sigaction 0.00 0.000000 0 1 rt_sigprocmask 0.00 0.000000 0 5 5 access 0.00 0.000000 0 2 dup2 0.00 0.000000 0 1 execve 0.00 0.000000 0 1 getrlimit 0.00 0.000000 0 1 arch_prctl 0.00 0.000000 0 2 1 futex 0.00 0.000000 0 1 set_tid_address 0.00 0.000000 0 1 set_robust_list ------100.00 0.015604 10240092 19 total

Jak moľesz siú przekonaè, czas trwania operacji wydđuľyđ siú 73 razy, podobny spa- dek zanotowano w przepustowoħci. Mamy tutaj do czynienia z powaľnym problemem, który wynika z tego, ľe polecenie dd wykonuje ogromnæ iloħè wywođaē systemowych. truss W systemach Solaris istnieje polecenie truss przeznaczone do monitorowania wywođaē systemowych, na przykđad:

$ truss -dE -p 81573 Base time stamp: 1356985396.2469 [ Mon Dec 31 20:23:16 UTC 2012 ] 0.0016 0.0000 waitid(P_ALL, 0, 0x08047A80, WEXITED|WTRAPPED|WSTOPPED|WCONTINUED) = 0 0.0018 0.0000 lwp_sigmask(SIG_SETMASK, 0x06820000, 0x00000000, 0x00000000, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF] 0.0019 0.0000 ioctl(255, TIOCGSID, 0x08047AEC) = 0 0.0019 0.0000 getsid(0) = 81573 0.0020 0.0000 ioctl(255, TIOCSPGRP, 0x08047B24) = 0

Kup książkę Poleć książkę 214 Rozdział 5 Aplikacje

0.0021 0.0000 lwp_sigmask(SIG_SETMASK, 0x00020000, 0x00000000, 0x00000000, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF] 0.0022 0.0000 ioctl(255, TCGETS, 0x0811D640) = 0 0.0023 0.0000 ioctl(255, TIOCGWINSZ, 0x08047B48) = 0 [...]

W zaprezentowanym przykđadzie uľyto nastúpujæcych opcji (omówienie wszystkich znajdziesz na stronie podrúcznika man):

-d. Wyħwietla pierwszæ kolumnú jako czas od poczætku epoki. -E. Wyħwietla drugæ kolumnú jako znacznik czasu pokazujæcy wyraľony w sekundach czas wykonywania wywođania systemowego. -p PID. Monitorowanie procesu o podanym identyfikatorze. Istnieje równieľ moľliwoħè podania polecenia, co spowoduje jego uruchomienie przez truss i monitorowanie.

Dane wyjħciowe zawierajæ po jednym wierszu dla wywođania systemowego i sæ uľy- teczne podczas przeksztađcania argumentów na postaè czytelnæ dla czđowieka. Znaczniki czasu majæ dokđadnoħè jedynie 0,1 ms, co nieco ogranicza ich uľytecznoħè. Polecenie truss obsđuguje równieľ tryb podsumowania, dostúpny za pomocæ opcji -c:

$ truss -c dd if=/dev/zero of=/dev/null bs=1k count=10k 10240+0 records in 10240+0 records out

syscall seconds calls errors _exit .000 1 read .075 10252 write .073 10246 open .000 9 1 close .000 10 brk .000 6 getpid .000 1 fstat .000 6 sysi86 .000 1 ioctl .000 1 1 execve .000 1 sigaction .000 2 getcontext .000 1 setustack .000 1 mmap .000 8 mmapobj .000 1 getrlimit .000 1 memcntl .000 3 sysconfig .000 3 sysinfo .000 1 lwp_private .000 1 llseek .000 3 schedctl .000 1

Kup książkę Poleć książkę 5.4. Metodologia i analiza 215

resolvepath .000 3 stat64 .000 2 fstat64 .000 4 open64 .000 2 ------sys totals: .150 20571 2 usr time: .029 elapsed: .880

Kolumna seconds pokazuje czas procesora poħwiúcony na wykonanie wywođania systemowego. Z kolei kolumna calls podaje liczbú wywođaē. Dziúki uľyciu opcji -u polecenie truss moľe równieľ przeprowadzaè swego rodzaju monitorowanie dynamiczne wywođaē funkcji na poziomie uľytkownika. Poniľej pokaza- no na przykđad monitorowanie wywođaē funkcji printf():

$ truss -u 'libc:*printf*' uptime /1: open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/SUNW_OST_OSCMD.mo", O_RDONLY) Err#2 ENOENT /1: -> libc:printf(0x403363, 0x0, 0x0, 0x0, 0x0, 0xfffffd7fffdfeab0) /1: <- libc:printf() = 4 /1: -> libc:printf(0x403368, 0x58, 0x0, 0x0, 0x0, 0x10) /1: <- libc:printf() = 11 [...]

Podobnie jak w przypadku polecenia strace, obciæľenie zwiæzane z wykonywaniem wielu wywođaē systemowych lub funkcji búdzie znaczne, co praktycznie uniemoľliwia zastosowanie polecenia truss w ħrodowisku produkcyjnym.

Monitorowanie buforowane W przypadku monitorowania buforowanego dane instrumentów mogæ byè bufo- rowane w jædrze, podczas gdy analizowany program kontynuuje dziađanie. Takie roz- wiæzanie róľni siú od monitorowania punktów kontrolnych, w których nastúpowađo przerywanie dziađania analizowanego programu. Narzúdzie DTrace pozwala na stosowanie monitorowania buforowanego i agregacji, aby tym samym zmniejszyè obciæľenie zwiæzane z operacjæ monitorowania i umoľliwiè programom rejestracjú wywođaē systemowych do póļniejszej analizy. Pewne przykđady takiego rozwiæzania zostanæ przedstawione w tym fragmencie ksiæľki. W systemie Linux, dziađajæcym pod kontrolæ jædra w wersji 3.7, do polecenia perf dodano pod- polecenie trace, które przeprowadza buforowane monitorowanie wywođaē systemowych (i nie tylko). Przedstawione dalej jednowierszowe wywođania narzúdzia DTrace obrazujæ pew- ne podstawy dotyczæce analizy wywođaē systemowych i sæ przeznaczone zarówno do systemów Linux, jak i Solaris (przykđady dotyczæ tego drugiego). Znacznie wiúcej przy- k đadów jednowierszowych wywođaē narzúdzia DTrace znajdziesz w dodatku D. Pokazane tutaj przykđady przetwarzajæ sygnađy (za pomocæ wywođania systemowego kill()), zawierajæ identyfikator procesu, jego nazwú oraz docelowy identyfikator proce- su i numer sygnađu.

Kup książkę Poleć książkę 216 Rozdział 5 Aplikacje

# dtrace -qn 'syscall::kill:entry { printf("%Y: %s (PID %d) sent a SIG %d to PID %d\n", walltimestamp, execname, pid, arg1, arg0); }' 2013 Apr 17 00:27:37: bash (PID 2583) sent a SIG 9 to PID 2638 2013 Apr 17 00:27:51: postgres (PID 25906) sent a SIG 16 to PID 25896 2013 Apr 17 00:27:51: postgres (PID 2676) sent a SIG 17 to PID 25906 2013 Apr 17 00:27:51: postgres (PID 2676) sent a SIG 17 to PID 25906

Podczas monitorowania przechwycono, jak proces bash wysđađ sygnađ –9 (SIGKILL) do procesu o identyfikatorze 2638, a takľe pewne sygnađy z procesu postgres (baza da- nych PostgreSQL). Uwzglúdnienie znaczników czasu moľe byè pomocne podczas korela- cji z innymi operacjami. Przedstawione jednowierszowe polecenie powoduje zliczanie wywođaē systemowych (za pomocæ agregacji) dla procesów o nazwie postgres (baza danych PostgreSQL):

# dtrace -n 'syscall:::entry /execname == "postgres"/ { @[probefunc] = count(); }' dtrace: description 'syscall:::entry ' matched 233 probes ^C setitimer 4 semsys 22 open64 35 kill 79 lwp_sigmask 79 setcontext 79 write 126 fcntl 252 pollsys 2498 read 2750 send 9542 recv 12096 llseek 27925

W trakcie monitorowania najczúħciej — 27 925 razy — byđo wykonywane wywođanie systemowe llseek(). Kolejne polecenie powoduje zmierzenie czasu trwania (nazywanego równieľ opóļ- nieniem) wywođaē systemowych read(), wykonywanych przez PostgreSQL:

# dtrace -n 'syscall::read:entry /execname == "postgres"/ { self->ts = timestamp; } syscall::read:return /self->ts/ { @["ns"] = quantize(timestamp - self->ts); self->ts = 0; }' dtrace: description 'syscall::read:entry ' matched 2 probes ^C ns value ------Distribution ------count 256 | 0 512 |@@ 1124 1024 |@@@@@@@ 5108 2048 |@@@@@@@@@@@@@@@@@@@@@@@ 15427 4096 |@@@@@@ 4391 8192 |@ 777 16384 |@ 425

Kup książkę Poleć książkę 5.4. Metodologia i analiza 217

32768 | 114 65536 | 5 131072 | 4 262144 | 4 524288 | 0

Podczas przedstawionej sesji monitorowania wiúkszoħè wywođaē systemowych read() trwađa od 1 μs do 8 μs (od 1024 ns do 8191 ns). Wywođanie systemowe read() operuje na deskryptorze pliku, który moľe byè obiektem systemu plików lub gniazdem sieciowym. Identyfikacja wywođaē zostanie przedstawiona w odpowiednich rozdziađach — odbywa siú za pomocæ tablicy fds[] narzúdzia DTrace, uľywanej do mapowania deskryptorów plików na ich typy systemów plików. W omawianym przykđadzie, jeħli wbudowana wartoħè timestamp zostanie zmie- niona na vtimestamp, to búdzie oznaczaè, ľe czas procesora jest mierzony tylko podczas wywođania systemowego. Takie rozwiæzanie moľe byè uľywane do porównania z czasem wykonywania, co pozwoli przekonaè siú, czy wywođanie systemowe przebywa wiúcej czasu w kodzie jædra czy zablokowane w oczekiwaniu na operacjú wejħcia-wyjħcia. Istnieje moľliwoħè tworzenia znacznie bardziej skomplikowanych skryptów DTrace w celu wyraľania na wiele róľ nych sposobów czasu dotyczæcego wywođania systemowego. Przykđady mogæ obejmowaè miúdzy innymi nastúpujæce skrypty (pochodzæ z zestawu DTraceToolkit, patrz odwođanie [3] na koēcu rozdziađu):

dtruss. Wersja truss, taka jak DTrace; dziađa na poziomie systemu. execsnoop. Monitorowanie wykonywania nowych procesów, odbywa siú za pomocæ wywođania systemowego exec(). opensnoop. Monitorowanie wywođaē systemowych open() wraz z róľnymi detalami. procsystime. Podsumowanie na wiele sposobów czasu dotyczæcego wywođaē systemowych.

Przedstawione rozwiæzania pozwalajæ rozwikđaè wiele kwestii zwiæzanych z wy- dajnoħciæ. Odbywa siú to przez ogólnæ identyfikacjú aktywnoħci procesu, któræ moľna dostroiè lub zupeđnie wyeliminowaè. Stanowi to pewien rodzaj charakterystyki obciæľenia: obciæľeniem sæ wywođania systemowe wykonywane przez aplikacjú. Na przykđad przedstawione polecenie execsnoop wraz z opcjæ -v wyħwietla znaczniki czasu w systemie dziađajæcym w chmurze:

# execsnoop -v STRTIME UID PID PPID ARGS 2013 Jan 12 22:10:05 0 15044 14378 /usr/bin/date +%M 2013 Jan 12 22:10:05 0 15039 15038 /opt/mon/bin/rrdtool graph /opt/mo... 2013 Jan 12 22:10:05 0 15037 15036 /opt/mon/bin/rrdtool update /opt/m... 2013 Jan 12 22:10:05 0 15041 15040 /opt/mon/bin/rrdtool graph /opt/mo... 2013 Jan 12 22:10:05 0 15043 15042 /opt/mon/bin/rrdtool graph /opt/mo... 2013 Jan 12 22:10:06 0 15046 15045 /usr/bin/echo 2013 Jan 12 22:10:06 0 15048 15045 /usr/bin/tail -200 2013 Jan 12 22:10:06 0 15049 15048 /usr/bin/cat -sv /var/adm/messages...

Kup książkę Poleć książkę 218 Rozdział 5 Aplikacje

2013 Jan 12 22:10:06 0 15050 15049 /usr/bin/ls -tr1 /var/adm/messages... 2013 Jan 12 22:10:06 0 15045 14377 /usr/bin/sh /usr/bin/dmesg [...]

Znaczniki czasu wskazujæ, ľe wszystkie procesy sæ wykonywane w czasie okođo 2 s. Wysoka liczba krótkotrwađych procesów moľe zuľywaè zasoby procesora i negatywnie wpđywaè na inne aplikacje, co wynika z koniecznoħci wykonywania wywođaē miúdzy procesorami (przeđæczania kontekstu MMU podczas koēczenia dziađania procesu).

5.4.4. Profilowanie operacji wejścia-wyjścia Profilowanie operacji wejħcia-wyjħcia peđni podobnæ rolú jak profilowanie procesora, ale pomaga takľe w ustaleniu, dlaczego i jak wykonywane sæ wywođania systemowe zwiæ- zane z operacjami wejħcia-wyjħcia. Do tego celu uľywa siú narzúdzia DTrace i analizuje stosy na poziomie uľytkownika dla wywođaē systemowych. Na przykđad przedstawione tutaj polecenie powoduje monitorowanie wywođaē sys- temowych read() wykonywanych przez PostgreSQL, zebranie informacji dotyczæcych stosu na poziomie uľytkownika oraz agregacjú zebranych danych:

# dtrace -n 'syscall::read:entry /execname == "postgres"/ { @[ustack()] = count(); }' dtrace: description 'syscall::read:entry ' matched 1 probe ^C [...] libc.so.1`__read+0x15 postgres`XLogRead+0xb7 postgres`XLogSend+0x115 postgres`WalSenderMain+0x10c6 postgres`PostgresMain+0x1aa postgres`ServerLoop+0x6fe postgres`PostmasterMain+0x7e2 postgres`main+0x412 postgres`_start+0x83 210 libc.so.1`__read+0x15 postgres`WaitLatchOrSocket+0xb1 postgres`PgstatCollectorMain.isra.21+0x2ed postgres`pgstat_start+0x68 postgres`reaper+0x5bd libc.so.1`__sighndlr+0x15 libc.so.1`call_user_handler+0x292 libc.so.1`sigacthandler+0x77 libc.so.1`syscall+0x13 libc.so.1`thr_sigsetmask+0x1c2 libc.so.1`sigprocmask+0x52 postgres`ServerLoop+0xb7 postgres`PostmasterMain+0x7e2 postgres`main+0x412 postgres`_start+0x83 10723

Kup książkę Poleć książkę 5.4. Metodologia i analiza 219

Dane wyjħciowe (skrócone) pokazujæ stosy na poziomie uľytkownika oraz zliczone liczby ich wystæpieē. Wspomniane stosy zawierajæ nazwy wewnútrznych funkcji aplika- cji. Prawdopodobnie nie búdziesz w stanie zrozumieè tych danych wyjħciowych, o ile nie przeprowadzisz analizy kodu ļródđowego. Jednak zdođasz zebraè wystarczajæco duľo uľytecznych informacji na podstawie nazw funkcji. Stos pierwszy zawiera XLogRead:; moľe byè powiæzany z rodzajem dziennika zdarzeē w bazie danych. Stos drugi zawiera PgstatCollectorMain.isra; nazwa wskazuje na pewne dziađania z zakresu monitorowania. Stosy dostarczajæ informacji o tym, dlaczego wykonywane sæ dane wywođania systemowe. Uľyteczne moľe byè przeanalizowanie dodatkowych atrybutów metodologii charakterystyki obciæľenia, o czym wspomniano juľ w rozdziale 2. „Metodologia”:

Kto? Identyfikator procesu, nazwa uľytkownika. Co? Komponent wykonujæcy dane wywođanie systemowe (na przykđad system plików lub gniazdo), wielkoħè operacji wejħcia-wyjħcia, wartoħè IOPS, przepustowoħè (wyraľona w bajtach na sekundú), inne atrybuty. Jak? Zmiana wartoħci IOPS na przestrzeni czasu.

Oprócz zastosowanego obciæľenia moľna przeanalizowaè jeszcze wydajnoħè wyniko- wæ — opóļnienie wywođania systemowego — jak wspomniano przy okazji poprzedniej metodologii.

5.4.5. Charakterystyka obciążenia Aplikacja zleca wykonywanie zadaē zasobom systemu — procesorom, pamiúci, syste- mowi plików, dyskom i sieci — przez uľycie wywođaē systemowych, podobnie jak ma to miejsce w przypadku systemu operacyjnego. Te wszystkie dziađania moľna prze- analizowaè za pomocæ metodologii charakterystyki obciæľenia, któræ przedstawiono w rozdziale 2. „Metodologia” oraz omówiono w kolejnych rozdziađach. Ponadto przeanalizowaè moľna obciæľenie aplikacji. Tutaj naleľy siú skoncentrowaè na operacjach wykonywanych przez aplikacjú i na ich atrybutach. To moľe byè kluczowa metryka w monitorowaniu wydajnoħci i podczas planowania pojemnoħci.

5.4.6. Metoda USE Metodú USE wprowadzono w rozdziale 2. „Metodologia” i zastosowano w kolejnych roz- dziađach. Pozwala ona na sprawdzenie poziomu wykorzystania, nasycenia i bđúdów we wszystkich zasobach sprzútowych. Wiele problemów zwiæzanych z wydajnoħciæ moľna usunæè dziúki uľyciu metody USE, która wskaľe zasób búdæcy wæskim gardđem. Metodú USE moľna zastosowaè takľe wzglúdem zasobów w postaci oprogramowa- nia, choè ta moľliwoħè zaleľy od danej aplikacji. Jeľeli jesteħ w stanie zdobyè wykres funkcjonalny pokazujæcy wewnútrzne komponenty aplikacji, przeanalizuj poziomy wykorzystania, nasycenia i bđúdów dla kaľdego zasobu oprogramowania i przekonaj siú, co ma sens.

Kup książkę Poleć książkę 220 Rozdział 5 Aplikacje

Na przykđad aplikacja moľe uľywaè puli wætków roboczych w celu przetwarzania ľædaē oraz kolejki przeznaczonej dla ľædaē oczekujæcych na swojæ kolej. Traktujæc wspomniane trzy metryki jako zasób, moľna je zdefiniowaè nastúpujæco:

Poziom wykorzystania. Ħrednia liczba wætków zajútych przetwarzaniem ľædaē w pewnym przedziale czasu, podana jako procent wszystkich wætków. Na przykđad wartoħè 50% oznacza, ľe ħrednio pođowa wætków byđa zajúta przetwarzaniem ľædaē. Poziom nasycenia. Ħrednia dđugoħè kolejki ľædaē w pewnym przedziale czasu. Ta wartoħè okreħla, ile ľædaē czeka na przetworzenie przez wætek roboczy. Bđúdy. Ľædania odrzucone lub zakoēczone niepowodzeniem z jakiegokolwiek powodu.

Twoje zadanie polega na znalezieniu sposobu pomiaru wymienionych metryk. Od- powiednie wartoħci mogæ byè dostarczane przez aplikacjú lub trzeba búdzie je dodaè bædļ zmierzyè za pomocæ innych narzúdzi, na przykđad oferujæcych moľliwoħè monito- rowania dynamicznego. Systemy kolejkowe, jak wymieniony w przykđadzie, moľna przeanalizowaè za pomocæ teorii kolejek (patrz rozdziađ 2. „Metodologia”). Spójrzmy teraz na inny przykđad, obejmujæcy deskryptory plików. System moľe nakđadaè pewne ograniczenia, poniewaľ iloħè zasobów nie jest nieskoēczona. Trzy wspo- mniane wczeħniej metryki moľna wiúc zdefiniowaè nastúpujæco:

Poziom wykorzystania. Liczba uľywanych deskryptorów plików, podana jako wartoħè procentowa dozwolonego limitu. Poziom nasycenia. Zaleľy od zachowania systemu operacyjnego. Jeľeli podczas oczekiwania na alokacjú deskryptora pliku wætek pozostaje zablokowany, wówczas to moľe byè liczba zablokowanych wætków oczekujæcych na dany zasób. Bđúdy. Bđúdy alokacji, na przykđad typu EFILE lub „Zbyt wiele otwartych plików”.

Przedstawione èwiczenie powtórz dla wszystkich komponentów aplikacji i pomiē te metryki, które nie majæ sensu. Taki proces moľe pomóc w przygotowaniu krótkiej listy rzeczy do sprawdzenia w aplikacji przed przejħciem do innych metodologii, takich jak analiza dræľæca.

5.4.7. Analiza drążąca W przypadku aplikacji analiza dræľæca moľe siú rozpoczynaè od sprawdzenia opera- cji wykonywanych przez dany program, by nastúpnie przejħè w gđæb aplikacji i zoba- czyè, jak sæ one przeprowadzane. Dla operacji wejħcia-wyjħcia tego rodzaju analiza dræľæca moľe obejmowaè biblioteki systemowe, wywođania systemowe oraz jædro. To zdecydowanie jest zaawansowane zadanie, które bardzo szybko doprowadzi analityka do wewnútrznych komponentów aplikacji. W idealnej sytuacji powinny byè one typu open source, co pozwoli na ich analizú. Narzúdzia oferujæce funkcjú monito- rowania dynamicznego (na przykđad DTrace, SystemTap lub perf) majæ instrumenty

Kup książkę Poleć książkę 5.4. Metodologia i analiza 221 przeznaczone dla wspomnianych komponentów wewnútrznych i mogæ prowadziè moni- torowanie w pewnych júzykach đatwiej niľ inne narzúdzia. Sprawdļ, czy uľywany júzyk oferuje wđasny zestaw narzúdzi przeznaczonych do analizy, których uľycie moľe okazaè siú lepszym rozwiæzaniem. Istniejæ równieľ okreħlone narzúdzia przeznaczone do analizy wywođaē bibliotek: ltrace w systemie Linux i apptrace w Solarisie (choè jego uľycie skđania do DTrace).

5.4.8. Analiza blokad W aplikacjach wielowætkowych blokady mogæ staè siú wæskim gardđem, negatywnie wpđywajæcym na wspóđbieľnoħè i skalowalnoħè. Analizú moľna przeprowadziè pod kætem:

sprawdzenia, czy wystúpuje zjawisko rywalizacji; sprawdzenia, czy blokady sæ nakđadane na dđugi czas.

Punkt pierwszy pozwala ustaliè, czy problem juľ wystúpuje. Dđugi czas blokady niekoniecznie jest problemem, ale moľe siú nim staè w przyszđoħci, gdy wzroħnie poziom jednoczesnego obciæľenia. W przypadku obu punktów warto ustaliè nazwú blokady (o ile istnieje) i ħcieľkú kodu prowadzæcæ do jej nađoľenia. Wprawdzie istniejæ specjalne narzúdzia przeznaczone do analizy blokad, ale problem moľna czasami rozwiæzaè, stosujæc jedynie profilowanie procesora. W blokadach wirujæ- cych stan rywalizacji przejawia siú w postaci zuľycia procesora i moľna go đatwo wy- chwyciè podczas profilowania procesora. Z kolei w adaptacyjnych blokadach muteksu stan rywalizacji czústo oznacza istnienie pewnych blokad, co równieľ moľna wychwyciè za pomocæ profilowania procesora. Warto jednak pamiútaè, ľe profilowanie procesora nie daje peđ nego obrazu sytuacji, poniewaľ wætki mogæ byè blokowane i uħpione podczas oczekiwania na zniesienie blokad. Zapoznaj siú z punktem 5.4.2, zatytuđowanym „Profilowanie procesora”. Oto przykđady specjalnych narzúdzi w systemie Solaris przeznaczonych do analizy blokad:

plockstat — analiza blokad na poziomie uľytkownika, lockstat — analiza blokad na poziomie jædra.

Zachowanie wymienionych poleceē jest podobne. Zostađy zaimplementowane za pomocæ narzúdzia DTrace, które moľna wykorzystaè do bezpoħredniego przeprowa- dzenia znacznie dokđadniejszej analizy blokad. To jest przykđad uľycia polecenia lockstat:

# lockstat -n 1000000 -C -s5 sleep 5 > lockstat.txt # more lockstat.txt Adaptive mutex spin: 134438 events in 5.058 seconds (26577 events/sec) ------Count indv cuml rcnt nsec Lock Caller 14144 11% 11% 0.00 1787 0xffffff0d71404348 zfs_range_unlock+0x2a nsec ------Time Distribution ------count Stack

Kup książkę Poleć książkę 222 Rozdział 5 Aplikacje

256 |@ 902 zfs_read+0x239 512 |@@@@ 1948 fop_read+0x8b 1024 |@@@@@@ 3033 read+0x2a7 2048 |@@@@@@@@@ 4286 read32+0x1e 4096 |@@@@@@ 3143 8192 |@ 656 16384 | 148 32768 | 24 65536 | 2 131072 | 0 262144 | 0 524288 | 0 1048576 | 2 ------Count indv cuml rcnt nsec Lock Caller 13701 10% 21% 0.00 1769 0xffffff0d71404348 zfs_range_lock+0x86 nsec ------Time Distribution ------count Stack 256 |@@ 1119 zfs_read+0x101 512 |@@@@ 1970 fop_read+0x8b 1024 |@@@ 1492 read+0x2a7 2048 |@@@@@@@@@@ 4976 read32+0x1e 4096 |@@@@@@@ 3469 8192 |@ 520 16384 | 124 32768 | 24 65536 | 7 ------[...] Adaptive mutex block: 399 events in 5.058 seconds (79 events/sec) ------Count indv cuml rcnt nsec Lock Caller 21 5% 5% 0.00 21053 0xffffff0d71404348 zfs_range_unlock+0x2a nsec ------Time Distribution ------count Stack 8192 |@@@@@ 4 zfs_read+0x239 16384 |@@@@ 3 fop_read+0x8b 32768 |@@@@@@@@@@@@@@@ 11 read+0x2a7 65536 |@@@@ 3 read32+0x1e ------Count indv cuml rcnt nsec Lock Caller 20 5% 10% 0.00 15107 0xffffff0d71404348 zfs_range_lock+0x86 nsec ------Time Distribution ------count Stack 8192 |@@@@ 3 zfs_read+0x101 16384 |@@@@@@@@@@@@ 8 fop_read+0x8b 32768 |@@@@@@@@@@@@@ 9 read+0x2a7 read32+0x1e [...] Spin lock spin: 2174 events in 5.058 seconds (430 events/sec) ------Count indv cuml rcnt nsec Lock Caller 589 27% 27% 0.00 73972 cp_default disp_lock_enter+0x26 nsec ------Time Distribution ------count Stack 512 |@@@ 65 disp_getbest+0x28

Kup książkę Poleć książkę 5.4. Metodologia i analiza 223

1024 |@@@@@@@@@@@@ 239 disp_getwork+0x37 2048 |@ 23 idle+0x55 4096 | 6 thread_start+0x8 8192 |@ 39 16384 |@ 37 32768 |@@ 53 65536 |@@ 43 131072 |@@ 45 262144 | 18 524288 | 3 1048576 | 7 2097152 | 4 4194304 | 7 [...] R/W reader blocked by writer: 1 events in 5.058 seconds (0 events/sec) ------Count indv cuml rcnt nsec Lock Caller 1 100% 100% 0.00 259688397 0xffffff0d6f0cf898 as_fault+0x2a9 nsec ------Time Distribution ------count Stack 268435456 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 pagefault+0x96 trap+0x2c7 cmntrap+0xe6 ------

W przedstawionym przykđadzie polecenie lockstat monitorowađo zdarzenia ry- walizacji (-C) na piúciu poziomach stosu (-s5) i zostađo uruchomione wraz z koprocesem (sleep(1)) w celu dostarczenia czasu utraty waľnoħci wynoszæcego 5 s. Dane zostađy przekierowane do pliku, aby moľna byđa đatwiej je przeglædaè (to ponad 100 000 wierszy). Dane wyjħciowe zaczynajæ siú od przedstawienia czasu blokad adaptacyjnych i roz- kđadu punktów pokazujæcych czas kaľdego zdarzenia rywalizacji wraz z nazwæ blokady i stosem. Najczúħciej wystúpowađa blokada zfs_range_unlock, która miađa 14 144 wystæ- pienia i ħredni czas trwania wynoszæcy 1,787 ns. Rozkđad pokazuje, ľe istniejæ dwa wy- stæpienia o czasie trwania przekraczajæcym 1 048 576 ns (w przedziale od 1 ms do 2 ms). Liczbú tych blokad moľna sprawdziè w danych wyjħciowych dotyczæcych adaptacyjnych blokad muteksu. Monitorowanie blokad na poziomie jædra lub uľytkownika wiæľe siú z pewnym ob- ciæľeniem. Wymienione tutaj narzúdzia sæ oparte na DTrace, co w maksymalnym stop- niu ogranicza wspomniane obciæľenie. Jak wczeħniej wspomniano, alternatywne rozwiæ- zanie polega na profilowaniu procesora na stađej czústotliwoħci (na przykđad 97 Hz) — pozwoli to wykryè wiele problemów zwiæzanych z blokadami (choè nie wszystkie) i nie spowoduje przy tym obciæľenia nieodđæcznie towarzyszæcego monitorowaniu.

5.4.9. Statyczne dostosowanie wydajności Statyczne dostosowanie wydajnoħci koncentruje siú na problemach wystúpujæcych w skon- figurowanym ħrodowisku. W przypadku wydajnoħci aplikacji naleľy przeanalizowaè wymienione aspekty konfiguracji statycznej:

Kup książkę Poleć książkę 224 Rozdział 5 Aplikacje

Jaka jest wersja uruchomionej aplikacji? Czy sæ dostúpne jej nowsze wersje? Czy w informacjach dotyczæcych nowych wydaē pojawiajæ siú jakiekolwiek wzmianki o poprawie wydajnoħci? Jakie sæ znane problemy z wydajnoħciæ w danej aplikacji? Czy dla aplikacji istnieje baza danych pozwalajæca na przeglædanie zgđoszonych bđúdów? W jaki sposób aplikacja zostađa skonfigurowana? Jeľeli zostađa skonfigurowana lub dostrojona odmiennie od jej ustawieē domyħlnych, to jaki byđ powód zastosowania takiej konfiguracji? Czy konfiguracjú przygotowano na podstawie pomiarów i analizy, czy po prostu losowo dobierajæc wartoħci? Czy aplikacja wykorzystuje buforowanie obiektów? Jaka jest wielkoħè bufora? Czy aplikacja pozwala na wspóđbieľnoħè? Jak to zostađo skonfigurowane (na przykđad czy zastosowano pulú wætków)? Czy aplikacja dziađa w trybie specjalnym? (Na przykđad mógđ zostaè wđæczony tryb debugowania, który powoduje spadek wydajnoħci dziađania aplikacji). Z jakich bibliotek systemowych korzysta aplikacja? W jakich sæ one wersjach? Jaki rodzaj alokacji pamiúci jest stosowany w aplikacji? Czy aplikacja zostađa skonfigurowana do uľycia ogromnych stron dla sterty? Czy aplikacja zostađa skompilowana? Jakiej wersji kompilatora uľyto? Jakie zastosowano opcje i optymalizacje kompilatora? Czy aplikacja jest w wersji 64-bitowej? Czy w aplikacji wystæpiđ jakikolwiek bđæd i teraz dziađa ona w trybie zdegradowanym? Czy w systemie zastosowano jakiekolwiek mechanizmy kontroli zasobów dla procesora, pamiúci, systemu plików, dysku lub sieci? (Taka sytuacja najczúħciej wystúpuje w przetwarzaniu w chmurze).

Udzielenie odpowiedzi na wymienione pytania moľe wskazaè róľne opcje konfigura- cyjne, które wczeħniej zostađy przeoczone.

5.5. Ćwiczenia 1. Odpowiedz na nastúpujæce pytania zwiæzane z terminologiæ: Co to jest bufor? Co to jest bufor cykliczny? Co to jest bufor wirujæcy? Co to jest adaptacyjna blokada muteksu? Jaka jest róľnica miúdzy wspóđbieľnoħciæ i równolegđoħciæ? Co oznacza powiæzanie z procesorem?

Kup książkę Poleć książkę 5.5. Ćwiczenia 225

2. Odpowiedz na pytania i wykonaj polecenia dotyczæce koncepcji: Jakie sæ ogólne wady i zalety uľycia ogromnych operacji wejħcia-wyjħcia? Do czego jest uľywana tabela hash blokad? Przedstaw ogólnæ charakterystykú wydajnoħci ħrodowiska júzyków kompilowanych, júzyków interpretowanych i tych, które uľywajæ maszyn wirtualnych. Wyjaħnij rolú mechanizmu usuwania nieuľytków i jego wpđyw na wydajnoħè. 3. Wybierz aplikacjú i odpowiedz na podstawowe pytania na jej temat: Jaka jest rola tej aplikacji? Jakie odmienne operacje sæ przez niæ wykonywane? W jakim trybie dziađa: uľytkownika czy jædra? W jaki sposób zostađa skonfigurowana? Jakie sæ kluczowe opcje zwiæzane z jej wydajnoħciæ? Jakie metryki wydajnoħci sæ przez niæ dostarczane? Jakie dzienniki zdarzeē sæ tworzone przez aplikacjú? Czy znajdujæ siú w nich jakiekolwiek informacje dotyczæce wydajnoħci? Czy w najnowszych jej wersjach zostađy usuniúte problemy zwiæzane z wydajnoħciæ? Czy w aplikacji istniejæ znane bđúdy wpđywajæce na jej wydajnoħè? Czy aplikacja ma swojæ spođecznoħè (na przykđad poħwiúcony jej kanađ IRC, spotkania uľytkowników)? Czy to jest spođecznoħè koncentrujæca siú na wydajnoħci aplikacji? Czy aplikacji poħwiúcono jakiekolwiek ksiæľki? Czy to sæ ksiæľki dotyczæce wydajnoħci? Czy istniejæ jacyħ uznani eksperci w zakresie danej aplikacji? Kim oni sæ? 4. Wybierz aplikacjú znajdujæcæ siú pod obciæľeniem, a nastúpnie wykonaj nastúpujæce zadania (wiele z nich búdzie wymagađo zastosowania monitorowania dynamicznego): Przed wykonaniem jakichkolwiek pomiarów odpowiedz na pytanie: Jakiego rodzaju ograniczeē oczekujesz — zwiæzanych z procesorem czy operacjami wejħcia-wyjħcia? Wyjaħnij powody. Za pomocæ narzúdzi monitorowania ustal, co jest czynnikiem ograniczajæcym wydajnoħè dziađania aplikacji: procesor czy operacje wejħcia-wyjħcia. Scharakteryzuj wielkoħè przeprowadzanych operacji wejħcia-wyjħcia, na przykđad odczyt i zapis systemu plików, otrzymywanie i wysyđanie danych przez sieè itd. Czy aplikacja korzysta z bufora? Ustal jego wielkoħè i wspóđczynnik trafnoħci. Dokonaj pomiaru opóļnienia (czasu udzielania odpowiedzi) dla operacji wykonywanych przez aplikacjú. Okreħl wartoħè ħredniæ, minimalnæ, maksymalnæ oraz peđny rozkđad.

Kup książkę Poleć książkę 226 Rozdział 5 Aplikacje

Przeprowadļ analizú dræľæcæ operacji, sprawdļ ļródđo wiúkszoħci opóļnieē. Scharakteryzuj obciæľenie stosowane w aplikacji, w szczególnoħci odpowiedz na pytania: kto i dlaczego. Przygotuj listú statycznego dostrojenia wydajnoħci aplikacji. Czy aplikacja pozwala na wspóđbieľnoħè? Sprawdļ jej moľliwoħci w zakresie stosowania synchronizacji podstawowej. 5. (Opcjonalne, zaawansowane) Opracuj dla systemu Linux narzúdzie o nazwie tsastat, którego zadaniem jest wyħwietlenie kolumn dla wszystkich szeħciu stanów stosowanych podczas analizy wætku oraz czasu spúdzonego w poszczególnych stanach. Dziađanie narzúdzia búdzie zbliľone do pidstat, podobnie jak generowane dane wyjħciowe.

5.6. Odwołania [Knuth 76] D. Knuth, Big Omicron and Big Omega and Big Theta, „ACM SIGACT News”, 1976. [Knuth 97] D. Knuth, The Art of Computer Programming, Volume 1: Fundamental Algorithms, wyd. 3, Addison-Wesley, 1997. [1] http://lwn.net/Articles/314512/ [2] http://nodejs.org/ [3] http://www.brendangregg.com/dtrace.html#DTraceToolkit

Kup książkę Poleć książkę Skorowidz

A opóļnienia, 85, 402, 553 opóļnienia stosu, 479 ACK, 540–542 skalowalnoħci, 91 adaptacyjne blokady muteksu, 197 stanu wætku, 205, 210 agent, 110 statystyczna, 674 agregacja đæcza, 601 TCP, 556 akcje, 174, 182 testu wydajnoħci, 652, 666 akcje agregujæce, 175 wspóđczynnika, 102 aktywnoħè monitorowa, 109 wywođaē systemowych, 210 algorytm zasobów, 36, 66 M:N szeregowania wætków, 141 analiza wydajnoħci Patrz takľe wydajnoħè Nagle, 542 chmury, 613 szeregowania, 130, 145, 228, 250, 636 dysków, 484–520 zegara dwuwskazówkowego, 326 blktrace, 512 algorytmy kontroli przeciæľenia, 541 DTrace, 495 alokacja iosnoop, 509 pamiúci, 145 iostat, 484 zasobów sieciowych, 558 iotop, 506 alokator, 315, 329, 364 MegaCli, 514 glibc, 332 perf, 505 libc, 331 pidstat, 495 libmtmalloc, 332 sar, 493 libumem, 332 smartctl, 515 pamiúci, 323 SystemTap, 505 slab, 330 wizualizacje, 516 SLUB, 331 pamiúci, 339–360 analiza, 84 narzúdzia, 339–360 awarii, 141 procesora, 264–297 blokad, 221 sieci, 560 cykli, 259, 337 dladm, 570 dræľæca, 84, 220, 557 Dtrace, 578 dysku, 401 ifconfig, 568 hipernadzorcy, 641 iftop, 593 obciæľenia, 36, 66, 67 ip, 569

755

Kup książkę Poleć książkę 756 Skorowidz

analiza wydajnoħci asocjacyjnoħè, 242 sieci audyt Solarisa, 168 kstat, 593 awaria lsof, 593 kaskadowa, 37 netstat, 560 strony, 308, 311 nfsstat, 593 nicstat, 569 B pathchar, 573 perf, 592 Backlog urzædzenia, 597 pfiles, 593 balloon driver, 636 ping, 571 banki pamiúci, 317, 324 routeadm, 593 biblioteka libkstat, 163 sar, 566 bity ToS, 558 snoop, 575 blok ss, 593 danych, 242 strace, 593 funkcjonalny, 79 SystemTap, 592 blokady tcpdump, 573 adaptacyjne muteksu, 197 traceroute, 572 muteksu, 81, 197 truss, 593 odczytu i zapisu, 197 Wireshark, 578 wirujæce, 197 systemów, 49 blokowe operacje wejħcia-wyjħcia, 165 systemu plików, 411, 432 bđúdne wspóđdzielenie, 199 antymetoda, 68 bđúdy, 76, 82, 551 losowej zmiany, 70 bđúdy fizyczne, 688 obwiniania kogoħ innego, 71 BSD, 143 API chmury, 606 btrfs, 398 aplikacje, 189 bufor, 49 analiza wydajnoħci, 204 cykliczny, 195 charakterystyka obciæľenia, 219 Dcache, 389 odpytywanie, 196 DNLC, 388 operacje wejħcia-wyjħcia, 194, 199 goræcy, 65 optymalizacja, 192 i-wúzđów, 390 powiæzanie z procesorem, 200 operacji dyskowych, 452 profilowanie operacji wejħcia-wyjħcia, 218 poziomu drugiego, 372 profilowanie procesora, 208 rozgrzany, 65 sprawdzanie wydajnoħci, 194 stron, 387, 389 stany wætku, 205 strony, 140, 321 architektura, 56 systemu plików, 314, 370, 386, 437 chmury, 607 TCP, 596 Crossbow, 142 TLB, 320 dysku, 458 zimny, 65 NUMA, 253 buforowanie, 63, 134, 373, 537 pamiúci, 315 buforowanie operacji zapisu, 376 pamiúci operacyjnej, 316 procesora, 229, 238 QPI, 244, 245 C RAID, 466 sieci, 539 CAS, Column Address Strobe, 316 oprogramowanie, 545 cele wydajnoħci, 191 protokođy, 539 CFS, 145 sprzút, 543 charakterystyka skalowalna, 607 obciæľenia, 83, 219, 256, 404, 552, 671 SPARC, 328 obciæľenia dysku, 476 sprzútowa, 315 pamiúci podrúcznej, 242 systemu plików, 384 uľycia pamiúci, 335 x86, 328 charakteryzacja obciæľenia, 68 chmura, 41, 92, 605

Kup książkę Poleć książkę Skorowidz 757

ciepđo, 65 publicznej chmury, 606 CMP, Chip-Level Multiprocessing, 228 sched, 720 CPI, Cycles Per Instruction, 233 syscall, 715 cykl sysinfo, 722 diagnostyczny, 74 tcp, 723 procesora, 231 UDP, 724 ľycia pođæczenia, 537 vminfo, 723 ľyciowy procesu, 126 dostawcy cykliczny bufor stron, 322 DTrace, 172, 496 czas sond TCP, 584 dziađania aplikacji, 238 dostrajanie, 650 jædra, 234 BIOS-u, 303 niebezczynnoħci, 62 bufora, 90, 408 obsđugi, 449 klasy szeregowania, 301 oczekiwania, 449 parametrów pamiúci, 361, 362 oczekiwania na obrót, 459 priorytetu, 261 podróľy pakietu, 537 procesora, 298 udzielenia odpowiedzi, 48 systemu plików, 438 usđugi, 97 wydajnoħci, 54, 223, 338, 408 uľytkownika, 234 wydajnoħci dysku, 522 wyszukiwania, 459, 499 wydajnoħci sieci, 557, 595, 601 wywođaē systemowych, 91 DRAM, 316 czerwony wieloryb, 681–699 duplikaty ACK, 541 czústotliwoħè taktowania zegara, 231 dynamiczna zmiana wielkoħci, 609 dynamiczne D monitorowanie, 145 tykniúcia, 121, 145 dane statystyczne, 89, 155, 163, 164 dysk, 42, 445 alokatora bliļniaków, 358 architektura, 458 blokad, 141 kontroler, 448 polecenia kstat, 431 lokalny, 610 polecenia sar, 344, 346, 567 operacje wejħcia-wyjħcia, 510, 619 stref pamiúci, 358 pamiúè podrúczna, 447 definiowanie celów, 191 strefowanie sektorów, 460 degradacja wydajnoħci, 58 szeregowanie operacji, 471 demon wirtualny, 445 kswapd, 325 z kolejkæ, 447 operacji page-out, 357 dziađanie dđugoħè sđowa, 237, 315 jædra, 120 DNLC, Directory Name Lookup Cache, 388 metody USE, 77 dokument dziedziczenie priorytetu, 235 RFC 1122, 600 dziennik pođæczeē, 537 RFC 1761, 575 RFC 2474, 558 E RFC 768, 542 RFC 793, 539 ECC, 461 RFC 896, 542 efekt dokumentacja serwera, 692 latarni ulicznej, 70 dođæczanie procesu, 302 obserwatora, 60 DoS, Denial of Service, 548 eksperyment, 104 dostawca elementy odstajæce, 108 fbt, 720 elementy odstajæce opóļnienia, 446 io, 496, 722 eliminacja niepotrzebnej pracy, 193 ip, 723 ext3, 395, 439 pid, 721 ext4, 395 profile, 718

Kup książkę Poleć książkę 758 Skorowidz

F implementacje wirtualizacji sprzútowej, 626 indeks wúzđa, 370 FACK, 542 informacje o sieci, 593 FFS, Fast File System, 143, 392 infrastruktura jako usđuga, 606 filtrowanie akcji, 514 instrukcje procesora, 228, 232 FLOPS, 664 intensywna wymiana, 322 fragmentacja, 375 interfejs framework /proc, 156–161 blktrace, 144 /sys, 161 DTrace, Patrz narzúdzie DTrace blokowy, 135 inotify, 144 DebugFS, 144 kstat, 162 niestabilny, 164 przezroczyste strony, 145 PAPI, 246 FSB, Front-Side Bus, 243 SAS, 465 FTL, Flash Translation Layer, 463 SCSI, 465 funkcje Serial ATA, 466 jædra systemu Linux, 143 urzædzenia blokowego, 470 systemu plików, 390 znakowy, 135 interfejsy G sieciowe, 531, 543, 598 systemów plików, 371 inľynier wydajnoħci, 35 generator obciæľenia, 91, 520 gniazda, sockets, 134, 596 IOPS, 39, 48, 60, 453 gospodarz, 620 IP QoS, 558 goħè, 606, 622 IPC, Inter-Process Communication, 197 grupa izolacja wydajnoħci, 611 kontrolna, 145 procesorów na wyđæcznoħè, 302 J grupowanie NUMA, 253 jawna antymetoda, 70 procesów, 144 jædra systemów, 118, 119 Linux, 138 H Solaris, 138 jednostka HBA, Host Bus Adapter, 448 czasu, 52 HDD, Hard Disk Drive, 458 funkcjonalna, 232 hierarchia plików, 132 MMU, 243 hipernadzorca, 626, 634 sterujæca, 238 KVM, 638 zarzædzania pamiúciæ, 243 rodzimy, 626 jednowierszowe wywođania DTrace, 279, 280, 356 Xen, 640 júzyk D, 173 HPC, High Performance Computing, 607 júzyki HT, HyperTransport, 244 interpretowane, 202 kompilowane, 201 I programowania, 200 JIT, Just-In-Time, 200 IaaS, Infrastructure as a Service, 606 identyfikacja, 84 K identyfikacja wizualna, 92 identyfikator kanađ urzædzenia, 633 akcji, 513 karta sieciowa, 531 procesu, 125 klasy szeregowania, 140, 249, 299 UUID, 621 CFS, 250 ignorowanie FSS, 252 bđúdów, 655 FX, 252 odchyleē, 656 IA, 252 perturbacji, 656 O(1), 250

Kup książkę Poleć książkę Skorowidz 759

przerwania, 252 M RT, 250, 251 SYS, 251 macierze RAID, 467, 469 SYSDC, 252 magistrala, 243 TS, 252 magistrala QPI, 318 kod ECC, 461 mapowanie koherencja, 93 pamiúci, 631 koherencja pamiúci podrúcznej, 195, 242 plików, 379 kolejka backlog, 588 procesów QEMU, 638 kolejki dziađania, 229, 230 mapy cieplne, 113, 295, 434, 518 kolizje hash, 199 opóļnienia, 518 kolorowanie strony, 324 wartoħci przesuniúcia, 517 kompilator JIT, 200 marketing, 650 komponenty maszyny wirtualne, 203 czasu synchronizacji, 691 mechanizm gniazda, 583 Cpusets, 144 procesora dwurdzeniowego, 239 Futex, 144 komunikacja miúdzyprocesowa, 197 prefetch, 375 koncepcje, 50 slab allocation, 141 konfiguracja systemu goħcia, 634 usuwania nieuľytków, 203 kontekst jædra, 127 mediana, 106 kontrola menedľer woluminów, 370 przeciæľenia w TCP, 597 metadane zasobów, 142, 262, 303, 339, 523, 558 fizyczne, 380 zasobów sieci, 598, 601 logiczne, 380 kontroler metoda dysku, 448, 462, 474, 483, 514 listy rzeczy do sprawdzenia, 71 w napúdzie SSD, 463 narzúdzi, 75, 254, 333, 473, 550 kopiowanie przy zapisie, 126, 391 naukowa, 73 koszt transakcji, 403 USE, 76, 219, 255, 334, 474, 551, 671, 688 ksiúgowanie, 391 dla systemu Linux, 701 KVM, Kernel-based Virtual Machine, 145, 638 dla systemu Solaris, 707 metodologia, 47 metryki L USE, 78, 80 wydajnoħci, 59 LFU, Least Frequently Used, 65 mikrotesty wydajnoħci, 91, 262, 409, 660 liczba dysków, 481, 521 centrów danych, 97 pamiúci, 339 operacji w ciægu sekundy, 60 sieci, 559 operacji wejħcia-wyjħcia, 60 systemu plików, 661 licznik, 150 MIPS, 664 operacji, 414 MLC, Multi Level Cell, 463 wydajnoħci, 247 MMU, Memory Management Unit, 144, 243, 319 wydajnoħci procesora, 166, 245 model limity zasobów procesora, 616 M/D/1, 98 Linux, 138 systemu kolejkowego, 97 lista modele skalowalnoħci, 96 wolnych stron pamiúci, 323 modelowanie, 91 zasobów, 78 modyfikowalne parametry listy demona kswapd, 326 kontrolera dysku, 525 losowe operacje odczytu, 521 sieci, 595 LPE, Linux Performance Events, 185 systemu operacyjnego, 523 LRU, Least Recently Used, 65 urzædzenia dyskowego, 525 LVM, Logical Volume Manager, 399 monitorowanie, 84, 108, 137, 149, 154 alokacji, 353 awarii stron, 356 buforowane, 215

Kup książkę Poleć książkę 760 Skorowidz

monitorowanie akcje, 173 dynamiczne, 40, 170, 504 analiza sieci, 578 funkcji, 281 analiza systemu plików, 414 jædra, 167 argumenty, 172 na poziomie procesu, 153 dokumentacja, 179 na poziomie systemu, 152 dostawcy, 172, 496 nowych procesów, 733 dostawcy sond TCP, 584 operacji dyskowych, 510 funkcje, 727 oprogramowania, 289 funkcjonalnoħè, 725 poszczególnych procesów, 167 jednowierszowe wywođania, 177 punktu kontrolnego, 211 monitorowanie alokacji, 353 retransmisji, 586 monitorowanie awarii stron, 356 statyczne, 170 monitorowanie dynamiczne, 170 stosów jædra, 733 monitorowanie statyczne, 170 systemu, 42 monitorowanie zdarzeē, 497 systemu plików, 423 obciæľenie, 178 szeregowania, 283 pođæczenia gniazd, 579 wolnego zdarzenia, 422 skrypty, 177 wydajnoħci, 185, 260, 406 sondy, 171, 726 wydajnoħci dysku, 475 typy zmiennych, 173, 175 wydajnoħci sieci, 554 wbudowane zmienne, 173, 727 wywođania, 732 zasoby, 179 zdarzeē, 87, 407, 479, 497 dtruss, 152 czas, 88 execsnoop, 152 dane wejħciowe, 88 fcachestat, 430 wynik, 88 FileBench, 437 montowanie, 132 fio, 436 MPO, 141 fmadm faulty, 293 MPSS, 141 free, 358 MRU, Most Recently Used, 65 gdb, 153 multitenancy, 606, 610 getdelays.c, 293 muteks, 198 htop, 293 mysqld, 279 ifconfig, 551 iftop, 593 N Intel VTune Amplifier XE, 154 iosnoop, 152 nadmierne zuľycie pamiúci, 338 iostat, 151, 358 nagđówek IP, 558 kstat, 164, 359, 593 napúd latencytop, 145 HDD, 458 LatencyTOP, 425 SSD, 459, 462 lgrpinfo, 294 narzúdzia lockstat, 293 analizy wydajnoħci dyskowych, 484–520 lsof, 593 mikrotestów wydajnoħci, 435 mdb, 153 monitorowania, 149, 166 MegaCli, 514 profilowania, 153 mpstat, 151 wizualizacji, 115 netstat, 151, 550 narzúdzie, Patrz takľe polecenie nfsstat, 593 AcmeMon, 43 oprofile, 144, 154, 293 atop, 293 Oracle Solaris Studio, 154 blktrace, 152 perf, 145, 152, 358, 505 Bonnie, 435 pfiles, 593 cachegrind, 154 pgstat, 293 cpustat, 359 pmap, 152 dmesg, 358 prtconf, 358 dtrace, 152 prtdiag, 358 DTrace, 40, 142, 168, 277, 578, 715–724 ps, 151 psrinfo, 293

Kup książkę Poleć książkę Skorowidz 761

routeadm, 593 ochotnicze wywđaszczenie jædra, 144 sar, 151 odchylenie standardowe, 106 smartctl, 515 odczyt snoop, 152 systemu plików, 91 ss, 593 z wyprzedzeniem, 376 strace, 153, 593 odrzucenia pakietów, 588 swap, 358 odwrócenie priorytetów, 235 swapon, 358 odzyskanie pamiúci, 165 sysbench, 298 ograniczenia systemtap, 152 chmury, 623 SystemTap, 154, 180, 725 przepustowoħci sieciowej, 558 tcpdump, 152 zasobu, 100 top, 152 ogromne strony, 144 trapstat, 359 OOM, Out Of Memory, 308 truss, 153, 593 opcje valgrind, 293, 358 iotop, 507–509 vmstat, 151 netstat, 560–566 Wireshark, 578 sar, 494 SystemTap, 284, 357 algorytmu szeregowania, 300 akcje, 182 gniazda, 601 dokumentacja, 185 iostat, 485–493 funkcje, 727 kompilatora, 299 funkcjonalnoħè, 725 procesora, 303 obciæľenie, 184 TCP, 597, 600 sondy, 181, 726 operacje wbudowane zmienne, 182, 727 asynchroniczne, 457 zasoby, 185 nieblokujæce wejħcia-wyjħcia, 199 zestawy tapset, 181 synchroniczne, 457 NAS, Network-Attached Storage, 469 systemu plików, 370 nasycenie, 49, 62, 76, 82, 314, 551 wejħcia-wyjħcia, 194, 218, 370, 446 negocjacja, 540 aplikacji, 458 negocjacja interfejsu, 538 bezpoħrednie, 378 NFU, Not Frequently Used, 65 czas wyszukiwania, 499 NIC, Network Interface Card, 531 dyskowe, 458 nietrafienie bufora, 372, 421 fizyczne, 370, 380 nieznane niewiadome, 59 gniazda, 582 NIS, 140 logiczne, 370, 380 notacja losowe, 374, 452 duľe O, 193 nieblokujæce, 378 Kendalla, 98 niezmodyfikowane, 378 NUMA, 200, 243, 253 niezwiæzane, 380 opóļnienia, 500 O poħrednie, 381 sekwencyjne, 374, 452 obciæľenie, 56–60, 121, 178, 184, 613 systemu plików, 618 robocze, 49 zmniejszone, 381 systemu plików, 433 zwiúkszone, 382 obliczanie opis problemu, 72 czasu, 450 opóļnienie, 39, 48, 60, 191, 240, 316, 530 wejħcia-wyjħcia, 145 algorytmu szeregowania, 234, 287 z opóļnieniem, 145 CAS, 316 obserwacja, 104 DNS, 51 obsđuga dyskowe, 449 64 bitów, 141 gniazda, 583 liczników, 121 odczytu, 691 ľædania, 124 pamiúci podrúcznej, 240 ocena wydajnoħci, 104 pierwszego bajta, 536 ping, 535

Kup książkę Poleć książkę 762 Skorowidz

opóļnienie pliki pođæczenia, 536 binarne, 160 pođæczenia TCP, 51 mapowane w pamiúci, 140 przerwania, 124 PMU, Performance Monitoring Unit, 245 sieci, 553 podsđuchiwanie pakietów, 167, 555 systemu plików, 373, 434 podsumowanie, 110 szeregowania, 165 podsumowanie opóļnienia, 732 VFS, 417 pojemnoħè wejħcia-wyjħcia, 446, 500 deskryptorów plików, 81 wywođania systemowego, 416 pamiúci, 617, 636 zwiæzane z tykniúciem, 120 proces/wætek, 81 opóļnione ACK, 542 systemu plików, 618, 636 oprogramowanie, 101 polecenia dyskowe, 446 optymalizacja kodu wynikowego, 201, 238 polecenie, Patrz takľe narzúdzie organizacja SPEC, 665 ::kmastat, 347, 429 otwarcie pliku, 415 blktrace, 512 cpustat, 292 P dd, 520 dladm, 570 pakiet, 530, 533, 534 dmesg, 334 ACK, 540 DTrace, Patrz narzúdzie DTrace FACK, 542 dyskowe, 454 SACK, 542 e2fsck, 440 SYN, 536 fcachestat, 429 pakiety sieciowe, 573 fmdump, 688 pamiúè free, 426 anonimowa, 308 fsstat, 413 flash, 463 ifconfig, 568 masowa, 610 ionice, 523 operacyjna, 308, 316, 617 iosnoop, 509 architektura, 316 iostat, 484, 690 nasycenie, 314 iotop, 506, 508 poziom wykorzystania, 314 ip, 569 przepeđnienie, 313 ipadm, 598 podrúczna, 195, 230 iperf, 594 buforowa, 136, 389 kstat, 431 dysku, 447, 461 kvmstat, 639 procesora, 239, 243, 319 mpstat, 268, 623 rezydentna, 308 ndd, 598 wirtualna, 129, 308, 618 netstat, 560, 685 parametry modyfikowalne systemu, 523 nicstat, 569 parawirtualizacja, 625, 628 pagesize, 362 partycjonowanie, 103 pathchar, 573 PCI pass-through, 632 perf, 284, 505, 592 PCL, Performance Counters for Linux, 284 pidstat, 275, 495 peđna wirtualizacja, 625 ping, 536, 571 percentyl, 106 pmap, 351 perf, 185 prstat, 273, 350, 620 perspektywy, 36 PIC, Performance Instrumentation Counters, ps, 271, 348 245, 292 ptime, 276 ping, 535 sar, 270, 343, 427, 566, 713 plan 9, 143 slabtop, 345, 428 planowanie pojemnoħci, 36, 67, 100, 608, 650 snoop, 575 plik stat, 288 debuginfo, 286 strace, 211, 413 meminfo, 430 tcpdump, 573 wymiany, 313 time, 276 top, 272, 350, 426

Kup książkę Poleć książkę Skorowidz 763

traceroute, 572, 682 pamiúci podrúczne, 230, 239, 243 truss, 213, 413 potok instrukcji, 232 uptime, 265 poziom nasycenia, 234 vfsstat, 412, 668 poziom wykorzystania, 233 vmstat, 267, 333, 340, 426, 688 sprzút, 238 xentop, 640 taktowanie zegara, 231 polityka wartoħè CPI, 233 Anticipatory, 472 Wartoħè CPI, 233 CFQ, 472 wielkoħè instrukcji, 233 Deadline, 471 zasoby, 253 Noop, 471 procesory polityki algorytmu szeregowania Intel, 241 BATCH, 251 logiczne, 228, 229 FIFO, 251 wirtualne, 228, 634 NORMAL, 251 profiler systemowy, 144 RR, 251 profilowanie, 63, 153, 257 pođæczenia CR3, 642 gniazd, 579 jædra, 278 lokalne, 539 operacji wejħcia-wyjħcia, 218 pomoc techniczna, 683 procesora, 208, 669 porównanie technologii wirtualizacji, 644 procesu, 286 port interfejsu, 530 systemu, 285 POSIX, 132 uľytkownika, 279 potok instrukcji, 232 program AcmeMon, 42 powiæzanie z procesorem, 262 programowanie, 650 poziom projekt systemu, 650 priorytetu przerwania, 124 protokođy sieciowe, 533 uľycia dysku wirtualnego, 455 protokóđ wykorzystania, 48, 60, 76, 82, 551 NIS, 140 interfejsu sieciowego, 538 NFS, 140 na podstawie czasu, 61 TCP, 539, 548 na podstawie pojemnoħci, 61 UDP, 542 procesora, 233 przechwytywanie pakietów, 167, 555 poziomy trafnoħci, 55 przeđæczanie kontekstu, 118 prawo skalowalnoħci przeđæcznik, 544 Amdahla, 94 przepeđnienie, 313 uniwersalnej, 95 przepustowoħè, 48, 58, 191, 370, 446, 530 priorytet architektury procesora, 245 procesu, 131 interfejsu sieciowego, 91, 552 przerwania, 124 przerwania, 118, 123, 283 szeregowania, 299 przestrzeē wætku, 250 adresowa, 308 problem obciæľenia bufora, 537 adresowa procesu, 328 procedura obsđugi ľædania, 124 jædra, 118 proces, 118, 125 uľytkownika, 118 mysqld, 279 wymiany, 308, 313 nadchodzæcy, 97 przetwarzanie w chmurze, 41, 82, 605 procesor, 118, 227, 628 multitenancy, 610 algorytm szeregowania, 246, 250 pamiúè masowa, 610 analiza wydajnoħci, 264–297 planowanie pojemnoħci, 608 architektura, 238 skalowalna architektura, 607 architektura superskalarna, 232 skalowalnoħè pozioma, 607 asocjacyjnoħè, 242 wirtualizacja systemu operacyjnego, 611 dostrajanie, 298 wspóđczynnik cena/wydajnoħè, 606 instrukcje, 232 przyħpieszenie, 39 kolejki dziađania, 230 pula pamiúci masowej, 400 liczniki wydajnoħci, 245 pule wætków, 81 metodologie wydajnoħci, 254–264 puđap skalowalnoħci, 94

Kup książkę Poleć książkę 764 Skorowidz

puđapka, 118 scrubbing, 392 punkt SCSI, 465 montowania, 132 segment, 308 nasycenia, 57 sektor, 446 zađamania, 92, 94 selektywne potwierdzanie, 540 punkty instrumentacji, 145 separacja obciæľenia, 409 serwer Redis, 692 Q sieci kolejkowe, 96 sieciowe operacje wejħcia-wyjħcia, 619 QPI, Quick Path Interconnect, 244 sieè, 134, 529 skala czasu, 52, 451 skalowanie, 57, 236, 263 R liniowe, 93 oprogramowania, 236 RAID, 466 pionowe, 103, 607 ramka, 530, 543 poziome, 103, 607 ramka jumbo, 534, 601 rozwiæzaē, 103 RCU, 144 skanowanie, 326 rdzeē, 228 pamiúci, 333 rejestr MSR, 246 stron, 325, 327 rejestrowanie, 152 skrypty rekomendacje, 56 do monitorowania, 504 RFS, Receive Flow Steering, 546 sieci, 590 rodzaje systemu plików, 423 dysków, 458 powđoki, 202 đæczeē operacji wejħcia-wyjħcia, 471 sloth disks, 462 macierzy RAID, 467 Solaris, 138 narzúdzi, 150 sonda, 169, 181, 283 opóļnieē sieciowych, 554 dynamiczna, 170 pamiúci masowej, 466 statyczna, 40, 145, 170 systemów plików, 392 sondy DTrace, 171 testów wydajnoħci, 660 SONET, 538 wirtualizacji sprzútowej, 625, 628 SPARC, 328 ROI, Return on Investment, 55 specjalne role, 34 systemy plików, 383 rotacja, 459 testy wydajnoħci, 659 router, 544 routing, 532 specyfika dostrajania, 360 rozkđad sprawdzanie normalny, 106 jædra, 694 opóļnienia, 107 wydajnoħci aplikacji, 194 wielomodalny, 107 poprawnoħci testu, 674 rozwiæzywanie problemów, 650 sprzút, 100 równolegđoħè, 196 SR-IOV, 632 równowaľenie obciæľenia, 248 SSD, Solid State Drive, 445, 459, 462 RPC, 140 standard DDR SDRAM, 318 RPS, Receive Packet Steering, 546 standardy biznesowe, 663 RSS, Receive Side Scaling, 546 stany wætku, 205 RSS, Resident Set Size, 313 statyczne dostosowanie wydajnoħci, 89, 223, 260, 480 RX, 551 statystyka, 103 rywalizacja, 93 sterowniki urzædzeē, 135 sterowniki urzædzeē sieciowych, 549 S sterta, 329 stopa zwrotu inwestycji, 55 stopniowa zmiana obciæľenia, 672 SACK, 540, 542 stos, 122, 585 SAR, System Activity Reporter, 154 jædra, 123 SAS, Serial Attached SCSI, 465 operacji dyskowych, 469 SATA, 466 operacji wejħcia-wyjħcia, 133, 384, 419, 501

Kup książkę Poleć książkę Skorowidz 765

oprogramowania systemu, 34 szeregowanie, 249 protokođów, 532 BVT, 634 sieciowy, 545, 547 hipernadzorcy, 626 sieciowy STREAMS, 141 Oparte na uznaniu, 635 TCP/IP, 134 SEDF, 634 uľytkownika, 123 w czasie rzeczywistym, 132 strategia Overcommit, 144 wejħcia-wyjħcia, 144 strefy, 142 szerokoħè bitu, 237 strona, 308, 320 szybkoħè szyny pamiúci, 318 stronicowana pamiúè wirtualna, 143 szyna, 317, 243 stronicowanie, 308, 322, 333 anonimowe, 311 Ś systemu plików, 310 strony pamiúci, 363 ħcieľka struktura danych i-wúzđa, 393 danych, 633 studium przypadku, 681–699 operacji wejħcia-wyjħcia, 633 SVM, Solaris Volume Manager, 399 ħrednia symulacja obciæľenia geometryczna, 105 bezstanowa, 662 harmoniczna, 105 stanowa, 662 waľona, 106 SYN, 536 ħrednie obciæľenie, 265 synchroniczne operacje zapisu, 377 ħrodowisko, 119 synchronizacja poczætkowa, 197 ħrodowisko procesu, 127 syscall, 118 system gospodarza, 620 T goħcia, 622 system operacyjny, 20, 117 tabele hash, 198 Linux, 138, 143 tablica asocjacyjna, 175, 501 SmartOS, 335 talerz magnetyczny, 453, 458 Solaris, 138 TCP, Transmission Control Protocol, 539 TENEX, 265 TCP Backlog, 597, 600 UNIX, 139, 143 technika short stroking, 460 wirtualizacja, 611 technologia system plików, 132, 369 KVM, 145 /tmp, 409 wirtualizacji sprzútowej, 625 analiza dysku, 401 wirtualizacji systemu operacyjnego, 612 analiza opóļnienia, 402 tenant, 606 analiza wydajnoħci, 411 TENEX, 265, 266 architektura, 384 teoretyczna przepustowoħè maksymalna, 460 btrfs, 398 teoria kolejek, 96 bufory, 386 testowanie wydajnoħci dysku, 520 charakterystyka obciæľenia, 404 testy nieregresywne, 44 dostosowanie wydajnoħci, 408 testy wydajnoħci, 298, 649 dostrajanie bufora, 408 aktywne, 667 ext3, 395, 439 analiza, 652 ext4, 395 analiza statystyczna, 674 FFS, 143, 392 charakterystyka obciæľenia, 671 funkcje, 390 efektywnoħè, 651 mikrotesty wydajnoħci, 409, 435 metoda USE, 671 monitorowanie wydajnoħci, 406 mikrotesty, 660 monitorowanie zdarzeē, 407 organizacja SPEC, 665 opróľnienie bufora, 437 pasywne, 665 separacja obciæľenia, 409 pomijanie istotnych informacji, 658 UFS, 394 powtarzalnoħè, 663 VFS, 133, 140, 143 produktu konkurencji, 657 ZFS, 142, 322, 396, 433, 440 profilowanie procesora, 669 systemy kolejkowe, 50, 96 przypadkowoħè, 653

Kup książkę Poleć książkę 766 Skorowidz testy wydajnoħci W skomplikowane narzúdzia, 655 specjalne, 659 wariancja, 106 sprawdzenie poprawnoħci, 674 wartoħci statystyczne, 106 standardy biznesowe, 663 wartoħè stopniowa zmiana obciæľenia, 672 IOPS, 454, 552 TPC, 664 ħrednia, 105 wđasne, 671 wæskie gardđo, 49 TLC, Tri Level Cell, 463 wætek, 118, 205, 235 ToS, Type of Service, 558 bezczynny, 253 TPC, 664 sprzútowy, 228 transfer, 446, 530 wætki przerwaē, 123 translacja wúzeđ obliczeniowy, 621 binarna, 625 wúzđy pamiúci, 317 danych wejħciowych, 463 wibracje, 461 transmisja pakietu, 585 wielkoħè transport, 446 bufora sieciowego, 54 tryb operacji wejħcia-wyjħcia, 454, 498 jædra, 121 pakietu, 534 uľytkownika, 118 pamiúci rezydentnej, 313 wyđæczonych przerwaē, 124 pamiúci wirtualnej, 313 tryby wykonywania wywođaē systemowych, 121 rekordu, 54 trzyetapowy proces negocjacji, 540 sektora, 460 TTFB, 536 strony, 363 tworzenie wielokanađowoħè, 318 procesu, 125 wieloprocesorowe systemy komputerowe, 141 skryptów DTrace, 217 wieloprocesorowoħè, 136 TX, 551 wieloprocesorowoħè symetryczna, 136 typ maszyny wirtualnej, 626 wieloprocesowoħè, 196, 236, 237 typy migracji, 324 wielowætkowoħè, 196, 236, 237 wielozadaniowoħè, 248 U wirtualizacja hybrydowa, 625 UDP, User Datagram Protocol, 542 sprzútowa, 605, 625, 645 UFS, 394 kontrola zasobów, 634 UMASK, 246 KVM, 627 UNIX, 139, 143 mapowanie pamiúci, 631 urzædzenia monitorowanie, 637 dyskowe, 466, 474 obciæľenie, 627 NAS, 469 obciæľenie procesora, 629 SCSI, 486 operacje wejħcia-wyjħcia, 632, 636 sieciowe, 600 parawirtualizacja, 628 USE, Utilization, Saturation and Errors, 76 pojemnoħè pami6úci, 63 USL, Universal Scalability Law, 95 pojemnoħè systemu plików, 636 usprawnienia stosu TCP/IP, 142 translacja binarna, 628 usuwanie nieuľytków, 203 VMware ESX, 626 uľywanie stref, 620 wielkoħè pamiúci, 632 Xen, 627 systemu operacyjnego, 605, 611, 645 V kontrola zasobów, 615, 624 monitorowanie, 619 VFS, Virtual File System, 133, 370, 384 obciæľenie, 613 VMCS, 642 wspomagana sprzútowo, 628 wirtualny system plików, 133, 140, 370 wizualizacja, 111, 294 wizualizacja rejestrów procesora, 643 wolumin, 399

Kup książkę Poleć książkę Skorowidz 767

woluminy dysków wirtualnych, 636 monitorowanie, 554 wspóđbieľnoħè, 196 opóļnienie, 535 wspóđbieľnoħè oparta na zdarzeniach, 196 systemu, 33, 49, 157, 681–699 wspóđczynnik systemu goħcia, 638 nietrafnoħci, 64 TCP, 540 odczyt/zapis, 453 wykorzystanie zasobów, 191 pođæczeē TCP, 552 wykres trafnoħci, 64 bloku funkcjonalnego, 79 zmiennoħci, 107 liniowy, 111, 516 wspóđdzielenie procesora, 617 punktowy, 112, 517 wspóđdzielona szyna systemowa, 244, 317 typu flame, 296 wyciek pamiúci, 337 warstwowy, 114 wydajnoħè, 37, 54, 159, Patrz takľe analiza wykrywanie duplikatów ACK, 541 wydajnoħci wymiana, 165, 308, 313, 322 algorytmów, 193 wyraľanie metryk, 78 baz danych, 664 wyszukiwanie, 459 bimodalna, 107 wyszukiwanie cylindryczne, 461 chmury, 613 wyħwietlanie sond, 728 dynamiczna, 89 wywđaszczenie, 136, 235, 248 dysków, 449, 484–520 wywođania analiza opóļnienia, 478 DTrace, 177 buforowanie, 452 miúdzy procesorami, 136, 282 charakterystyka obciæľenia, 476 systemowe, 118, 127, 167, 210, 693 dopasowanie statyczne, 480 epoll(), 144 dostrajanie, 522 madvise(), 439 dostrojenie, 483 poll(), 196 dostrojenie bufora, 481 posix_fadvise(), 439 kontrola zasobów, 481 splice(), 144 koēczenie operacji, 456 wzorce na podstawie czasu, 109 metoda narzúdzi, 473 metoda USE, 474 X mikrotesty wydajnoħci, 481 monitorowanie, 475 x86, 328 narzúdzia mikrotestów, 521 Xen, 634, 640 nasycenie, 456 XPS, Transmit Packet Steering, 547 polecenie dyskowe, 454 pomiar czasu, 449 poziom wykorzystania, 455 Z skale czasu, 450 skalowanie, 483 zadanie, 118 pamiúci, 332–39 zadanie bezczynnoħci, 251 analiza cykli, 337 zakres charakterystyka, 336 pamiúci, 324 kontrola zasobów, 339 procesu, 151 metoda narzúdzi, 333 systemu, 151 metoda USE, 334 zapobieganie przeciæľaniu TCP, 144 mikrotesty, 339 zarzædzanie monitorowanie, 337 pamiúciæ, 243, 321 statyczne dostrojenie, 338 stronicowanie, 130 wykrywanie wycieków, 337 wymiana, 130 procesora, 254–264 stronami, 324 sieci, 535 zasobami, 137 dostosowanie statyczne, 557 zasoby, 76 dostrajanie, 595 kontrolne, 137 kontrola zasobów, 558 oprogramowania, 81 metoda narzúdzi, 550 procesora, 253 metoda USE, 551 zbieranie, 321, 325 mikrotesty, 559 zdalne wywođywanie procedur, 140

Kup książkę Poleć książkę 768 Skorowidz

zdarzenia znaczniki kontrolera, 514 czasu, 383, 511 SCSI, 503 jædra, 145 TCP, 584 znane zegar, 120 niewiadome, 59 dwuwskazówkowy, 327 wiadome, 59 pamiúci, 318 zwalnianie pamiúci, 321 procesora, 318 zestawy tapset, 181 Ź ZFS, 396, 440, 442 zliczanie ļródđa danych statystycznych, 155 mikrostanu, 166 operacji wejħcia-wyjħcia, 168 opóļnienia, 165, 207 Ż procesów, 167 przepđywu, 168 ľædanie stronicowania, 311 rozszerzone, 168 wywođaē systemowych, 730, 731 zmiana oprogramowania, 44

Kup książkę Poleć książkę