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
next prev 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).