From owner-freebsd-performance@FreeBSD.ORG Wed Jul 23 19:08:12 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35205106566C for ; Wed, 23 Jul 2008 19:08:12 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from parsely.rain.com (parsely.rain.com [199.26.172.196]) by mx1.freebsd.org (Postfix) with ESMTP id C8AD68FC18 for ; Wed, 23 Jul 2008 19:08:11 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (uucp@localhost) by parsely.rain.com (8.11.4/8.11.4) with UUCP id m6NIjTg74887 for freebsd-performance@freebsd.org; Wed, 23 Jul 2008 11:45:29 -0700 (PDT) (envelope-from freebsd@sopwith.solgatos.com) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id SAA09833; Wed, 23 Jul 2008 18:43:48 GMT Message-Id: <200807231843.SAA09833@sopwith.solgatos.com> To: freebsd-performance@freebsd.org Date: Wed, 23 Jul 2008 11:43:48 +0100 From: Dieter Subject: disk i/o unfairness with multiple processes X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@sopwith.solgatos.com List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 19:08:12 -0000 I've been seeing unfairness in disk i/o when multiple processes compete for resources. While some unfairness can be tolerated in order to gain overall efficiency, (e.g. avoiding long seeks) there is a limit. I've seen this with various scenarios, with 6.0, 6.2 and 7.0. Here is a simple test case which demonstrates the problem, and should be easy for others to duplicate. AMD64 2 GiB memory 7200 rpm SATA connected to nforce4-ultra FreeBSD 7.0 FFS, soft-updates $ time man de > /dev/null real 0m0.013s user 0m0.011s sys 0m0.001s $ cat 9_GB_file 9_GB_file 9_GB_file 9_GB_file > /dev/null & [1] 84904 $ time man de > /dev/null [1]+ Done cat 9_GB_file 9_GB_file 9_GB_file 9_GB_file > /dev/null real 9m20.508s user 0m1.053s sys 0m44.091s $ systat -vmstat reports that cat is reading at 50-60 MB/s, which is reasonable for this disk. The 9_GB_file and /usr are both on the same disk. Accessing different disks is more likely to give the expected performance. I suspect that some scenarios bottleneck in memory. I certainly expect man to take longer if it is competing for disk i/o, but 9 minutes seems a bit much. The user and sys times are also up significantly, which seems odd?