Mailbag
This month's answers created by:
[ Anderson Silva, Henry Grebler, Mulyadi Santosa, Mike Orr (Sluggo) ]...and you, our readers!
Our Mailbag
SFLC vs. Westinghouse (Busybox GPL violation)
Jimmy O'Regan [joregan at gmail.com]
Thu, 5 Aug 2010 16:15:39 +0100
https://www.theregister.co.uk/2010/08/04/gpl_violation_westinghouse/
"It's the first time a US court has awarded an injunction ordering a GPL violator to permanently stop distribution of out-of-compliance GPL'd software."
https://sfconservancy.org/news/2010/aug/03/busybox-gpl/ https://www.ebb.org/bkuhn/blog/2010/08/03/more-gpl-success.html
-- <Leftmost> jimregan, that's because deep inside you, you are evil. <Leftmost> Also not-so-deep inside you.
Load average vs CPUs
Mike Orr [sluggoster at gmail.com]
Mon, 23 Aug 2010 13:15:26 -0700
Hello Answer Gang. I was raised to believe that the load average reported by 'uptime' and 'top' should not go above 1.0 except for short-term transitory cases, and if it persistently goes to 2 or 3 then either you seriously need more hardware or you're trying to run too much. But recently I heard that the target number is actually equal to the number of CPUs. My server has 4 CPUs according to /proc/cpuinfo, so does that mean I should let the load average go up to 4 before being concerned?
In fact, my load average has not been that high. It was 1.5 or 1.7 when I noticed the server bogging down noticeably, and that was probably because of a large backup rsync, and a webapp that was being unusually memory-grubbing. Still, my basic question remains, is 1.5 or 2 normal for a multi-CPU system?
One other issue is, I'm not sure if it really has four full CPUs. I think it might have two of those "dual core" thingys that have two processors but share the same I/O and cache or something. Here's a bit of the 'dmesg' output in case it's meaningful:
[ 0.000000] Initializing CPU#0 [ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found [ 0.000000] Calgary: detecting Calgary via BIOS EBDA area [ 0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing! [ 0.000000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.000000] Placing 64MB software IO TLB between ffff8800091de000 - ffff88000 d1de000 [ 0.000000] software IO TLB at phys 0x91de000 - 0xd1de000 [ 0.000000] Memory: 8185276k/8912896k available (5499k kernel code, 524948k a bsent, 202672k reserved, 3081k data, 796k init) ... [ 0.020000] Initializing CPU#1 [ 0.020000] CPU: Trace cache: 12K uops, L1 D cache: 16K [ 0.020000] CPU: L2 cache: 1024K [ 0.020000] CPU 1/0x6 -> Node 0 [ 0.020000] CPU: Physical Processor ID: 3 [ 0.020000] CPU: Processor Core ID: 0 [ 0.020000] CPU1: Thermal monitoring enabled (TM1) [ 0.300088] CPU1: Intel(R) Xeon(TM) CPU 2.80GHz stepping 09 [ 0.300099] checking TSC synchronization [CPU#0 -> CPU#1]: passed. [ 0.310146] Booting processor 2 APIC 0x1 ip 0x6000 [ 0.020000] Initializing CPU#2 [ 0.020000] CPU: Trace cache: 12K uops, L1 D cache: 16K [ 0.020000] CPU: L2 cache: 1024K [ 0.020000] CPU 2/0x1 -> Node 0 [ 0.020000] CPU: Physical Processor ID: 0 [ 0.020000] CPU: Processor Core ID: 0 [ 0.020000] CPU2: Thermal monitoring enabled (TM1) [ 0.470108] CPU2: Intel(R) Xeon(TM) CPU 2.80GHz stepping 09 [ 0.470120] checking TSC synchronization [CPU#0 -> CPU#2]: passed. [ 0.480175] Booting processor 3 APIC 0x7 ip 0x6000 [ 0.020000] Initializing CPU#3 [ 0.020000] CPU: Trace cache: 12K uops, L1 D cache: 16K [ 0.020000] CPU: L2 cache: 1024K [ 0.020000] CPU 3/0x7 -> Node 0 [ 0.020000] CPU: Physical Processor ID: 3 [ 0.020000] CPU: Processor Core ID: 0 [ 0.020000] CPU3: Thermal monitoring enabled (TM1) [ 0.640119] CPU3: Intel(R) Xeon(TM) CPU 2.80GHz stepping 09 [ 0.640128] checking TSC synchronization [CPU#0 -> CPU#3]: passed. [ 0.650032] Brought up 4 CPUs [ 0.650037] Total of 4 processors activated (22401.29 BogoMIPS).
-- Mike Orr <sluggoster at gmail.com>
[ Thread continues here (6 messages/16.81kB) ]
| Share |
|
