All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Priebe <s.priebe@profihost.ag>
To: Andrey Korolyov <andrey@xdel.ru>
Cc: Mark Nelson <mark.nelson@inktank.com>,
	"pve-devel@pve.proxmox.com" <pve-devel@pve.proxmox.com>,
	"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: Limited IOP/s on Dual Xeon KVM Host
Date: Sat, 10 Nov 2012 22:21:08 +0100	[thread overview]
Message-ID: <509EC544.3030000@profihost.ag> (raw)
In-Reply-To: <CABYiri8_1JVQqMHBCMqQGGg-XzfZrL7YVSYHZbQ3K92NSDGyVQ@mail.gmail.com>

Got it fixed by Bios update... crazy.

Am 10.11.2012 17:00, schrieb Andrey Korolyov:
> On Sat, Nov 10, 2012 at 5:49 PM, Stefan Priebe <s.priebe@profihost.ag> wrote:
>> Am 10.11.2012 14:41, schrieb Mark Nelson:
>>
>>> On 11/10/2012 02:03 AM, Stefan Priebe wrote:
>>>>
>>>> Hello lists,
>>>>
>>>> on a dual Xeon KVM Host i get max 6000 IOP/s random 4k writes AND reads.
>>>> On a Single Xeon KVM Host i get 17.000-18.000 IOP/s write and read. I
>>>> already tried to pin the kvm process using numactl and also the fio
>>>> process but it doesn't help on the dual xeon.
>>>>
>>>> 10GBE Network is fine. I get 9.8Gbit/s on both hosts. Kernel is also he
>>>> same on both.
>>>>
>>>> Anybody an idea?
>>>
>>>
>>> When you say KVM host, do you mean the underlying node or the virtual
>>> machine instance?
>>
>> Sorry i'm talking about the vm host regarding the HW. The vm instance is
>> always the same.
>>
>>
>>> If you mean underlying node, it could be remote memory access or if you
>>> are on a last gen xeon if you have dual io hubs, you could be hitting a
>>> remote io hub for the network card.  I wouldn't think that would cause
>>> such a big hit, but those are things to look into.
>>
>>
>> I'm on E5-Xeon. What means io hub?
>
> QPI path length, in other terms, numa distance(hope Mark means the
> same). Yes, it is impossible to have such degradation even in worst
> case on two-head node. I assume two possible things - you have pinned
> many processes on the core set which including default core for the
> network card` irq, please check it via /proc/interrupts, or you have
> not really did pinning and qemu process losing ticks by switching
> cores - it may be checked, say, by top and guest cpu bencmark. For the
> network card, it may be generally recommended to move its irq affinity
> to entire numa node to which it belongs.
>
>>
>>
>> Stefan
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

  parent reply	other threads:[~2012-11-10 21:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-10  8:03 Limited IOP/s on Dual Xeon KVM Host Stefan Priebe
2012-11-10 13:41 ` Mark Nelson
     [not found]   ` <509E5979.3070508-4GqslpFJ+cxBDgjK7y7TUQ@public.gmane.org>
2012-11-10 13:49     ` Stefan Priebe
2012-11-10 16:00       ` Andrey Korolyov
2012-11-10 19:16         ` Stefan Priebe
2012-11-10 21:21         ` Stefan Priebe [this message]
2012-11-11  9:14           ` Dietmar Maurer
2012-11-11 12:04             ` Stefan Priebe

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=509EC544.3030000@profihost.ag \
    --to=s.priebe@profihost.ag \
    --cc=andrey@xdel.ru \
    --cc=ceph-devel@vger.kernel.org \
    --cc=mark.nelson@inktank.com \
    --cc=pve-devel@pve.proxmox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.