Jak monitorować obciążenie serwera bez zgadywania
Opublikowano 14 lipca 2026
Serwer rzadko wysyła uprzejme ostrzeżenie, zanim przeciążona witryna zacznie przekraczać limit czasu odpowiedzi. Znacznie częściej ktoś zauważa, że panel WordPress działa wolno, strona kasy się zawiesza albo dostarczanie e-maili zaczyna się opóźniać. Wiedza o tym, jak monitorować obciążenie serwera, daje ci szansę zauważyć narastające przeciążenie, zanim zrobią to odwiedzający.
Obciążenie serwera to nie jedna liczba, na którą można rzucić okiem i o niej zapomnieć. To obraz złożony z zapotrzebowania na CPU, dostępnej pamięci, aktywności dysku, ruchu sieciowego i procesów konkurujących o zasoby. Jeśli odczytasz te sygnały łącznie, możesz odróżnić zwykły skok ruchu od serwera, który potrzebuje pomocy.
Co faktycznie mierzy obciążenie serwera
W systemie Linux load average mierzy liczbę zadań, które są gotowe do uruchomienia na CPU albo czekają w stanie nieprzerywalnym, często dlatego, że oczekują na operacje wejścia/wyjścia dysku. Zwykle zobaczysz trzy wartości reprezentujące średnie obciążenie z ostatniej 1, 5 i 15 minut.
Wartość taka jak `0.60, 0.80, 1.20` nie jest automatycznie dobra ani zła. Sensowne porównanie dotyczy obciążenia i liczby rdzeni CPU dostępnych dla serwera. Na serwerze z jednym rdzeniem CPU utrzymujące się obciążenie 1.00 oznacza, że rdzeń jest w pełni zajęty. Na serwerze czterordzeniowym obciążenie 1.00 jest zwykle komfortowe, ponieważ nadal dostępna jest rezerwa mocy.
Nawet od tej reguły jest wyjątek. Wysokie load average przy niskim użyciu CPU może wskazywać raczej na oczekiwanie na dysk niż na presję na procesor. Dlatego monitorowanie wyłącznie load average może skierować cię w złą stronę. Liczba mówi ci, że praca czeka. Otaczające ją metryki mówią ci dlaczego.
Jak monitorować obciążenie serwera we właściwych miejscach
Zacznij od widoku monitorowania, który pozwala sprawdzać bieżącą aktywność i ostatnie trendy. Dane w czasie rzeczywistym pomagają podczas incydentu, a wykresy historyczne pomagają odpowiedzieć na bardziej użyteczne pytanie: czy zdarzyło się to raz, czy dzieje się to codziennie o 2:00 p.m.?
Panel sterowania z monitorowaniem serwera w czasie rzeczywistym ułatwia to właścicielom witryn i zespołom, które nie chcą trzymać terminala otwartego przez cały dzień. W FASTPANEL zasoby serwera można przeglądać obok witryn i kont, które z nich korzystają, co ogranicza pracę detektywistyczną, gdy jeden projekt zaczyna zużywać więcej niż swoją część.
Aby przyjrzeć się temu bliżej w systemie Linux, dobrze znane polecenia nadal wykonują świetną robotę. `uptime` szybko pokazuje load average. `top` lub `htop` pokazuje procesy, które w tej chwili używają CPU i pamięci. `free -m` pomaga ocenić użycie pamięci i swapu, a `df -h` pokazuje, czy pełny system plików dokłada się do problemu. Do sprawdzania aktywności dysku przydatne są `iostat` i `iotop`, jeśli są zainstalowane.
Najlepsza konfiguracja wykorzystuje oba podejścia: przejrzysty panel do codziennej obserwacji i kontrolę z wiersza poleceń, gdy trzeba sprawdzić konkretny proces, zapytanie, zadanie kopii zapasowej lub zdarzenie ruchu.
Obserwuj te sygnały łącznie
Gdy otwierasz ekran monitorowania serwera, skup się na tych powiązanych sygnałach:
- Wykorzystanie CPU i load average pokazują, czy procesy konkurują o czas procesora.
- Użycie pamięci i aktywność swapu ujawniają, czy serwerowi kończy się RAM i czy przenosi dane do wolniejszej pamięci dyskowej.
- Miejsce na dysku, oczekiwanie I/O i przepustowość dysku pomagają zidentyfikować pełne dyski lub pamięć masową, która nie nadąża z odczytem i zapisem.
- Ruch sieciowy i liczba połączeń pokazują, czy presję na usługi webowe wywiera uzasadniony popyt, boty czy nagły wzrost ruchu.
- Najbardziej obciążające procesy pokazują, która usługa, użytkownik, witryna lub zaplanowane zadanie stoi za tą aktywnością.
Wysoki procent użycia CPU podczas premiery produktu może być czymś oczekiwanym. Wysokie oczekiwanie I/O przy umiarkowanym użyciu CPU to inna historia, często związana z kopiami zapasowymi, pracą bazy danych, rotacją logów lub przeciążonym woluminem pamięci masowej. Celem nie jest panika na widok czerwonej linii. Celem jest znalezienie wąskiego gardła.
Najpierw ustal normalny poziom odniesienia
Przydatne alerty zależą od wiedzy, jak wygląda normalne zachowanie twojego serwera. Witryna małej firmy może przez większość dnia działać spokojnie i mieć skok obciążenia podczas zaplanowanego importu. Dostawca hostingu może mieć stałą aktywność na dziesiątkach kont. Ruchliwy serwer agencji może notować przewidywalne szczyty za każdym razem, gdy ruszają kampanie klientów.
Śledź dane przez co najmniej dwa do czterech tygodni, zanim uznasz każdy wzrost za incydent. Szukaj wzorców w obciążeniu, CPU, pamięci, dyskowym I/O i ruchu. Dopasuj te wzorce do znanych zdarzeń: kopii zapasowych, zadań cron, aktualizacji wtyczek, zadań raportowych lub godzin największego ruchu odwiedzających.
Taki poziom odniesienia zapobiega dwóm częstym błędom. Pierwszy polega na ustawieniu alertów tak nisko, że stają się szumem w tle. Drugi polega na akceptowaniu powtarzającego się spowolnienia tylko dlatego, że stało się znajome. Jeśli obciążenie osiąga 6 każdej nocy na czterordzeniowym serwerze, a witryny pozostają szybkie, może to być do opanowania. Jeśli ten sam wzorzec zbiega się z wolnymi zapytaniami bazy danych i wydłużającym się czasem odpowiedzi, wymaga uwagi.
Ustaw alerty, które prowadzą do działania
Alert powinien mówić komuś, aby sprawdził konkretny stan, a nie tylko ogłaszać, że serwer istnieje. Ustaw progi na podstawie czasu trwania, a nie tylko wartości. Krótki skok użycia CPU jest normalny. CPU powyżej 90% przez 15 minut daje więcej informacji. Ta sama zasada dotyczy pamięci, użycia dysku i load average.
Używaj reguł alertów dla utrzymującego się wysokiego obciążenia względem liczby rdzeni CPU, wysokiego użycia CPU, małej ilości dostępnej pamięci, rosnącego aktywnego swapu, wysokiego oczekiwania na dyskowe I/O oraz dysków zbliżających się do granicy pojemności. Miejsce na dysku zasługuje na wcześniejsze ostrzeżenie, niż oczekuje większość zespołów. Czekanie, aż wolumin będzie zapełniony w 100%, zamienia proste czyszczenie w awarię usługi.
Gdzie to możliwe, uwzględnij w alercie kontekst: serwer, którego dotyczy problem, bieżące obciążenie, stan pamięci, wykorzystanie dysku i czas rozpoczęcia tego stanu. Jeśli alerty przychodzą bez kontekstu, ludzie spędzają pierwsze dziesięć minut na ustalaniu, co alert właściwie oznacza. To nie jest monitorowanie. To administracyjne cardio.
Analizuj wysokie obciążenie bez zgadywania
Gdy obciążenie rośnie, zacznij od najkrótszej drogi do dowodów. Sprawdź, czy użycie CPU również jest wysokie. Jeśli tak, posortuj uruchomione procesy według użycia CPU i zidentyfikuj odpowiedzialną usługę. Procesy robocze serwera WWW, procesy PHP, zapytania bazy danych, skanowanie malware i źle zaplanowane zadania cron to częste źródła.
Jeśli obciążenie jest wysokie, ale użycie CPU nie, sprawdź oczekiwanie I/O i aktywność dysku. Kopia zapasowa zapisująca wiele plików, baza danych przebudowująca indeks albo prawie pełny dysk mogą sprawić, że procesy będą czekać, nawet gdy dostępna jest moc CPU. Sprawdź miejsce w systemie plików, przejrzyj ostatnie zaplanowane zadania i poszukaj nietypowo intensywnej aktywności odczytu lub zapisu.
Następnie sprawdź pamięć. Mała ilość dostępnego RAM i utrzymujące się użycie swapu mogą sprawić, że każda usługa będzie wydawała się wolna, ponieważ serwer stale przenosi strony pamięci między RAM a dyskiem. Ponowne uruchomienie usługi może dać krótką przerwę, ale nie naprawi aplikacji, która potrzebuje więcej pamięci, procesu wymykającego się spod kontroli ani serwera, który jest po prostu zbyt mały jak na swoje obciążenie.
Na końcu przyjrzyj się ruchowi i połączeniom. Nagły wzrost może być dobrą wiadomością, na przykład skuteczną kampanią, albo czymś mniej pożądanym, jak agresywne boty uderzające w strony logowania. Logi dostępu do sieci Web, liczba połączeń i widoki zasobów dla poszczególnych witryn pomagają oddzielić rzeczywiste zapotrzebowanie odwiedzających od niechcianego szumu.
Napraw przyczynę, nie wykres
Właściwa reakcja zależy od wąskiego gardła. W przypadku presji na CPU zoptymalizuj kosztowny kod aplikacji, buforuj powtarzalną pracę, dostrój procesy robocze PHP albo przenieś cykliczne zadania poza godziny szczytu. W przypadku presji na bazę danych zbadaj wolne zapytania, brakujące indeksy i limity połączeń, zanim dodasz więcej zasobów serwera.
W przypadku presji związanej z dyskiem usuń niepotrzebne pliki, upewnij się, że kopie zapasowe nie konkurują z ruchem odwiedzających, i użyj szybszej pamięci masowej, jeśli wymaga tego obciążenie. W przypadku presji na pamięć ogranicz marnotrawne usługi, ostrożnie dostosuj limity aplikacji albo zwiększ RAM. Skalowanie w górę może być właściwym ruchem, ale powinno wynikać z danych, a nie z frustracji.
Warto też rozważyć izolację kont na serwerach współdzielonych lub obsługujących wiele witryn. Jedna źle zoptymalizowana witryna nie powinna móc zamienić każdej innej strony w powolne przeprosiny. Widoczność per konto znacznie ułatwia zidentyfikowanie źródła i ustawienie uczciwych limitów tam, gdzie są potrzebne.
Kontynuuj monitorowanie po naprawie
Po wprowadzeniu zmiany obserwuj te same metryki podczas kolejnego okresu wzmożonego ruchu. Niższe load average jest zachęcające, ale liczą się też czasy odpowiedzi, wskaźniki błędów i doświadczenie użytkownika. Serwer może wyglądać na spokojniejszy, podczas gdy kolejka bazy danych lub błąd aplikacji nadal pozostają.
Dobre monitorowanie polega mniej na wpatrywaniu się w wykresy, a bardziej na budowaniu pewności: wiesz, jak wygląda norma, otrzymujesz przydatne ostrzeżenia i masz jasny kolejny krok, gdy coś zaczyna zachowywać się kreatywnie. W ten sposób zarządzanie serwerem staje się rutynową częścią prowadzenia witryn, a nie powodem, przez który znika ci wieczór.