xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Steven Haigh <netwiz@crc.id.au>
To: konrad.wilk@oracle.com
Cc: roger.pau@citrix.com, xen-devel@lists.xen.org
Subject: Re: 4.2.1: Poor write performance for DomU.
Date: Mon, 25 Mar 2013 13:21:09 +1100	[thread overview]
Message-ID: <514FB495.2000200@crc.id.au> (raw)
In-Reply-To: <514EC323.3040106@crc.id.au>

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?

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

  parent reply	other threads:[~2013-03-25  2:21 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 [this message]
2013-08-20 16:48                             ` Konrad Rzeszutek Wilk
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=514FB495.2000200@crc.id.au \
    --to=netwiz@crc.id.au \
    --cc=konrad.wilk@oracle.com \
    --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).