X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id B201A52BB0 for ; Mon, 18 Jul 2005 20:31:41 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 11061-10 for ; Mon, 18 Jul 2005 23:31:40 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by svr1.postgresql.org (Postfix) with ESMTP id 4382A52BAE for ; Mon, 18 Jul 2005 20:31:38 -0300 (ADT) Received: by wproxy.gmail.com with SMTP id i32so1093156wra for ; Mon, 18 Jul 2005 16:31:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f0WrQ3deGdjBEGTN2q1oYQ2x8FJu7bLD0tmgr0fIdggon0ubd+8xy6j/IFBr2/dOKwQXOHBcx+N2gR8HxsiIf2Pw6J4/XVY1XNfWTAqq8/HLGs1+01Dkh+Yts/F8W++NwLUeJiej2hIJgtc4yQO5fT+K8yQdXC2n7zEoj18xIZY= Received: by 10.54.38.40 with SMTP id l40mr538132wrl; Mon, 18 Jul 2005 16:30:53 -0700 (PDT) Received: by 10.54.120.11 with HTTP; Mon, 18 Jul 2005 16:30:53 -0700 (PDT) Message-ID: <59d991c405071816304af42ef@mail.gmail.com> Date: Mon, 18 Jul 2005 19:30:53 -0400 From: Christopher Petrilli Reply-To: Christopher Petrilli To: Tom Lane Subject: Re: Impact of checkpoint_segments under continual load conditions Cc: Vivek Khera , pgsql-performance@postgresql.org In-Reply-To: <16794.1121718743@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <59d991c4050717100874c08a86@mail.gmail.com> <59d991c405071811457ccdd3f1@mail.gmail.com> <16394.1121715156@sss.pgh.pa.us> <59d991c405071812342e290f57@mail.gmail.com> <16794.1121718743@sss.pgh.pa.us> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.121 tagged_above=0 required=5 tests=AWL, RCVD_BY_IP X-Spam-Level: X-Archive-Number: 200507/274 X-Sequence-Number: 13515 On 7/18/05, Tom Lane wrote: > Christopher Petrilli writes: > > On 7/18/05, Tom Lane wrote: > >> I have no idea at all what's causing the sudden falloff in performance > >> after about 10000 iterations. COPY per se ought to be about a > >> constant-time operation, since APPEND is (or should be) constant-time. > >> What indexes, foreign keys, etc do you have on this table? What else > >> was going on at the time? >=20 > > The table has 15 columns, 5 indexes (character, inet and timestamp). > > No foreign keys. The only other thing running on the machine was the > > application actually DOING the benchmarking, written in Python > > (psycopg), but it was, according to top, using less than 1% of the > > CPU. It was just talking through a pipe to a psql prompt to do the > > COPY. >=20 > Sounds pretty plain-vanilla all right. >=20 > Are you in a position to try the same benchmark against CVS tip? > (The nightly snapshot tarball would be plenty close enough.) I'm > just wondering if the old bgwriter behavior of locking down the > bufmgr while it examined the ARC/2Q data structures is causing this... So here's something odd I noticed: 20735 pgsql 16 0 20640 11m 10m R 48.0 1.2 4:09.65 postmaster =20 20734 petrilli 25 0 8640 2108 1368 R 38.1 0.2 4:25.80 psql The 47 and 38.1 are %CPU. Why would psql be burning so much CPU? I've got it attached ,via a pipe to another process that's driving it (until I implement the protocol for COPY later). I wouldn't think it should be uing such a huge percentage of the CPU, no? The Python script that's actually driving it is about 10% o the CPU, which is just because it's generating the incoming data on the fly.=20 Thoughts? I will give the CVS head a spin soon, but I wanted to formalize my benchmarking more first. Chris --=20 | Christopher Petrilli | petrilli@gmail.com