Basically this:

Post #154,980 by folkert 5/13/04 12:29:18 PM Reply	Basically this: The number of runnable processes or "want to run" jobs in the run queue. Now, this can be misleading, You have to also look at the CPU(s) usage. For a some implemetations of Java I have worked with, some machines are running at load averages of 200+. Reason being was, the applets/servlets(whatever) were all very small and fast. Jobs sometimes requied 500 or so of them to be run. Many of these small things had very short runtimes, as short a 18 clicks(1 ms). Most were about 40-90 ms. Worked very well. Well, as long as we put system limits in proper (we ran everything as "normal users" to enable resource limiting), it ran just fine. Response was fine, I had to adjust the monitoring system to not panic at such a high number with LOW CPU usage. So I modified the monitor, to watch the number of jobs(load average) AND the CPU utilization, along with Memory Pages available. You really have to know what you are running to be able to determine what is good/bad. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* Give a man a match, he'll be warm for a minute. Set him on fire, he'll be warm for the rest of his life!
Post #154,996 by ben_tilly 5/13/04 2:11:48 PM Reply	This I know I've said [link\|http://use.perl.org/comments.pl?sid=20059&cid=30733\|as much] elsewhere. (Though I can't admit to personally seeing a system with load over 100 that wasn't melting down. But I've seen an Oracle server where 40 was a light load..) I would think, though, that with load that high you have other architectural problems. First of all on most systems (Linux 2.6 being a notable exception), the scheduler is going to start taking up considerable CPU. Secondly responsiveness is going to take a beating as processes wind up waiting a few hundred time slices before their turn comes up in the scheduler. Since the scheduler itself doesn't normally show up in CPU usage figures, you wouldn't get this reported. (In fact at some point reported CPU will drop and keep on dropping as actual work done bumps into CPU minus unreported kernel activity.) Responsiveness of high priority jobs (ie higher than the bulk of those spinning processes) might be unimpeded, but something has to show the fact of that contention somewhere. IF the system and job are tasked correctly, none of this might matter. The system gets the job done just fine. But if you could change the software architecture to not put so much pressure on the scheduler, you'd probably get even more out of the same equipment. Cheers, Ben To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]
Post #155,060 by folkert 5/13/04 6:18:59 PM Reply	This particular set of machines were PowerRISC and AIX AIX has the ability to limit the scheduler to take into effect the expected average "load" and base its decisions on CPU and Memory usage. Since the Whole of Java and the Appserver was in memory, and it had Plenty of RAM, Multiple CPU (4) and fast I/O Drives (SSA) and 2 - GBit ENET card... It really was not ever in any pain from scheduling (init) taking over. 2.6 has a scheduler with similar capacity. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* Give a man a match, he'll be warm for a minute. Set him on fire, he'll be warm for the rest of his life!

Welcome to IWETHEY!