Debug pamięci w Linuksie (pamięć od strony technicznej)
Artykuł ten będzie traktował o debugingu pamięci operacyjnej w środowisku GNU/Linux. I w zasadzie nie jest przeznaczony dla ZU (choć starałem się opisać to w jak najprzystępniejszy sposób) :-), adresowany jest głównie do programistów oraz tzw. hackerów jądra - osób, które mają udział w procesie powstawania jądra systemu GNU/Linux. Na początek garść potrzebnej teorii.
Wszystkie programy korzystają z pamięci operacyjnej (nawet te, które pozornie nic nie robią lub też ich nie widzimy). Zła implementacja zarządzania pamięcią w programie skutkuje zazwyczaj poważnymi błędami, wyciekami oraz niestabilnym działaniem. Postaram opisać się pokrótce takie zachowania, przyczyny ich występowania oraz sposoby jak sobie z nimi radzić. No to lecimy!
Pamięć jest urządzeniem do przechowywania informacji, które pochodzą z uruchomionych//działających aplikacji. Proces zazwyczaj przechowywany jest w określonym, zaadresowanym przedziale pamięci (zapisujemy ten przydział komórki za pomocą systemu heksadecymalnego), może on jednak rezydować na dysku twardym (w swap'ie) w sytuacji gdy nie jest używany lub gdy system operacyjny nie potrafi zaalokować odpowiedniej ilości pamięci dla programu. Pamięć użytkownika (wydzielony dział pamięci operacyjnej, do którego użytkownik ma pełen dostęp) jest zarządzana na dwa sposoby - przez jądro samo w sobie oraz użycie funkcji wywołań pamięci takich jak malloc() i pochodne.
Pamięć jądra
Jądro systemu operacyjnego zarządza zapotrzebowaniem procesów na pamięć operacyjną. Gdy użytkownik uruchamia aplikację, kernel automagicznie alokuje przestrzeń adresową w pamięci użytkownika dla tego procesu. W kolejnym etapie sam proces rozpoczyna zarządzanie przydzieloną mu strukturą pamięci, adresując i dzieląc ją wedle danego schematu:
- Tekst -- przechowywane są tutaj dane '"tylko do odczytu" programu, zazwyczaj stosowane do bieżącej funkcji. Wielokrotne instancje tego samego programu potrafią współdzielić ten obszar pamięci (decyduje o tym kernel).
- Dane statyczne -- miejsce alokacji danych statycznych ("dobrze-znanych"). Generalnie jest to miejsce przechowywania zmiennych globalnych oraz statycznych atrybutów klas C++. System alokuje tą część pamięci dla każdej instancji programu osobno.
- "Pole walki" (często nazywane "przestrzenią miejsca") -- miejsce przetrzymywania dynamicznych bibliotek, binarek etc. Jest to zaalokowany stos (heap()), z najniższym elementem o najwyższym priorytecie, przechowujący strukturę pamięci alokowanej dynamicznie. Adresacja pamięci w stosie odbywa się w sposób przyrostowy - od najniższych rejestrów do najwyższych.
- Stos -- gdy tylko program odwołuje się do zadeklarowanej funkcji, obecny stan musi zostać zaaplikowany na stos. Stos rośnie w dół, od najwyższych adresacji do najniższych. Stos ten przydzielany jest dla każdego procesu osobno.
Pamięć użytkownika
Pamięć użytkownika składana jest na stosie (nie, nie palona jak w średniowieczu ;-)) w "polu walki". Miejsce to jest zarządzane przez funkcje malloc(), realloc(), free() oraz calloc(). Są one częścią biblioteki libc. Z ciekawostek warto wymienić fakt, iż użytkownik 'root' zawsze ma dostęp do pamięci użytkownika, użytkownik nigdy nie ma dostępu do przestrzeni adresowej 'roota' oraz żaden z nich nie potrafi wpisywać danych do przestrzeni adresowej jądra (za wyłączeniem specjalnych wywołań do systemu /proc, które konfigurujemy w czasie kompilacji jądra). Zatem bzdurą są opowiastki, jakoby to użytkownik wyrzucił dump'a z /proc/kmem i uzyskał informacje zastrzeżone. Chociaż, zdarzają się sytuacje, w których root musi przesłać coś bezpośrednio do kernela. To tzw. SysRq, o których pisałem już kiedyś. Ale to nie o tym mówić chciałem! Wróć!
Inne funkcje pamięci
W systemach GNU/Linux programy zwiększają swoje miejsce w pamięci w przekalkulowanych, wcześniej zdefiniowanych inkrementacjach, zazwyczaj o jedną stronę pamięci lub alokację do granicy obecnej strony. Gdy tylko stos będzie potrzebował więcej 'miejsca' niż obecnie zadeklarowała pamięć użytkownika (przy starcie procesu), wywołana jest funkcja systemowa brk(), która żądają więcej pamięci od kernela. Co ciekawe, ilość przydzielonej pamięci może być definiowana funkcją sbrk()!
Aby obejrzeć obecny stos oraz "pole walki", zobacz na /proc//maps konkretnego procesu. Ujrzysz, z jakich bibliotek korzysta program, ile każda z nich zabiera pamięci użytkownika, możesz podejrzeć adresację pamięci i popatrzeć jak działa stos (watch). Mniam ;-)
Struktura
Za każdym razem gdy malloc() alokuje pamięć - tak naprawdę alokuje jej więcej niż funkcja sbrk() kazała. "Memory routines" (czyli schematy zarządzania pamięcią) używają tej dodatkowej przestrzeni do dbania o stabilność procesu (swoisty zapętlony maintance). Aby zadeklarować dokładnie taką wartość pamięci, jaką potrzebujemy, użyjmy wywołania malloc_usable_space(). Paczka pamięci alokowanej jest zazwyczaj o 8 bitów większa, z tym musimy się już pogodzić.
A jak wygląda taka paczka? Struktura paczki (strony) jest odpowiednio ustalona. Na początku znajduje się pole zawierające wielkość poprzedniej strony, dalej kolejno wielkość obecnej strony, żądana pamięć (wraz z nadmiarem pamięci (wspomniane min. 8 bit)) i na końcu znowu wielkość strony. Ostatnie pole zawiera flagę, która wskazuje, czy system zarządzania pamięcią ma zająć się stroną od razu po zakończeniu poprzedniej (ciągłe dane).
Schemat zarządzania pamięcią w GNU/libc używa tzw. "koszyków" aby utrzymać strony pamięci w podobnych rozmiarach dla zwiększenia wydajności i zapobieżeniu fragmentacji pamięci (nieużywane, bardzo małe strony pamięci między wielkimi stronami nigdy nie zostałyby użyte (wymagałoby to przepisania praktycznie każdego obecnie używanego programu)). Obecne systemy zarządzania tym procesem są bardzo dobrze dobrane i wyważone, nie są jednak zorientowane na szybkość operacji (jedynie na bezpieczeństwo tejże). Tutaj nadal pozostaje pole do popisu dla hackerów jajka. I to ogromne!
i wreszcie:
Debug
Pamięć może sprawiać problemy. Np. przez użycie już zadeklarowanej przez proces pamięci w innym wątku//z odwołaniem do innej strony, bądź też próbą zwolnienia (free()) pamięci już zwolnionej. Choć zazwyczaj nie zaczyna to być problemem samym w sobie, zazwyczaj coś idzie źle gdy proces chce przejąć ponownie źle zaalokowany//zwolniony przydział pamięci. W rezultacie - adres jest używany dwukrotnie (pierwszy - ten "źle" wykonany, drugi - obecne odwołanie), co zazwyczaj powoduje zrzut pamięci (core dump) w sytuacji gdy adres zawiera wskaźniki do innych części pamięci lub offsety zadokowane statycznie.
Kolejnym znanym problemem jest "łażenie" po preambule strony pamięci. Proces potrafi dowolnie modyfikować pola strony, w ten sposób może też zastąpić całą preambułę strony. Zazwyczaj powoduje to całkowitą odmowę posłuszeństwa ze strony zarządcy pamięci i w czasie odwołań do danej strony - początek memory leaka. (wycieku pamięci)
Czasem nadpisywany jest właściwy stos danych - a to prowadzi do całkowitego zniszczenia danych. Użytkownik widzi taką sytuację na ekranie monitora zazwyczaj jako nagłe i nieoczekiwane zakończenie programu nad którym prowadził pracę z całkowitą stratą danych, którymi program owy zarządzał (Microsoft Word jest tutaj dobrym przykładem). Podobne zachowanie reprezentuje bardzo często Mozilla Firefox, Opera oraz OpenOffice. Zazwyczaj takie zniszczenie danych w stronie pamięci nie zakańcza procesu od razu. Użytkownik często zaczyna dostawać przeróżne, dziwne komunikaty (znane "pamięć nie może być read") bądź też zauważyć dziwne zachowanie programu (wolne działanie, wysyłanie na ekran dziwnych znaków, problemy z myszką). W takiej sytuacji ZU powinien natychmiast zamknąć program zapisując swoją pracę.
Podobnie, jeśli zapis nagłówka strony zostanie zniszczony, zarządca zwróci błąd na głównej pętli (co zaowocuje podobnym przypadkiem jak powyżej).
Użycie niezaalokowanej pamięci w "polu bitwy" także może spowodować błędy. Najczęstszą sytuacją, która ma miejsce, jest zapis do pamięci poza stosem, lecz ciągle w stronie pamięci. W zasadzie sytuacja taka nie powoduje błędu, dopóki nowo zaalokowana pamięć (np. poprzez jądro) nie odwoła się do wcześniej zadeklarowanej i zapisanej pamięci poza stosem.
Najczęstszym jednak błędem zarządcy pamięci jest moment, w którym program próbuje użyć pamięci poza obszarem zadeklarowanej dla danego procesu przestrzeni adresowej. Rezultatem takiej operacji jest uwielbiany przez programistów SIGSEGV (segmentation violation fault), a program automatycznie zrzuca pamięć (tzw. memory dump, core dump). Najprostszym sposobem zaimplikowania takiej sytuacji jest kompilacja i uruchomienie poniższego programu:
#include <stdio.h>
int main(){ printf(*"Hello World!"); return 0;}
ciekawostka: jest to najszybszy sposób edycji popularnego Hello World zważając na kryterium minimalnej odległości Levenshteina, aby wyrzucił on SIGSEGV. ;-)
Jednak najbardziej destruktywną sytuacją, która może się przydarzyć, jest sytuacja, w której cały stos pamięci w stronie jest uszkodzony. Program traci wówczas wszystkie zmienne lokalne, parametry, rejestry poprzednich ramek//stron i co najgorsze - zwraca adres komórki pamięci do stosu. W takim przypadku program staje się niemożliwy do debugowania, gdyż ramki są renderowane i przekazywane do samych siebie. Aby wykryć tego typu uszkodzenia pamięci należy użyć jednego z płatnych debuggerów, które potrafią zastąpić kod wykonywalny w samej binarce i już na etapie przetwarzania stosu sygnalizować błędy. Niestety, nigdy takich programów nie używałem i nie potrafię Wam polecić jednego, konkretnego.
A żeby sobie ułatwić życie:
memprof - debugujemy graficznie!
Mając dość bawienia się w gdb czy inne, konsolowe debuggery zechcemy może użyć jednego z narzędzi graficznych na licencji GNU/GPL. Takim narzędziem jest memprof. Korzysta on z wywołań gdb, które w odpowiedni sposób parsuje wyrzucając miłe dla oka komunikaty :-). Kontroluje on procesy poprzez BFD (binary file descriptor) i w zasadzie nie sprawia problemów. Interfejs graficzny oferuje poprzez bilbioteki GTK1.2 oraz GTK2.
I to by było w zasadzie tyle. Artykuł ten miał na celu otwarcie oczu programistom, którzy czasem podchodzą do swojego programu "ok, kompiluje się, działa, jest odporny na głupotę użytkownika!", po czym okazuje się, że za 1056 uruchomieniem na komputerze nasz kochany program się wywala.... Debugujcie swoje dzieła! Nie bądźmy jak Microsoft ;-)))
Bardzo był bym rad, gdy któryś ze zwykłych użytkowników Linuksa dzięki temu artowi zainteresował się głębiej jądrem i procesami. Hackerzy jądra ciągle są poszukiwani. :-)
I na koniec - dziękuję Tobie - za to że przeczytałeś ten artykuł i dobrnąłeś do końca. Zdaję sobie sprawę, że tematyka odbiega znacznie od tego, co robiłem na tym joggerze do tej pory. Cóż - w końcu to w założeniu miał być blog techniczny :-). W następnym cyklu - używanie gdb, czyli szybki tutorial krok po kroczku.
Enjoy!
Prawdziwa przezroczystość konsoli w KDE (Ubuntu Feisty 7.04)
Zbudowałem paczkę, dzięki której użytkownicy Beryla pod KDE będą mogli cieszyć się pełną i prawdziwą przezroczystością programu "konsole". Efekt możecie podziwiać na screenie obok.
UWAGA! Nie radzę instalować tego programu w systemie innym niż Ubuntu 7.04 oraz naprawdę nie radzę instalować tej paczki w systemie, na którym nie używa się Beryla. Za skutki takich poczynań nie odpowiadam.
Link 1 Link 2
Exim4 + Mailman as Mailing List Manager on Debian
So, let's say you are a Debian server administrator and you want to set up a mailing list for your users. You have already configured Exim4 as MTA and installed Mailman from offical repositories. With smile on face you are sending a message on {list}@{server} and...
pipe to |/var/lib/mailman/mail/mailman post ...
generated by .......
local delivery failed
The following text was generated during the delivery attempt:
------ pipe to |/var/lib/mailman/mail/mailman post ...
generated by ....------
Group mismatch error. Mailman expected the mail
wrapper script to be executed as group "daemon", but
the system's mail server executed the mail script as
group "Debian-exim". Try tweaking the mail server to run the
script as group "daemon", or re-run configure,
providing the command line option `--with-mail-gid=Debian-exim'.
This is a well known problem with group permissions. Forums all over the world explain the problem but none of those have right clues to deal with it.
In short words - it is a bug in Debian package. Maintainer of mailman-2.1.9 somehow forgot to change default group of mailman from "deamon" to "Debian-exim" (which is required by Exim4 to recognize Mailman and deal with pipe of messages encoded in /etc/aliases). Also - I really do not know why packager set default path to /var/lib! The way to solve it is recompiling Mailman with option:
--with-mail-gid=Debian-exim
..but, wait a minute. The default path of Debian's mailman is not compatible with default path of source package. Changing the path with configure options is really bad idea.
Few minutes ago I finally got over it. Path of mailman source local installation is /usr/local/mailman, so we must manually override some starting scripts of mailman. Here's a solution. Right when we configure, make and make install our new Mailing List Manager we must create a init.d script for running it with correct permissions.
#!/bin/bash echo "Starting mailman..." su mailman -c 'python mailmanctl -s -q start' & sleep 1 su mailman -c 'python /usr/local/mailman/bin/qrunner --runner=ArchRunner:0:1 -s' & su mailman -c 'python /usr/local/mailman/bin/qrunner --runner=BounceRunner:0:1 -s' & su mailman -c 'python /usr/local/mailman/bin/qrunner --runner=CommandRunner:0:1 -s' & su mailman -c 'python /usr/local/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s' & su mailman -c 'python /usr/local/mailman/bin/qrunner --runner=NewsRunner:0:1 -s' & su mailman -c 'python /usr/local/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s' & su mailman -c 'python /usr/local/mailman/bin/qrunner --runner=VirginRunner:0:1 -s' & su mailman -c 'python /usr/local/mailman/bin/qrunner --runner=RetryRunner:0:1 -s' &
Remember! Run "newlist" directly from /usr/local/mailman/bin to create lists (not command "newlist" from default path /usr/bin!) and don't forget to run "newaliases" after modifying /etc/aliases. Also, you have to configure your httpd.conf for cgi-bin scripts which is provider with mailman source package.
ScriptAlias /mailman/ /usr/local/mailman/cgi-bin/
<Directory /usr/local/mailman/cgi-bin/>
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
Alias /pipermail/ /usr/local/mailman/archives/public/
<Directory /usr/local/mailman/archives/public>
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Alias /mmimages/ /usr/share/doc/mailman/images/
<Directory /usr/share/doc/mailman/images>
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
After that, restart apache and mailman (with your changed script!). Now your Web Control Panel is fully configured and set up. Add subscribers and enjoy it! :)
Other way to solve the problem is contact maintainer of package mailman or build our own package mailman-exim4-2.1.9. I will try to do both.
At last - please contact me if you encountered the same problem. I realize that this mini-solution is not a full HowTo. A bunch of links that helped me or point me at good way to look:
http://www.exim.org/howto/mailman.html"
http://tectonic.co.za/view.php?id=538
http://mail.python.org/pipermail/mailman-users/2004-January/033817.html
http://archives.free.net.ph/message/20070306.165258.c83599e1.en.html
Siemens CXV70 jako modem via kabel USB
Technologia poszła nam naprzód... Internet w każdym miejscu świata, za półdarmo (w stosunku tego, co było jeszcze 4-5 lat temu). Mnie też to dopadło - pokusa odbierania poczty, rozmowy ze znajomymi przez Jabbera czy też zwyczajne surfowanie po sieci jadąc pociągiem z laptopem na kolanach jest silna..
PlusGSM oraz inne polskie sieci komórkowe oferują w bardzo niskich cenach pakietową transmisję danych poprzez GPRS. Wystarczy posiadać telefon komórkowy z Bluetooth oraz odbiornik Bluetooth w swojej komórce i świat stoi przed nami otworem.
Siemens CXV70, telefon który posiadam, nie oferuje niestety Bluetooth. Dziwi mnie to, telefony z niższej półki Siemensa posiadają ten standard. Mój laptop także nie posiada wbudowanego adaptera BlueTooth. Koszt zakupu telefonu z Bluetooth + karty PCMCIA Bluetooth to około 200zł - troszkę zbyt drogi interes jak na studenta.
Istnieje jednak o wiele tańszy sposób połączenia - zakup kabla USB. Kabel taki kosztuje ok. 20zł i umożliwia wykorzystanie naszego telefonu jako modemu pppd GPRS! W sieci nie znalazłem żadnego poradnika, który opisywałby sposób przewodowego połączenia telefonu marki Siemens poprzez przewód USB (myślałem już, że jest to niemożliwe...), zatem spłodziłem to:
Sposób uruchomienia połączenia GPRS przez kabel USB:
W pierwszej kolejności podłączamy naszą komórkę do komputera i odpalamy:
# lsusb
Powinniśmy ujrzeć nasz kabel (nazwa dowolna, zależna od typu kabla). Załadujmy najważniejszy moduł:
# modprobe cdc-acm
Moduł ten pozwala na wykorzystanie telefonu jako modemu. Wywołując:
# dmesg | tail
zapewne ujrzymy log potwierdzający włączenie modemu w telefonie. Instalujemy potrzebne oprogramowanie:
# apt-get install pppd wvdial
Oraz konfigurujemy połączenie wgrywając poniższe pliki do katalogu /etc/ppp/peers.
gprs gprs-connect-chat gprs-disconnect-chat gprs-wvdial.conf
Przejrzyjmy każdy z tych plików i zdefiniujmy rodzaj operatora, dane dostępowe oraz port naszego kabla. W przykładzie wykorzystane zostały dane Ery TAK-TAK oraz port /dev/ttyUSB0.
W zasadzie to już koniec konfiguracji. Z internetem łączymy się za pomocą komendy:
# pppd call gprs
A rozłączamy się poprzez:
# killall pppd
Rozwiązanie to pozwoliło mi zaoszczędzić masę pieniędzy, którą przeznaczyłbym na nowy telefon z Bluetooth. Teraz mogę odbierać pocztę w każdym miejscu (PlusGSM obejmuje swoim zasięgiem praktycznie całą Polskę), o każdej porze. Jestem zadowolony, moja "mobilność" po raz kolejny "wzrosła".:)
Monitorowanie użycia procesora - CPU utilization
W artykule nie znajdziecie informacji o popularnych "monitorach systemu", takich jak gdesklets, conky czy karamba. Zajmę się opisem realnego zużycia czasu procesora, średnim obciążeniem oraz pochodnymi tego tematu. Zostaliście ostrzeżeni. Nie będę też opisywał instalacji aplikacji czy miejsca, gdzie można je znaleźć. Nie sądzę, by ktokolwiek miał ban na google i gcc. Większość narzędzi z tego artykułu znajduje się w paczce sysstat znajdującej się w repozytoriach Debiana. No to zaczynamy!
Sposób zarządzania przydziałem czasu CPU w systemie Linux jest troszkę zakręcony. W większości wypadków proces, który okupuje CPU będzie go używał do czasu, aż proces nie zakończy się lub nie przejdzie w stan wstrzymania (oczekiwania). Od tej reguły są wyjątki (jak choćby przerwania SysRQ jądrą lub zaawansowane zapytania poprzez /proc), w większości wypadków jednak sytuacja, w której proces A blokuje czas procesora procesowi B jest dość częsta. Opisywałem niedawno cpulimit, dzięki któremu mamy pewne możliwości sterowania obciążeniem naszego procesora. Istnieją oczywiście bardziej zaawansowane metody, którymi zajmę się troszkę później...
... ponieważ aby zacząć zarządzać naszym procesorem, musimy wiedzieć jakie procesy "siedzą" w maszynie. Najbardziej popularny i najmniej skuteczny jest program
# top
wraz z jego lepszymi pochodnymi - atop/htop. Top sam w sobie jest programem bardzo ograniczonym i nie umożliwia skutecznego monitoringu naszego systemu. Aplikacje atop oraz htop rozszerzają te możliwości, jednak nie w stopniu satysfakcjonującym. (polecam jednak używanie programu htop w codziennym zarządzaniu systemem, znacznie ułatwia pracę).
Drugim, znacznie ciekawszym programem jest:
# mpstat -P ALL
Sposób raportowania zastosowany w tym programie jest przemyślany, strona podręcznika man daje jasny i czysty obraz na działanie programu. Nie będę przepisywał tutaj treści, wystarczy spojrzeć na wynik powyższego polecenia:
19:47:40 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 19:47:40 all 1,96 0,02 0,62 0,15 0,13 0,13 0,00 96,99 363,19 19:47:40 0 1,75 0,03 0,65 0,23 0,26 0,27 0,00 96,82 363,19 19:47:40 1 2,17 0,02 0,59 0,07 0,00 0,00 0,00 97,16 0,00
Raporty minutowe z działania naszego procesora możemy uzyskać poprzez narzędzie:
# sar
Raport wygląda w następujący sposób:
12:00:02 AM CPU %user %nice %system %iowait %idle 12:10:01 AM all 1.05 0.00 0.28 0.04 98.64 12:20:01 AM all 0.74 0.00 0.34 0.38 98.54 12:30:02 AM all 1.09 0.00 0.28 0.10 98.53 ..... 05:10:01 AM all 8.78 0.00 37.74 0.03 53.44 05:20:02 AM all 8.30 0.00 35.45 0.06 56.18 Średnia: all 3.09 0.00 9.14 0.09 87.68
Sar drukuje na standardowe wyjście kumulatywną aktywność obciążenia systemowego. Można sprawić, aby sar zachowywał się dokładnie tak, jak my będzie tego chcieć. przykładowe wywołanie; 2 sekundy interwału; 5-krotne wywołanie:
# sar -u 2 5
19:52:39 CPU %user %nice %system %iowait %steal %idle 19:52:41 all 0,00 0,00 0,75 0,00 0,00 99,25 19:52:43 all 1,50 0,00 1,00 0,00 0,00 97,51 19:52:45 all 4,00 0,00 1,00 0,00 0,00 95,00 19:52:47 all 3,97 0,00 0,99 0,00 0,00 95,04 19:52:49 all 7,71 0,00 1,99 0,00 0,00 90,30 Średnia: all 3,44 0,00 1,15 0,00 0,00 95,41
Opis wartości:
- %user:Procent obciążenia CPU przy wywołaniu aplikacji z poziomu użytkownika
- %nice: Jak wyżej, zlicza jednak procent obciążenia przez procesy ze zmienionym niceness
- %system: Wykorzystanie CPU przez procesy jądra
- %iowait: Procent czasu, w których procesor(y) był(y) nieużywane podczas gdy system wykonywał zapytania I/O.
- %idle: Jak wyżej, z tym że zlicza procent czasu, w którym procesor i system niczym się nie zajmowały
Sar pozwala na logowanie równoległe do plików tekstowych, obsługuje własny format pliku raportu (binarny), umożliwia działanie poprzez nohup (polecane). Jest to potężne narzędzie i administrator systemu (oraz nawet zwykły użytkownik!) nie powinien o nim zapominać.
Nie zostaje nic więcej, jak sprawdzić, które procesy najmują najwięcej czasu procesora.
# ps -eo pcpu,pid,user,args | sort -k 1 -r | head -10
lub
# ps -eo pcpu,pid,user,args | sort -r -k1 | less
Komendy te podają nam najbardziej zasobożerne procesy w kolejności od najmniej zajmującego czas procesora do najbardziej.
Dodatkowo można posłużyć się poleceniem
# iostat
Które pozwoli na szybkie sprawdzenie stanu naszej jednostki centralnej oraz dysków twardych.
Ostatnią rzeczą, jaką musimy się zająć jest Load Average. Seban opisał to na swojej Jabbie. Dodam jeszcze, że LA >1 przez ostatnie 15 minut jest już czymś, czym musimy się zająć, a LA >2 jest sytuacją wymagającą szybkiej interwencji.
Teraz jesteśmy w stanie monitorować nasz system, dowiadując się którymi procesami mamy się martwić.
W kolejnym odcinku : przygoda z konsolą część trzecia oraz zaawansowane podejście do sygnałów systemowych (sys/signal.h) Linuksa! Enjoy!
