--- name: "bonnie" section: "1" platform: "linux" package: "bonnie" version: "1-3" release: "Debian 2.2 (Potato)" platforms: ["linux"] url: "https://new.carta.tech/bonnie" --- # bonnie(1) Unix filesystem performance benchmark ## NAME bonnie - Unix filesystem performance benchmark ## SYNOPSIS **bonnie** \[ -d scratch-dir \] \[ -s size-in-Mb \] \[ -m machine-label \] ## OPTIONS - **-d scratch-dir** **Directory to create working file in. Filesystem must be large enough to** **accomodate the size of the working file.** - **-s size-in-Mb** **Size of the working file in megabytes. Defaults size is 100 megabytes. The** **larger the better.** - **-m machine-label** **Identifying label to use for the machine benchmark is being run on.** ## DESCRIPTION **bonnie is a file system benchmark which attempts to study bottlenecks -** **it is named 'Bonnie' for semi-obvious reasons.** **Specifically, 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 performs a series of tests on a file of known size. By default, that** **size is 100 Mb (but that's not enough - see below). For each test, Bonnie** **reports the bytes processed per elapsed second, per CPU second, and the** **% CPU usage (user and system).** **In each case, an attempt is made 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. The tests are:** **1. Sequential Output** **1.1 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.** **1.2 Block. The file is created using [write(2)](/write/2.md). The CPU overhead** **should be just the OS file space allocation.** **1.3 Rewrite. Each BUFSIZ of the file is read with [read(2)](/read/2.md), dirtied, and** **rewritten with [write(2)](/write/2.md), requiring an [lseek(2)](/lseek/2.md). 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.** **2. Sequential Input** **2.1 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.** **2.2 Block. The file is read using [read(2)](/read/2.md). This should be a very pure** **test of sequential input performance.** **3. Random Seeks** **This test runs SeekProcCount processes in parallel, doing a total of** **4000 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)](/read/2.md).** **In 10% of cases, it is dirtied and written back with [write(2)](/write/2.md).** **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)](/lseek/2.md) calls** **per second declines asymptotically to near 30, once the effect of** **caching is defeated.** **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.** ## COPYRIGHT **Copyright (c) Tim Bray, 1990.** **Everybody is hereby granted rights to use, copy, and modify this program,** **provided only that this copyright notice and the disclaimer below** **are preserved without change.** **DISCLAIMER:** **This program is provided AS IS with no warranty of any kind, and** **The author makes no representation with respect to the adequacy of this** **program for any particular purpose or with respect to its adequacy to** **produce any particular result, and** **The author shall not be liable for loss or damage arising out of** **the use of this program regardless of how sustained, and** **In no event shall the author be liable for special, direct, indirect** **or consequential damage, loss, costs or fees or expenses of any** **nature or kind.** ## BUGS **None known** ## AUTHOR **Tim Bray \**