xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Steven Haigh <netwiz@crc.id.au>
Cc: roger.pau@citrix.com, xen-devel@lists.xen.org
Subject: Re: 4.2.1: Poor write performance for DomU.
Date: Tue, 20 Aug 2013 12:48:26 -0400	[thread overview]
Message-ID: <20130820164826.GC11652@phenom.dumpdata.com> (raw)
In-Reply-To: <514FB495.2000200@crc.id.au>

On Mon, Mar 25, 2013 at 01:21:09PM +1100, Steven Haigh wrote:
> So, based on my tests yesterday, I decided to break the RAID6 and
> pull a drive out of it to test directly on the 2Tb drives in
> question.
> 
> The array in question:
> # cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4]
> md2 : active raid6 sdd[4] sdc[0] sde[1] sdf[5]
>       3907026688 blocks super 1.2 level 6, 128k chunk, algorithm 2
> [4/4] [UUUU]
> 
> # mdadm /dev/md2 --fail /dev/sdf
> mdadm: set /dev/sdf faulty in /dev/md2
> # mdadm /dev/md2 --remove /dev/sdf
> mdadm: hot removed /dev/sdf from /dev/md2
> 
> So, all tests are to be done on /dev/sdf.
> Model Family:     Seagate SV35
> Device Model:     ST2000VX000-9YW164
> Serial Number:    Z1E17C3X
> LU WWN Device Id: 5 000c50 04e1bc6f0
> Firmware Version: CV13
> User Capacity:    2,000,398,934,016 bytes [2.00 TB]
> Sector Sizes:     512 bytes logical, 4096 bytes physical
> 
> From the Dom0:
> # dd if=/dev/zero of=/dev/sdf bs=1M count=4096 oflag=direct
> 4096+0 records in
> 4096+0 records out
> 4294967296 bytes (4.3 GB) copied, 30.7691 s, 140 MB/s
> 
> Create a single partition on the drive, and format it with ext4:
> Disk /dev/sdf: 2000.4 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disk identifier: 0x98d8baaf
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdf1            2048  3907029167  1953513560   83  Linux
> 
> Command (m for help): w
> 
> # mkfs.ext4 -j /dev/sdf1
> ......
> Writing inode tables: done
> Creating journal (32768 blocks): done
> Writing superblocks and filesystem accounting information: done
> 
> Mount it on the Dom0:
> # mount /dev/sdf1 /mnt/esata/
> # cd /mnt/esata/
> # bonnie++ -d . -u 0:0
> ....
> Version  1.96       ------Sequential Output------ --Sequential
> Input- --Random-
> Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr-
> --Block-- --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec
> %CP /sec %CP
> xenhost.lan.crc. 2G   425  94 133607  24 60544  12   973  95 209114
> 17 296.4   6
> Latency             70971us     190ms     221ms   40369us   17657us
> 164ms
> 
> So from the Dom0: 133Mb/sec write, 209Mb/sec read.
> 
> Now, I'll attach the full disk to a DomU:
> # xm block-attach zeus.vm phy:/dev/sdf xvdc w
> 
> And we'll test from the DomU.
> 
> # dd if=/dev/zero of=/dev/xvdc bs=1M count=4096 oflag=direct
> 4096+0 records in
> 4096+0 records out
> 4294967296 bytes (4.3 GB) copied, 32.318 s, 133 MB/s
> 
> Partition the same as in the Dom0 and create an ext4 filesystem on it:
> 
> I notice something interesting here. In the Dom0, the device is seen as:
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> 
> In the DomU, it is seen as:
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> 
> Not sure if this could be related - but continuing testing:
>     Device Boot      Start         End      Blocks   Id  System
> /dev/xvdc1            2048  3907029167  1953513560   83  Linux
> 
> # mkfs.ext4 -j /dev/xvdc1
> ....
> Allocating group tables: done
> Writing inode tables: done
> Creating journal (32768 blocks): done
> Writing superblocks and filesystem accounting information: done
> 
> # mount /dev/xvdc1 /mnt/esata/
> # cd /mnt/esata/
> # bonnie++ -d . -u 0:0
> ....
> Version  1.96       ------Sequential Output------ --Sequential
> Input- --Random-
> Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr-
> --Block-- --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec
> %CP /sec %CP
> zeus.crc.id.au   2G   396  99 116530  23 50451  15  1035  99 176407
> 23 313.4   9
> Latency             34615us     130ms     128ms   33316us   74401us
> 130ms
> 
> So still... 116Mb/sec write, 176Mb/sec read to the physical device
> from the DomU. More than acceptable.
> 
> It leaves me to wonder.... Could there be something in the Dom0
> seeing the drives as 4096 byte sectors, but the DomU seeing it as
> 512 byte sectors cause an issue?

There is certain overhead in it. I still have this in my mailbox
so I am not sure whether this issue got ever resolved? I know that the 
indirect patches in Xen blkback and xen blkfront are meant to resolve
some of these issues - by being able to carry a bigger payload.

Did you ever try v3.11 kernel in both dom0 and domU? Thanks.
> 
> -- 
> Steven Haigh
> 
> Email: netwiz@crc.id.au
> Web: https://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> Fax: (03) 8338 0299

  reply	other threads:[~2013-08-20 16:48 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-20  2:10 4.2.1: Poor write performance for DomU Steven Haigh
2013-02-20  8:26 ` Roger Pau Monné
2013-02-20  8:49   ` Steven Haigh
2013-02-20  9:49     ` Steven Haigh
2013-02-20 10:12       ` Jan Beulich
2013-02-20 11:06         ` Andrew Cooper
2013-02-20 11:08           ` Steven Haigh
2013-02-20 12:48             ` Andrew Cooper
2013-02-20 13:18             ` Pasi Kärkkäinen
2013-03-08 20:42               ` Konrad Rzeszutek Wilk
2013-03-08  8:54       ` Steven Haigh
2013-03-08  9:43         ` Roger Pau Monné
2013-03-08  9:46           ` Steven Haigh
2013-03-08  9:54             ` Roger Pau Monné
2013-03-08 20:49         ` Konrad Rzeszutek Wilk
2013-03-08 22:30           ` Steven Haigh
2013-03-11 13:30             ` Konrad Rzeszutek Wilk
2013-03-11 13:37               ` Steven Haigh
2013-03-12 13:04                 ` Konrad Rzeszutek Wilk
2013-03-12 14:08                   ` Steven Haigh
     [not found]                   ` <514EA337.7030303@crc.id.au>
     [not found]                     ` <514EA6B0.8010504@crc.id.au>
     [not found]                       ` <514EA741.7050403@crc.id.au>
2013-03-24  9:10                         ` Steven Haigh
2013-03-24  9:54                           ` Steven Haigh
2013-03-25  2:21                           ` Steven Haigh
2013-08-20 16:48                             ` Konrad Rzeszutek Wilk [this message]
2013-08-20 18:25                               ` Steven Haigh
2013-09-05  8:28                               ` Steven Haigh
2013-09-06 13:33                                 ` Konrad Rzeszutek Wilk
2013-09-06 23:06                                   ` Steven Haigh
2013-09-06 23:37                                     ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130820164826.GC11652@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=netwiz@crc.id.au \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).