Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Sep 1999 19:05:15 +0200
From:      Brad Knowles <blk@skynet.be>
To:        Adrian Filipi-Martin <adrian@ubergeeks.com>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: Vinum performance testing...
Message-ID:  <v0420551eb4057ffd4cfe@[195.238.1.121]>
In-Reply-To:  <Pine.BSF.3.96.990915122410.461A-100000@lorax.ubergeeks.com>
References:   <Pine.BSF.3.96.990915122410.461A-100000@lorax.ubergeeks.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 12:29 PM -0400 1999/9/15, Adrian Filipi-Martin wrote:

> 	Nice.  I can use these graphs when making arguments about whether
> to buy DPT's or other hardware.

	Keep in mind that these tests were done with old DPT hardware, 
not their most current stuff.

> 	My only question is have you thought about adding system CPU usage
> to the graphs?  It seems that under most cases CPU cycles are the only
> thing the DPT's are saving, but I have no idea how many cycles are spent by
> vinum.

	I was calling rawio with a particular set of command-line 
arguments as suggested to me by Greg Lehey (the author of vinum and 
rawio), so CPU utilization information was not captured.  I believe 
that this data is available with different sets of arguments to 
rawio, but the output would be quite a bit messier and not nearly so 
easy to turn into a spreadsheet.


	My inclination would be to continue to run the tests in basically 
the same way I have been, but to instead also run some additional 
tests on certain specific test configurations of interest (e.g., 
vinum 4-Way stripe with 256KB stripe size and 256 sector average 
transfer size) to capture this information only for those specific 
tests.

	This way you've got the kind of CPU utilization information you 
want, but you didn't waste a lot of time and effort in attempting to 
collect that information for the entire battery of tests.


	I can say that the few tests I do recall running that provided 
more detail, CPU utilization from vinum was very minimal.  One test I 
have a record of running on this same configuration reported the 
following:

/usr/local/bin/rawio -s 45660241920 -v 1 /dev/vinum/data1
>Test name:                  anon
>Transfer count:            32768
>Record count:              16384
>Process count:                 8
>Device size:          2147483647
>Test    ID           Time      KB/sec    %User    %Sys  %Total  Reads   Writes
>RR     anon    781.799011      2700.7     0.1      6.7     6.8  131072  0
>SR     anon    994.598389      4318.3     0.1      7.3     7.3  131072  0
>RW     anon   2871.548584       736.3     0.0      1.9     1.9  0       131072
>SW     anon    195.158478     22007.6     0.2     60.8    60.9  0       131072

	Of course, this was with older versions of vinum and rawio, and I 
believe that the %Sys percentage reported was a bug that was fixed 
long ago.  Except for the Sequential Write test, you can see that the 
overall CPU utilization was less than 10% across the board, and less 
than 2% for the Random Write test (although that number seems 
suspiciously low and might also have been the result of a bug which 
has almost certainly been fixed since).

-- 
   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 & 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?v0420551eb4057ffd4cfe>