-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 22 Nov 2007, Yashpal Nagar wrote: > Raj Mathur wrote: > > So in a sense the load average is a measure of the load on the > > system. Higher load averages mean that the processor is unable to > > handle the demands put onto it by the tasks running in the system. > > However, there are no fixed measures for defining what load average > > is high and what is low. I personally would start getting worried > > if a server under my control was consistently showing load averages > > higher than say, 5; on the other hand, it all depends on what sort > > of tasks the server is doing and how fast and often the kernel does > > context switches. > > Apart from uptime, which tells about the load average in the form of > average number of processes essentially in "run_queue" at a time, > over last 1 minute, 5 minute and 15 minutes. There is another program > called System Acitivty Report (SAR) which represents the CPU > utilization in the form of percentages. > > The CPU load monitored by SAR is shown in % > > [EMAIL PROTECTED]:/var/log/sa> sar -f sa31|more > Linux 2.6.16.21-0.8-default (hostux2) 31/08/07 > > 00:00:26 CPU %user %nice %system %iowait > %steal %idle > 00:01:26 all 0.98 0.00 0.53 0.78 > 0.00 97.70 > 00:02:26 all 0.80 0.00 0.33 0.65 > 0.00 98.22 > > How does this % relates to the uptime output? Does this % refers to > the run_queue capacity? Is there any way we can modify run_queue.
No clue what run_queue is -- are you sure it's part of sar? > In SAR's case, is it fair to sum the % of queues (excluding %idle) > and conclude that as the total "CPU load" at that time? The sar numbers are pretty straightforward if you have a grasp of the CPU states. Imagine a system that runs just one program which does the following: 1. Calculate the inverse of a 100x100 matrix 2. Open a file on a floppy disk 3. Write the inverted matrix onto the floppy 4. Sleep for 30 seconds When the program is calculating, the CPU is in user state. When it's opening the file, it makes a call to the kernel and the kernel executes some code related to opening files. At this time (when it's executing kernel code), the CPU is in system state. When the program is writing the file, it's typically waiting for one write to complete (it is blocked) before issuing the next write command. This is iowait state. Idle state is self-explanatory -- the CPU is twiddling its thumbs waiting for someone to give it some work, like when the program above is sleeping. So to sum up: Times when the CPU is executing user code is counted in %user. Times when the CPU is executing a system call (or running any other kernel code) is counted in %system. Times when the CPU is waiting for some I/O to complete is counted in %iowait. Times when the CPU is doing nothing is counted in %idle. Since the CPU must be doing one of these things at any time, the sum of these percentages will always be 100. If you find your CPU is spending a lot of time in iowait, it means your CPU is lying idle because one process (or possibly more) has issued a R/W call, and no other process is ready to run until that R/W completes. You could probably add some comparatively CPU-intensive applications to that system and find little or no degradation in performance since the new applications will soak up CPU iowait time; in other words, the applications will be able to utilise the CPU while other processes are waiting for their R/W to complete. Relationship between CPU states and load averages? Just about the only one I can see is that if your CPU is 100% idle your load average should be 0 :) Regards, - -- Raju - -- Raj Mathur [EMAIL PROTECTED] http://kandalaya.org/ Freedom in Technology & Software || February 2008 || http://freed.in/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F PsyTrance & Chill: http://schizoid.in/ || It is the mind that moves -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHRPC5yWjQ78xo0X8RAp+wAJ9xVLv6/YH3MnzTZp6FxEEGL3c8PACeKSlX ZCi+9cZaCiH2x4ZVSyW9FUM= =Mi7P -----END PGP SIGNATURE----- _______________________________________________ ilugd mailinglist -- ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd Next Event: http://freed.in - February 22/23, 2008 Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/ilugd@lists.linux-delhi.org/
