From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRNHm-00005M-KK for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:15:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRNHi-0004Hz-7J for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:15:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRNHh-0004Hr-TH for qemu-devel@nongnu.org; Thu, 25 Oct 2012 09:15:42 -0400 Message-ID: <50893B7A.2010800@redhat.com> Date: Thu, 25 Oct 2012 15:15:38 +0200 From: Orit Wasserman MIME-Version: 1.0 References: <5088F46D.6080605@profihost.ag> <508909F4.8020100@redhat.com> <508915DE.5080509@profihost.ag> <508924E1.3@redhat.com> <50892E08.5090404@profihost.ag> In-Reply-To: <50892E08.5090404@profihost.ag> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] slow xbzrle List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Priebe - Profihost AG Cc: qemu-devel On 10/25/2012 02:18 PM, Stefan Priebe - Profihost AG wrote: > Am 25.10.2012 13:39, schrieb Orit Wasserman: >> 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. > > sure here are some values from a loaded VM (20% cpu load with MySQL) - with an increased cache size does not look much better: > > Oct 25 14:16:39 migration xbzrle cachesize: 536870912 transferred 0 pages 0 cachemiss 159634 overflow 0 > Oct 25 14:16:41 migration xbzrle cachesize: 536870912 transferred 0 pages 0 cachemiss 173631 overflow 0 > Oct 25 14:16:43 migration xbzrle cachesize: 536870912 transferred 0 pages 0 cachemiss 187627 overflow 0 > Oct 25 14:16:45 migration xbzrle cachesize: 536870912 transferred 0 pages 0 cachemiss 201624 overflow 0 It looks like the cache got smaller 1073741824 > 536870912 ... try 2G cache size Orit > > Greets, > Stefan