From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 04:48:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09A7316A4CF; Wed, 21 Jul 2004 04:48:18 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D80743D4C; Wed, 21 Jul 2004 04:48:18 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i6L4mHKI090936; Tue, 20 Jul 2004 23:48:17 -0500 (CDT) (envelope-from dan) Date: Tue, 20 Jul 2004 23:48:17 -0500 From: Dan Nelson To: jesk Message-ID: <20040721044816.GA56020@dan.emsphone.com> References: <056801c46eb3$bd0e2a40$45fea8c0@turbofresse> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <056801c46eb3$bd0e2a40$45fea8c0@turbofresse> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: I/O or Threading Suffer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 04:48:19 -0000 In the last episode (Jul 21), jesk said: > i figured out that the performanceloss only really occur if the > process is heavily writing on the filesystem. dd if=/dev/zero > of=/dev/null bs=128k doesnt hurt much in responsetime of parallel > processes, but when dd operates on the filesystem with of=foo every > process will be affect in executiontime. a simple ps or ls meanwhile > dding onto the disk will be hang for dozen of seconds. Ah. now that's a different story. You're out of the control of the process scheduler and into the disk. I don't suppose you're using an IDE/ATA disk with no tagged queueing? :) Run "dmesg | grep depth.queue" to see how many requests can be queued up on your disk at once. That dd is stuffing lots of dirty data into the disk cache, and all the other processes have to wait in line to get their I/Os done. You'll see much better results from a SCSI disk (with usual queue depths between 32 and 64), and even better results from a multi-disk hardware RAID array (which will have a large write cache). -- Dan Nelson dnelson@allantgroup.com