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 A852C52BD1 for ; Mon, 18 Jul 2005 15:46:32 -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 23015-07 for ; Mon, 18 Jul 2005 18:46:24 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by svr1.postgresql.org (Postfix) with ESMTP id 0955152996 for ; Mon, 18 Jul 2005 15:46:23 -0300 (ADT) Received: by wproxy.gmail.com with SMTP id i35so1052059wra for ; Mon, 18 Jul 2005 11:46:24 -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=fzdyxgwM0EHwlpwkiVXl4cVEn56OlccDYj6X+HmyIRR4ok1+k3IEIf1Z/zrq7qLN5vX1jkLAToOdc8qFKZAgduwmTHpZx6+WMJVvYZ1By4a1WAXT0OwexG6ZWrDqWtyyevp9yEXodPGFFUW8dq7dwCotazZm+P3MnyQhxUyS36E= Received: by 10.54.37.47 with SMTP id k47mr460663wrk; Mon, 18 Jul 2005 11:45:37 -0700 (PDT) Received: by 10.54.120.11 with HTTP; Mon, 18 Jul 2005 11:45:35 -0700 (PDT) Message-ID: <59d991c405071811457ccdd3f1@mail.gmail.com> Date: Mon, 18 Jul 2005 14:45:35 -0400 From: Christopher Petrilli Reply-To: Christopher Petrilli To: Vivek Khera Subject: Re: Impact of checkpoint_segments under continual load conditions Cc: pgsql-performance@postgresql.org In-Reply-To: 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> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.126 tagged_above=0 required=5 tests=AWL, RCVD_BY_IP X-Spam-Level: X-Archive-Number: 200507/267 X-Sequence-Number: 13508 On 7/18/05, Vivek Khera wrote: >=20 > On Jul 17, 2005, at 1:08 PM, Christopher Petrilli wrote: >=20 > > Normally, checkpoint_segments can help absorb some of that, but my > > experience is that if I crank the number up, it simply delays the > > impact, and when it occurs, it takes a VERY long time (minutes) to > > clear. >=20 > There comes a point where your only recourse is to throw hardware at > the problem. I would suspect that getting faster disks and splitting > the checkpoint log to its own RAID partition would help you here. > Adding more RAM while you're at it always does wonders for me :-) My concern is less with absolute performance, than with the nosedive it goes into. I published some of my earlier findings and comparisons on my blog, but there's a graph here: http://blog.amber.org/diagrams/comparison_mysql_pgsql.png Notice the VERY steep drop off. I'm still trying to get rid of it, but honestly, am not smart enough to know where it's originating. I have no desire to ever use MySQL, but it is a reference point, and since I don't particularly need transactional integrity, a valid comparison. Chris --=20 | Christopher Petrilli | petrilli@gmail.com