Rozwiązywanie problemów z wydajnością i izolowanie wąskich gardeł w systemie Linux
Dotyczy: ✔️ maszyny wirtualne z systemem Linux
Problemy z wydajnością i wąskie gardła
W przypadku wystąpienia problemów z wydajnością w różnych systemach operacyjnych i aplikacjach każdy przypadek wymaga unikatowego podejścia do rozwiązywania problemów. Procesor CPU, pamięć, sieć i wejścia/wyjścia (we/wy) to kluczowe obszary, w których mogą wystąpić problemy. Każdy z tych obszarów wyświetla różne objawy (czasami jednocześnie) i wymaga różnych diagnoz i rozwiązań.
Problemy z wydajnością mogą być spowodowane błędną konfiguracją aplikacji lub konfiguracji. Przykładem może być aplikacja internetowa, która ma warstwę buforowania, która nie jest poprawnie skonfigurowana. Ta sytuacja wyzwala więcej żądań przepływanych z powrotem do serwera pochodzenia zamiast obsługi z pamięci podręcznej.
W innym przykładzie dziennik ponownego wykonywania bazy danych MySQL lub MariaDB znajduje się na dysku systemu operacyjnego lub na dysku, który nie spełnia wymagań bazy danych. W tym scenariuszu może wystąpić mniej transakcji na sekundę (TPS) ze względu na konkurencję dla zasobów i wyższe czasy odpowiedzi (opóźnienie).
Jeśli w pełni zrozumiesz problem, możesz lepiej określić, gdzie szukać na stosie (procesor CPU, pamięć, sieć, operacje we/wy). Aby rozwiązać problemy z wydajnością , należy ustanowić punkt odniesienia , który umożliwia porównywanie metryk po wprowadzeniu zmian i ocenę, czy ogólna wydajność uległa poprawie.
Rozwiązywanie problemu z wydajnością maszyny wirtualnej nie różni się od rozwiązywania problemu z wydajnością w systemie fizycznym. Chodzi o określenie, który zasób lub składnik powoduje wąskie gardło w systemie.
Ważne jest, aby zrozumieć, że wąskie gardła zawsze istnieją. Rozwiązywanie problemów z wydajnością polega na zrozumieniu, gdzie występuje wąskie gardło i jak przenieść go do mniej obraźliwego zasobu.
Ten przewodnik ułatwia odnajdywanie i rozwiązywanie problemów z wydajnością w usłudze Azure Virtual Machines w środowisku systemu Linux.
Uzyskiwanie wskaźników wydajności
Można uzyskać wskaźniki wydajności, które potwierdzają lub odmawiają, czy ograniczenie zasobu istnieje.
W zależności od badanego zasobu wiele narzędzi może pomóc w uzyskaniu danych odnoszących się do tego zasobu. Poniższa tabela zawiera przykłady głównych zasobów.
| Zasób | Narzędzie |
|---|---|
| Procesor CPU | top, , htop, mpstat, , pidstatvmstat |
| Dysk | iostat, , iotopvmstat |
| Sieć | ip, , vnstatiperf3 |
| Pamięć | free, , topvmstat |
W poniższych sekcjach omówiono wskaźniki i narzędzia, których można użyć do wyszukiwania głównych zasobów.
Zasób procesora CPU
Określony procent procesora CPU jest używany lub nie. Podobnie procesy poświęcają czas na użycie procesora CPU (na przykład 80 procent usr użycia) lub nie (np. bezczynność 80 procent). Głównym narzędziem umożliwiającym potwierdzenie użycia procesora CPU jest top.
Narzędzie top jest domyślnie uruchamiane w trybie interaktywnym. Odświeża co sekundę i pokazuje procesy posortowane według użycia procesora CPU:
[root@rhel78 ~]$ top
top - 19:02:00 up 2:07, 2 users, load average: 1.04, 0.97, 0.96
Tasks: 191 total, 3 running, 188 sleeping, 0 stopped, 0 zombie
%Cpu(s): 29.2 us, 22.0 sy, 0.0 ni, 48.5 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 7990204 total, 6550032 free, 434112 used, 1006060 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7243640 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd
1680 root 20 0 410268 38596 5644 S 3.0 0.5 2:15.10 python
772 root 20 0 90568 3240 2316 R 0.3 0.0 0:08.11 rngd
1472 root 20 0 222764 6920 4112 S 0.3 0.1 0:00.55 rsyslogd
10395 theuser 20 0 162124 2300 1548 R 0.3 0.0 0:11.93 top
1 root 20 0 128404 6960 4148 S 0.0 0.1 0:04.97 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.56 ksoftirqd/0
7 root rt 0 0 0 0 S 0.0 0.0 0:00.07 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.0 0.0 0:06.00 rcu_sched
10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 lru-add-drain
11 root rt 0 0 0 0 S 0.0 0.0 0:00.05 watchdog/0
12 root rt 0 0 0 0 S 0.0 0.0 0:00.04 watchdog/1
13 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/1
14 root 20 0 0 0 0 S 0.0 0.0 0:00.21 ksoftirqd/1
16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
18 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
19 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd
21 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kintegrityd
Teraz przyjrzyj się wierszowi dd procesu z tych danych wyjściowych:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd
Widać, że dd proces zużywa 99,7% procesora CPU.
Uwaga
Użycie procesora CPU można wyświetlić w narzędziu
top, wybierając pozycję 1.Narzędzie
topwyświetla całkowite użycie ponad 100 procent, jeśli proces jest wielowątkowy i obejmuje więcej niż jeden procesor CPU.
Innym przydatnym odwołaniem jest średnia obciążenia. Średnia obciążenie pokazuje średnie obciążenie systemu w 1-minutowych, 5-minutowych i 15-minutowych interwałach. Wartość wskazuje poziom obciążenia systemu. Interpretacja tej wartości zależy od liczby dostępnych procesorów CPU. Jeśli na przykład średnia obciążenia wynosi 2 w systemie z jednym procesorem CPU, system jest tak załadowany, że procesy zaczynają kolejkować. Jeśli obciążenie wynosi średnio 2 w systemie z czterema procesorami CPU, łączne użycie procesora CPU wynosi około 50%.
Uwaga
Liczbę procesorów można szybko uzyskać, uruchamiając nproc polecenie .
W poprzednim przykładzie średnia obciążenia wynosi 1,04. Jest to system z dwoma procesorami, co oznacza, że użycie procesora CPU wynosi około 50%. Ten wynik można sprawdzić, jeśli zauważysz 48,5% bezczynności procesora CPU. (W danych wyjściowych top polecenia wartość bezczynności procesora CPU jest wyświetlana przed etykietą id ).
Użyj średniej obciążenia jako szybkiego omówienia sposobu działania systemu.
Uruchom polecenie , uptime aby uzyskać średnią obciążenia.
Zasób dysku (we/wy)
Podczas badania problemów z wydajnością we/wy poniższe terminy pomagają zrozumieć, gdzie występuje problem.
| Okres | opis |
|---|---|
| Rozmiar operacji we/wy | Ilość danych przetwarzanych na transakcję, zwykle zdefiniowana w bajtach. |
| Wątki we/wy | Liczba procesów, które wchodzą w interakcję z urządzeniem magazynowym. Ta wartość zależy od aplikacji. |
| Rozmiar bloku | Rozmiar we/wy zdefiniowany przez urządzenie bloku zapasowego. |
| Rozmiar sektora | Rozmiar każdego sektora na dysku. Ta wartość to zazwyczaj 512 bajtów. |
| Liczba operacji we/wy na sekundę | Operacje danych wyjściowych danych wejściowych na sekundę. |
| Opóźnienie | Czas zakończenia operacji we/wy. Ta wartość jest zwykle mierzona w milisekundach (ms). |
| Throughput (Przepływność) | Funkcja ilości przesyłanych danych przekroczyła określony czas. Ta wartość jest zwykle definiowana jako megabajty na sekundę (MB/s). |
Liczba operacji we/wy na sekundę
Operacje danych wyjściowych wejściowych na sekundę (IOPS) to funkcja liczby operacji wejścia i wyjścia (we/wy), które są mierzone w określonym czasie (w tym przypadku sekund). Operacje we/wy mogą być operacjami odczytu lub zapisu. Usunięcia lub odrzucenia można również liczyć jako operację w systemie magazynu. Każda operacja ma jednostkę alokacji odpowiadającą rozmiarowi operacji we/wy.
Rozmiar operacji we/wy jest zwykle definiowany na poziomie aplikacji jako ilość danych zapisywanych lub odczytywanych na transakcję. Często używany rozmiar we/wy to 4K. Jednak mniejszy rozmiar operacji we/wy, który zawiera więcej wątków, daje wyższą wartość operacji we/wy na sekundę. Ponieważ każda transakcja może zostać wykonana stosunkowo szybko (ze względu na niewielki rozmiar), mniejsze operacje we/wy umożliwiają ukończenie większej liczby transakcji w tym samym czasie.
Wręcz przeciwnie, załóżmy, że masz taką samą liczbę wątków, ale używasz większej liczby operacji we/wy. Liczba operacji we/wy na sekundę zmniejsza się, ponieważ ukończenie każdej transakcji trwa dłużej. Jednak przepływność zwiększa się.
Rozważmy następujący przykład:
1000 operacji we/wy na sekundę oznacza, że dla każdej sekundy kończy się tysiąc operacji. Każda operacja zajmuje mniej więcej jedną milisekundę. (Istnieje 1000 milisekund w ciągu jednej sekundy). Teoretycznie każda transakcja ma mniej więcej jedną milisekundę do zakończenia lub około 1 ms opóźnienia.
Znając wartość IOSize i liczbę operacji we/wy na sekundę, możesz obliczyć przepływność, mnożąc wartość IOSize według liczby operacji we/wy na sekundę.
Na przykład:
1000 operacji we/wy na sekundę przy rozmiarze 4K IOSize = 4000 KB/s lub 4 MB/s (dokładne 3,9 MB/s)
1000 operacji we/wy na sekundę przy rozmiarze 1 mln operacji we/wy = 1000 MB/s lub 1 GB/s (976 MB/s do dokładnego)
Bardziej przyjazną wersję równania można napisać w następujący sposób:
IOPS * IOSize = IOSize/s (Throughput)
Produktywność
W przeciwieństwie do liczby operacji we/wy na sekundę przepływność jest funkcją ilości danych w czasie. Oznacza to, że podczas każdej sekundy pewna ilość danych jest zapisywana lub odczytywana. Ta szybkość jest mierzona w <czasie> danych>/<lub megabajtach na sekundę (MB/s).
Jeśli znasz wartości przepływności i IOSize, możesz obliczyć liczbę operacji we/wy na sekundę, dzieląc przepływność przez IOSize. Należy znormalizować jednostki do najmniejszej konotacji. Jeśli na przykład wartość IOSize jest zdefiniowana w kilobajtach (kb), należy przekonwertować przepływność.
Format równania jest zapisywany w następujący sposób:
Throughput / IOSize = IOPS
Aby umieścić to równanie w kontekście, rozważ przepływność wynoszącą 10 MB/s w rozmiarze IOSize 4K. Po wprowadzeniu wartości w równaniu wynik wynosi 10 240/4=2560 operacji we/wy na sekundę.
Uwaga
10 MB jest dokładnie równe 10 240 KB.
Opóźnienie
Opóźnienie to pomiar średniej ilości czasu potrzebny na zakończenie każdej operacji. Liczba operacji we/wy na sekundę i opóźnienie są powiązane, ponieważ obie koncepcje są funkcją czasu. Na przykład przy 100 operacji we/wy na sekundę każda operacja trwa około 10 ms. Jednak ta sama ilość danych może być pobierana jeszcze szybciej przy niższych liczbach operacji we/wy na sekundę. Opóźnienie jest również nazywane czasem wyszukiwania.
Informacje o danych wyjściowych iostat
W ramach pakietu iostat sysstat narzędzie zapewnia wgląd w wydajność dysku i metryki użycia. iostat może pomóc w zidentyfikowaniu wąskich gardeł związanych z podsystemem dysków.
Możesz uruchomić iostat polecenie w prostym poleceniu. Podstawowa składnia jest następująca:
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
Parametry określają, jakie informacje iostat są dostępne. Bez żadnego parametru iostat polecenia wyświetla podstawowe szczegóły:
[host@rhel76 ~]$ iostat
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76) 08/05/2019 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
41.06 0.00 30.47 21.00 0.00 7.47
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 182.77 5072.69 1066.64 226090 47540
sdd 2.04 42.56 22.98 1897 1024
sdb 12.61 229.23 96065.51 10217 4281640
sdc 2.56 46.16 22.98 2057 1024
md0 2.67 73.60 45.95 3280 2048
Domyślnie iostat wyświetla dane dla wszystkich istniejących urządzeń blokowych, chociaż minimalne dane są udostępniane dla każdego urządzenia. Dostępne są parametry, które ułatwiają identyfikowanie problemów przez dostarczanie rozszerzonych danych (takich jak przepływność, liczba operacji we/wy na sekundę, rozmiar kolejki i opóźnienie).
Uruchom polecenie iostat , określając wyzwalacze:
sudo iostat -dxctm 1
Aby jeszcze bardziej rozwinąć iostat wyniki, użyj następujących parametrów.
| Parametr | Akcja |
|---|---|
-d |
Wyświetl raport wykorzystania urządzenia. |
-x |
Wyświetlanie statystyk rozszerzonych. Ten parametr jest ważny, ponieważ zapewnia liczbę operacji we/wy na sekundę, opóźnienie i rozmiary kolejek. |
-c |
Wyświetl raport wykorzystania procesora CPU. |
-t |
Wydrukuj czas wyświetlania każdego raportu. Ten parametr jest przydatny w przypadku długich przebiegów. |
-m |
Wyświetl statystyki w megabajtach na sekundę, czyli bardziej czytelną dla człowieka formę. |
Liczba 1 w poleceniu informuje iostat o odświeżeniu co sekundę. Aby zatrzymać odświeżanie, naciśnij Ctrl+C.
Jeśli dołączysz dodatkowe parametry, dane wyjściowe będą wyglądać podobnie do następującego tekstu:
[host@rhel76 ~]$ iostat -dxctm 1
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76) 08/05/2019 _x86_64_ (1 CPU)
08/05/2019 07:03:36 PM
avg-cpu: %user %nice %system %iowait %steal %idle
3.09 0.00 2.28 1.50 0.00 93.14
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.02 0.52 9.66 2.46 0.31 0.10 70.79 0.27 23.97 6.68 91.77 2.94 3.56
sdd 0.00 0.00 0.12 0.00 0.00 0.00 64.20 0.00 6.15 6.01 12.50 4.44 0.05
sdb 0.00 22.90 0.47 0.45 0.01 5.74 12775.08 0.17 183.10 8.57 367.68 8.01 0.74
sdc 0.00 0.00 0.15 0.00 0.00 0.00 54.06 0.00 6.46 6.24 14.67 5.64 0.09
md0 0.00 0.00 0.15 0.01 0.00 0.00 89.55 0.00 0.00 0.00 0.00 0.00 0.00
Informacje o wartościach
Główne kolumny z danych wyjściowych iostat są wyświetlane w poniższej tabeli.
| Kolumna | opis |
|---|---|
r/s |
Odczyty na sekundę (liczba operacji we/wy na sekundę) |
w/s |
Zapisy na sekundę (liczba operacji we/wy na sekundę) |
rMB/s |
Odczyt megabajtów na sekundę (przepływność) |
wMB/s |
Zapis megabajtów na sekundę (przepływność) |
avgrq-sz |
Średni rozmiar we/wy w sektorach; pomnóż tę liczbę według rozmiaru sektora, czyli zwykle 512 bajtów, aby uzyskać rozmiar operacji we/wy w bajtach (rozmiar we/wy) |
avgqu-sz |
Średni rozmiar kolejki (liczba operacji we/wy w kolejce oczekujących na obsłużenie) |
await |
Średni czas w milisekundach dla operacji we/wy obsługiwanych przez urządzenie (opóźnienie) |
r_await |
Średni czas odczytu w milisekundach dla operacji we/wy obsługiwanych przez urządzenie (opóźnienie) |
w_await |
Średni czas odczytu w milisekundach dla operacji we/wy obsługiwanych przez urządzenie (opóźnienie) |
Dane prezentowane przez iostat program są informacyjne, ale obecność niektórych danych w niektórych kolumnach nie oznacza problemu. Dane z iostat programu powinny być zawsze przechwytywane i analizowane pod kątem możliwych wąskich gardeł. Duże opóźnienie może wskazywać, że dysk osiąga punkt nasycenia.
Uwaga
Możesz użyć pidstat -d polecenia , aby wyświetlić statystyki we/wy na proces.
Zasób sieciowy
Sieci mogą mieć dwa główne wąskie gardła: niską przepustowość i duże opóźnienia.
Do przechwytywania szczegółów przepustowości na żywo można użyć vnstat . Jednak vnstat nie jest dostępna we wszystkich dystrybucjach. Powszechnie dostępne iptraf-ng narzędzie to kolejna opcja wyświetlania ruchu interfejsu w czasie rzeczywistym.
Opóźnienie sieci
Opóźnienie sieci w dwóch różnych systemach można określić za pomocą prostego ping polecenia w protokole ICMP (Internet Control Message Protocol):
[root@rhel78 ~]# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=5.33 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=5.24 ms
^C
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 5.240/5.291/5.339/0.035 ms
Aby zatrzymać działanie ping, naciśnij Ctrl+C.
Przepustowość sieci
Przepustowość sieci można zweryfikować przy użyciu narzędzi, takich jak iperf3. Narzędzie iperf3 działa na serwerze/modelu klienta, w którym aplikacja jest uruchamiana, określając flagę -s na serwerze. Następnie klienci łączą się z serwerem, określając adres IP lub w pełni kwalifikowaną nazwę domeny (FQDN) serwera w połączeniu z flagą -c . Poniższe fragmenty kodu pokazują, jak używać iperf3 narzędzia na serwerze i kliencie.
Server (Serwer)
root@ubnt:~# iperf3 -s ----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------Klient
root@ubnt2:~# iperf3 -c 10.1.0.4 Connecting to host 10.1.0.4, port 5201 [ 5] local 10.1.0.4 port 60134 connected to 10.1.0.4 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 5.78 GBytes 49.6 Gbits/sec 0 1.25 MBytes [ 5] 1.00-2.00 sec 5.81 GBytes 49.9 Gbits/sec 0 1.25 MBytes [ 5] 2.00-3.00 sec 5.72 GBytes 49.1 Gbits/sec 0 1.25 MBytes [ 5] 3.00-4.00 sec 5.76 GBytes 49.5 Gbits/sec 0 1.25 MBytes [ 5] 4.00-5.00 sec 5.72 GBytes 49.1 Gbits/sec 0 1.25 MBytes [ 5] 5.00-6.00 sec 5.64 GBytes 48.5 Gbits/sec 0 1.25 MBytes [ 5] 6.00-7.00 sec 5.74 GBytes 49.3 Gbits/sec 0 1.31 MBytes [ 5] 7.00-8.00 sec 5.75 GBytes 49.4 Gbits/sec 0 1.31 MBytes [ 5] 8.00-9.00 sec 5.75 GBytes 49.4 Gbits/sec 0 1.31 MBytes [ 5] 9.00-10.00 sec 5.71 GBytes 49.1 Gbits/sec 0 1.31 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 57.4 GBytes 49.3 Gbits/sec 0 sender [ 5] 0.00-10.04 sec 57.4 GBytes 49.1 Gbits/sec receiver iperf Done.
Niektóre typowe iperf3 parametry klienta przedstawiono w poniższej tabeli.
| Parametr | Opis |
|---|---|
-P |
Określa liczbę równoległych strumieni klienta do uruchomienia. |
-R |
Odwraca ruch. Domyślnie klient wysyła dane do serwera. |
--bidir |
Testuje zarówno przekazywanie, jak i pobieranie. |
Zasób pamięci
Pamięć to inny zasób rozwiązywania problemów do sprawdzenia, ponieważ aplikacje mogą lub nie używają części pamięci. Możesz użyć narzędzi, takich jak free i top , aby przejrzeć ogólne wykorzystanie pamięci i określić, ile pamięci zużywają różne procesy:
[root@rhel78 ~]# free -m
total used free shared buff/cache available
Mem: 7802 435 5250 9 2117 7051
Swap: 0 0 0
W systemach z systemem Linux często występuje 99- procentowe wykorzystanie pamięci. W danych wyjściowych free znajduje się kolumna o nazwie buff/cache. Jądro systemu Linux używa wolnej (nieużywanej) pamięci do buforowania żądań we/wy w celu uzyskania lepszych czasów odpowiedzi. Ten proces jest nazywany pamięcią podręczną strony. Podczas nacisku pamięci (scenariusze, w których pamięć jest niska), jądro zwraca pamięć używaną dla pamięci podręcznej strony, aby aplikacje mogły używać tej pamięci.
W danych wyjściowych free dostępna kolumna wskazuje ilość pamięci dostępnej dla procesów do użycia. Ta wartość jest obliczana przez dodanie ilości pamięci buff/pamięci podręcznej i wolnej pamięci.
Możesz skonfigurować polecenie w celu sortowania top procesów według użycia pamięci. Domyślnie top sortuje według wartości procentowej procesora CPU (%). Aby posortować według użycia pamięci (%), wybierz Shift+M po uruchomieniu polecenia .top Poniższy tekst przedstawia dane wyjściowe z top polecenia :
[root@rhel78 ~]# top
top - 22:40:15 up 5:45, 2 users, load average: 0.08, 0.08, 0.06
Tasks: 194 total, 2 running, 192 sleeping, 0 stopped, 0 zombie
%Cpu(s): 12.3 us, 41.8 sy, 0.0 ni, 45.4 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 st
KiB Mem : 7990204 total, 155460 free, 5996980 used, 1837764 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1671420 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
45283 root 20 0 5655348 5.3g 512 R 99.7 69.4 0:03.71 tail
3124 omsagent 20 0 415316 54112 5556 S 0.0 0.7 0:30.16 omsagent
1680 root 20 0 413500 41552 5644 S 3.0 0.5 6:14.96 python
[...]
Kolumna RES wskazuje pamięć rezydentną. Reprezentuje rzeczywiste użycie procesu. Narzędzie top zapewnia podobne dane wyjściowe do free pod względem kilobajtów (KB).
Wykorzystanie pamięci może wzrosnąć więcej niż oczekiwano, jeśli aplikacja wystąpi przecieki pamięci. W scenariuszu przecieku pamięci aplikacje nie mogą zwolnić stron pamięci, które nie są już używane.
Oto inne polecenie używane do wyświetlania najważniejszych procesów zużywających pamięć:
ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
Poniższy tekst przedstawia przykładowe dane wyjściowe polecenia :
[root@rhel78 ~]# ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
PID COMMAND USER COMMAND %CPU %MEM
45922 tail root tail -f /dev/zero 82.7 61.6
[...]
W poniższych przykładowych danych wyjściowych można zidentyfikować wykorzystanie pamięci z zdarzeń Kill (OOM, Out of Memory) Kill , jak pokazano w następujących przykładowych danych wyjściowych:
Jun 19 22:42:14 rhel78 kernel: Out of memory: Kill process 45465 (tail) score 902 or sacrifice child
Jun 19 22:42:14 rhel78 kernel: Killed process 45465 (tail), UID 0, total-vm:7582132kB, anon-rss:7420324kB, file-rss:0kB, shmem-rss:0kB
OOM jest wywoływany po użyciu pamięci RAM (pamięci fizycznej) i swap (dysku).
Uwaga
Możesz użyć pidstat -r polecenia , aby wyświetlić statystyki pamięci procesu.
Określanie, czy istnieje ograniczenie zasobu
Możesz określić, czy ograniczenie istnieje, używając poprzednich wskaźników i znając bieżącą konfigurację. Ograniczenie można porównać z istniejącą konfiguracją.
Oto przykład ograniczenia dysku:
Maszyna wirtualna D2s_v3 może mieć 48 MB/s przepływności bez pamięci podręcznej. Do tej maszyny wirtualnej jest dołączony dysk P30, który może wynosić 200 MB/s. Aplikacja wymaga co najmniej 100 MB/s.
W tym przykładzie zasób ograniczający jest przepływnością ogólnej maszyny wirtualnej. Wymaganie aplikacji w porównaniu z konfiguracją dysku lub maszyny wirtualnej może wskazywać zasób ograniczający.
Jeśli aplikacja wymaga <zasobu> miary1><, a bieżąca konfiguracja <zasobu> może dostarczyć tylko< miarę2>, może to być czynnik ograniczający.
Definiowanie zasobu ograniczającego
Po określeniu zasobu, który ma być czynnikiem ograniczającym w bieżącej konfiguracji, zidentyfikuj, jak można go zmienić i jak wpływa na obciążenie. Istnieją sytuacje, w których ograniczenie zasobów może istnieć z powodu miary oszczędzania kosztów, ale aplikacja nadal jest w stanie obsłużyć wąskie gardło bez problemów.
Na przykład:
Jeśli aplikacja wymaga 128 GB (pomiar) pamięci RAM (zasób), a bieżąca konfiguracja pamięci RAM (zasób) może dostarczać tylko 64 GB (pomiar), to wymaganie może być czynnikiem ograniczającym.
Teraz możesz zdefiniować zasób ograniczający i podjąć działania na podstawie tego zasobu. Ta sama koncepcja dotyczy innych zasobów.
Jeśli te zasoby ograniczające są oczekiwane jako miara oszczędzania kosztów, aplikacja powinna obejść wąskie gardła. Jeśli jednak istnieją te same miary oszczędzania kosztów, a aplikacja nie może łatwo obsłużyć braku zasobów, ta konfiguracja może powodować problemy.
Wprowadzanie zmian na podstawie uzyskanych danych
Projektowanie pod kątem wydajności nie dotyczy rozwiązywania problemów, ale zrozumienia, gdzie może wystąpić następne wąskie gardło i jak go obejść. Wąskie gardła zawsze istnieją i można je przenosić tylko do innej lokalizacji projektu.
Jeśli na przykład aplikacja jest ograniczona przez wydajność dysku, można zwiększyć rozmiar dysku, aby zapewnić większą przepływność. Jednak sieć staje się kolejnym wąskim gardłem. Ponieważ zasoby są ograniczone, nie ma idealnej konfiguracji i musisz regularnie rozwiązywać problemy.
Dzięki uzyskaniu danych w poprzednich krokach można teraz wprowadzać zmiany na podstawie rzeczywistych, mierzalnych danych. Możesz również porównać te zmiany z wcześniej mierzonym punktem odniesienia, aby sprawdzić, czy istnieje konkretna różnica.
Rozważmy następujący przykład:
Po uzyskaniu punktu odniesienia podczas działania aplikacji ustaliliśmy, że system miał stałe użycie procesora CPU w 100 procentach w konfiguracji dwóch procesorów CPU. Zaobserwowano średnią obciążenia wynoszącą 4. Oznaczało to, że system kolejkował żądania. Zmiana systemu 8 procesora CPU zmniejszyła użycie procesora CPU do 25 procent, a średnia obciążenia została zmniejszona do 2, gdy zastosowano to samo obciążenie.
W tym przykładzie istnieje wymierna różnica podczas porównywania uzyskanych wyników ze zmienionymi zasobami. Przed zmianą istniało wyraźne ograniczenie zasobów. Jednak po zmianie istnieje wystarczająca ilość zasobów, aby zwiększyć obciążenie.
Migrowanie z środowiska lokalnego do chmury
Migracje z konfiguracji lokalnej do przetwarzania w chmurze mogą mieć wpływ na kilka różnic w wydajności.
Procesor CPU
W zależności od architektury konfiguracja lokalna może uruchamiać procesory CPU o większej szybkości zegara i większe pamięci podręczne. Wynik byłby zmniejszony czas przetwarzania i wyższe instrukcje na cykl (IPC). Ważne jest, aby zrozumieć różnice w modelach i metrykach procesora CPU podczas pracy nad migracjami. W takim przypadku relacja jeden do jednego między liczbami procesora CPU może nie być wystarczająca.
Na przykład:
W systemie lokalnym, który ma cztery procesory, które działają na poziomie 3,7 GHz, jest łącznie 14,8 GHz dostępne do przetwarzania. Jeśli odpowiednik liczby procesorów CPU jest tworzony przy użyciu maszyny wirtualnej D4s_v3, która jest wspierana przez procesory 2,1 GHz, zmigrowana maszyna wirtualna ma dostęp do przetwarzania o 8,1 GHz. Oznacza to około 44 procent spadku wydajności.
Dysk
Wydajność dysku na platformie Azure jest definiowana przez typ i rozmiar dysku (z wyjątkiem dysku w warstwie Ultra, która zapewnia elastyczność w zakresie rozmiaru, liczby operacji we/wy na sekundę i przepływności). Rozmiar dysku definiuje limity liczby operacji we/wy na sekundę i przepływności.
Opóźnienie to metryka zależna od typu dysku zamiast rozmiaru dysku. Większość lokalnych rozwiązań magazynu to macierze dysków, które mają pamięci podręczne DRAM. Ten typ pamięci podręcznej zapewnia opóźnienie w milisekundach (około 200 mikrosekund) i wysoką przepływność odczytu/zapisu (IOPS).
W poniższej tabeli przedstawiono średnie opóźnienia platformy Azure.
| Typ dysku | Opóźnienie |
|---|---|
| Ssd w warstwie Ultra/Premium w wersji 2 | Trzycyfrowe μs (mikrosekundy) |
| SSD w warstwie Premium/SSD w warstwie Standardowa | Ms (milisekundy) |
| Standardowy dysk twardy | Dwie cyfry ms (milisekundy) |
Uwaga
Dysk jest ograniczany, jeśli osiągnie limity liczby operacji we/wy na sekundę lub przepustowości, ponieważ w przeciwnym razie opóźnienie może zwiększyć się do 100 milisekund lub więcej.
Różnica opóźnienia między środowiskiem lokalnym (często mniejszym niż milisekund) a dyskiem SSD w warstwie Premium (w milisekundach jednocyfrowych) staje się czynnikiem ograniczającym. Zwróć uwagę na różnice w opóźnieniu między ofertami magazynu i wybierz ofertę, która lepiej pasuje do wymagań aplikacji.
Sieć
Większość konfiguracji sieci lokalnej używa łączy 10 Gb/s. Na platformie Azure przepustowość sieci jest definiowana bezpośrednio przez rozmiar maszyn wirtualnych. Niektóre przepustowości sieci mogą przekraczać 40 Gb/s. Upewnij się, że wybrano rozmiar, który ma wystarczającą przepustowość dla potrzeb aplikacji. W większości przypadków czynnikiem ograniczającym jest limity przepływności maszyny wirtualnej lub dysku zamiast sieci.
Pamięć
Wybierz rozmiar maszyny wirtualnej, który ma wystarczającą ilość pamięci RAM dla aktualnie skonfigurowanej pamięci RAM.
Diagnostyka wydajności (PerfInsights)
Narzędzie PerfInsights jest zalecanym narzędziem z pomoc techniczna platformy Azure w przypadku problemów z wydajnością maszyny wirtualnej. Została zaprojektowana tak, aby obejmowała najlepsze rozwiązania i dedykowane karty analizy dla procesora CPU, pamięci i operacji we/wy. Można go uruchomić za pośrednictwem witryny Azure Portal lub z poziomu maszyny wirtualnej, a następnie udostępnić dane zespołowi pomoc techniczna platformy Azure.
Uruchamianie narzędzia PerfInsights
Narzędzie PerfInsights jest dostępne zarówno dla systemu operacyjnego Windows , jak i Linux . Sprawdź, czy dystrybucja systemu Linux znajduje się na liście obsługiwanych dystrybucji dla diagnostyki wydajności dla systemu Linux.
Uruchamianie i analizowanie raportów za pośrednictwem witryny Azure Portal
Po zainstalowaniu narzędzia PerfInsights za pośrednictwem witryny Azure Portal oprogramowanie instaluje rozszerzenie na maszynie wirtualnej. Użytkownicy mogą również zainstalować narzędzie PerfInsights jako rozszerzenie, przechodząc bezpośrednio do pozycji Rozszerzenia w bloku maszyny wirtualnej, a następnie wybierając opcję diagnostyki wydajności.
Opcja 1 witryny Azure Portal
Przejrzyj blok maszyny wirtualnej i wybierz opcję Diagnostyka wydajności. Zostanie wyświetlona prośba o zainstalowanie opcji (używa rozszerzeń) na wybranej maszynie wirtualnej.
Opcja 2 w witrynie Azure Portal
Przejdź do karty Diagnozowanie i rozwiązywanie problemów w bloku maszyny wirtualnej i poszukaj linku Rozwiązywanie problemów w obszarze Problemy z wydajnością maszyny wirtualnej.
Czego należy szukać w raporcie narzędzia PerfInsights
Po uruchomieniu raportu narzędzia PerfInsights lokalizacja zawartości zależy od tego, czy raport został uruchomiony w witrynie Azure Portal, czy jako plik wykonywalny. W przypadku jednej z opcji uzyskaj dostęp do wygenerowanego folderu dziennika lub (jeśli w witrynie Azure Portal) pobierz lokalnie na potrzeby analizy.
Uruchamianie za pośrednictwem witryny Azure Portal
Otwórz raport narzędzia PerfInsights. Karta Wyniki rejestruje wszelkie wartości odstające pod względem zużycia zasobów. Jeśli występują wystąpienia niskiej wydajności ze względu na określone użycie zasobów, karta Wyniki kategoryzuje każde znalezienie jako duży wpływ lub Średni wpływ.
Na przykład w poniższym raporcie widzimy, że wykryto wyniki o średnim wpływie związane z usługą Storage i zobaczymy odpowiednie zalecenia. Po rozwinięciu zdarzenia Wyniki zostanie wyświetlonych kilka kluczowych szczegółów.
Aby uzyskać więcej informacji na temat narzędzia PerfInsights w systemie operacyjnym Linux, zobacz How to use PerfInsights Linux in Microsoft Azure (Jak używać narzędzia PerfInsights Linux na platformie Microsoft Azure).
Więcej informacji
Skontaktuj się z nami, aby uzyskać pomoc
Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pomoc techniczną społeczności platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.