Thumper benchmarks
| Line 12: | Line 12: | ||
I ran the benchmark again while taking a 'zfs snapshot' every 30 seconds (to simulate filesystem replication to another host). I tested with the snapshots only, and with an incremental 'zfs send' after each snapshot. This seemed to have no impact on performance. | I ran the benchmark again while taking a 'zfs snapshot' every 30 seconds (to simulate filesystem replication to another host). I tested with the snapshots only, and with an incremental 'zfs send' after each snapshot. This seemed to have no impact on performance. | ||
| + | |||
| + | I ran the same benchmark over NFS, with filebench running on ms2. This achieved 121MB/sec (close to the GE limit) and 120 operations/sec. It would be interesting to try this with smaller files. | ||
Revision as of 14:50, 26 September 2008
I ran some testing on the new thumpers using filebench. I tested Solaris 10 Update 5, all current patches installed, with ZFS. The machines have 48 250GB disks, configured as two root disks, 44 data disks, and two hotspares (unused in this test). It has 2 dual-core 2.8GHz Opterons and 16GB RAM.
I first tested with a workload designed to simulate the images workload on amane. This started 2 "uploader" threads; these deleted one file, created two new files (of a random size up to 1MB), then slept for 2 seconds. Concurrently, it started 100 "webservers" threads; these opened a random file, read its entire contents in 64KB blocks, then closed it.
I prepared the benchmark by creating 25,000 files in a filesystem, totalling about 25GB. Notice this size exceeds the system's RAM.
Over a 1200-second run, the system achieved 1MB/sec write performance (expected given the low workload) and 726MB/sec read performance. On average, 725 entire file reads per second was achieved (this suggests that file size did not greatly affect the performance; probably caused by ZFS's aggressive read-ahead).
Next I ran the same benchmark with 20 creator threads (that is, 10 times the write workload) and ran for 1200 seconds again. This produced 10MB/sec writes and 900MB/sec reads (possibly because of caching? need to re-run this one.)
Then I re-ran both benchmarks with an fsync() after every file write (this is a more accurate simulation of NFS, which requires synchronous writes). This produced no apparent performance decrease in either benchmark, although significantly more disk writing was noticed in 'zpool iostat'.
I ran the benchmark again while taking a 'zfs snapshot' every 30 seconds (to simulate filesystem replication to another host). I tested with the snapshots only, and with an incremental 'zfs send' after each snapshot. This seemed to have no impact on performance.
I ran the same benchmark over NFS, with filebench running on ms2. This achieved 121MB/sec (close to the GE limit) and 120 operations/sec. It would be interesting to try this with smaller files.
