Wyszukiwanie w witrynie

Jak monitorować wykorzystanie systemu, awarie i rozwiązywać problemy z serwerami Linux — część 9


Chociaż Linux jest bardzo niezawodny, mądrzy administratorzy systemu powinni znaleźć sposób, aby przez cały czas mieć oko na zachowanie i wykorzystanie systemu. Zapewnienie czasu pracy możliwie najbliższego 100% oraz dostępności zasobów to krytyczne potrzeby w wielu środowiskach. Zbadanie przeszłego i obecnego stanu systemu pozwoli nam przewidzieć i najprawdopodobniej zapobiec możliwym problemom.

Przedstawiamy program certyfikacji Linux Foundation

W tym artykule przedstawimy listę kilku narzędzi dostępnych w większości dystrybucji nadrzędnych, umożliwiających sprawdzanie stanu systemu, analizowanie przestojów i rozwiązywanie bieżących problemów. W szczególności spośród niezliczonej ilości dostępnych danych skupimy się na procesorze, przestrzeni dyskowej i wykorzystaniu pamięci, podstawowym zarządzaniu procesami i analizie dzienników.

Wykorzystanie przestrzeni dyskowej

W Linuksie istnieją 2 dobrze znane polecenia używane do sprawdzania wykorzystania przestrzeni dyskowej: df i du.

Pierwszy z nich, df (co oznacza wolny od dysku), jest zwykle używany do raportowania całkowitego wykorzystania miejsca na dysku przez system plików.

Przykład 1: Raportowanie wykorzystania miejsca na dysku w bajtach i formacie czytelnym dla człowieka

Bez opcji df raportuje wykorzystanie miejsca na dysku w bajtach. Z flagą -h wyświetli te same informacje, używając zamiast tego MB lub GB. Należy pamiętać, że raport ten obejmuje również całkowity rozmiar każdego systemu plików (w blokach 1-KB), wolne i dostępne miejsce oraz punkt podłączenia każdego urządzenia pamięci masowej.

df
df -h

To z pewnością miłe – ale istnieje inne ograniczenie, które może sprawić, że system plików stanie się bezużyteczny, a mianowicie kończy się i-węzeł. Wszystkie pliki w systemie plików są mapowane na i-węzeł zawierający metadane.

Przykład 2: Sprawdzanie użycia i-węzła przez system plików w formacie czytelnym dla człowieka za pomocą
df -hTi

możesz zobaczyć ilość używanych i dostępnych i-węzłów:

Zgodnie z powyższym obrazem, w katalogu /home używanych jest 146 i-węzłów (1%), co oznacza, że w tym systemie plików nadal można utworzyć 226 KB plików.

Przykład 3: Znajdowanie i/lub usuwanie pustych plików i katalogów

Pamiętaj, że może zabraknąć miejsca w pamięci na długo przed wyczerpaniem się i-węzłów i odwrotnie. Z tego powodu należy monitorować nie tylko wykorzystanie przestrzeni dyskowej, ale także liczbę i-węzłów używanych przez system plików.

Użyj poniższych poleceń, aby znaleźć puste pliki lub katalogi (zajmujące 0B), które używają i-węzłów bez powodu:

find  /home -type f -empty
find  /home -type d -empty

Możesz także dodać flagę -delete na końcu każdego polecenia, jeśli chcesz także usunąć te puste pliki i katalogi:

find  /home -type f -empty --delete
find  /home -type f -empty

Poprzednia procedura usunęła 4 pliki. Sprawdźmy jeszcze raz liczbę używanych/dostępnych węzłów w /home:

df -hTi | grep home

Jak widać, używanych jest obecnie 142 i-węzłów (o 4 mniej niż wcześniej).

Przykład 4: Badanie wykorzystania dysku według katalogu

Jeśli użycie określonego systemu plików przekracza wstępnie zdefiniowany procent, możesz użyć du (skrót od użycia dysku), aby dowiedzieć się, które pliki zajmują najwięcej miejsca.

