From: Roy Sigurd Karlsbakk <roy@karlsbakk.net>
To: linux-lvm <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] pvmove speed
Date: Fri, 17 Feb 2017 18:33:31 +0100 (CET) [thread overview]
Message-ID: <789911251.1077.1487352811794.JavaMail.zimbra@karlsbakk.net> (raw)
In-Reply-To: <22695.11391.98129.185244@quad.stoffel.home>
[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]
> Roy> I get 200MB on a cold day and 500 on a nice one from this
> Roy> SAN. These 40-50MB/s seem really being limited by pvmove
> Roy> alone. Nothing else shows this limit. That's why I'm asking.
> Roy> Vennlig hilsen / Best regards
>
> Is any one CPU pegged on your server running the pmove? It's probably
> single threaded and if it's a single LV you're moving, that might
> explain the problem.
No. CPU is hardly in use at all, and the little is spread across all four vcores - https://karlsbakk.net/tmp/pvmove-top.png. It's running on a very low-traffic host.
> It might also be that even though you have 4 x 1gb to one server,
> since it's the same IP pair on each end, it's not really spreading the
> load across all the links.
That would make sense if I got around 100MB/s from that, but I get a *total* of 100MB/s, read and write inclusive. The host machine is connected to 10Gbps, the new storage, dell compellent, is on 10Gbps, everything, really is 10Gbps except the old equallogic stuff, being on 4x1Gbps. For utilisation and bandwidth, see the munin graphs here https://karlsbakk.net/tmp/pvmove-munin.png. A pvmove /dev/sdc /dev/sde is currently running
> It might be faster to do a clone on the source side, and then use DD
> to copy the data from the quiet clone to the destination. Then mount
> the destination and use rsync to bring them up to sync.
It's not practically possible, since the amount of data is too high. Thus pvmove, to allow for concurrent use.
> But it would be helpful to see more details about the OS, etc.
It's not much to say - standard RHEL7 with some bits from EPEL, but basically just the normal bits. System is running on an ESXi 6.5 host. Old storage is raw device mappings to an Equallogic box (or two), new storage is VMFS 6. I really can't see any issues here, except the fact that the utilisation of sdc + sde == 100 and that this is constant.
So - any ideas?
roy
[-- Attachment #2: Skjermbilde 2017-02-17 kl. 18.23.41.png --]
[-- Type: image/png, Size: 510334 bytes --]
[-- Attachment #3: Skjermbilde 2017-02-17 kl. 18.21.22.png --]
[-- Type: image/png, Size: 288244 bytes --]
next prev parent reply other threads:[~2017-02-17 17:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-11 8:59 [linux-lvm] pvmove speed Roy Sigurd Karlsbakk
2017-02-16 18:22 ` Roy Sigurd Karlsbakk
2017-02-17 0:44 ` L A Walsh
2017-02-17 1:24 ` pattonme
2017-02-17 15:12 ` Roy Sigurd Karlsbakk
2017-02-17 17:01 ` John Stoffel
2017-02-17 17:33 ` Roy Sigurd Karlsbakk [this message]
2017-02-17 23:00 ` L A Walsh
2017-02-18 8:12 ` Roy Sigurd Karlsbakk
2017-02-18 16:55 ` Mark Mielke
2017-02-20 9:59 ` Zdenek Kabelac
2017-03-31 16:27 ` Roy Sigurd Karlsbakk
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=789911251.1077.1487352811794.JavaMail.zimbra@karlsbakk.net \
--to=roy@karlsbakk.net \
--cc=linux-lvm@redhat.com \
/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).