Mamy już zainstalowany system. Skonfigurowaliśmy go do pełnienia szeregu ról. Z czasem jednak okazuje się, że nie wszystko działa jak należy. A to ktoś się skarży, że poczto wolno działa, a to ktoś inny się skarży, że kopiowanie się zrywa, a jeszcze ktoś inny z firmy partnerskiej narzeka, że czasami nie może się połączyć przez VPN. Aby zaradzić takim sytuacjom, a najlepiej w ogóle sie przed nimi ustrzec, należy system regularnie monitorować.
Co możemy sprawdzić?
- Czy start systemu przebiegł poprawnie?
- Konfigurację sprzętową
- Aktualne obciążenie systemu?
- Stan dysków
Start systemu
Tutaj mamy w zasadzie dwa sposoby:
- plik /var/log/boot.msg, który jest nieco rozszerzoną wersją tego, co pojawia się na ekranie podczas startu systemu,
- polecenie dmesg, które formalnie wyświetla bufor warstwy jądra systemum, ale w praktyce możemy prześledzić jak przebiegał start systemu.
Zwykle zawartość pliku /var/log/boot.msg jest bardziej obszerna od wyniku polecenia dmesg. Plik boot.msg możemy także obejrzeć za pomocą konsoli YaST: Miscellaneous > View Start-up Log.
Informacja o sprzęcie
Informacje o sprzęcie możemy uzyskać z plików z katalogu /proc oraz za pomocą poleceń. Najpierw przejrzyjmy pliki:
- /proc/cpuinfo — informacja o procesorze
- /proc/meminfo — informacja o pamięci operacyjnej
- /proc/devices — urządzenia używane w systemie
- /proc/ioports — porty wejścia/wyjścia (I/O)
- /proc/interrupts — lista IRQ
- /proc/dma — kanały DMA
- /proc/bus/pci/devices — urządzenia PCI
- /proc/scsi/scsi — urządzenia SCSI
Natomiast polecenia są następujące:
- hwinfo — generuje spore podsumowanie o sprzęcie. Możemy też dodać parametry, np. --short (skrócone podsumowanie) lub --log plik (wtedy wynik będzie przekierowany do pliku):
# hwinfo | less # hwinfo --short # hwinfo --log raport.txt
- hdparm — pozwala obejrzeć lub ustawić parametry dysków
- fdisk — pozwala obejrzeć partycje oraz zarządzać nimi
- iostat — pokazuje statystyki użycie urządzeń pod kątem operacji wejścia/wyjścia
- lspci — lista urządzeń PCI; opcje -v i -vv pozwalają na ujawnienie nieco więcej szczegółów
- siga — polecenie generujące raport o stanie systemu (w tym konfiguracji np. usług)
- sitar — kolejne polecenia generujące raporty o stanie systemu, w tym przypadku na podstawie plików /proc
- df, du — pozwala ustalić zużycie miejsca na dysku
Niektórym z powyższych poleceń przyjrzymy się bardziej dokładnie, jak będziemy chcieli poprawiać niektóre z ustawień.
Oczywiście podstawowym źródłem informacji o działaniu usług i systemu oraz związanymi z nimi problemami jest system logowania (dziennik zdarzeń), czyli podsystem syslog-ng. Ale to zostanie omówione w oddzielnym artykule.
No dobrze, ale co konkretnie możemy ustalić?
Analiza zużycia procesora
Przede wszystkim sprawdzamy stan zużycia procesora i jeśli jest nadmierny, próbujemy ustalić, które procesy wykorzystują go najbardziej. Zwykle jest tak, że taki proces będzie 1 lub będą 2, 3. Mamy tutaj polecenia top, uptime, ewentualnie program KDE System Guard (ksysguard), który w bardzo przystępnej formie prezentuje dane (będzie on zresztą rekomendowany również w innych sytuacjach).
Analiza zużycia pamięci
Kolejna kwestia to ilość pamięci RAM oraz partycja wymiany. Sporo możemy się dowiedzieć z pliku /proc/meminfo, ale bardziej przejrzyste są wyniki polecenie free:
# free
total used free shared buffers cached
Mem: 588800 582860 5940 0 77528 336392
-/+ buffers/cache: 168940 419860
Swap: 1164672 112 1164560
Zatrzymajmy się chwilę nad powyższymi wynikami. Znaczenie kolumn jest następujące:
- total — sumaryczna dostępna ilość pamięci
- used — aktualnie wykorzystana ilość pamięci
- free — wolna ilość pamięci
- buffers/cached — ilość pamięci wykorzystana przez programy do buforowania swoich danych, jednak nie niezbędna do ich poprawnego działania (można by rzec "czynności operacyjnych")
Pierwsze łatwe spostrzeżenie jest takie, że total=used+free, drugie, że buffers+cached<used. Wiersz Mem dotyczy pamięci fizycznej, a Swap wirtualnej, czyli partycji wymiany. Co zatem oznacza środkowy wiersz?
W większości nowoczesnych systemów operacyjnych, przez prawie cały czas działania systemu ilość wolnej pamięci RAM jest zwykle bardzo mała. Wynika to z faktu, że dysk jest dużo wolniejszy od pamięci RAM i jeśli to tylko możliwe, programy buforują dane z dysku w pamięci RAM. Jednak jeśli tylko pamięć jest potrzebna, program może bufor zwolnić i znowu korzystać z dysku. Wracając do środkowego wiersza, kolumny mają następujące znaczenie: used(w2) = used(w1)-(buffers+cached), free(w2)=free(w1)+(buffers+cached) (w1 i w2 oznaczają wiersz 1 i wiersz 2). Warto zauważyć, że kiedy chcemy określić faktyczną ilość wolnej pamięci RAM, to wiersz 2 wyniku jest najbardziej miarodajny, gdyż określa ile aplikacje faktycznie mają RAMu do dyspozycji, a nie ile jest go wolnego w danej chwili.
Jeśli wolnego RAMu jest mało, możemy ustalać winnego poleceniem top. Domyślnie wyniki są sortowane wg zużycia procesora, więc wprowadzamy kolejno F, n, Enter, no i mamy posortowane po zużyciu pamięci.
Kolejną rzeczą, którą możemy sprawdzić, to ilość danych przenoszonych pamiędzy pamięcią fizyczną RAM a partycją wymiany. Wykorzystujemy do tego polecenie vmstat. Przykładowo:
# vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 342312 55720 281728 0 0 4 2 260 193 0 0 100 0 0 1 0 0 342312 55720 281728 0 0 0 0 272 173 0 0 100 0 0 0 0 0 342312 55720 281728 0 0 0 0 252 178 0 1 99 0 0 0 0 0 342312 55720 281728 0 0 0 0 271 187 0 0 100 0 0 0 0 0 342312 55720 281728 0 0 0 24 256 171 0 0 98 2 0
(opcja 1 oznacza generowanie kolejnego wyniku co sekundę). To co nas interesuje to kolumny si i so, które oznaczają kolejno ilość danych przeniesionych z dysku do pamięci oraz ilość danych przeniesionych z pamięci na dysk. Najlepiej, jeśli są tam same zera, jednak jeśli jest tam sporo niemałych wartości, warto się zastanowić nad przyczyną.
Podsumowując, do zbadania zużycia pamięci operacyjnej mamy:
- polecenie free
- polecenie vmstat, kolumny si i so
- program ksysguard
Analiza wydajności dysków
Po sprawdzeniu procesora i pamięci, możemy przyjrzeć się zużyciu dysków twardych. Pierwszym sposobem jest użycie polecenia z poprzedniej analizy, czyli
# vmstat 1
Tym razem jednak patrzymy na kolumny bi (czytanie) i bo (zapisywanie). Jeśli są tam duże liczby, mamy powód do niepokoju.
Kolejne polecenie to iostat (składowa pakietu sysstat). W poleceniu
# iostat -x 1 /dev/sda
opcje i parametry mają następujące znaczenie: -x — dodatkowe informacje, 1 — odświeżanie co sekundę, /dev/sda — statystyki mają dotyczyć wybranego dysku (bez podania tego, wszystkie dyski będą analizowane). Wynik zawiera sporo różnych informacji, nas jednak interesują przede wszytkich 2 kolumny:
- await — średni łączny czas obsługi żądania operacji I/O (w milisekundach); obejmuje to czas spędzony w kolejce oraz czas wykonania operacji I/O,
- svctm — średni łączny czas wykonania operacji I/O.
Podobnie jak wyżej, jeśli te czasy są duże, co więcej, jeśli czas await jest istotnie większy od svctm, jest powód, żeby drążyć tą kwestię dalej.
Podsumowując, do zbadania wydajności dysków mamy:
- polecenie vmstat, kolumny bi i bo
- polecenie iostat
Analiza wydajności sieci
Tutaj najprostszym w obsłudze narzędziem jest ksysguard. Odpalamy, a następnie znajdujemy Network, Intefaces i wskazujemy interfejs sieciowy. Liczniki mamy pogrupowane na "receiver" i "transmitter". Po prawej stronie zwalniamy miejsce i przeciągamy:
- Data — ilość odebranych lub wysłanych danych
- Packets — liczba odebranych lub wysłanych pakietów
- Collisions — liczba kolizji (dostępne tylko dla nadajnika), zbyt duża negatywnie wpływa na wydajność
- Dropped Packets — liczba odrzuconych pakietów, zbyt duża ich liczba negatywnie wpływa na wydajność; przyczyn może być wiele, te najistotniejsze to:
- poszczególne składowe sieci działają na różnych szybkościach, np. karta sieciowa w 1Gb a router w 10Mb,
- reguły na firewallu powodują odrzucanie pakietów.
- Errors — liczba błędów.
Problemy z siecią mogą także wynikach z błędnie działających usług, uruchomionych nawet niekoniecznie na komputerze, gdzie problemy się pojawiają. Typowe sytuacje:
- problemy z serwerem DNS — wiele usług zależy do rozwiązywania nazw i jeśli ta część systemu nawala, może spowalniać działanie wielu programów,
- problemy z serwerem Proxy — podobonie, programy zależące od serwera proxy, również mogą działać nieprawidłowo w przypadku, gdy usługa proxy nawala,
- NFS, Samba — kolejnym kluczowym elementów są usługi plików, od których może zależeć wiele innych usług i programów.
Podsumowując, do zbadania wydajności sieci mamy:
- program ksysguard (tutaj najprościej)
- polecenie ip
Jak zmniejszyć obciążenie procesora i wykorzystanie pamięci?
Kilka elementów, które można wykonać.
- Sprawdzić, które programy powodują nadmierne wykorzystanie pamięci. Być może są one źle napisane i jest możliwe ich poprawienie lub znalezienie zamienników.
- Sprawdzić, czy uruchomione jest tylko wykorzystywane oprogramowanie, głównie chodzi tutaj o:
- System X. W przypadku serwera zwykle okienka nie są potrzebne. Wtedy albo ręcznie odpalamy
# init 3
lub w pliku /etc/inittab wiersz initdefault poprawiamy na następujący:id:3:initdefault:
- Przegląd usług uruchamianych przy starcie. Mamy do tego polecenie chkconfig.
- System X. W przypadku serwera zwykle okienka nie są potrzebne. Wtedy albo ręcznie odpalamy
- Dbać zawsze o bieżące aktualizacje oprogramowania.
- Rozdzielić partycje swap na wiele dysków. Wtedy wpisy w pliku /etc/fstab mogłyby wyglądać tak:
/dev/sda1 swap swap pri=1 0 0 /dev/sdb1 swap swap pri=1 0 0
(pri=1 nadają ten sam priorytet obu partycjom) - Poprawić parametry techniczne, np. wymienić/zainstalować procesor, dodać pamięci RAM. Często dodanie pamięci RAM jest niezbyt kosztowne, a szybko potrafi zwiększyć efektywność całego systemu.
Poprawa wydajności dysków
Dla dysków IDE można przede wszystkim włączyć DMA, chociaż domyślnie powinien być włączony:
# hdparm -d /dev/hda # hdparm -d 1 /dev/hda(najpierw sprawdzamy stan, a potem włączamy DMA). Ogólnie, hdparm pozwala na ustawienie szeregu parametrów dysków IDE. Dla dysków SCSI i SATA należy używać polecenia sdparm (krótkie wprowadzenie: http://sg.danny.cz/sg/sdparm.html). Można też przetestować wydajność poleceniem
# hdparm -t /dev/sda
Są jeszcze 3 parametry, które można dopasowywać w naszym systemie. Zmiany, które będzie robić, będą dostępne tylko podczas działania systemu, więc jeśli chcemy, żeby były również dostępne po restarcie systemu, należy je dopisać do pliku /etc/init.d/boot.local
IO Scheduler
Jest to podsystem, który zbiera żądania operacji na dysku i optymalizuje kolejność ich wykonania. My mamy do dyspozji parametr określający długość długość kolejki, która będzie optymalizowana. Dobór parametrów na następujące przełożenie:
- mniejsza wartość = krótsze oczekiwanie, ale mniejsza przepustowość,
- większa wartość = dłuższe oczekiwanie, ale większa przepustowość.
echo 6 > /sys/block/sda/queue/iosched/quantum
Przy mało obciążonych systemach zmiana parametru pewnie wiele nie zmieni, ale przy bardzo obciążonych systemach, może się udać coś poprawić.
Parametr Read-ahead
Kolejny parametr określa o ile więcej będzie przeczytanych danych od tego, czego żąda aplikacja. Ma to znaczenie, gdyż aplikacja zwyle nie czyta tylko początku pliku, ale zwykle cały plik. Tutaj również mamy syutację, że im większy parametr, tym większa przepustowość, ale większe opóźnienia (ryzyko: być może przeczytamy niepotrzebnie). W SLES 10 jest to domyślnie 512KB i możemy to zmienić poleceniem:
# echo 256 > /sys/block/sda/queue/read_ahead_kb
Parametr swappiness
Parametr ten określa jak bardzo będzie wykorzystywana partycja wymiany w skali 0-100 (0 — w ogóle nie bedzie wykorzystywana). W SLES 10 domyślnie jest to 60, co przy obecnej dostępności pamięci RAM wydaje się za dużą wartością. Możemy ją zmienić następująco:
# echo 20 > /proc/sys/vm/swappiness
Wyłączenie aktualizacji atime
Dla każdego pliku przechowywane są następujące informacje:
- moment utworzenia pliku (ctime)
- moment ostatniej modyfikacji (mtime)
- moment ostatniego dostępu (atime)
Czyli za każdym razem kiedy np. plik jest odczytywany, trzeba zaktualizować jego atime. Jeśli atime nie jest nam potrzebny, możemy te aktualizacje wyłączyć. Wystarczy wśród opcji montowania w pliku fstab (lub przy ręcznym montowaniu) dopisać noatime.
Opcja notail (tylko reiserfs)
W tradycyjnych systemach plików zawsze wykorzystywane są całe bloki do przechowania nawet małej ilości danych (wtedy reszta bloku jest marnowana). W reiserfs domyślnie te reszty nie są marnowane, ale wpływa to negatywnie na wydajność systemu. Możemy przy montowaniu użyć opcji notail, która włączy z powrotem marnowanie tych resztek, jednak dzięki temu zwiększy nam to wydajność systemu.
Tryb journalingu (tylko ext3)
Partycja ext3 daje różne poziomy journalingu:
- data=journal
- data=ordered
- data=writeback
od najbardziej do najmniej bezpiecznego. Domyślnie włączony jest data=journal. Możemy to przestawić na data=writeback (dokładnie taki parametr dopisujemy do parametrów montowania), to zwiększy wydajność, a jednocześnie nadal jesteśmy w pewien sposób zabezpieczeni na wypadek awarii systemu.
Poprawa wydajności sieci
To co przede wszystkim wpływa na wydajność sieci to użyty sprzęt i okablowanie. Niemniej w linuksie jest kilka parametrów, których przestawienie może poprawić wydajność systemu.
- sysctl -w net.ipv4.tcp_rw_recycle=1. Po zakończeniu połączenia TCP gniazdo przechodzi w stan TIME_WAIT, w którym to stanie jest zablokowane do ponownego użycia. Żeby móc szybko ponownie użyć takie gniazdo, ustawiamy tą opcję. Uwaga: pewnych sytuacjach włączenie tej opcji może doprowadzać do niestabilności, należy więc włączenie tej opcji dobrze przemyśleć.
- sysctl -w net.ipv4.tcp_rw_reuse=1. Znaczenie j.w., przy czym jest to tak jakby "bezpieczeniejsza wersja" powyższej opcji.
- sysctl -w net.ipv4.tcp_keepalive_time=400. Określamy czas, przez który system sprawdza, czy druga strona połączenia jest osiągalna (połączenie jest nawiązane), domyślnie 900. Zmniejszenie tego czasu redukuje liczbę otwartych i nieużywanych połączeń.
Więcej parametrów można obejrzeć tutaj: http://www.speedguide.net/articles/linux-tweaking-121
Powertweak
Na koniec warto polecić narzędzie o nazwie powertweak. Jest to frontend do licznych opcji dostępnych w /proc. Co więcej, przy każdej opcji jest krótki komentarz do czego służy. Uruchamiamy YaST -> Powertwak.