■ Benchmark Tool - bonnie

http://www.textuality.com/bonnie/
http://www.textuality.com/bonnie/advice.html

Bonnie is a benchmark which measures the performance of Unix file system operations. Bonnie is concerned with identifying bottlenecks. Bonnie performs a series of tests on a file of known size. If the size is not pecified, Bonnie uses 100 Mb; but that probably isn't enough for a big modern server - you your file to be a lot bigger than the available RAM.

The testing items include:

■Sequential Output
※Per-Character：
The file is written using the putc() stdio macro. The loop that does the writing should be small enough to fit into any reasonable I-cache. The CPU overhead here is that required to do the stdio code plus the OS file space allocation.

※Block：
The file is created using write(2). The CPU overhead should be just the OS file space allocation.

※Rewrite：
Each Chunk (currently, the size is 16384) of the file is read with read(2), dirtied, and rewritten with write(2), requiring an lseek(2). Since no space allocation is done, and the I/O is well-localized, this should test the effectiveness of the filesystem cache and the speed of data transfer.

■Sequential Input：
※Per-Character：
The file is read using the getc() stdio macro. Once again, the inner loop is small. This should exercise only stdio and sequential input.

※Block：
The file is read using read(2). This should be a very pure test of sequential input performance.

■Random Seeks
This test runs SeekProcCount (currently 4) processes in parallel, doing a total of 4000 lseek()s to locations in the file computed using by random() in bsd systems, drand48() on sysV systems. In each case, the block is read with read(2). In 10% of cases, it is dirtied and written back with write(2). The idea behind the SeekProcCount processes is to make sure there's always a seek queued up.

---

■指令用法
./Bonnie [-d scratch-dir] [-s size-in-Mb] [-m machine-label] [-html]

[-d scratch-dir]
The name of a directory; Bonnie will write and read scratch files in this directory. Bonnie does not do any special interpretation of the directory name, simply uses it as given. Suppose you used -d /raid1/TestDisk; Bonnie would write, then read back, a file whose name was something like /raid1/TestDisk/Bonnie.34251.
If you do not use this option, Bonnie will write to and read from a file in the current directory, using a name something like ./Bonnie.35152.

Bonnie does clean up by removing the file after using it; however, if Bonnie dies in the middle of a run, it is quite likely that a (potentially very large) file will be left behind.

[-s size-in-Mb]
The number of megabytes to test with. If you do not use this, Bonnie will test with a 100Mb file. In this discussion, Megabyte means 1048576 bytes. If you have a computer that does not allow 64-bit files, the maximum value you can use is 2047.

[-m machine-label]
This is the label that Bonnie will use to label its report. If you do not use this, Bonnie will use no label at all.

[-html]
If you use this, Bonnie will generate a report in HTML form, as opposed to plain text. This is not all that useful unless you are prepared to write a table header.

---

■執行結果範例： 參考自 http://www.textuality.com/bonnie/advice.html
      
mystery：This test was run with the option -m mystery , "mystery" is the label for the test.
750：This test was run with the option
-s 750：Bonnie used a 750-Megabyte file to do the testing. For the numbers to be valid, the computer had better not have had more than about 200M of memory.
534：When writing the file by doing 750 million putc() macro invocations, Bonnie recorded an output rate of 534 K per second.
65.7：When writing the file by doing 750 million putc() macro invocations, the operating system reported that this work consumed 65.7% of one CPU's time. This is not very good; it suggests either a slow CPU or an inefficient implementation of the stdio interface.
1236：When writing the 750-Mb file using efficient block writes, Bonnie recorded an output rate of 1,236 K per second.
22.5：When writing the 750-Mb file using efficient block writes, the operating system reported that this work consumed 22.5% of one CPU's time.
419：While running through the 750-Mb file just creating, changing each block, and rewriting, it, Bonnie recorded an ability to cover 418 K per second.
17.5：While running through the 750-Mb file just creating, changing each block, and rewriting, it, the operating system reported that this work consumed 17.5% of one CPU's time.
564：While reading the file using 750 million getc() macro invocations, Bonnie recorded an input rate of 564 K per second.
74.3：While reading the file using 750 million getc() macro invocations, the operating system reported that this work consumed 74.3% of one CPU's time. This is amazingly high.
1534：While reading the file using efficient block reads, Bonnie reported an input rate of 1,534 K per second.
32.8：While reading the file using efficient block reads, the operating system reported that this work consumed 32.8% of one CPU's time.
35.0：Bonnie created 4 child processes, and had them execute 4000 seeks to random locations in the file. On 10% of these seeks, they changed the block that they had read and re-wrote it. The effective seek rate was 32.8 seeks per second.
8.3：During the seeking process, the operating system reported that this work consumed 8.3% of one CPU's time.