Embedded Systems Architecture System Performance Embedded Systems Architecture 1
Wydajność systemu Wydajność to ekscytująca, zmienna i wymagająca dyscyplina. Brendan GREG Wydajność systemu analiza całego systemu łącznie ze wszystkimi komponentami sprzętowymi oraz pełnym stosem oprogramowania. Wszystko co znajduje się na ścieżce danych oprogramowanie i sprzęt, ma wpływ na wydajność. W systemach rozproszonych to oznacza to wiele serwerów i aplikacji. Embedded Systems Architecture 2
Wydajność systemu Wydajność oznacza podejmowanie działań w następującej wydajności: Zdefiniowanie celów związanych z wydajnością oraz modelowaniem wydajności. Przygotowanie charakterystyki wydajności prototypu oprogramowania i sprzętu. Przeprowadzenie analizy kodu źródłowego wstępna integracja. Przeprowadzenie testów nieregresywnych kompilowanego oprogramowania, wydania typu pre- i post-. Wykonanie testów wydajności danej wersji oprogramowania. Testowanie dowodu koncepcji ang. proof-of-concept przed jego wdrożeniem w środowisku docelowym. Optymalizacja konfiguracji przed jego wdrożeniem w środowisku produkcyjnym. Monitorowanie oprogramowania działającego w środowisku produkcyjnym. Analiza zgłoszonych problemów dotyczących wydajności. Embedded Systems Architecture 3
Wydajność systemu Pierwsze pięć kroków stanowią część tradycyjnego modelu tworzenia oprogramowania. Przygotowany produkt trafia na rynek, a kolejnym krokiem jest przeprowadzenie testów dowodu koncepcji w środowisku klienta lub wdrożenie i konfiguracja. Jeżeli w środowisku klienta zostaną odkryte problemy w ostatnich trzech krokach oznacza to, że nie zostały zauważone lub usunięte w trakcie prac nad danym produktem. Idealnym rozwiązaniem jest sytuacja, w której inżynier wydajności rozpocznie pracę za min nastąpi wybór sprzętu i oprogramowania. Na każdym kolejnym etapie procesu usunięcie problemów może okazać się coraz trudniejsze. Embedded Systems Architecture 4
Wydajność systemu PERSPEKTYWY Działania związane z wydajnością systemu można postrzegać z różnych perspektyw: analiza obciążenia; analiza zasobów. Dotyczą one spojrzenia na stos oprogramowania z różnych kierunków. Perspektywa analizy zasobów jest często stosowana przez administratorów systemu odpowiedzialnych za jego zasoby. Programiści aplikacji, którzy są odpowiedzialni za wydajność podczas obciążenia, najczęściej koncentrują się na perspektywie analizy obciążenia. Każda perspektywa ma wady i zalety. W wielu sytuacjach konieczne jest z spojrzenie punktu widzenia obu perspektyw. Embedded Systems Architecture 5
Wydajność systemu PERSPEKTYWY Wydajność jest subiektywna. To co jeden z użytkowników uznaje za niewystarczającą wydajność, czyli problem, inny użytkownik może uznać za dobrą wydajność. Embedded Systems Architecture 6
Wydajność systemu METOLOGIA Metodologie analizy wydajności: obserwacyjne; eksperymentalne. Modelowanie i planowanie pojemności. Embedded Systems Architecture 7
Wydajność systemu METRYKI Najczęściej stosowane rodzaje metryk wydajności systemu obejmują: IOPS liczba operacji wejścia-wyjścia wykonywanych w ciągu sekundy; przepustowość liczba operacji lub ich wielkość w ciągu sekundy; poziom wykorzystania stopień zajętości zasobu obliczany na podstawie ilości czasu, który we wskazanym przedziale czasu był poświęcony na aktywne wykonywanie zadania; dla zasobów dostarczających pamięci masowych może to oznaczać zużytą pamięć np. wykorzystana ilość pamięci operacyjnej; opóźnienie czas, w którym operacja czeka na przeprowadzenie; czasem pojęcie to może odnosić się do całkowitego czasu operacji, jest odpowiednikiem czasu udzielenia odpowiedzi. Embedded Systems Architecture 8
Wydajność systemu METRYKI Wszelkie perturbacje mogą wpływać na wyniki testu. Dotyczy to perturbacji powodowanych przez: zaplanowane działania systemu; działania pozostałych użytkowników systemu; inne obciążenia. Źródło zakłóceń nie musi być oczywiste do jego ustalenia może być konieczne przeprowadzenie drążącej analizy wydajności. Co może być szczególnie trudne w pewnych środowiskach przetwarzania w chmurze (wpływ innych tenantów). Perturbacje Dane wejściowe Obciążenie Wydajność systemu podczas testu Wydajność końcowa Embedded Systems Architecture 9
Wydajność systemu Kompromisy Wydajność systemu świadomość istnienia pewnych kompromisów. Kompromis typu wybierz dwa z dobrze, szybko, tanio z użyciem terminologii z projektów informatycznych; Dobrze Wydajność Szybko Tanio Na czas Niedrogo Embedded Systems Architecture 10
Wydajność systemu Kompromis W wielu projektach stawia się na elementy na czas i niedrogo, wydajność pozostawia do poprawienia w późniejszych fazach. Problemem mogą być wcześniej podjęte decyzje uniemożliwiające poprawę wydajności. Do wspomnianych decyzji dla przykładu zalicza się: wybór nieoptymalnej architektury pamięci masowej; wykorzystanie języka programowania lub systemu operacyjnego który nie udostępnia zaawansowanych narzędzi przydatnych w analizie wydajności. Stopa zwrotu inwestycji ROI Return of Investment; Embedded Systems Architecture 11
Wydajność systemu Kompromis Skalowalność liniowa. Osiągnięcie i przekroczenie punktu na kolanach, rywalizacja o zasoby systemu powoduje negatywny wpływ na wydajność systemu. W ogólności liczba wykonywanych zadań spada. Punkt nasycenia. Embedded Systems Architecture 12
Wydajność systemu Niewiadome Na polu wydajności systemów musimy rozpatrywać różnego rodzaju niewiadome: Znane wiadome rzeczy, o których wiemy, mamy świadomość że trzeba sprawdzić metryki wydajności i znamy ich wartości bieżące. (Wykorzystanie procesora 10%); Znane niewiadome rzeczy, o których wiemy że ich nie znamy, mamy świadomość konieczności sprawdzenia metryki lub istnienia podsystemu, ale jeszcze go nie zaobserwowałeś.(co wykorzystuje moc procesora?); Nieznane niewiadome rzeczy, o których nie wiemy, że powinniśmy je znać.(wpływ przerwań na wykorzystanie mocy procesora). Embedded Systems Architecture 13
Wydajność systemu Analiza zasobów Podejmowane działania: Wyszukiwanie problemów związanych z wydajnością sprawdzenie, czy określony typ zasobu odpowiada za dany problem; Planowanie pojemności zbieranie informacji pomagających w ustaleniu wielkości nowych systemów oraz określenie kiedy zasoby istniejących systemów mogą zostać wyczerpane. Embedded Systems Architecture 14
Wydajność systemu Analiza obciążenia Pozwala sprawdzić wydajność aplikacji dla stosowanego obciążenia oraz sposobów reakcji aplikacji na dane obciążenie. Badane obszary podczas analizy obciążenia: żądania aktualne obciążenie; opóźnienie czas udzielenia odpowiedzi przez aplikację; zakończenie pracy sprawdzenie czy wystąpiły jakiekolwiek błędy; Embedded Systems Architecture 15
Jawna antymetoda analiza oparta na obserwacji; Antymetoda losowej zmiany analiza oparta na eksperymentach; Antymetoda obwiniania kogoś innego analiza oparta na hipotezach; Metoda listy przygotowanej ad hoc analiza oparta na obserwacji i eksperymentach; Opis problemu zbieranie informacji; Metoda naukowa analiza oparta na obserwacji; Cykl diagnostyczny analiza cyklu życiowego; Metoda narzędzi analiza oparta na obserwacji; Metoda USE (ang. Utilization, Saturation and Errors) analiza oparta na obserwacji; Charakterystyka obciążenia analiza oparta na obserwacji, planowanie pojemności; Analiza drążąca analiza oparta na obserwacji; Analiza opóźnienia analiza oparta na obserwacji; Metoda R analiza oparta na obserwacji; Embedded Systems Architecture 16
Monitorowanie zdarzeń analiza oparta na obserwacji; Dane statystyczne będące punktem odniesienia analiza oparta na obserwacji; Monitorowanie wydajności analiza oparta na obserwacji, planowanie pojemności; Teoria kolejek analiza statyczna, planowanie pojemności; Statyczne dostosowywanie pojemności - analiza oparta na obserwacji, planowanie pojemności; Dostosowanie bufora analiza oparta na obserwacji, dostrajanie; Mikro testy wydajności analiza oparta na eksperymentach; Planowanie pojemności planowanie pojemności, dostrajanie; Embedded Systems Architecture 17
Jawna antymetoda: Brak wyboru przemyślanej metodologii; Analiza wydajności odbywa się przy pomocy wybranych narzędzi monitorowania, które są nam znane lub wybiera przypadkowo; Podejście albo się uda, albo nie ; Zazwyczaj prowadzi do przeoczenia wielu typów problemów; Dostosowywanie wydajności na zasadzie prób i błędów; Wada tej metodologii odkrycie może być problemem ale nie tym, którego szukamy. Embedded Systems Architecture 18
Antymetoda losowej zmiany: Antymetoda oparta na eksperymentach; Podejmowane działania: 1. Losowy wybór elementu, który zostanie zmodyfikowany. 2. Modyfikacja wybranego elementu w jednym kierunku. 3. Pomiar wydajności. 4. Modyfikacja wybranego elementu w przeciwnym kierunku. 5. Pomiar wydajności. 6. Sprawdzenie czy wynik otrzymany w krokach 3. lub 5 jest lepszy niż wynik początkowy. Jeśli tak pozostawiamy zmiany i wracamy do pkt.1. Metodologia bardzo czasochłonna. Embedded Systems Architecture 19
Antymetoda obwiniania kogoś innego: Podejmowane działania: 1. Wyszukanie systemu lub komponentu środowiska, za który nie odpowiadamy. 2. Postawienie hipotezy, że wybrany w pkt.1 system lub komponent jest źródłem problemu. 3. Przekazanie informacji o problemie zespołowi odpowiedzialnemu za wybrany w pkt.1 komponent lub system. 4. Jeżeli hipoteza okaże się nieprawdziwa powrót do punktu 1. Metodologia zrzucanie winy na innych. Marnowanie zasobów ludzkich w innych zespołach szukających problemu, który ich nie dotyczy. Embedded Systems Architecture 20
Opis problemu: Podejmowane działania odpowiedź na poniższe pytania: 1. Dlaczego sądzisz, że występuje problem związany z wydajnością? 2. Czy używany system kiedykolwiek oferował doskonałą wydajność? 3. Jakie zmiany zostały ostatnio wprowadzone? Oprogramowanie? Sprzęt? Czy zmieniło się obciążenie? 4. Czy problem dotyczy także innych użytkowników lub aplikacji? 5. W jakim środowisku pracujesz? Jaki sprzęt i oprogramowanie są używane? Wersje? Konfiguracje? Odpowiedzi te prowadzą do pośredniej przyczyny problemu i w efekcie do jego rozwiązania. Embedded Systems Architecture 21
Metoda naukowa: Sposób postępowania: 1. Pytanie problem związany z wydajnością. 2. Hipoteza prawdopodobna przyczyna niezadawalającej wydajności. 3. Przewidywanie oparte o hipotezę. 4. Test sprawdzający przewidywanie, może mieć charakter obserwacyjny lub eksperymentalny. 5. Analiza na podstawie zebranych danych podczas testu. Embedded Systems Architecture 22
Metoda naukowa: Test obserwacyjny wyraźny spadek wydajności systemu po migracji do komputera z mniejszą ilością pamięci operacyjnej. Prawdopodobna przyczyna mniejszy bufor systemu plików. Sprawdzenie współczynnika trafień. Test eksperymentalny zwiększenie bufora poprzez dodanie pamięci RAM. Embedded Systems Architecture 23
Cykl diagnostyczny: Hipoteza; Weryfikacja hipotezy; Dane; Hipoteza. W cyklu kładzie się nacisk na szybkie zebranie danych dla nowej hipotezy, którą następnie sprawdza się, modyfikuje itd. Embedded Systems Architecture 24
Metoda narzędzi: Przygotowanie listy dostępnych narzędzi z zakresu wydajności (opcjonalnie instalacja lub zakup innych). Przygotowanie użytecznych metryk dostarczanych przez dane narzędzie w odniesieniu do każdego narzędzia. Dla każdej metryki przygotowanie listy reguł możliwych do zastosowania podczas interpretacji. Powyższe czynności stworzą nakazową listę rzeczy do sprawdzenia, wskazującą narzędzia do użycia, metryki do odczytania i sposoby ich interpretacji. Opiera się o znane narzędzia, które mogą dostarczać niekompletnego obrazu systemu. Użytkownik może być nieświadomy otrzymywania niekompletnego obrazu. Problemy wymagające wykorzystania własnych narzędzi mogą zostać niewykryte i nierozwiązane. Embedded Systems Architecture 25
Metoda narzędzi: Duża ilość dostępnych narzędzi i metryk może spowodować że przeanalizowanie ich może okazać się bardzo czasochłonne. Konieczność poznania wad i zalet narzędzi dostarczających podobnych funkcjonalności. Embedded Systems Architecture 26
Metoda USE Utilization, Saturation and Errors poziom wykorzystania, nasycenie i błędy. Powinna być stosowana na wczesnym etapie analizy systemu. Pozwala wykryć wąskie gardła w systemie. Postępowanie możemy sprowadzić do stwierdzenia: Dla każdego zasobu sprawdź poziom wykorzystania, nasycenia oraz błędy. Zasób: wszystkie fizyczne, funkcjonalne komponenty serwera (procesory, szyny, pamięć itp.). Oprogramowanie również stanowi zasób, który można przeanalizować. Poziom wykorzystania: Dla zdefiniowanego przedziału czasu oznacza procentową ilość czasu, przez który zasób był zajęty wykonywaniem zadań. Zajęty zasób nadal może przyjmować kolejne zadania. Poziom przy którym traci tę możliwość wskazywany jest przez nasycenie. Embedded Systems Architecture 27
Nasycenie: Poziom, do którego zasób może akceptować dodatkowe zadania niemożliwe do wykonania w danej chwili. Zadania są najczęściej kolejkowane. Błędy: Liczba błędów. Embedded Systems Architecture 28
W przypadku pamięci operacyjnej poziom wykorzystania jest równy pojemności danego zasobu. Jest to odmienne podejście niż w przypadku definicji opartej na czasie. Po osiągnięciu nasycenia zasób musi kolejkować nowe zadania lub wygenerować błąd, który jest uwzględniany przez metodę USE. Błędy należy sprawdzać gdyż ich skutki mogą mieć znaczący wpływ na wydajność. Metoda USE ogranicza liczbę kluczowych metryk, aby wszystkie zasoby mogły być sprawdzone tak szybko jak to możliwe. System może cierpieć z powodu kilku problemów związanych z wydajnością. Może się okazać, że znaleziony problem nie jest problemem, którego szukamy. Dlatego też jeśli zachodzi potrzeba sprawdzenia następnych zasobów każde odkrycie należy sprawdzić za pomocą innych metodologii, jeszcze przed powrotem do metody USE. Embedded Systems Architecture 29
Charakterystyka obciążenia prosta i efektywna metoda identyfikacji problemów pojawiających się na skutek danego obciążenia. Koncentrujemy się w niej na danych wejściowych systemu a nie na końcowej wydajności. Obciążenie można scharakteryzować odpowiadając na poniższe pytania: Co powoduje obciążenie? Jaki jest identyfikator procesu lub użytkownika powodującego obciążenie? Jaki jest zdalny adres IP? Dlaczego dane obciążenie zostało zastosowane? Jaka jest ścieżka kodu i stos wywołań? Jak przedstawia się charakterystyka danego obciążenia? Jakie są wartości IOPS, przepustowość i jaki jest wykonywany rodzaj operacji (odczyt/zapis)? Zaobserwowane zmiany (odchylenie standardowe). Czy dane obciążenie ulega zmianie w czasie? Czy istnieje wzorzec, który można przypisać obciążeniu? Embedded Systems Architecture 30
Zwiększenie wydajności można uzyskać poprzez pozbycie się niepotrzebnie wykonywanych zadań. Czasem mogą one być wykonywane przez błędnie działającą aplikację, np. wątek zablokowany w pętli zużywa czas procesora. Przyczynę może stanowić nieprawidłowa konfiguracja, np. kopia zapasowa systemu wykonywana w godzinach pracy. Atak typu DoS (Denial of Service odmowa usług) Przygotowanie charakterystyk obciążenia pozwala wykryć wspomniane problemy. Embedded Systems Architecture 31
Analiza drążąca Metodologia ta rozpoczyna się od analizy problemu na poziomie ogólnym, a następnie na coraz większym zawężaniu badanego obszaru na podstawie wcześniejszych wyników. Odrzucane są nieinteresujące obszary a drążone są coraz bardziej te, które wydają się interesujące. Cały proces może wymagać przeanalizowania całego stosu oprogramowania aż do warstwy sprzętowej, aby znaleźć przyczynę problemu. Etapy: 1. Monitorowanie nieustanne rejestrowanie danych statystycznych. 2. Identyfikacja pozwala zawęzić analizę do konkretnych zasobów. 3. Analiza analiza określonych obszarów w celu znalezienia źródła problemu. Embedded Systems Architecture 32
Analiza opóźnień Metodologia ta polega na sprawdzeniu ilości czasu koniecznego do ukończenia danej operacji. Analiza ta dzielona jest na mniejsze fragmenty, które dzielone są na kolejne. Celem takiego postępowania jest rozbicie fragmentów o największym opóźnieniu, aby można było znaleźć przyczynę problemu i jego rozwiązanie. Embedded Systems Architecture 33
Start Pomiar opóźnienia Podział na A i B Pomiar A lub B (lub obu fragmentów) Czy problem został rozwiązany Tak Koniec A Który fragment jest wolniejszy: A, czy B? B Embedded Systems Architecture 34
Metoda R Metodologia opracowana na potrzeby baz danych firmy Oracle. Koncentruje się na znalezieniu źródła opóźnienia na podstawie analizy zdarzeń monitorowania Oracle. Opracowana dla baz danych można ją wykorzystać do analizy systemów. Embedded Systems Architecture 35
Monitorowanie zdarzeń Analiza wydajności wymaga zbadania podsumowania przygotowanego na podstawie następujących zdarzeń: Instrukcje procesora, Dyskowe operacje wejścia-wyjścia i inne polecenia, Pakiety systemowe, Wywołania systemowe, Wywołania bibliotek, Transakcje aplikacji, Zapytania do bazy danych itp. Embedded Systems Architecture 36
Podczas monitorowania zdarzeń koncentrujemy się na wyszukiwaniu następujących informacji: Dane wejściowe wszystkie atrybuty żądania zdarzenia: typ, kierunek, wielkość itd.; Czas czas rozpoczęcia i zakończenia zdarzenia, a także opóźnienie; Wynik błędy stanu, wynik zdarzenia (wielkość). Embedded Systems Architecture 37
Statystyczne dostosowanie wydajności Metoda ta koncentruje się na kwestiach skonfigurowanej architektury. W przeciwieństwie do innych metodologii, które skupiają się na wydajności przy określonym obciążeniu, wydajność dynamiczna analiza ta może być przeprowadzana, gdy system jest bezczynny, czyli nie znajduje się pod żadnym obciążeniem. Statystyczna analiza wydajności i jej dostosowywanie polega na przejrzeniu wszystkich komponentów systemu i odpowiedzeniu na n/w pytania: Czy dany komponent ma sens? Czy dana konfiguracja ma sens, biorąc pod uwagę przewidywane obciążenie? Embedded Systems Architecture 38
Czy dany komponent jest skonfigurowany w najlepszy sposób, biorąc pod uwagę przewidywane obciążenie? Czy wystąpiły jakiekolwiek błędy związane z danym komponentem i czy działa on w ograniczonym zakresie? Przykłady problemów, które można rozwiązać przy pomocy statycznego dostosowywania wydajności: Negocjacja szybkości interfejsu sieciowego: 100 Mb/s zamiast 1Gb/s; Uszkodzony dysk w puli macierzy RAID; Użyta starsza wersja systemu operacyjnego, aplikacji lub firmware u; Wielkość rekordu systemu plików niedopasowana do wielkości obciążenia wejścia-wyjścia; Embedded Systems Architecture 39
Dostosowanie bufora Systemy operacyjne i aplikacje mogą używać wielu buforów dla poprawy wydajności wejścia-wyjścia. Bufory te mogą znajdować się na poziomach od aplikacji po fizyczne dyski. Ogólna strategia dostrajania buforów na poszczególnych poziomach: Bufor powinien znajdować się na jak najwyższym poziomie na stosie oprogramowania, maksymalnie blisko wykonywanych zadań. Zmniejsza to operacyjne obciążenie związane z trafnością bufora. Sprawdzenie bufor jest włączony i działa. Sprawdzenie wskaźnika trafności/nietrafności bufora. Sprawdzenie bieżącej wielkości bufora z dynamicznie ustalaną wielkością. Embedded Systems Architecture 40
Dostosowanie bufora do bieżącego obciążenia. Wykonanie tego zadania zależy od dostępnych parametrów dostrajania bufora. Dostosowanie obciążenia do danego bufora. Wykonanie tego zadania oznacza usunięcie z bufora niepotrzebnych obiektów i tym samym zwolnienie miejsca dla potrzebnych obiektów. Kolejnym zagadnieniem w tej metodzie jest sprawdzenie czy nie występuje podwójne buforowanie, które zużywa pamięć operacyjną. Sprawdzenie wpływu dostrajania buforów na różnych poziomach na ogólny przyrost wydajności. Embedded Systems Architecture 41
Mikrotesty wydajności Metoda ta pozwala na sprawdzenie wydajności przy prostym i sztucznym obciążeniu. Jest przeciwieństwem do przemysłowych testów wydajności, które mają na celu przetestowanie wydajności pod rzeczywistym obciążeniem. W testach używane są narzędzia do mikrotestów i generatory obciążenia. Przykłady mikrotestów: Czas wywołań systemowych. Odczyty systemów plików. Przepustowość sieci. Sprawdzenie bieżącej wielkości bufora z dynamicznie ustalaną wielkością. Embedded Systems Architecture 42
Modelowanie Modelowanie może być wykorzystane do analizy skalowalności, czyli jak wydajność będzie skalowana wraz ze zmianą obciążenia lub zasobów. Zasobami mogą być komponenty sprzętowe, procesory, jak i oprogramowanie, procesy lub wątki. Analiza skalowalności może pokazać iż w określonym punkcie wydajność przestaje być skalowana liniowo punkt załamania, ograniczenie wynikające z zasobów. Embedded Systems Architecture 43