Date: Tue, 6 Apr 1999 14:57:25 +0200 From: Brad Knowles <blk@skynet.be> To: Tom <tom@uniserve.com> Cc: Mike Tancsa <mike@sentex.net>, doka@triton.kiev.sovam.com, freebsd-stable@FreeBSD.ORG Subject: Re: benchmark program Message-ID: <19990406145725.011137@relay.skynet.be> In-Reply-To: <Pine.BSF.4.02A.9904050812500.9618-100000@shell.uniserve.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 5, 1999, Tom <tom@uniserve.com> wrote:
> What (2**31) -1) problem?
I have been unable to create benchmark files much larger than 10GB,
and the sizes reported to me from bonnie have been very close to (2^31)-1
for files just slightly smaller than 10GB. For example:
>>mercury# bonnie -d /data1 -s 10230
>>File '/data1/Bonnie.4304', size: 2136997888
>>Writing with putc()...done
>>Rewriting...done
>>Writing intelligently...done
>>Reading with getc()...done
>>Reading intelligently...done
>>Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
>> -------Sequential Output-------- ---Sequential Input--
>>--Random--
>> -Per Char- --Block--- -Rewrite-- -Per Char- --Block---
>>--Seeks---
>>Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec
>>%CPU
>> 2038 20362 96.5 25710 50.3 4578 8.2 15820 77.3 16107 14.7
248.7 3.9
> Since the file is large, the cache is not useful.
If I've got a machine with 4GB of RAM, having a maximum file size
that I can test of 10GB means that a significant portion of the file can
fit into the buffer cache. Since the filesystem I'm currently testing is
42GB in size, I'd like to be able to use the entire thing for the test.
Of course, I don't have a machine today with 4GB of RAM, but that's a
distinct possibility in the not-to-distant future. At that time, the
machine would have filesystems on the order of 250GB in size, and again,
I'd like to be able to use the whole thing in order to guarantee that the
buffer cache has virtually no effect on the benchmark.
> Yes, bonnie is situated towards testing raw io performance.
Not really. It doesn't read and write directly to raw devices,
by-passing the filesystem and buffer cache, etc.... There are other (as
yet, unpublished) benchmarking programs that do read and write directly
from/to raw devices. However, I will let their author(s) speak for
themselves.
> Well, it shouldn't be hard to create one.
I can create one, but to make sure that it follows the appropriate
statistical distribution of file sizes and both sustained and burst
incoming article speed of a typical news server, will actually take a
fair amount of work.
I think I can cajole people like Jeremy Nixon and Russell Vincent to
give me enough statistical information that I can figure out minimum,
maximum, and typical distributions (including curve shape) of things like
file sizes, article arrival speeds, numbers of files per directory,
depths of directory hierarchies, etc....
However, writing the program to actually implement all of this will
still be non-trivial. I was hoping that someone might already have
something along these lines, or at least some tools that would test
things like mixes of creating large numbers of variously sized files and
deleting them, creating subdirectory hierarchies with various numbers of
subdirectories and deleting them, etc....
--
These are my opinions -- not to be taken as official Skynet policy
____________________________________________________________________
|o| Brad Knowles, <blk@skynet.be> Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin Rue Col. Bourg, 124 |o|
|o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o|
|o| http://www.skynet.be Belgium |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
Unix is very user-friendly. It's just picky who its friends are.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990406145725.011137>