Filesystem I/OCurrently the major focus of the dragonfly project is the developmentof a new filesystem, so it's interesting to see how well the dragonflyfilesystem layer performs. I created a 500MB memory filesystem (MFS)and used sysbench to perform multi-threaded random write I/O. Itseems that MFS cannot create file systems larger than 500MB, which wasa limiting factor on dragonfly and 4.11.
 Dragonfly 1.12 UP performance is about 30% lower than FreeBSD 4.11 UPperformance. Enabling SMP does not impose an overhead on this test,but there is no performance benefit seen from multiple threads, andinstead performance drops as low as FreeBSD 4.11 SMP performance athigh loads.
FreeBSD 7.0 does not support the MFS file system; the nearestalternative is the tmpfs filesystem which was used for this test.
The sysbench file I/O benchmark apparently has a race condition thatcause it to abort under high I/O load (enabling debugging shows thatsysbench is sometimes generating I/O requests that are out of range ofthe specified test parameters such as file size and number of files,so this appears to be a sysbench bug). This was only a factor on 7.0but the benchmarks were averaged over 5 trials to reduce error.
FreeBSD 7 scales to 3 simultaneous writers and peak SMP performance isa factor of 4 times higher than dragonfly peak performance and 2.6times higher than freebsd 4 performance. FreeBSD 7 peak performancemay be limited by memory bandwidth rather than kernel scalinglimitations, although those come into play at higher loads.
FreeBSD 7.0 has a 20% overhead from SMP on this test compared to UP,which may be because the lockmgr primitive has not yet been optimizedfor SMP mode (this work is in progress). However, SMP performanceexceeds UP with a second writer, and SMP remains 17% faster than UP athigh loads.
UP performance on FreeBSD 7 is 2.6 times higher than dragonfly UPperformance and 1.8 times higher than freebsd 4 UP performance. It isunknown how much of this difference is due to the different design ofthe tmpfs filesystem.
NetworkingNetworking is the major subsystem that has received SMP developmentwork in dragonfly, although it was never completed and still does notallow concurrency in network processing (FreeBSD has a parallelizednetwork stack, and further performance work is ongoing in FreeBSD8.0).
I did not directly test network performance as e.g. a DNS or webserver. I can do this if someone is interested.
NFS performance on this hardware was anomalously low in both 4.11 anddragonfly, averaging only about 300KB/sec on an intel gigabit ethernetNIC. This did not impact the other benchmarks because they were notperforming NFS I/O.
StabilityThe assertion is often made by dragonfly project supporters thatdragonfly has "much better" stability than FreeBSD. It is not clearby what metric this is being objectively evaluated (if at all). Adirect measurement of stability is desirable.
One measure of system stability is the ability to function correctlyunder extreme overload conditions. This tends to provoke raceconditions and other exceptions at a higher frequency than at thelight loads encountered on desktop systems.
To simulate system overload I ran the stress2 benchmark suite on the8-core xeon. This is a suite of test applications that impose massiveoverload on the system under various concurrent workloads. FreeBSD isable to run this test suite indefinitely without errors.
The first problem was encountered while trying to unpack the stress2archive to NFS:
# ls
stress2.tgz
# tar xvf stress2.tgz
tar: Error opening archive: Failed to open 'stress2.tgz': No such file or directory
# ls -l
ls: stress2.tgz: No such file or directory
total 0
This looks like it might be a bug with the dragonfly name cache.
After starting the stress suit, the system panicked in under 4minutes. Unfortunately I was unable to obtain details of the panicbecause the serial console was not working.
Obviously one panic does not demonstrate wide-ranging systeminstability, but it does point to a possible selection bias amongstthe project supporters, who may not be looking hard enough for thestability problems that exist.
SummaryAs with the dragonfly 1.8 kernel, the dragonfly 1.12 kernel does notscale to a second CPU on the benchmarks performed, and the limited SMPimplementation can cause a large performance loss at higher loads.There is sometimes a large performance overhead from enabling SMPcompared to UP, and performance was sometimes worse than that of 4.11.In all cases measured, FreeBSD 7.0 performs significantly better thanboth FreeBSD 4.11 and dragonfly 1.12 in both SMP and UPconfigurations.
共3页: 上一页 [1] 2 [3] 下一页 |
