From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:53039)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <owasserm@redhat.com>) id 1TRLmT-0004Kz-WD
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 07:39:27 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <owasserm@redhat.com>) id 1TRLmQ-0004iw-1E
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 07:39:21 -0400
Received: from mx1.redhat.com ([209.132.183.28]:52054)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <owasserm@redhat.com>) id 1TRLmP-0004i8-PI
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 07:39:17 -0400
Message-ID: <508924E1.3@redhat.com>
Date: Thu, 25 Oct 2012 13:39:13 +0200
From: Orit Wasserman <owasserm@redhat.com>
MIME-Version: 1.0
References: <5088F46D.6080605@profihost.ag> <508909F4.8020100@redhat.com>
	<508915DE.5080509@profihost.ag>
In-Reply-To: <508915DE.5080509@profihost.ag>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] slow xbzrle
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
Cc: qemu-devel <qemu-devel@nongnu.org>

On 10/25/2012 12:35 PM, Stefan Priebe - Profihost AG wrote:
> Am 25.10.2012 11:44, schrieb Orit Wasserman:
>>> Is this known or is something wrong?
>> My guess this workload migrates fine without XBZRLE so it is not the speed or downtime :).
>> it could be that the cache size is too small resulting with a lot of cache misses which means
>> XBZRLE makes things worse and just uses CPU to maintain the cache.
>> Other option is that this workload changes the pages too much which can result with a lot of over flows
>> which result in XBZRLE to waste CPU scanning the pages.
>> As this is idle mysql my guess it the first scenario.
>>
>> Can you send the cache size, cache miss and overflow (from 'info migrate')?
> 
> Example got from a log file (it's the info from info migrate just in another format):
> migration xbzrle
> cachesize: 1073741824
> transferred 0
> pages 0
> cachemiss 1315374
Looks like a lot of cache miss, you can try increasing the cache size (migrate_set_cache_size).
But you should remember that for an idle guest XBZRLE is wasteful,
it is useful for workload that changes the same memory pages frequently.

Orit 
> overflow 0
> 
> Stefan