bonnie++ details¶

(adapted from www.coker.com.au/bonnie++/readme.html)

The tests run by bonnie attempt to keep optimizers from noticing it’s all bogus. The idea is to make sure that these are real transfers to/from user space to the physical disk.

IO Test¶

These are the types of filesystem activity that have been observed to be bottlenecks in I/O-intensive applications, in particular the text database work done in connection with the New Oxford English Dictionary Project at the University of Waterloo.

It initially performs a series of tests on a file (or files) of known size. For each test, Bonnie reports the number of Kilo-bytes processed per elapsed second, and the % CPU usage (sum of user and system). If a size >1G is specified then we will use a number of files of size 1G or less.

Sequential Output¶

• put_c (K/s): 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.
• put_block (K/s): The file is created using write(2). The CPU overhead should be just the OS file space allocation.
• rewrite (K/s): Each BUFSIZ 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¶

• getc (K/s): The file is read using the getc() stdio macro. Once again, the inner loop is small. This should exercise only stdio and sequential input.

• get_block (K/s): The file is read using read(2). This should be a very pure test of sequential input performance.

Random Seeks¶

• seeks (K/s): This test runs SeekProcCount processes (default 3) in parallel, doing a total of 8000 lseek()s to locations in the file specified 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. AXIOM: For any unix filesystem, the effective number of lseek(2) calls per second declines asymptotically to near 30, once the effect of caching is defeated. One thing to note about this is that the number of disks in a RAID set increases the number of seeks. For read using RAID-1 (mirroring) will double the number of seeks. For write using RAID-0 will multiply the number of writes by the number of disks in the RAID-0 set (provided that enough seek processes exist). The size of the file has a strong nonlinear effect on the results of this test. Many Unix systems that have the memory available will make aggressive efforts to cache the whole thing, and report random I/O rates in the thousands per second, which is ridiculous. As an extreme example, an IBM RISC 6000 with 64 Mb of memory reported 3,722 per second on a 50 Mb file. Some have argued that bypassing the cache is artificial since the cache is just doing what it’s designed to. True, but in any application that requires rapid random access to file(s) significantly larger than main memory which is running on a system which is doing significant other work, the caches will inevitably max out. There is a hard limit hiding behind the cache which has been observed by the author to be of significant import in many situations – what we are trying to do here is measure that number.

Files Test¶

This test involves file create/stat/unlink to simulate some operations that are common bottlenecks on large Squid and INN servers, and machines with tens of thousands of mail files in /var/spool/mail.

The file creation tests use file names with 7 digits numbers and a random number (from 0 to 12) of random alpha-numeric characters. For the sequential tests the random characters in the file name follow the number. For the random tests the random characters are first.

The size of files is either zero bytes, or a random size within a specified range (we use a range of 0k to 15K). Files greater than zero bytes have random data written to them.

Sequential¶

• seq_create (files/second): files are created in numeric order.
• seq_stat (files/second): files are stat()ed in readdir() order (ie the order they are stored in the directory which is very likely the to be the same order as which they were created). Also, the data of files larger than 0 bytes is read.
• seq_del (files/second): files are then deleted in the same order.

Random¶

• ran_create (files/second): create the files in an order that will appear random to the file system (the last 7 characters are in numeric order on the files).
• ran_stat (files/second): we stat() random files (this will return very good results on file systems with sorted directories because not every file will be stat()ed and the cache will be more effective). Also, the data of files larger than 0 bytes is read.
• ran_del (files/second): we then delete all the files in random order.