Dlaczego niskie średnie wykorzystanie może ukrywać intensywnie pracujący serwer domowy?

Niskie średnie wykorzystanie może ukrywać zajęty serwer domowy, ponieważ średnia kompresuje czas, rdzenie CPU, procesy i typy zasobów do niewielkiego zestawu liczb. Serwer może spędzić większość minuty bezczynnie, a mimo to zatrzymać każde interaktywne żądanie podczas krótkiego, pięciosekundowego skoku.

Ten sam brak dopasowania pojawia się, gdy jeden rdzeń jest nasycony, zadania czekają na pamięć masową, wątki blokują się na blokadzie, odzyskiwanie pamięci zatrzymuje alokacje lub tylko niewielka część żądań doświadcza bardzo wysokich opóźnień. Maszyna wydaje się zajęta, gdy krytyczne żądanie czeka, nie tylko gdy całkowite CPU lub RAM pokazują 100%.

Dlaczego długie okna próbkowania usuwają krótkie okresy zajętości?

Systemy monitorujące zwykle uśredniają liczniki zasobów przez piętnaście sekund, jedną minutę lub dłużej. długie okna próbkowania ukrywają krótkie skoki CPU, ponieważ krótki okres pełnej wydajności staje się umiarkowaną wartością po połączeniu z dłuższym okresem bezczynności.

Serwer pracujący na 100% CPU przez sześć sekund i prawie bezczynny przez pozostałe pięćdziesiąt cztery sekundy może raportować niską średnią z jednej minuty. Żądanie sieciowe pojawiające się w tych sześciu sekundach doświadcza pełnej kolejki, a nie późniejszego bezczynnego czasu, który rozcieńcza wykres.

Próbkowanie z niższą częstotliwością potęguje ten efekt. Metryka o wysokiej rozdzielczości może uchwycić skok, podczas gdy pulpit nawigacyjny z godzinowym interwałem przechowuje tylko średnią, minimum i maksimum lub nawet tylko jeden punkt średni.

Jak jeden rdzeń może być nasycony, podczas gdy całkowite wykorzystanie CPU wygląda na niskie?

Całkowite użycie CPU uśrednia aktywność wszystkich procesorów logicznych, ale wykorzystanie CPU może ukrywać zatrzymane wykonanie. Aplikacja jednowątkowa lub gorąca kolejka jądra może osiągnąć swój limit, podczas gdy pozostałe rdzenie pozostają bezczynne.

W systemie ośmiordzeniowym jeden w pełni zajęty rdzeń może wyglądać jak około jedna ósma całkowitej pojemności CPU. Jeśli pisarz bazy danych, pętla zdarzeń, wątek kompresji lub ścieżka softirq zależy od tego rdzenia, dodanie bezczynnych rdzeni nie skróci etapu szeregowego.

Częstotliwość, termiczne ograniczenia, hyper-threading, migracja planisty i zatrzymania pamięci również zmieniają, ile pracy reprezentuje jeden punkt procentowy. Wykorzystanie na rdzeń i wykonana praca są bardziej informatywne niż jedna liczba dla całego hosta.

Dlaczego procesor może wyglądać na bezczynny, podczas gdy aplikacje czekają na dostęp do pamięci masowej?

Obciążenie Linuxa to nie tylko procent CPU. średnie obciążenie obejmuje zadania czekające na I/O, więc wątki zablokowane na dyskach, systemach plików sieciowych lub kontrolerach magazynu mogą sprawiać wrażenie zablokowania systemu.

Procesor może być dostępny, ale aplikacja nie może kontynuować, dopóki nie zakończy się odczyt, zatwierdzenie dziennika, opróżnienie bazy danych, operacja metadanych lub odpowiedź sieciowego magazynu danych. Czas bezczynności CPU jest więc skutkiem wąskiego gardła, a nie dowodem, że żądanie ma wystarczające zasoby.

Sprawdź opóźnienia urządzeń, głębokość kolejki, oczekiwanie na I/O, zablokowane zadania, zachowanie systemu plików i RTT sieciowego magazynu danych. Niska wartość MB/s nie wyklucza nasycenia, gdy obciążenie składa się z wielu małych, synchronicznych operacji.

Jak blokady, pule i kolejki generują pracę bez wysokiego zużycia CPU?

Wątki mogą być obecne, a żądania aktywne, nie zużywając CPU, ponieważ czekają na stan współdzielony. konflikty blokad mogą podnosić opóźnienia bez wzrostu CPU, gdy jedna transakcja uniemożliwia innym operacjom postęp.

