[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Quentin Hartman
Subject: Re: [Qemu-discuss] apt-get fsync in VM (Was: Disk Performance)
Date: Mon, 9 Jun 2014 11:32:34 -0600

Just to follow up on this  for others. I ended up needing to change the ceph file system backend to xfs (from btrfs) and enable the "network=writeback" filesystem cache setting in my qemu config to get apt-get to behave well in VMs.


On Fri, Jun 6, 2014 at 2:07 PM, Quentin Hartman <address@hidden> wrote:
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?



[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]