views:

72

answers:

4

This command gets some data from MySQL and then manipulates it. Why is the 'real' time so much higher than the 'user' time?

>time ./command.rb

real    45m45.457s
user    3m36.478s
sys     0m28.226s

For clarification - I understand the difference between the real, user, and sys output. However, I am confused at why there is such a great difference. The machine I am running this on has virtually nothing else using the CPU, and I don't have any threading in my command. All it does is fetch data. Could a complex MySQL statement be the cause of such a gap?

+2  A: 

The system is spending most of its time waiting for disks to spin and heads to seek.

The "user" time is the time actually spent by the CPU crunching numbers for you.

Carl Smotricz
+2  A: 

user and sys report the amount of time the cpu is busy. The CPU won't be busy when blocked on anything, like network or disk I/O. Try, e.g., "time sleep 1", or "time dd if=/dev/zero of=/dev/null bs=1024 count=1000000" to see the differences. The first just blocks, the second will include a lot of CPU use.

Aidan Cully
So network traffic could cause part of this? If a request takes 200ms end-to-end, any idea what part might be the CPU?
Justin
Network traffic isn't very CPU intensive at all. If you're using the loopback interface (e.g. to talk to a SQL server on the localhost), it's likely to be much more CPU bound then I/O bound, but otherwise, the CPU usage associated with a network connection is likely to be minimal.Also, you're only measuring the CPU usage of your script. The SQL server will be taking some CPU (and disk I/O) time trying to answer your request, and you're not seeing that in your measurement.
Aidan Cully
+1  A: 

The "real" time is the amount of actual wall-clock time that passed, where the "user" and "sys" times are the amount of CPU time used for your job in each class of processing. For the "real" time to be so much higher, your job probably spent a lot of time waiting for resources or sleeping.

chaos
+1  A: 

Just a guess, but if you are viewing the results over an ssh connection, it may be possible that much of your time is waiting for the processor to encrypt the data to be sent to your remote console.

Ape-inago
I appreciate the insight! I am logged in to the box through ssh, but running through a local gnu screen, so that overhead would not be included in the output of `time`.
Justin