Skocz do: nawigacji, wyszukiwania

Amplwcs2


Uruchomienie analizy


  1. Otwieramy zakładkę wyboru analizy, klikamy prawym przyciskiem na projekt w Project Navigator następnie wybieramy New Analisys… lub klikamy przycisk Button 12.png w pasku narzędzi. Zakładka z wyborem analizy wygląda następująco:
    Amp new lw 1.png
  2. Z drzewa analiz Analysis Type wybieramy rodzaj analizy – Locks and Waits
  3. Uruchamiamy analizę klikając przycisk Start


W trakcie wykonywania analizy wyświetlona zostanie zakładka Collection Log, która przedstawia informacja o postępach analizy oraz czasie jaki upłynął od jej rozpoczęcia. Po zakończeniu analizy zebrane informacje wyświetlone zostaną w zakładce Summary



Interpretacja rezultatów


Po zakończeniu analizy automatycznie otwierana jest zakładka Summary, która w przypadku analizowanej przez nas aplikacji wygląda następująco:
Amp new lw 2.png

W górnej części zakładki znajduje się sekcja Eplased Time, która przedstawia następujące dane na temat analizowanej aplikacji:

  • Eplased Time – całkowity czas jaki minął od początku do końca zbierania informacji
  • Total Thread Count – liczba wątków wykorzystanych w programie
  • Wait Time – przedstawia czas kiedy wątki aplikacji czekały na jakieś wydarzenie np.: oczekiwanie na synchronizacje
  • Spin Time – czas oczekiwania, gdy procesor był zajęty
  • Wait Count – określa ilość sytuacji, kiedy wątki aplikacji czekały
  • CPU Time – czas CPU potrzebny na wykonanie aplikacji (suma czasu CPU wszystkich wątków aplikacji)
  • Paused Time – przedstawia, na jak długo analiza została wstrzymana.


W przypadku analizowanej aplikacji wartość metryki Wait Time jest zbyt wysoka. W sekcji Top Waiting Objects przedstawiona jest lista obiektów synchronizacji wraz z wartościami metryk Wait Time oraz Wait Count, posortowane malejąco według metryki Wait Time. W przypadku analizowanej aplikacji obiektem synchronizacji, spędzającym najwięcej czasu na czekaniu jest Mutex. Poniżej znajdują się dwa wykresy.


Thread Concurrency Histogram przedstawiający wartość Eplased Time i poziom współbieżności dla wykorzystywanej liczby wątków. W najlepszym przypadku najwyższy słupek powinien znajdować się w części OK lub Ideal. Wartość Target Concurrency domyślnie równa jest ilości CPU w systemie. Average obliczane jest na podstawie CPU Time / Eplased Time, im wartość bliższa jest liczbie logicznych CPU w systemie, tym lepiej. Dla analizowanej przez nas aplikacji wielowątkowej uruchomionej w systemie posiadającym 16 rdzeni, średnie użycie CPU na wykresie wynosi nieco ponad 1, kiedy powinno być bliskie 16. Oznacza to, że aplikacja nie wykorzystuje w pełni możliwości oferowanych przez system. Po najechaniu na słupek, wyświetlany jest czas w jakim aplikacja wykonuje obliczenia przy danej liczbie rdzeni. Widzimy, że w przypadku analizowanej aplikacji, jej poziom współbieżności sklasyfikowany jest jako niski.


CPU Usage Histogram przedstawia Eplased Time oraz poziom użycia logicznych procesorów. W idealnym przypadku najwyższy słupek powinien znajdować się w części OK lub Ideal. Po najechaniu na słupek wyświetlany jest czas, jaki aplikacja spędza na wykonywaniu obliczeń przy danej liczbie CPU. Widzimy, że analizowana przez nas aplikacja spędza ponad 10 sekund wykorzystując 1 rdzeń, co sklasyfikowane jest jako niskie wykorzystanie dostępnych CPU.


Analiza obiektów synchronizacji

  1. Przechodzimy do zakładki Bottom-up, która w przypadku analizowanej aplikacji wygląda następująco:
    Amp new lw 3.png

Obiekty synchronizacji znalezione w analizowane aplikacji wyświetlone zostają w postaci listy w zakładce Bottom-up. Każdy z nich posiada własny identyfikator (hash numer). Obiekty posortowane są od najniższego do najwyższego poziomu wykorzystania CPU. Słupki na liście obok danego obiektu przedstawiają jak dany obiekt wykorzystuje możliwości oferowane przez system. Obok w kolumnie Wait Count, znajduje się wartość określająca ile razy dany obiekt, został wywołany w aplikacji.


Widzimy, że w przypadku analizowanej aplikacji mamy jeden obiekt, który powoduje najdłuższy czas oczekiwania. Rozwinięcie pozycji na liście przedstawia metodę, w której dany obiekt został wywołany. W przypadku analizowanej aplikacji znajduje się on w funkcji draw_task::().


Analiza kodu źródłowego

  1. Klikamy dwukrotnie na obiekt synchronizacji znajdujący się na pierwszej pozycji na liście. Otwarta zostanie zakładka Source przedstawiająca kod źródłowy aplikacji, która wygląda następująco:
Amp new lw 4.png

Po otwarciu zakładki Source zaznaczona zostaje linia z wybranym obiektem synchronizacji. Widzimy, że w przypadku analizowanej aplikacji jest nim mutex o nazwie rgb_mutex, który powoduje, że funkcja czeka przez blisko 36 sekund. W trakcie tego czasu, krytyczna sekcja wywołana została 456 razy.



< Wstecz

Dalej >