[Qemu-discuss] apt-get fsync in VM (Was: Disk Performance)

[Quentin Hartman]

So! I've corrected the configuration of my Ceph cluster and am now getting about 70MB/s writes and 85MB/s reads inside VM's backed by rbd volumes. Generally performance of these machines "feels" quite good, which supports the consistent results I'm getting from iozone, dbench, and dd [1]. However, specifically when installing packages using apt-get it's still taking forever, often causing chef-client timeouts and all sorts of other pain. This does not seem to happen with instances that are booting from locally-stored images. Presumably this is due to apt-get's somewhat notorious fsync behavior [2].

Have any of you seen this behavior in Ubuntu or Debian based VMs? If so, have you discovered a way to overcome it?

Thanks!

QH

[1] - I got criticized previously for using dd for benchmarking, and I admit it is not the most in-depth test, but the results I got from it have been consistent with what I got from "better" tools, so I think it is probably fine if you just need something quick to see which way the wind is blowing.

[2] - google "apt-get fsync" for lots of talk on the topic if you're not familiar. especially https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588254

On Fri, May 30, 2014 at 11:13 AM, Stephan von Krawczynski <address@hidden> wrote:

On Fri, 30 May 2014 16:53:50 +0000
address@hidden wrote:

> On Fri, May 30, 2014 at 06:47:15PM +0200, Stephan von Krawczynski wrote:
>
> > > I'm no expert on this, but it sounds to me like the file copy is using
> > > memory to cache disk blocks, swapping out the memory that is the
> > > emulated memory of the guests.  It seems to me that the solution to
> > > that is to force the Qemu process's memory space to remain in RAM.
> > >
> > > Is there a way to do that in Linux?
> >
> > No.
>
> Unrelated to solving the original problem, just wanted to point out this
> is in fact trivially possible, and there have been patches in the past
> to implement it.
>
> See http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg05081.html
> and http://linux.die.net/man/2/mlockall
>
>
> David

Well, I guess you mean "-realtime mlock=on" option. It did not help me.

Regards,
Stephan