From owner-freebsd-performance@FreeBSD.ORG Sun Mar 4 22:16:51 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB36216A400 for ; Sun, 4 Mar 2007 22:16:51 +0000 (UTC) (envelope-from _pppp@mail.ru) Received: from mx28.mail.ru (mx28.mail.ru [194.67.23.67]) by mx1.freebsd.org (Postfix) with ESMTP id A95E213C441 for ; Sun, 4 Mar 2007 22:16:51 +0000 (UTC) (envelope-from _pppp@mail.ru) Received: from f31.mail.ru (f31.mail.ru [194.67.57.70]) by mx28.mail.ru (mPOP.Fallback_MX) with ESMTP id 274276E97F8 for ; Mon, 5 Mar 2007 00:53:27 +0300 (MSK) Received: from mail by f31.mail.ru with local id 1HNydx-000MLw-00; Mon, 05 Mar 2007 00:53:25 +0300 Received: from [91.76.23.231] by koi.mail.ru with HTTP; Mon, 05 Mar 2007 00:53:25 +0300 From: dima <_pppp@mail.ru> To: O. Hartmann Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [91.76.23.231] Date: Mon, 05 Mar 2007 00:53:25 +0300 In-Reply-To: <45E7F09B.7070005@zedat.fu-berlin.de> References: <45E7F09B.7070005@zedat.fu-berlin.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Cc: freebsd-performance@freebsd.org Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dima <_pppp@mail.ru> List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2007 22:16:52 -0000 > The last days I tried to figure out why some of my lab's FreeBSD boxes > and also mine at home seem to be outperformed by some Linux setups > around here and I saw something interesting. > > On my lab's FreeBSD 6.2/i386 box (ASUS P4P800, ICH5 with two SATA 150 > ports, two SATA 300 drives attached) I copied big files (~ 5GB) from one > drive to another while the box didn't do anything else than copying. I > watched the copy process via 'systat -vmstat 1' and realized, that the > value of 'KB/t' never go byond 128 (128kb buffer limit?). But more > frustrating, I never got beyond 33 MB/s transfer rate although > bonni/bonni++ told me both drives are capable doing much more (~75 MB/s > each). > At home, I use a FreeBSD 7.0-CURRENT box on an ASUS > A8N32-SLI/nForce4-SLI based box, amd64 (no 32Bit compatibility). Two > Hitachi T7K250 250 GB/SATA II drives build up a RAID 0 (nVidia > MediaShield), and additionally there is a SAMSUNG Spinpoitn SP2004C > attached to the controller. bonni results in 55 MB/s for the SP2004C > alone and gives ~ 65 - 70 MB/s for the Hitachis, each and roughly 115 > MB/s for the RAID 0. But copying from the single drive to the RAID 0 or > from the RAID 0 to the single drive also reaches this oscure 33 MB/s > boundary! > > In the first place I thought the older i386 hardware has some > hard-limits, but we have several boxes of the exact same hardware around > here and a wide spread Linux and Windows utilization and on those boxes > equipted with more than one harddrive (PATA or SATA) the effective > transfer rate shown up is about 50 - 65 MB/s as expected with copying a > big 5G file from one drive to another. > > The hardwrae limit is completely nonsense when it comes to the AMD64 box > with newer hardware. > > Before digging into this problem deeper with benchmarks, could anyone > explain why FreeBSD reaches this 33 MB/s limit (sounds like UDMA 33 > defaults, but on both boxes nForce4 and ICH5 controller are recognized > and show up with SATA300 or SATA150 capabilities, respective)? May I > have some knobs I'm not aware of to tune disk performance? > > I would appreciate any coments on that and if someone has some good > ideas how to benchmark those subjects, please let me know. I think you're quite OK with dd. I do believe you'll get a comparable results for cp setting "noatime" option in mount(8)s. As you were told, the default mount mode is noasync which is "synchronous metadata + asynchronous data". But FreeBSD still updates metadata for atime on every file read. 2all: Are there any reasons not to make noasync the default mount option? It greatly improves FS performance and I don't think many modern administrators do care about access times of their files (assuming how many files a modern box has). Regards, Dmitriy.