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 3645952833 for ; Tue, 19 Jul 2005 13:42:30 -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 74392-01 for ; Tue, 19 Jul 2005 16:42:20 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id C59615284F for ; Tue, 19 Jul 2005 13:42:18 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j6JGg8qj007225; Tue, 19 Jul 2005 12:42:08 -0400 (EDT) To: Christopher Petrilli Cc: PFC , Vivek Khera , pgsql-performance@postgresql.org Subject: Re: Impact of checkpoint_segments under continual load conditions In-reply-to: <59d991c40507190930244ba9bb@mail.gmail.com> 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> <59d991c405071907482bb0689b@mail.gmail.com> <59d991c4050719084460b376f1@mail.gmail.com> <4541.1121788647@sss.pgh.pa.us> <59d991c40507190930244ba9bb@mail.gmail.com> Comments: In-reply-to Christopher Petrilli message dated "Tue, 19 Jul 2005 12:30:34 -0400" Date: Tue, 19 Jul 2005 12:42:08 -0400 Message-ID: <7224.1121791328@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200507/289 X-Sequence-Number: 13530 Christopher Petrilli writes: > On 7/19/05, Tom Lane wrote: >> I'm suddenly wondering if the performance dropoff corresponds to the >> point where the indexes have grown large enough to not fit in shared >> buffers anymore. If I understand correctly, the 5000-iterations mark >> corresponds to 2.5 million total rows in the table; with 5 indexes >> you'd have 12.5 million index entries or probably a couple hundred MB >> total. If the insertion pattern is sufficiently random that the entire >> index ranges are "hot" then you might not have enough RAM. > This is entirely possible, currently: > shared_buffers = 1000 Ah-hah --- with that setting, you could be seeing shared-buffer thrashing even if only a fraction of the total index ranges need to be touched. I'd try some runs with shared_buffers at 10000, 50000, 100000. You might also try strace'ing the backend and see if behavior changes noticeably when the performance tanks. FWIW I have seen similar behavior while playing with MySQL's sql-bench test --- the default 1000 shared_buffers is not large enough to hold the "hot" part of the indexes in some of their insertion tests, and so performance tanks --- you can see this happening in strace because the kernel request mix goes from almost all writes to a significant part reads. On a pure data insertion benchmark you'd like to see nothing but writes. regards, tom lane