Przejdź do treści 
Pokazuję, jak Metryki serwera takich jak bezczynność procesora, obciążenie i iowait w taki sposób, że mogę oddzielić prawdziwe wąskie gardła od nieszkodliwych skoków i podjąć ukierunkowane środki zaradcze. Wyjaśniam, które wartości graniczne mają sens, w jaki sposób kluczowe liczby oddziałują na siebie i jak wyprowadzam konkretne kroki z mierzonych wartości.
Punkty centralne
- Bezczynność procesorapokazuje wolny czas obliczeniowy i ukryte fazy oczekiwania
- Średnie obciążeniemierzy kolejki i wykorzystanie rdzenia
- iowaiteksponuje pamięć masową i hamulce sieciowe
- InterakcjaRozpoznawanie wzorców zamiast postrzegania poszczególnych wartości w oderwaniu od siebie.
- AlertyDefiniowanie istotnych progów i trendów
Prawidłowa interpretacja bezczynności procesora
Czytam Bezczynność procesora jako odsetek czasu, w którym procesor nie wykonuje niczego ani nie czeka na operacje wejścia/wyjścia, i zawsze oceniam go w kontekście bieżących obciążeń. Jeśli bezczynność często utrzymuje się powyżej 60-80%, planuję więcej zadań lub zmniejszam skalę usług, ponieważ istnieją niewykorzystane rezerwy. Jeśli bezczynność spada poniżej 20 procent przez dłuższy czas, najpierw szukam procesów związanych z procesorem, nieefektywnych pętli i braku równoległości. Jeśli Idle spada, podczas gdy czas użytkownika (us) i czas systemowy (sy) są wysokie, wiele można powiedzieć o czystym głodzie obliczeniowym; z drugiej strony, jeśli Idle spada, podczas gdy iowait wzrasta, wskazuje to na blokady poza procesorem. W przypadku serwerów internetowych uważam, że zakres od 20 do 40 procent bezczynności średnio dziennie jest zdrowy, o ile czasy odpowiedzi pozostają stabilne, a użytkownicy nie są zauważalnie dotknięci żadnymi wartościami odstającymi.
Zrozumienie obciążenia serwera
Oceniam Średnie obciążenie jako średnią liczbę procesów, które chcą obliczyć lub oczekują na czas procesora i porównać ją bezpośrednio z liczbą rdzeni. Jeśli 1-minutowe obciążenie wielokrotnie przekracza liczbę rdzeni, tworzone są kolejki, co znajduje odzwierciedlenie w opóźnieniach w planowaniu i dłużej działających żądaniach. W przypadku codziennych decyzji zwracam szczególną uwagę na 5- i 15-minutowe obciążenie, ponieważ wygładza ono czasy szczytowe i pozwala uniknąć fałszywych alarmów spowodowanych krótkimi szczytami. Na 4-rdzeniowym serwerze interpretuje wartości obciążenia do około 3,2 jako solidne wykorzystanie; w przypadku wartości powyżej 4,0 aktywnie badam procesy, blokady i ścieżki I/O. Jeśli chcesz uniknąć typowych błędnych interpretacji obciążenia, możesz znaleźć praktyczne wskazówki na stronie Prawidłowe odczytywanie średniej obciążenia, gdzie namacalnie przedstawiam przypadki graniczne i przykłady obliczeń.
Wyraźne rozgraniczenie oczekiwania I/O (oczekiwania CPU)
Rozróżniam między iowait ściśle od rzeczywistego wykorzystania, ponieważ procesor jest gotowy, ale nie może obliczyć, ponieważ czeka na operacje pamięci lub sieci. Jeśli iowait utrzymuje się stale powyżej 10 procent, najpierw sprawdzam opóźnienia nośników danych, głębokości kolejek, wąskie gardła systemu plików i ścieżki sieciowe. Jeśli na szczycie pojawia się wiele procesów ze statusem D (nieprzerwane uśpienie), utwierdza mnie to w podejrzeniu blokowania dostępu I/O. W takich przypadkach dyski SSD NVMe, więcej IOPS, zoptymalizowane opcje montażu lub większa pamięć podręczna stron przyspieszają przetwarzanie, zanim pomyślę o skalowaniu. Przewodnik zawiera zwięzłe wprowadzenie z typowymi przykładowymi obrazami Zrozumienie oczekiwania na operacje wejścia/wyjścia, aby pomóc mi we wstępnej diagnozie.
Prawidłowe kategoryzowanie ciśnienia pamięci
Oddzielam się Drukowanie z pamięci Świadomy wąskich gardeł CPU i I/O, ponieważ niedobory pamięci mają swoje własne sygnatury. Jeśli aktywność odzyskiwania stron wzrasta, widzę kolumny si/so (swap in/out) w vmstat lub wskaźniki błędów stron w sar i koreluję to z iowait i czasami odpowiedzi. Umiarkowane wykorzystanie swapów nie jest automatycznie złe w przypadku dużej pamięci podręcznej stron, ale uporczywe swapowanie spowalnia każdy procesor. W takich sytuacjach udział bezczynności niekoniecznie się zmniejsza, podczas gdy obciążenie może wzrosnąć - procesy czekają wtedy na odzyskane strony i blokują kolejkę uruchamiania. Przed skalowaniem pamięci RAM lub dostosowaniem pamięci podręcznej sprawdzam w szczególności proporcje pamięci podręcznej stron (wolne/bufory/bufor podręczny), główne błędy dotkniętych procesów i ustawienie swappiness. W systemie Linux używam również PSI (Pressure Stall Information) pod /proc/pressure/memory, aby sprawdzić, czy zadania czekają zauważalnie na pamięć. Jeśli PSI pokazuje zwiększone przeciągnięcia w znaczących oknach czasowych, zwiększam przestrzeń pamięci podręcznej stron, odciążam pamięć podręczną obiektów / zapytań w aplikacji lub przenoszę zadania wsadowe do cichszych okien, aby interaktywne obciążenia nie dusiły się z powodu presji pamięci.
Współdziałanie biegu jałowego, obciążenia i oczekiwania
Oceniam Interakcja kluczowych danych, ponieważ wzorce ujawniają więcej niż pojedyncze wartości. Wysokie obciążenie w połączeniu z wysokim czasem bezczynności często wskazuje na blokady we/wy: Wiele procesów czeka, a sam procesor jest znudzony. Z drugiej strony, niski czas bezczynności przy niskim obciążeniu wskazuje na intensywne obliczeniowo pojedyncze procesy, które zajmują CPU przez długi czas bez powodowania dużych kolejek. Jeśli czas kradzieży (st) w maszynach wirtualnych również wzrasta, informuję hostera o potencjalnym overbookingu lub rozważam zmianę hosta. Dopiero gdy interakcja działa prawidłowo, decyduję się na środki takie jak skalowanie pionowe, dystrybucja pozioma lub ukierunkowana optymalizacja kodu.
Rozważ częstotliwość procesora, turbo i throttling
Sprawdzam Częstotliwości procesora i Turbo Boost, ponieważ wartości procentowe (us/sy) mogą być mylące, jeśli częstotliwość taktowania jest skalowana dynamicznie. Jeśli częstotliwość spada (oszczędzanie energii, dławienie termiczne), bezwzględna moc obliczeniowa spada, choć w stanie spoczynku i obciążenia może wyglądać na niezmienioną. Odczytuję bieżące MHz na rdzeń (np. za pomocą turbostatu lub cpupower) równolegle do wykorzystania i oceniam szczyty pod kątem temperatury i gubernatora (oszczędzanie energii, wydajność). Jeśli występują szczyty opóźnień podczas krótkich faz bezczynności, niskie stany C (C6+) mogą wydłużyć czas wybudzania - w przypadku usług krytycznych dla opóźnień ustawiam bardziej konserwatywne limity stanu C lub regulator wydajności, podczas gdy obciążenie wsadowe korzysta z oszczędności energii. Odkrywam Dławienie termiczne Przy ciągłym obciążeniu planuję ulepszenia chłodzenia, redukuję niekrytyczne zadania w tle w gorących fazach lub rozdzielam obciążenia tak, aby rdzenie nie dławiły się, a metryki zapewniały bardziej realistyczny obraz.
NUMA, przerwania i powinowactwo
Zwracam uwagę na Strefy NUMA i dystrybucji przerwań, ponieważ ruch krzyżowy zniekształca te wskaźniki. Jeśli wątek wielokrotnie uzyskuje dostęp do pamięci na „niewłaściwym“ węźle NUMA, opóźnienia zauważalnie rosną, podczas gdy obciążenie i iowait pokazują wzorce takie jak „dużo się dzieje, ale niewielki postęp“. Sprawdzam hotspoty za pomocą numactl/numastat, przypinam obciążenia do węzłów (CPU i pamięci) zgodnie z wymaganiami i zwracam uwagę na rozmiary puli buforów na gniazdo dla baz danych. Rozkładam obciążenie sieciowe za pomocą RSS/RPS/XPS i sprawdzam /proc/interrupts, aby pojedynczy rdzeń nie przenosił wszystkich przerwań NIC i nie działał jako wąskie gardło. Jeśli wykryję wysokie udziały sy% przy niewielkiej pracy użytkownika, interpretuję to jako wskaźnik drukowania IRQ, ścieżek kopiowania jądra lub sum kontrolnych - w takich przypadkach pomagają zaktualizowane sterowniki, niestandardowe opcje odciążania i sprawiedliwy balans IRQ między rdzeniami.
Szybka diagnostyka na terminalu
Zaczynam od top lub htop, aby natychmiast zobaczyć podział procesora (us, sy, ni, id, wa, hi, si, st), wartości obciążenia i widoczne procesy. Następnie sprawdzam czas pracy dla obciążenia o trzech wartościach i porównuję 1-, 5- i 15-minutowe trendy z czasem zdarzenia. Za pomocą vmstat uzyskuję widok przepływu kolejki uruchamiania, przełączników kontekstowych, aktywności wymiany i historii iowait. W przypadku nośnika danych używam iostat, odczytuję tps, await, svctm i identyfikuję szczyty opóźnień na urządzenie lub LUN. Jeśli pidstat i perf pokazują gorące punkty w kodzie, nadaję priorytet dotkniętym ścieżkom, zanim pomyślę o sprzęcie, ponieważ często osiągam szybkie korzyści dzięki niewielkiej poprawce we właściwym miejscu.
Kontenery i grupy C: rozpoznawanie dławienia
Oceniam Limity kontenerów jako możliwą przyczynę, jeśli obrazy obciążenia nie pasują. Jeśli limity CPU (CFS) skracają czas procesu, widzę rosnące obciążenie z zaskakująco niskim czasem us%, ponieważ zadania czekają na następne okno wycinka czasu. W Kubernetes upewniam się, że żądania oraz limity są realistyczne: Zbyt wąskie limity prowadzą do throttlingu, zbyt niskie żądania prowadzą do wąskich gardeł harmonogramowania na węźle. Sprawdzam liczniki dławienia w cgroup, obserwuję kontenery z wysokim współczynnikiem przełączania kontekstu i zamykam powinowactwo przypinania procesora i najpierw skaluję limity przed aktualizacją węzłów. Limity pamięci bez nadwyżki mogą prowadzić do zabójstw OOM - mogę to rozpoznać po nagłym zakończeniu procesów, widocznych z wyprzedzeniem poważnych błędach i nieregularnych szczytach opóźnień. Środki zaradcze to rozsądne limity pamięci, dystrybucja pozioma i bufory dla zadań w tle, aby ścieżki produkcyjne nie były spowalniane przez limity.
Rozsądny wybór wartości granicznych i alertów
Ustawiłem Wartości progowe tak, aby zgłaszały rzeczywiste zagrożenia, a krótkoterminowe szczyty nie wywoływały ciągłych alarmów. W przypadku bezczynności procesora planuję ostrzeżenia od około 20%, dla iowait od 10%, a dla obciążenia od 80% rdzeni, w każdym przypadku z krótkim opóźnieniem. Drugi etap z wyższym progiem uruchamia eskalację lub automatyczne skalowanie, aby dać mi czas na działanie. Do monitorowania trendów używam 15-minutowego obciążenia i porównuję je z dziennymi i tygodniowymi wzorcami, aby rozpoznać sezonowe szczyty. Alerty wysyłam w pakiecie, dzięki czemu skupiam się na sytuacjach incydentalnych i nie gubię się w powiadomieniach.
| Metryki | Orientacja | Ostrzeżenie | Krytyczny | Możliwa przyczyna | Szybkie działanie |
|---|---|---|---|---|---|
| Bezczynność procesora | > 60 % | < 20 % | < 10 % | Silna ścieżka kodu, zbyt mało rdzeni | Profilowanie i paralelizacja hotspotów |
| Obciążenie | < Liczba rdzeni | > 0,8 × rdzenie | > 1,0 × rdzeni | Kolejki, blokady, przeciążenia we/wy | Sprawdź najważniejsze procesy, ogranicz blokady |
| iowait | < 5 % | > 10 % | > 20 % | Wolny dysk/sieć, zbyt małe wskazówki | NVMe/RAID, zwiększenie głębokości kolejki |
Planowanie wydajności z SLO i poziomami bazowymi
I link Pojemność z SLO (np. czas odpowiedzi 95%) zamiast wartości średnich. W przypadku procesora określam wartości docelowe (np. bezczynność P95 nie poniżej 20%), aby krótkie obciążenia szczytowe nie zamieniały się natychmiast w kolejki. W przypadku obciążenia korzystam z historycznych wartości bazowych w zależności od pory dnia i sezonu, aby zbudować dynamiczne progi, które uwzględniają wzrost lub kampanie. Alerty definiuję jako złożone: Tylko wtedy, gdy na przykład obciążenie > rdzeni, iowait > 10 procent i opóźnienie P95 wzrasta, wyzwalany jest etap 2. W środowiskach chmurowych planuję rezerwy etapowe (np. +25% rdzeni, +x IOPS) i mam gotowe playbooki dotyczące tego, jak reguły automatycznego skalowania wchodzą w życie bez generowania awarii. Testuję zmiany za pomocą pomiarów A/B, dokumentuję wskaźniki przed/po i upewniam się, że optymalizacje nie tylko przesuwają obciążenie, ale eliminują wąskie gardła w dłuższej perspektywie.
Typowe przyczyny i rozwiązania
Często widzę wysokie wartości iowait dla małych woluminów w chmurze z niewystarczającymi gwarancjami IOPS, dlatego też specjalnie przełączam się na pamięć masową NVMe lub większe woluminy z wyższymi gwarancjami i znacznie skracam czas oczekiwania. Jeśli wysokie obciążenie występuje przy normalnym iowait, często znajduję nieefektywne wyrażenia regularne, brakujące pamięci podręczne lub gadatliwe ORM, które łagodzę za pomocą indeksów, dostrajania zapytań i buforowania odpowiedzi. Jeśli dominuje czas systemowy, przyglądam się przerwaniom sieciowym, stanom sterowników i funkcjom odciążania karty sieciowej, ponieważ burze IRQ wiążą procesor. W przypadku sporadycznych spadków z jednoczesną kradzieżą czasu w maszynach wirtualnych, sprawdzam zajętość hosta i przenoszę się do spokojniejszej okolicy. Jeśli aplikacja skaluje się poziomo, uszczelniam wąskie gardła za pomocą centralnych pamięci podręcznych, asynchronicznych kolejek i wyraźnych limitów czasu, aby pojedyncze wartości odstające nie blokowały całego węzła.
Wirtualizacja: zwróć uwagę na kradzież czasu
Mierzę ukraść czas (st) w środowiskach zwirtualizowanych, ponieważ pokazuje, ile czasu obliczeniowego poświęca hiperwizor. Jeśli st regularnie wzrasta powyżej kilku procent, przesyłam zgłoszenie do dostawcy wraz z dokumentami metrycznymi i proszę o przeniesienie lub dedykowane zasoby. W scenariuszach z wieloma dzierżawcami planuję również bufory dla obciążenia, aby krótkie wąskie gardła spowodowane przez sąsiadów nie prowadziły bezpośrednio do alarmów. Po stronie hosta ograniczam niepotrzebne zadania w tle, aby stworzyć więcej miejsca na produktywne obciążenie we wrażliwych oknach. W przypadku krytycznych systemów preferuję dedykowane rdzenie lub instancje bare-metal, aby zapewnić przewidywalne opóźnienia.
Pulpity nawigacyjne i praktyka monitorowania
Buduję Pulpity nawigacyjne tak, aby pokazywały rozkład procesora, obciążenie, iowait, pamięć, dysk i wartości sieciowe razem i zapewniały mi łańcuchy przyczyn w ciągu kilku sekund. Krótkie, pięciosekundowe interwały próbkowania ujawniają skoki, a podsumowane widoki uwidaczniają trendy. Tworzę alerty w zależności od sezonowości i pory dnia, aby nocne zmiany nie uruchamiały się przy każdym szczycie. Playbooki, w których przechowuję standardowe testy i ścieżki eskalacji, pomagają mi w analizie, dzięki czemu nikt nie zaczyna od zera. Jeśli chcesz zacząć w ustrukturyzowany sposób, możesz rzucić okiem na mój artykuł Analiza danych z monitoringu który podsumowuje najważniejsze panele i kluczowe postacie.
Testowanie wydajności bez martwych punktów
Sprawdzam Wąskie gardła nie tylko przy pełnym obciążeniu, ale także w fazach bezczynności, ponieważ kopie zapasowe, zadania cron i uruchamianie indeksów często kolidują w nocy. W przypadku aplikacji o dużym natężeniu ruchu tworzę realistyczne profile obciążenia, które obejmują zimne pamięci podręczne i fazy rozgrzewania. Konsekwentnie rejestruję porównania A/B przed i po zmianach, aby móc oddzielić rzeczywiste efekty od przypadkowych wahań. W przypadku ścieżek pamięci koreluję opóźnienia, głębokości kolejek i przepustowość, aby rozpoznać przyczynę i skutek. Na poziomie sieci używam selektywnego przechwytywania pakietów, jeśli same wskaźniki nie wyjaśniają, dlaczego żądania utknęły.
Praktyczne przepisy: Próbki do pomiarów
- Wysokie obciążenie, wysoka bezczynność, wysoki iowait: sprawdzenie ścieżek I/O, zwiększenie głębokości kolejki, buforowanie przed dyskiem.
- Niski czas bezczynności, niskie obciążenie: Pojedynczy gorący wątek - profilowanie, równoległość lub wsad.
- Wysoki sy%, normalny us%: Optymalizacja gorącej ścieżki IRQ/jądra, sterownika/offloadingu i dystrybucji przerwań.
- Obciążenie zbliżone do liczby rdzeni, szczyt opóźnienia tylko przy przepustnicy turbo: sprawdź chłodzenie/regulator, unikaj przepustnicy.
- Kontenery z pasami dławienia: zwiększanie limitów CPU, harmonizowanie żądań/limitów, ograniczanie współdzierżawy.
- Pamięć-PSI wzrosła, iowait umiarkowany: dostosuj pamięć podręczną stron/zestaw roboczy, dodaj pamięć RAM lub przenieś zadania wsadowe.
Krótkie podsumowanie
Czytam Bezczynność procesora, Load i iowait zawsze współpracują ze sobą, ponieważ wzorzec dostarcza ustaleń i sprawia, że moje kolejne kroki są jasne. Dzięki jasnym progom, krótkim interwałom i znaczącym pulpitom nawigacyjnym zapobiegam ślepym lotom i reaguję w odpowiednim czasie. Szukam gorących punktów w kodzie dla obciążenia CPU, lepszych ścieżek I/O i buforowania dla iowait, a także usprawniam kolejki i synchronizację dla dużych obciążeń. W maszynach wirtualnych uwzględniam czas kradzieży, aby ograniczenia infrastruktury nie pojawiały się jako problem aplikacji. Utrzymanie tej dyscypliny zmniejsza liczbę awarii, rozsądnie wykorzystuje zasoby i utrzymuje czasy odpowiedzi na niezmiennie niskim poziomie.
