2 x quad-core system is slower that 2 x dual core on FreeBSD

[Miroslav Lachman]

Tom Evans wrote:
> On Tue, 2007-12-04 at 13:00 +0100, Ivan Voras wrote:
> 
>>Krassimir Slavchev wrote:
>>
>>
>>>There is another report for such problems:
>>>
>>>http://blog.insidesystems.net/articles/2007/04/09/what-did-i-do-wrong
>>
>>Of course - FreeBSD 6.x is really bad at SMP where number of CPUs is
>>larger then about 2 and the loads include much kernel work (e.g. IO,
>>context switches). Numeric tasks (SSL) don't depend on the kernel and so
>>they scale ok. See
>>http://people.freebsd.org/~kris/scaling/Scalability%20Update.pdf for
>>details.
>>
>>Another issue is interesting in this thread: that apparently 7.0 also
>>has a well defined workload where it fails.
>>
> 
> 
> There is also his follow up to that post, comparing postgres on 6.2 with
> 7.0 (ULE and 4BSD schedulers).
> 
> http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
> 
> I'm very excited about getting some 7.0 servers into testing prior to
> deployment as production mysql boxes. Having run 7-CURRENT on my lappy
> for best part of 15 months, I think its supersmashinggreat :)

I know this thread is about SMP scalling, but most of my machines are UP 
(Sun Fire X2100) so I run my own synthetic benchmarks (super-smack on 
MySQL 5.0.45 and ab on Apache 2.2.6) on an old box with AMD Barton 2500+ 
with 512MB RAM.
I was a little disappointed, because FreeBSD 6.2 UP behaves better than 
FreeBSD 7.0-BETA3 (4BSD and ULE tested).

super-smack on 6.2
Query_type      num_queries     max_time        min_time        q_per_s
select_index    6000000         0               0              15061.63

super-smack on 7.0 (no metter if 4BSD or ULE)
Query_type      num_queries     max_time        min_time        q_per_s
select_index    6000000         0               0              14320.31

used command: super-smack select-key.smack 10 300000
results are from the second run

The Apache Benchmark result was same on 6.2 and 7.0 (about 165 req/s), 
but on 7.0 Apache forks more processes (MPM prefork was used) than on 6.2.
On 6.2 Apache has about 40 httpd processes running, but on 7.0 it has 
about 130 and console response was very very bad.

example of top from 7.0 running ab -c 15 -n 50000 
http://192.168.1.164/phpinfo.php

last pid:  1650;  load averages: 83.80, 33.58, 13.71 
                                                              up 
0+00:32:44  12:09:16
170 processes: 126 running, 43 sleeping, 1 zombie
CPU states: 65.9% user,  0.0% nice, 14.1% system, 19.9% interrupt,  0.0% 
idle
Mem: 140M Active, 20M Inact, 64M Wired, 5028K Cache, 34M Buf, 9708K Free
Swap: 512M Total, 41M Used, 470M Free, 8% Inuse

Console response was better with ULE than 4BSD, but stil not so smooth 
like in 6.2

So I will postpone upgrade of all my 6.2 UP machines until 7.x UP will 
behave better or 6.x will reach EOL.

Miroslav Lachman