Hallo Liste, ich muß gestehen, ich habe bei dem time Befehl ein Verständnissproblem. Wenn ich time Programmname ausführe, zeigt er mir die Gesamtzeit, die Zeit im Usermode und die Zeit im Kernelmode, zb: real 0m19.915s user 0m3.500s sys 0m0.273s Die Realzeit verstehe ich, die sagt mir meine Stopuhr auch, aber warum sind user + sys nicht gleich der Realzeit? Load liegt bei 0,3, die CPU bei 60% laut procmeter, und eine Ausgabe erfolgt bei dem Programm auch nicht. Was macht er also die fehlenden 16 Sekunden? Vielleicht hat jemand von Euch eine Erklärung? Viele Grüße Jürgen
Hallo, Am Donnerstag, 20. Januar 2005 19:08 schrieb Jürgen Jentsch:
Die Realzeit verstehe ich, die sagt mir meine Stopuhr auch, aber warum sind user + sys nicht gleich der Realzeit? Load liegt bei 0,3, die CPU bei 60% laut procmeter, und eine Ausgabe erfolgt bei dem Programm auch nicht. Was macht er also die fehlenden 16 Sekunden?
Warten auf den Seek in der Festplatte, warten bis der richtige Sektor vorbeigeflogen kommt, das Ganze konkuriert natuerlich mit den anderen Festplattenoperationen. Warten auf Netzwerk. Warten auf den Bus (npi) Andreas
On Thursday 20 January 2005 19:08, Jürgen Jentsch wrote:
Wenn ich time Programmname ausführe, zeigt er mir die Gesamtzeit, die Zeit im Usermode und die Zeit im Kernelmode, zb: real 0m19.915s user 0m3.500s sys 0m0.273s
real ist die Zeit, die Du auch mit der Stoppuhr messen kannst. Die anderen beiden beziehen sich auf die Zeit, die der Prozess die CPU belegt hatte. Während sys war er dabei im Kernelspace. Also er rechnete an Systemcalls rum. Während user war er im Userspace. Meist ist sys sehr viel kleiner als user, da die meisten Systemcalls nur wenig rechnen. Hier ein paar Experimente, die das vielleicht verdeutlichen: 1.) einige Additionen in perl:
time perl -e 'for($i=0; $i<10000000; $i++) {}'
real 0m1.227s user 0m1.214s sys 0m0.002s Das ist ein fast reines userspace Programm, das auch immer bereit ist, den Prozessor zu belegen. Daher viel user, wenig sys und real=sys+user 2.) Rechnen im Kernel: /dev/urandom liefert Pseudozufallszahlen, die der Kernel berechnet. Viel lesen aus /dev/urandom sollte also viel sys erzeugen:
time dd if=/dev/urandom of=/dev/null bs=10k count=1000 1000+0 records in 1000+0 records out
real 0m2.020s user 0m0.002s sys 0m2.004s Wie erwartet. 3.) Viel warten, CPU nicht belegt, daher sollten user und sys im Vergleich zu real sehr klein sein. Hierfür eignen sich fast alle IO Operationen (FTP, HTTP über ein reales Netz, Disk IO mit DMA, Terminal IO, ...) oder auch einfach sleep.
time sleep 2
real 0m2.005s user 0m0.001s sys 0m0.003s Torsten
Am Donnerstag, 20. Januar 2005 20:30 schrieb Torsten Foertsch:
On Thursday 20 January 2005 19:08, Jürgen Jentsch wrote:
Wenn ich time Programmname ausführe, zeigt er mir die Gesamtzeit, die Zeit im Usermode und die Zeit im Kernelmode, zb: real 0m19.915s user 0m3.500s sys 0m0.273s
real ist die Zeit, die Du auch mit der Stoppuhr messen kannst. Die anderen beiden beziehen sich auf die Zeit, die der Prozess die CPU belegt hatte. Während sys war er dabei im Kernelspace. Also er rechnete an Systemcalls rum. Während user war er im Userspace. Meist ist sys sehr viel kleiner als user, da die meisten Systemcalls nur wenig rechnen.
Dank an alle für die Erklärung! Dann werde ich wohl mal suchen müssen, wo das Programm wartet. Disk IO ist ja fast nur mysql, vielleicht braucht das bei meinen Anweisungen so lange. Danke Jürgen
participants (3)
-
Andreas Stieger -
Jürgen Jentsch -
Torsten Foertsch