Pule połączeń, blokady plików, transakcje baz danych, kolejki pracowników, zaległości gniazd i semafory aplikacji mają ograniczoną współbieżność. Pula z każdym zajętym miejscem jest nasycona, nawet jeśli zadania zajmujące te miejsca same czekają.

Dlatego długość kolejki i czas oczekiwania mają znaczenie. Wykorzystanie opisuje zasób wykonujący pracę; nasycenie opisuje zapotrzebowanie, które nie może się rozpocząć lub zakończyć natychmiast.

Dlaczego presja pamięci może zatrzymać aplikacje zanim RAM wyda się wyczerpany?

Kontener może mieć wolną pamięć w ramach własnego limitu, podczas gdy host jest już pod presją. bezpośrednie odzyskiwanie pamięci może zatrzymać wątki aplikacji, gdy jądro musi zwolnić strony przed zaspokojeniem nowej alokacji.

Panel kontrolny może nie pokazywać zdarzenia braku pamięci, podczas gdy wątki żądań wchodzą w odzyskiwanie, czekają na zapis stron brudnych, powodują błędy niedawno usuniętych stron lub odbudowują zestaw roboczy usunięty przez inne obciążenie.

Mierz ciśnienie pamięci, poważne błędy stron, aktywność swapu, czas odzyskiwania, zapis stron brudnych oraz ponowne trafienia w pamięć podręczną. Ważne jest, czy zadania są zatrzymane z powodu pamięci, a nie czy pasek użytej pamięci wizualnie jest pełny.

Które metryki ujawniają ukryty stan zajętości?

Użytkownicy doświadczają wolnych żądań na krawędzi rozkładu, więc średnie opóźnienie może ukrywać najwolniejsze żądania. Śledź percentyle, maksima i ślady na poziomie żądań zamiast tylko średniego czasu odpowiedzi.

Połącz wysokorozdzielcze dane CPU na rdzeń, kolejki zadań, opóźnienia I/O, zablokowane zadania, informacje o zastoju z powodu presji, odzyskiwanie pamięci, zajętość puli połączeń, oczekiwania na blokady oraz opóźnienia p95 lub p99 aplikacji. Wyrównaj je na tej samej osi czasu, aby można było śledzić jedną ścieżkę oczekiwania przez warstwy.

krótkie połączenia powtarzają stałą pracę konfiguracyjną. Mierz wykonaną pracę i czas oczekiwania podczas wolnego momentu; spokojna średnia długoterminowa nie wyjaśni, który zasób uniemożliwił postęp tego żądania.

FAQ

Czy średnie obciążenie Linuxa to to samo co wykorzystanie CPU?

Nie. Średnie obciążenie obejmuje zadania gotowe do wykonania oraz zadania w nieprzerwalnym uśpieniu, które często obejmują wątki czekające na I/O.

Czy 20% całkowitego CPU może oznaczać wąskie gardło CPU?

Tak. Jeden rdzeń, jeden wątek lub jedna zserializowana ścieżka jądra mogą być nasycone, podczas gdy pozostałe rdzenie pozostają w większości bezczynne.

Dlaczego serwer wydaje się wolny po ustąpieniu skoku?

Kolejki mogą się jeszcze opróżniać, pamięci podręczne mogą wymagać rozgrzania, brudne dane mogą się jeszcze zapisywać, a podczas pierwotnego zastoju mogły się nagromadzić ponowne próby.

Który pojedynczy wskaźnik powinien zastąpić wykorzystanie CPU?

Żaden pojedynczy wskaźnik nie wystarczy. Połącz wykorzystanie z sygnałami nasycenia i opóźnienia dla CPU, pamięci, pamięci masowej, sieci oraz ścieżki żądań samej aplikacji.

Ostateczne wnioski

Niska średnia nie dowodzi, że serwer domowy ma natychmiastową pojemność. Agregacja czasowa może zniwelować skoki, całkowite użycie CPU może ukrywać jeden gorący rdzeń, bezczynne procesory mogą czekać na pamięć masową, a blokady lub odzyskiwanie pamięci mogą zatrzymać żądania bez wyraźnego wskaźnika wykorzystania. Metryki nasycenia o wysokiej rozdzielczości i opóźnienia na końcu wykresu pokazują, czy krytyczna praca mogła faktycznie postępować, gdy serwer był zajęty.