On Tue, 2008-07-15 at 19:20 -0500, Jon Nelson wrote: > On Tue, Jul 15, 2008 at 7:01 PM, Richard Scobie <richard@xxxxxxxxxxx> wrote: > > Keld Jørn Simonsen wrote: > > > >> I would actually welcome more tests with specific user profiles, like > >> many small reads and writes for database use, and concurrent random > >> reading and writing to simulate the load on a server. What bonnie++ is > >> reporting is only equential IO. This is important on work stations, but > >> actually not on servers. > > > > The following is from the Bonnie++ man page: > > > > "There are two sections to the program's operations. The first is to > > test the IO throughput in a fashion that is designed to simulate some > > types of database applications. The second is to test creation, reading and > > deleting many small files in a fashion similar to the usage patterns of > > programs such as Squid or INN." > > > > So I guess the author thinks it's valid for more than sequential I/O. > > > > In any case, while we may be in a minority, Justin, I and a few others are > > interested in sequential I/O, as we build servers required to read > and write > > multiple streams of uncompressed SD and HD video in realtime. > > In that case, the 'fstest' program (google for it, it's associated > with the samba folks IIRC), might be just the ticket. > You specify the number of children (real children, not threads), the > number of files each child will open, populate, verify, and then > delete, the size of the files, and a few other options. It very nicely > simulates a set of totally greedy I/O intensive processes. > I was thinking of benchmarks at a higher level too. fstest and fio seem like good candidates for making a configuration that tests performance that can be easily run on another system without much setup required. A few other ideas I had were using postal for simulating a mail server env and doing "something" with PostgreSQL. The latter is really a fairly large can of worms because you would need to lock down the various RAID caches, read aheads (which might actually adversely effect performance if the kernel second guesses PG badly), the pg configuration (eg, its caching settings) and of course where the base tables and indexes landed on disk. If anyone has pointers for testing PG performance on RAID I'd love to hear about them either on / off list.
Attachment:
signature.asc
Description: This is a digitally signed message part
