Tema se objevilo, alespon pro mne, v pravou chvili. Vcera jsem badal nad tim, co je v souboru /proc/loadavg - statistika o poctu procesu a uptime - alespon tak jsem to pochopil podle manualovych stranek. Co jsem ale nezjistil, kde by se dalo splasit cislo kolik % casu stravi system diskovymi operacemi. Nemohlo by to byt v nekterem z pristich pokracovani ?
Rozhodne dik, tohle se mi zrovna hodi.
Zdravim,
pokial viem, informacie tohoto typu (ktore zobrazuje FreeBSD a to uz nehovorim o solarise) v linuxe nie su, pretoze ich jadro nepocita. Ak by niekto patchol jadro tak aby toto ratalo, mohol by rovno urobit aj nejaky specialny subor do /proc :)
/proc/partitions (s patricnymi RH patchi jadra pro 2.4 jiny netusim jak to s nima je) jinak iostat
pasky@machine:~$ cat /proc/stat | head -1
cpu 131726 300 38556 8711687
kde tento radek je generovan prikazem
len = sprintf(page, "cpu %u %u %u %lu\n", user, nice, system, jif * smp_num_cpus - (user + nice + system));
coz znamena ze tyto cisla znamenaji kolik casu stravil procesor chroustanim uzivatelskych programu, zanajsovanych programu, a systemoveho kodu, a nakonec kolik stravil lelkovanim - takze jednoduchy vypocet celkove zateze procesoru jest load[%]=($1+$2+$3)/($4-$1-$2-$3)*100
Dovolil bych si trochu upresneni. Onu "diskusi v konferenci linux@linux.cz" jsem rozpoutal ja svym dotazem, jestli nekdo nema podrobny popis procfs a jestli kdyz ho napisu, bude o nej zajem. Zajem byl, tak jsem zacal psat. Uz to mam skoro hotove, chybi mi jeden adresar a dnes vidim na rootu tento clanek. Kdyby se autor alespon ozval, ze dela neco podobneho, mohli jsme spojit sily...
K dotazu ohledne "casu straveneho diskovymi operacemi". Pokud vim, nic takoveho z /procu nezjistite a nezjistite ani pocet prenesenych bloku per proces (jen globalne v systemu). Pokud proces bezi na systemu sam a ceka jen na disk, lze to zhruba odvodit od vytizeni systemu. Ale prozo, uz jsem videl system, ktery byl zatizen na 60% a pritom podle vypisu topu jeden proces bral 3%, dalsi 1% a zbyle skoro nic...
Myslím, že vůbec nebude vadit, když zveřejníte svou práci na totéž téma. Určitě jsou i věci, ve kterých se nepřekrýváte.
Pokud se kdokoliv chystate napsat clanek o cemkoliv tematicky se hodicim pro ROOT.cz a chcete ho u nas i zverejnit (samozrejme za honorar), napiste nam a podobnym problemum muzeme predejit.
Ale samozrejme neni problem uverejnit dva clanky od ruznych autoru na jedno tema, pokud se nebudou vylozene prekryvat.
Díky za Qčka ty mamlasi, budem ve vatě. A vy ostatní, přihazujte, hovada!
Bohuzel (bohudik?) je prispivani do diskuze tak jednoduche, ze ho zvladne i anonym s IQ okolo teploty vzduchu.
Doufam, ze netreba vysvetlovat, ze autor prispevku nema nic spolecneho s redakci ROOT.cz.
Upozornuji, ze teplota vzudu muze byt i pres 50 a neni to nic zvlastniho. Coz bych u autora kritizovaneho prispevku nerekl.
A jsou to stupne Celsia nebo Fahrenheita? ( nedej Boze, aby to byly Kelviny :-))
PS: At zije flame.
Toz skoro vsecko jasne, akorad nerozumim, kde autor vzal syntax pro ps:
$ps -e rovno 300
Je to OK? A ma to nejakou souvislost s CZ Linuxem??
u me se proces s danym pid vypise takto:
$ps -p 300 (RedHat Linux 6.1, US)
Pokud jsou ty linuxy vzajemne nekompatibilni, pak to neni dobre...
nejen bashovou syntaxi ziv je clovek, je dobre chapat i slozitejsi vetne celky v jazyce rodnem, zvlaste je-li prikaz "ps -e", vypisujici udaje o vsech procesech, zretelne oddelen od ceskeho "rovno" pomoci kurzivy. :))
Taky jsem naletel:-) Ona totiz v linksu ta kurziva nebyla videt...
mam blbej dotaz........ proč bys měl být s jádrem 2.4.5 sebevrah??? je snad stabilně nestabilní či co? :o)
Mam jeste hloupejsi dotaz. Kdesi v literature jsem se docet, ze liche cislo na konci znamena verzi nestabilni. Jak to tedy je? Diky.
s tou lichosti je to na druhe pozici. 2.4.x je stabilni ale treba 2.3.x je nestabilni
Velmi hezky clanek, skoda, ze Lemming psal podobny, ale mohl se prece ozvat i on. Doufam, ze ho nebude publikovat pouze v Linuxove konferenci. >;-)
Vsiml jsem si v textu poznamky o TracerPid, juknul na Google a nasel par patchu, v jadre byla chyba pri vypisu tohoto cisla. Mam jadro 2.4.3 (a nepripadam si jako sebevrah>;-) a ta chyba uz vypada opravene.
Pak mne napadlo to vyzkouset, treba intuice nezklame. Spustil jsem dalsi bash a z vedlejsiho okna ho zacal trasovat pomoci attachnuti gdb (gdb /bin/bash <jeho-pid>). Nu a jak tracing zacal, objevil se pid gdb-cka jako TracerPid toho bashe v /proc/<jeho-pid>/status.
Takze bych se odvazil tvrdit, ze TracerPid pro proces1 udava pid procesu2, ktery proces1 trasuje (nula znamena, ze proces neni jinym trasovan).
Trasovani se pouziva pro ladeni jiz existujicich programu. Na unixu se muzete pripojit k jiz bezicimu procesu, zastavovat ho, zkoumat jeho pametovy prostor a pokud mate k dispozici i jeho zdrojaky, muzete z toho byt natolik moudri, ze najdete chybu, protoze mate moznost sledovat zivot programu in-natura. Dale odkazuji na info gdb.
No dostal jsem se k netu, tak jen co si myslim na polozene otazky:
- s lemmingem jsme se uz domluvili, clanky na rootu dopisu ja
- pri syst.programovani se radeji pouzivaji sluzby jadra, jsou standartizovanejsi, proc je pomerne nekonzistentni mezi ruznymi Unix-* systemy. Jinak vyuziti proc primo neni nic moc dobry napad, lepsi (pro prenositelnost) jsou knihovny typu libproc
- sebevrah nejsem, jadro 2.4.5 je vsak v soucasnosti posledni stabilni (v dobe psani clanku) a jsou lide, kteri poslednim jadrum moc neveri, protoze je jeste nikdo delsi dobu netestoval. Osobne bych pri nasazeni na nejaky server take radsi zvazil neco "lehce" starsiho. Ale to by byla dlouha diskuze.
- TracerPid - podle logiky to odpovida ale v jadre 2.4.5 ktere mam k dispozici se tam proste natvrdo dosadila '0'. Pokud existuje patch, diky za nej
Pokud mate nejake napady, pripominky ohledne obsahu a hlavne zpracovavanych adresaru, neco vam chybi (SCSI, ???) dejte vedet (na e-mil)
Podivame-li se (v jadre 2.4.5, kdo ma stalee stahovat nove jadro a hlavne pak rebootovat pocitac ;) do /usr/src/linux/fs/proc/base.c, na radce 315 nalezneme
funkci mem_read(), ktera obsluhuje prave cteni/zapis do tohoto souboru. A protoze jsme si po stracnuti onoho cat /proc/%d/mem zjistili, ze syscall vraci -ESRCH, podivame se po nem - a nalezneme ho hned na zacatku, jako:
if (!MAY_PTRACE(task))
return -ESRCH;
kde MAY_PTRACE je definovano jen kousek vyse, jako:
#define MAY_PTRACE(p) \
(p==current||(p->p_pptr==current&&(p->ptrace & PT_PTRACED)&&p->state==TASK_STOPPED))
z toho vyplyva, ze z bezpecnostnich duvodu muzeme pracovat s timto souborem (totez je u mem_write) pouze, pokud ulohu prave ptrace()ujeme, a pokud je zrovna zastavena. U prave beziciho bashe tedy mame smulu ;-)
ČLÁNKY DO MAILU