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 <sk...@ithnet.com> wrote: > On Fri, 30 May 2014 16:53:50 +0000 > dw+qemu-disc...@hmmz.org 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 > > > >
