From owner-freebsd-stable@FreeBSD.ORG Sat Aug 7 18:23:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E85851065673 for ; Sat, 7 Aug 2010 18:23:35 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 97C638FC08 for ; Sat, 7 Aug 2010 18:23:35 +0000 (UTC) Received: by qwg5 with SMTP id 5so4808131qwg.13 for ; Sat, 07 Aug 2010 11:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=xmyHEBYPbyae5MyEzEZOhZ94oWECbLDzhHE/Req2exc=; b=qe7wBG7YME2lLEnEo+XlvVk54CDxhadzyoHJl3rbBDtbwh68ubjUuxBwDs2+OKDzs0 vAYP2OxgHXvRnVUDM24RSQ/iPeRsI/BLTJgtwQVXJUwD9sYrjNQaez6dF7LaI4qysphM Rj3MTONnUJ5zUnEMPhIWshDlhlB5h4huKULnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=GvDmUKeA4bYFDg+HehdUTtpCWX0ZJPfQfc4RaZAGswc/872//lBwpIuy65sU0q+ke9 B72aQr+9Wty+d8KSqEKWXGeaktfRCnKZB769goKzvTiNDbwo0jtdWMScxEAJRyct6WWU iryUDwdypXMScIj6esyoO3mCKxodmT5DfGnD8= Received: by 10.229.71.68 with SMTP id g4mr5645708qcj.174.1281203915264; Sat, 07 Aug 2010 10:58:35 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.236.132 with HTTP; Sat, 7 Aug 2010 10:58:15 -0700 (PDT) In-Reply-To: References: From: Ivan Voras Date: Sat, 7 Aug 2010 19:58:15 +0200 X-Google-Sender-Auth: 32ZcBK6Eh4mFFqRR1rHrxHvE5Bo Message-ID: To: Joshua Boyd Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE Slow Write Speeds on ESXI 4.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 18:23:36 -0000 On 7 August 2010 19:03, Joshua Boyd wrote: > On Sat, Aug 7, 2010 at 7:57 AM, Ivan Voras wrote: >> It's unlikely they will help, but try: >> >> vfs.read_max=32 >> >> for read speeds (but test using the UFS file system, not as a raw device >> like above), and: >> >> vfs.hirunningspace=8388608 >> vfs.lorunningspace=4194304 >> >> for writes. Again, it's unlikely but I'm interested in results you >> achieve. >> > > This is interesting. Write speeds went up to 40MBish. Still slow, but 4x > faster than before. > [root@git ~]# dd if=/dev/zero of=/var/testfile bs=1M count=250 > 250+0 records in > 250+0 records out > 262144000 bytes transferred in 6.185955 secs (42377288 bytes/sec) > [root@git ~]# dd if=/var/testfile of=/dev/null > 512000+0 records in > 512000+0 records out > 262144000 bytes transferred in 0.811397 secs (323077424 bytes/sec) > So read speeds are up to what they should be, but write speeds are still > significantly below what they should be. Well, you *could* double the size of "runningspace" tunables and try that :) Basically, in tuning these two settings we are cheating: increasing read-ahead (read_max) and write in-flight buffering (runningspace) in order to offload as much IO to the controller (in this case vmware) as soon as possible, so to reschedule horrible IO-caused context switches vmware has. It will help sequential performance, but nothing can help random IOs.