In May 2007 I ran some benchmarks of Dragonfly 1.8 to evaluateprogress of its SMP implementation, which was the original focus ofthe project when it launched in 2003 and is still widely believed tobe an area in which they had made concrete progress. This was part ofa larger cross-OS multiprocessor performance evaluation comparingimprovements in FreeBSD to Linux, NetBSD and other operating systems.
The 2007 results showed essentially no performance increase frommultiple processors on dragonfly 1.8, in contrast to the performanceof FreeBSD 7.0 which scaled to 8 CPUs on the benchmark.
Recently Dragonfly 1.12 was released, and the question was raised on the dragonfly-users mailing list of how well the OS performs after afurther year of development. I performed several benchmarks to studythis question.
In this round of testing I compared Dragonfly 1.12, FreeBSD 4.11 andFreeBSD 7.0, running on the same 8-core Xeon hardware. On Dragonflythe GENERIC kernel configuration was used except for enabling SMP andAPIC_IO (for the SMP tests), and removing I486_CPU. Under FreeBSD theGENERIC kernel was used except for enabling the SCHED_ULE scheduler on7.0, removing I486_CPU and enabling SMP when appropriate. The testapplications were compiled from ports/pkgsrc and the sameversions and configuration options used for each OS.
MySQLThis is a good general test of kernel performance and parallelism, aswell as performance of the thread library. MySQL performance(together with PostgreSQL performance) has been a driving force inFreeBSD, Linux and NetBSD SMP development over the past year: MySQL configuration is the same as in my previous test and is alsodocumented here
Here are the results:
 Dragonfly 1.12 achieves peak SMP performance of only 15% better thanUP performance, and drops to about 50% below UP performance at higherloads. Enabling SMP has a 20% performance overhead on this benchmark.
UP mode is faster than 4.11 when using the libthread_xu library. Withlibc_r (not graphed) performance is identical to 4.11 in both UP andSMP mode, so the UP performance increase is most likely due to thethread library.
Note: I am using mysql 5.0.51 in the current tests, which hasdifferent performance characteristics than the older 5.0.37 testedlast year, so the current data cannot directly be compared to theprevious dragonfly 1.8 graphs to evaluate whether a small amount ofprogress was made since 1.8. However, there does not appear to be anysignificant performance improvement from dragonfly 1.8 to 1.12.
FreeBSD 7.0 scales to 8 CPUs on this benchmark. Peak performance is6.5 times higher than peak dragonfly performance, and 9.0 times higherthan FreeBSD 4.11 performance. UP performance is consistent with SMPperformance with a single thread. 7.0 UP is 45% faster than 4.11 UPand 10% faster than dragonfly UP.
Note that while these benchmarks are on a test system with 8 CPUcores, the results also provide information about performance onsystems with fewer than 8 cores, such as dual core systems. If thesystem does not show appreciable performance gain when 2 threads areactive and most CPUs are idle, it is unlikely to perform much betterwhen the system only has 2 CPUs. I could not test this directlybecause I don't know how to disable CPUs at boot time/run time indragonfly.
For example, this graph shows FreeBSD 7.0 running postgresql on thesame system with 1, 2, 4 or 8 CPU cores active, as well as comparingthe UP and SMP kernel running with 1 CPU active
 The performance seen with 8 CPUs also scales down to 1, 2 and 4 CPUs.This also shows that there is negligible overhead from running theFreeBSD 7.0 SMP kernel on a UP system on this workload.
共3页: 上一页 1 [2] [3] 下一页 |
