X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 53E399FACFE for ; Wed, 10 May 2006 11:18:32 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 03028-05-6 for ; Wed, 10 May 2006 11:18:17 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from ustc.edu.cn (smtp.ustc.edu.cn [202.38.64.16]) by postgresql.org (Postfix) with SMTP id 25E789FB1BA for ; Wed, 10 May 2006 11:17:25 -0300 (ADT) Received: (eyou send program); Wed, 10 May 2006 22:17:20 +0800 Message-ID: <347270640.30146@ustc.edu.cn> X-EYOUMAIL-SMTPAUTH: wfg@mail.ustc.edu.cn Received: from unknown (HELO localhost.localdomain) (210.45.75.53) by 202.38.64.8 with SMTP; Wed, 10 May 2006 22:17:20 +0800 Received: from wfg by localhost.localdomain with local (Exim 4.61) (envelope-from ) id 1FdpVG-0001kQ-Qw; Wed, 10 May 2006 22:17:26 +0800 Date: Wed, 10 May 2006 22:17:26 +0800 From: Wu Fengguang To: blender@jaskom.pl Cc: pgsql-performance@postgresql.org Subject: Re: PostgreSQL VACCUM killing CPU Message-ID: <20060510141726.GA6620@mail.ustc.edu.cn> Mail-Followup-To: Wu Fengguang , blender@jaskom.pl, pgsql-performance@postgresql.org References: <1147167570.494108.284720@i39g2000cwa.googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1147167570.494108.284720@i39g2000cwa.googlegroups.com> User-Agent: Mutt/1.5.11+cvs20060126 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/246 X-Sequence-Number: 19033 On Tue, May 09, 2006 at 03:19:08AM -0700, blender@jaskom.pl wrote: > I have got such problem. > Im running Postgresql 7.3.2 on Linux 2.6.13. > What is see when VACCUM is running and killing my CPU is: > > Cpu(s): 3.2% us, 0.0% sy, 0.0% ni, 0.0% id, 96.8% wa, 0.0% hi, > 0.0% si > > what i am worry about is "96.8% wa" why is it like that? It's killing your disk drives instead of CPU(which is mostly _idle_ waiting for I/O completion). Run this command to get an idea of the I/O activities: iostat -x 3 3 [AD]Running a kernel patched with adaptive read-ahead may help it: http://www.vanheusden.com/ara/adaptive-readahead-11.1-2.6.16.5.patch.gz