Przykład podano dla /var, który, jak widać na pierwszym obrazku powyżej, jest używany w 67%.

du -sch /var/*

Uwaga: możesz przejść do dowolnego z powyższych podkatalogów, aby dowiedzieć się dokładnie, co się w nich znajduje i ile zajmuje każdy element. Można następnie wykorzystać te informacje do usunięcia niektórych plików, jeśli nie są potrzebne, lub do zwiększenia rozmiaru woluminu logicznego, jeśli to konieczne.

Przeczytaj także

  1. 12 przydatnych poleceń „df” do sprawdzania miejsca na dysku
  2. 10 przydatnych poleceń „du” do sprawdzania wykorzystania dysku przez pliki i katalogi

Wykorzystanie pamięci i procesora

Klasyczne narzędzie w Linuksie, które służy do ogólnej kontroli wykorzystania procesora/pamięci i zarządzania procesami, jest najlepszym poleceniem. Dodatkowo na górze wyświetlany jest widok działającego systemu w czasie rzeczywistym. Istnieją inne narzędzia, których można użyć do tego samego celu, takie jak htop, ale zdecydowałem się na top, ponieważ jest on instalowany od razu po wyjęciu z pudełka w dowolnej dystrybucji Linuksa.

Przykład 5: Wyświetlanie aktualnego statusu systemu za pomocą przycisku top

Aby rozpocząć od góry, po prostu wpisz następujące polecenie w wierszu poleceń i naciśnij Enter.

top

Przyjrzyjmy się typowemu najlepszemu wyjściu:

W wierszach od 1 do 5 wyświetlane są następujące informacje:

1. Bieżący czas (20:41:32) i czas pracy (7 godzin i 41 minut). Do systemu zalogowany jest tylko jeden użytkownik, a średnie obciążenie z ostatnich 1, 5 i 15 minut. Wartości 0,00, 0,01 i 0,05 wskazują, że w tych przedziałach czasu system był bezczynny przez 0% czasu (0,00: żaden proces nie czekał na procesor), następnie został przeciążony o 1% (0,01: średnio 0,01 procesów czekało na procesor) i 5% (0,05). Jeśli jest mniejsza niż 0 i mniejsza liczba (na przykład 0,65), system był bezczynny przez 35% w ciągu ostatnich 1, 5 lub 15 minut, w zależności od tego, gdzie pojawia się wartość 0,65.

2. Obecnie uruchomionych jest 121 procesów (pełną listę można zobaczyć w 6). Tylko 1 z nich działa (w tym przypadku na górze, jak widać w kolumnie %CPU), a pozostałych 120 czeka w tle, ale „śpi” i pozostanie w tym stanie, dopóki ich nie wywołamy. Jak? Możesz to sprawdzić, otwierając wiersz mysql i wykonując kilka zapytań. Zauważysz, jak wzrasta liczba uruchomionych procesów.

Alternatywnie możesz otworzyć przeglądarkę internetową i przejść do dowolnej strony obsługiwanej przez Apache, a otrzymasz ten sam wynik. Oczywiście w tych przykładach założono, że obie usługi są zainstalowane na Twoim serwerze.

3. us (czasowo działające procesy użytkownika o niezmodyfikowanym priorytecie), sy (czasowo działające procesy jądra), ni (czasowo działające procesy użytkownika ze zmodyfikowanym priorytetem), wa (czas oczekiwania na zakończenie operacji we/wy), hi (czas spędzony na obsłudze przerwań sprzętowych), si (czas spędzony na obsłudze przerwań programowych), st (czas skradziony z aktualnej maszyny wirtualnej przez hypervisor – tylko w środowiskach zwirtualizowanych).

4. Użycie pamięci fizycznej.

5. Zamień wykorzystanie przestrzeni.

Przykład 6: Sprawdzanie użycia pamięci fizycznej

Aby sprawdzić użycie pamięci RAM i zamiany, możesz także użyć polecenia free.

free

Oczywiście możesz także użyć przełączników -m (MB) lub -g (GB), aby wyświetlić te same informacje w formie czytelnej dla człowieka:

free -m

Tak czy inaczej trzeba mieć świadomość, że jądro rezerwuje jak najwięcej pamięci i udostępnia ją procesom, gdy o to poproszą. W szczególności linia „-/+ bufory/pamięć podręczna” pokazuje rzeczywiste wartości po uwzględnieniu pamięci podręcznej we/wy.

Innymi słowy, ilość pamięci wykorzystywanej przez procesy i ilość dostępna dla innych procesów (w tym przypadku odpowiednio 232 MB wykorzystane i 270 MB dostępne). Kiedy procesy potrzebują tej pamięci, jądro automatycznie zmniejszy rozmiar pamięci podręcznej we/wy.

Przeczytaj także: 10 przydatnych „bezpłatnych” poleceń do sprawdzania użycia pamięci w systemie Linux

Bliższe spojrzenie na procesy

W dowolnym momencie w naszym systemie Linux działa wiele procesów. Do dokładnego monitorowania procesów będziemy używać dwóch narzędzi: ps i pstree.

Przykład 7: Wyświetlanie całej listy procesów w systemie za pomocą ps (pełny standardowy format)

Używając opcji -e i -f połączonych w jedną (-ef) możesz wyświetlić listę wszystkich procesów aktualnie uruchomionych w Twoim systemie. Możesz przesłać te dane wyjściowe do innych narzędzi, takich jak grep (jak wyjaśniono w części 1 serii LFCS), aby zawęzić dane wyjściowe do żądanych procesów:

ps -ef | grep -i squid | grep -v grep

Powyższa lista procesów zawiera następujące informacje:

właściciel procesu, PID, nadrzędny PID (proces nadrzędny), wykorzystanie procesora, czas uruchomienia polecenia, tty (? wskazuje, że jest to demon), skumulowany czas procesora i polecenie skojarzone z procesem.

Przykład 8: Dostosowywanie i sortowanie danych wyjściowych ps

Być może jednak nie potrzebujesz wszystkich tych informacji i chciałbyś pokazać właściciela procesu, polecenie, które go uruchomiło, jego PID i PPID oraz procent aktualnie używanej pamięci – w tej kolejności i posortuj według wykorzystanie pamięci w kolejności malejącej (zwróć uwagę, że ps jest domyślnie sortowane według PID).

ps -eo user,comm,pid,ppid,%mem --sort -%mem

Gdzie znak minus przed %mem oznacza sortowanie w kolejności malejącej.

Jeśli z jakiegoś powodu proces zaczyna zużywać zbyt dużo zasobów systemowych i może zagrozić ogólnej funkcjonalności systemu, będziesz chciał zatrzymać lub wstrzymać jego wykonanie, przekazując mu jeden z następujących sygnałów za pomocą programu zabijającego. Innym powodem, dla którego warto to zrobić, jest sytuacja, gdy rozpocząłeś proces na pierwszym planie, ale chcesz go wstrzymać i wznowić w tle.

Signal name Signal number Description
 SIGTERM 15  Kill the process gracefully.
 SIGINT 2  This is the signal that is sent when we press Ctrl + C. It aims to interrupt the process, but the process may ignore it.
 SIGKILL 9  This signal also interrupts the process but it does so unconditionally (use with care!) since a process cannot ignore it.
 SIGHUP 1  Short for “Hang UP”, this signals instructs daemons to reread its configuration file without actually stopping the process.
 SIGTSTP 20  Pause execution and wait ready to continue. This is the signal that is sent when we type the Ctrl + Z key combination.
 SIGSTOP 19  The process is paused and doesn’t get any more attention from the CPU cycles until it is restarted.
 SIGCONT 18  This signal tells the process to resume execution after having received either SIGTSTP or SIGSTOP. This is the signal that is sent by the shell when we use the fg or bg commands.
Przykład 9: Wstrzymywanie wykonywania uruchomionego procesu i wznawianie go w tle

Kiedy normalne wykonanie określonego procesu oznacza, że podczas jego działania na ekran nie zostaną przesłane żadne dane wyjściowe, możesz chcieć uruchomić go w tle (dodając znak ampersand na końcu polecenia).

process_name &

lub
Gdy zacznie działać na pierwszym planie, zatrzymaj go i wyślij do tła

Ctrl + Z
kill -18 PID

Przykład 10: Zabijanie na siłę, proces „oszalał”

Należy pamiętać, że każda dystrybucja zapewnia narzędzia do bezpiecznego zatrzymywania/uruchamiania/restartowania/przeładowywania typowych usług, takich jak usługa w systemach opartych na SysV lub systemctl w systemach opartych na Systemd.

Jeśli proces nie odpowiada na te narzędzia, możesz go zabić siłą, wysyłając do niego sygnał SIGKILL.

ps -ef | grep apache
kill -9 3821

A więc... Co się stało/dzieje?

Kiedy w systemie nastąpiła jakakolwiek przerwa (czy to przerwa w dostawie prądu, awaria sprzętu, planowane lub nieplanowane przerwanie procesu, czy też jakakolwiek nieprawidłowość), dzienniki znajdują się w /var/log są Twoimi najlepszymi przyjaciółmi, aby ustalić, co się stało lub co może być przyczyną problemów, z którymi się borykasz.

cd /var/log

Niektóre elementy w /var/log to zwykłe pliki tekstowe, inne to katalogi, a jeszcze inne to skompresowane pliki obróconych (historycznych) dzienników. Będziesz chciał sprawdzić te, które mają w nazwie słowo błąd, ale sprawdzenie pozostałych może się również przydać.

Przykład 11: Sprawdzanie logów pod kątem błędów w procesach

Wyobraź sobie ten scenariusz. Klienci sieci LAN nie mogą drukować na drukarkach sieciowych. Pierwszym krokiem do rozwiązania tej sytuacji jest przejście do katalogu /var/log/cups i sprawdzenie, co tam jest.

Możesz użyć polecenia tail, aby wyświetlić ostatnie 10 linii pliku dziennika błędów, lub tail -f dziennik_błędów, aby wyświetlić dziennik w czasie rzeczywistym.

cd /var/log/cups
ls
tail error_log

Powyższy zrzut ekranu zawiera przydatne informacje, które pomogą zrozumieć, co może być przyczyną problemu. Pamiętaj, że wykonanie poniższych kroków lub skorygowanie nieprawidłowego działania procesu może nadal nie rozwiązać ogólnego problemu, ale jeśli od samego początku przyzwyczaisz się do sprawdzania dzienników za każdym razem, gdy pojawi się problem (czy to lokalny, czy sieciowy), możesz z pewnością będzie na dobrej drodze.

Przykład 12: Sprawdzanie dzienników pod kątem awarii sprzętu

Chociaż awarie sprzętu mogą być trudne do rozwiązania, powinieneś sprawdzić dmesg i dzienniki komunikatów oraz grep pod kątem słów powiązanych z częścią sprzętową, która jest uznawana za wadliwą.

Poniższy obraz pochodzi z /var/log/messages po wyszukaniu słowa błąd za pomocą następującego polecenia:

less /var/log/messages | grep -i error

Widzimy, że mamy problem z dwoma urządzeniami pamięci masowej: /dev/sdb i /dev/sdc, co z kolei powoduje problem z macierzą RAID.

Wniosek

W tym artykule omówiliśmy niektóre narzędzia, które mogą pomóc Ci zawsze mieć świadomość ogólnego stanu systemu. Ponadto musisz upewnić się, że Twój system operacyjny i zainstalowane pakiety zostały zaktualizowane do najnowszych stabilnych wersji. I nigdy, przenigdy nie zapomnij sprawdzić dzienników! Następnie udasz się we właściwym kierunku, aby znaleźć ostateczne rozwiązanie wszelkich problemów.

Zachęcamy do pozostawiania komentarzy, sugestii lub pytań – jeśli je masz – za pomocą poniższego formularza.