WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Aoe or iScsi???

To: Adi Kriegisch <adi@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-users] Aoe or iScsi???
From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
Date: Fri, 9 Jul 2010 15:08:08 +0200
Cc: Adi Kriegisch <kriegisch@xxxxxxxx>, Gilberto Nunes <gilberto.nunes@xxxxxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 09 Jul 2010 06:09:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100708121800.GN14460@xxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <1278331728.1787.12.camel@note-311a> <201007080954.13843.bart.coninckx@xxxxxxxxxx> <20100708121800.GN14460@xxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.4 (Linux/2.6.31.12-0.2-desktop; KDE/4.3.5; x86_64; ; )
On Thursday 08 July 2010 14:18:00 Adi Kriegisch wrote:
> Hi!
> 
> [SNIP]
> 
> > >  latency.) 2. measure the IOPS you get. I personally prefer using
> > > FIO[3] which is readily available in Debian. FIO is fully configurable;
> > > there are however some reasonable examples which you might use:
> > >    /usr/share/doc/fio/examples/iometer-file-access-server mimiks a
> > > typical file server workload with 80% read. The IOPS calculator
> > > above[1] is only
> 
> [SNAP]
> 
> > I have been looking at FIO, but what jobfile do you use that you find
> > optimal to test network storage for Xen?
> 
> Actually this is a very hard to answer question! ;-)
> Short answer: I use iometer-file-access-server with (1) 80% (2) 100% (3) 0%
> read. Then I have a feeling for what I may expect from the hardware...
> 
> Long answer:
> Benchmarking is actually about lying -- depending on who is doing those
> benchmarks. There is an excellent presentation about benchmarking by Greg
> Smith of Postgres fame[1] stating some universal truths about how to
> conduct benchmarks.
> The most important part is to know what you need: The more details you have
> the less you're lying or the less you're in danger of being lied to.
> In benchmarking terms this means defining an I/O profile. To get that right
> you need to monitor your existing infrastructure (eg by collecting the
> output of 'iostat') and conducting the very same benchmarks you're doing on
> your new hardware on the old one as well.
> One of my servers reports the following on iostat for a disk containing
> some mailboxes:
> Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
> sda              45.40       356.65       158.90 2005866781  893707736
> 
> This means: Since power-on (65 days in this case) the server does 45 IOPS
> on average per second. Now it is up to me to know if this server does about
> the same amount of work 24/7 or if it is only busy during the day (which
> means that you need to calculate two or three times the IOPS for 12 or 8
> hours being really busy. (This is a file server scenario in an average
> office. ie: 45*(24/12) or 45*(24/8))
> The next thing I get is the ratio between reads and writes:
> 1% .............. (2005866781 + 893707736)/100
> read percent .... 2005866781/2005866781.0/percent = 69.2 %
> write percent ... 893707736.0/percent = 30.8 %
> 
> There is one more very important thing in the output of iostat:
> (this is actually from a different machine than the above) the average cpu
> usage:
> avg-cpu:  %user   %nice %system %iowait  %steal   %idle
>           10.35    2.44    5.69    8.63    0.00   72.89
> 
> This shows that the system spends more than 8% of its time on waiting for
> the completion of outstanding I/Os (which is a bad thing ;-) ).
> 
> With those numbers one is able to get a better understanding of what
> servers are doing. Using that information gives the ability to create a
> set of FIO jobfiles that roughly describe the workload expected and shows
> wether a storage backend (and in parts the rest of the systems) is able to
> handle that.
> When you're doing benchmarks from time to time you'll get a feeling for
> what a storage backend can handle when looking at FIO's results. Using your
> own jobfiles with more jobs running in parallel (numjobs=..), using
> different block sizes (either blocksize=Xk where x is 4,8,... or mixing
> blocksizes as done in iometer-file-access-server) and finding a balance
> between read and write transactions you might see more clearly if a storage
> system can handla your specific workload.
> 
> Do those benchmarks in your own setup. Do not let someone else do them for
> you. In case of network storage, be it iSCSI, AoE, NFS or whatever, refrain
> running the benchmarks on the storage system itself: The results will not
> reflect the real throughput of the system, numbers will almost always be
> higher!
> 
> Uh, quite a lot of text again... ;) Hope this helps! Feedback and
> discussion apprechiated...
> 
> -- Adi
> 
> [1]
>  http://www.pgcon.org/2009/schedule/attachments/123_pg-benchmarking-2.pdf
> 


Adi,

most useful and elaborate info, thx a mille!!!

B.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>