From owner-freebsd-current Tue Mar 7 11:27:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA22656 for current-outgoing; Tue, 7 Mar 1995 11:27:31 -0800 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA22649 for ; Tue, 7 Mar 1995 11:27:29 -0800 Received: by pelican.com (Smail3.1.28.1 #5) id m0rm4uI-000K2tC; Tue, 7 Mar 95 11:26 WET Message-Id: Date: Tue, 7 Mar 95 11:26 WET From: pete@pelican.com (Pete Carah) To: phk@ref.tfs.com Subject: Re: more ETXTBSY bugs Newsgroups: pelican.fbsd-c In-Reply-To: <199503070843.AAA25109@ref.tfs.com> Organization: Pelican Consulting Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk In article <199503070843.AAA25109@ref.tfs.com> you write: > >> In article <9503062157.AA19959@cs.weber.edu> Terry writes: >> ..... >> >I'd like to see the people seeing the thrashing problems add about 16M >> >of swap without doing any extra apllications and see what happens. If > >This is the same as the "chatter bug" and it is well understood now. >don't try this, and if you do: after some time you will see on "vmstat -m" >that you have a LOT of vnodes, more than sysctl(kern.maxvnodes), and >you will also loose diskspace... Actually that was Terry's hint, not mine; I *know* my swap usage is low; there is almost 30mb free swap during very heavy chatter.. (and the other is obviously going to lose as long as the txtbusy bug is there; I can wait... Those two things aren't (intimately) related, except for both having something to do with reference counts. The cure for txtbusy may well require yet another reference count, especially for shared libs.) What I *was* going to do was put an incremental-output option in vmstat when -w is specified, probably with yet another switch, and add the two variables that David suggested to vmstat rather than running his program standalone... The incremental-output may want to be reduced to xxx per second like the sgi osview does (osview is their vmstat-like thing, though it puts out lots more stuff, especially on multiprocessor systems), so that different interrogation periods can be compared directly. In this case I may want to do what SGI (or 'top') does and use curses too. -- Pete