[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] block IO latency tracker without using QMP socket.
From: |
Benoît Canet |
Subject: |
Re: [Qemu-devel] block IO latency tracker without using QMP socket. |
Date: |
Thu, 28 Aug 2014 17:00:44 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
The Thursday 28 Aug 2014 à 13:36:35 (+0100), Stefan Hajnoczi wrote :
> On Wed, Aug 27, 2014 at 04:58:12PM +0200, Anshul Makkar wrote:
> > I am writing a block IO latency tracker.
> >
> > As obvious, I am calculating the latency by tracking the interval between
> > start of IO and end of IO.
> > (firing my latency tracker from function BlockDriverAIOCB *raw_aio_submit()
> > raw-posix.c when job is submitted).
> >
> > The latency data per QEMU process will be written to shared memory and then
> > another app uses this shared memory to read the data. That's a simple
> > architecture.
> >
> > Can't use "info blockstats" QMP command as qmp socket is used and blocked
> > by some other process in our subsystem.
> >
> > Just want a suggestion whether my approach is correct given the constraint
> > that I can't use qmp socket or if any alternative is possible.
>
> Simplest option: use iostat(1) inside the guest.
>
> Or you can use tracing tools to measure block I/O request latency.
>
> An example from a few years ago:
> http://www.linux-kvm.org/page/Virtio/Block/Latency
>
> It depends what you are trying to achieve.
Stefan: ProfitBrick is a cloud provider.
This means they could prepare AMI (Virtual machine images) with stuff in it but
they never would access the shell of a running VM.
What happen in the guest after the AMI instanciation into a running VM is the
end user business and the cloud provider should not violate the end user
territory.
I also agree that having QEMU collecting latencies statistics would be very
useful.
Best regards
Benoît
>
> Stefan