From owner-freebsd-current@FreeBSD.ORG Thu Jul 28 21:37:09 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org 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 DBB3716A41F for ; Thu, 28 Jul 2005 21:37:09 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21F8E43D55 for ; Thu, 28 Jul 2005 21:37:08 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6SLk0b5015733; Thu, 28 Jul 2005 15:46:00 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E94FED.7000801@samsco.org> Date: Thu, 28 Jul 2005 15:36:45 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <42E88135.30603@elischer.org> <42E88F2B.5000108@elischer.org> In-Reply-To: <42E88F2B.5000108@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: FreeBSD Current Subject: Re: Apparent strange disk behaviour in 6.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 28 Jul 2005 21:37:10 -0000 Julian Elischer wrote: > > > Julian Elischer wrote: > >> >> >> I've been playing around with some raid arrays. >> I've notived some odd things. >> >> > [stuff] > > Ok I've done some researching.. > > it APPEARS that teh system is swapping out running programs in order to > store more write data! > > experiment: > boot to single user mode. > type: > mount {big partition} > dd if=/dev/zero bs=128K of=/$bigpartition}/bigfile count=1000000 > > notice that after a short while your dd is killed because the system is > out of swapspace. > (it doesn't have any) > Why the F*ck does it need swapspace.? there are exactly 2 proceses > running in userspace > and one of them s in wait4(). dd shows a resident size of about 170KB > leaving about a GIGABYTE of unused RAM. > > The system should make dd wait rather than trying to swap its pages out.. > > > if you then do > swapon (your swap device) > and repeat teh command in the background, > vmstat 1 will show you pages being faulted in and out... > no WONDER IO goes to hell in a handbasket.. > > Outgoing IO should never be able to force running programs out! > It should start re-using old pages from the same file! I've seen this too. It's especially easy to trigger if you do a large buildworld, especially using -j. > > 4.11 gives a consinstent 65MB/sec with this array, for as long as I run > it.. > 6.0 gives me 65MB for 15 seconds and then it drops to 20MB/sec and then > 10MB/sec > and the swap disk bursts into life. > > the array goes from all the lights solidly on, to bursts of activity > with large gaps in between them. > > I think that it's time for F/S, disk, and VM guys to sit down in a room and start figuring out how to reign things back in. We've basically had little real-world checks on this kind of stuff for 5 years (i.e. since 5-CURRENT), and it's quite possible that things have gotten massively un-tuned, non-obvious but critical backpressure codepaths have beeen garbage collected, etc. Scott