You are not really getting the whole truth. Its not how many processes are using the CPU at once. Read the first lines on the link I posted earlier.
"What is Server Load Average? Server Load tries to measure the number of active processes - taking into account waiting processes in the queue to access the processors, and also the current running processes. The Server Load Average gives the sum of the average number of jobs in the queue over the last 1, 5, and 15 minutes. Load average is not a UNIX command - it is an embedded metric that appears in the output of other UNIX commands such as uptime and procinfo. " Note the word 'queue' in the first sentence. If you still are not convinced try this link instead: http://www.teamquest.com/resources/gunther/ldavg1.shtml The summary of that link specifies: 1. The "load" is not the utilization but the total queue length. 2. They are point samples of three different time series. 3. They are exponentially-damped moving averages. 4. They are in the wrong order to represent trend information. I cant find any information about the load in the top manpage. But I do have the description from the manpage from the function that top, w, uptime and such uses. "The getloadavg() function returns the number of processes in the system run queue averaged over various periods of time. Up to nelem samples are retrieved and assigned to successive elements of loadavg[]. The system imposes a maximum of 3 samples, representing averages over the last 1, 5, and 15 minutes, respectively." Maybe you are trying to say the same thing, but you are writing it in a way that makes it quite wrong. Btw, there is no such thing as "using the CPU at once". Each process must wait its turn to get kernel resources. The schedular is trying to do this the best way it can, but its not always enough, hence the load gets higher. /Bjorn On Sat, 25 Jun 2005, Clayton Macleod wrote: > argh. It's not hard to understand. It's the average of how many > processes are using the CPU *at once*, over a given time period. I > truly don't give a rat's ass how you *guess* how your servers are > performing. But giving load average such a high priority in your > decision clearly makes it a guess. Doowutchyalike. What makes you > think there are 9 million different man pages for a given app? heh. > /me shakes head > > On 6/25/05, Ian mu <[EMAIL PROTECTED]> wrote: > > I don't think it means 100% at all. No idea where you get that from. > > Its just your explanation doesn't make sense. How can it be how many > > processes have used the cpu in the last minute? Are you saying when > > load is 0.5 half a process has used the cpu in the last 5 mins? > > Basically you're not making sense is the problem. > > > > Load is the amount of processes on average "waiting". Thats VERY > > different. I.e if your load is 1, it means on average there is always > > 1 process waiting to grab some cpu time. If load is 2, there are 2 > > processes waiting on average to keep it pretty simplified. > > > > Load doesn't directly relate to cpu "usage", no one has said that > > iirc. I would say people need to watch both. A load > 2 on a single > > cpu will start to give bad performance on games even if cpu usage is > > 30% (you can get this on certain maps/games for example). Load for me > > is "generally" a better indicator than cpu usage as it gives a better > > viewpoint of responsiveness of servers (imo). But I wouldn't let a > > game machine go over load 2 or load 70% as a rule of thumb for me. > > > > Not sure what man page you're looking at btw. > > > -- > Clayton Macleod > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > -- Users are like bacteria - each one causes a thousand tiny crises until the host finally gives up and dies. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
