From owner-freebsd-xen@freebsd.org Wed Sep 14 13:36:08 2016 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9C42BD9550 for ; Wed, 14 Sep 2016 13:36:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 995E91714 for ; Wed, 14 Sep 2016 13:36:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u8EDa8cB003697 for ; Wed, 14 Sep 2016 13:36:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-xen@FreeBSD.org Subject: [Bug 212681] I/O is slow for FreeBSD DOMu on XenServer Date: Wed, 14 Sep 2016 13:36:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: performance X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rainer@ultra-secure.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-xen@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 13:36:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212681 --- Comment #3 from rainer@ultra-secure.de --- Our hardware is local disks (not SSDs) networked via ScaleIO. I've run a dd from one disk of a VM to another one and it was very, very sl= ow. OS: "Other (64bit)" (which is actually a little bit faster than choosing "FreeBSD 10" (freebsd11 ) 0 # dc3dd wipe=3D/dev/ada1 dc3dd 7.2.641 started at 2016-08-18 13:24:02 +0200 compiled options: command line: dc3dd wipe=3D/dev/ada1 device size: 104857600 sectors (probed), 53,687,091,200 bytes sector size: 512 bytes (probed) 53687091200 bytes ( 50 G ) copied ( 100% ), 3084 s, 17 M/s input results for pattern `00': 104857600 sectors in output results for device `/dev/ada1': 104857600 sectors out dc3dd completed at 2016-08-18 14:15:26 +0200 The question remains: why is this and what can one do? One of our customers has an application-workload (php+mysql) that takes 3s = to process on an Ubuntu 16 VM with 2 vCPUs and 8GB RAM. The FreeBSD VM is completely unusable for this because it's bogged down to a halt, regardless of how many vCPUs and RAM I give it. --=20 You are receiving this mail because: You are the assignee for the bug.=