From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: VT is comically slow Date: Mon, 03 Jul 2006 04:48:57 -0400 Message-ID: <44A8D9F9.4020603@redhat.com> References: <44A8D54A.3000100@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <44A8D54A.3000100@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Rik van Riel wrote: > VT by itself seems fine, but once a VT domain is running a workload that > is network intensive combined with a disk/cpu intensive workload, things > get incredibly slow. > > Operations that take less than a second with either workload running > alone can now take many seconds, sometimes the better part of a minute! > > Is this some limitation of the qemu device model? Looking at it a bit more closely, it appears that postgresql doing disk IO from inside a fully virtualized domain totally kills the CPU. It gets so bad that a simple "dmesg" takes 10-20 seconds to start, and after that it spews data maybe 7 or 8 lines every other second. Actually slower than serial console... This is totally unusable :( -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan