Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id E34774DA6AA for ; Thu, 10 May 2012 08:36:32 -0300 (ADT) Received: from mail-pb0-f46.google.com ([209.85.160.46]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SSRfb-0007sZ-Qh for pgsql-performance@postgresql.org; Thu, 10 May 2012 11:36:32 +0000 Received: by pbbrp8 with SMTP id rp8so1792806pbb.19 for ; Thu, 10 May 2012 04:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=SBCIqMdm6dWazyd+g7DgH+EiyGCT1utfuleGRnCH3lo=; b=mlnVSu1qBudZDlp6aQHScghMhoIGpSs0LeAHRfREPR9JGlZUpgZgexuZY0If5KaA1u a+ZbhTLyP1tRtrx8PtMf5Do11Dd/V4T0TbesdCXu6SmzihHtWTb8RPf1Wyi8EQTvNiQX USLsGulCaG+I8hRF4wYs7UGNoFnKA1i5mQWdt/9vle3GY9MKvNovYt+hQYbbkgOyVmU5 TC5HAV1K0BAa29WftR2GNY5yq6Go1+ryXOgaj+H9NzT0XBmNDrq+D6CR4c7AbEHw9ZjW fzgoG4+07AW6mt/xeDvVdbv6R311kwRDa0DMzvbvwJ6QTmJETz14boGfDQ3GDIaxJyRz OQow== Received: by 10.68.216.98 with SMTP id op2mr19645320pbc.93.1336649778544; Thu, 10 May 2012 04:36:18 -0700 (PDT) Received: from maumau (p1042-ipbfp401sizuokaden.shizuoka.ocn.ne.jp. [122.20.60.42]) by mx.google.com with ESMTPS id wn3sm9263327pbc.74.2012.05.10.04.36.16 (version=SSLv3 cipher=OTHER); Thu, 10 May 2012 04:36:17 -0700 (PDT) Message-ID: <37AC2C75CBA4411F84F5F995EDF91503@maumau> From: "MauMau" To: "Claudio Freire" Cc: "Merlin Moncure" , References: <61B94EF1D7774715BC565DD84C731BDD@maumau> In-Reply-To: Subject: Re: Could synchronous streaming replication really degrade the performance of the primary? Date: Thu, 10 May 2012 20:34:43 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201205/75 X-Sequence-Number: 46899 From: "Claudio Freire" On Wed, May 9, 2012 at 7:34 PM, MauMau wrote: >> Yes, I understand it is natural for the response time of each transaction >> to >> double or more. But I think the throughput drop would be amortized among >> multiple simultaneous transactions. So, 50% throughput decrease seems >> unreasonable. > I'm pretty sure it depends a lot on the workload. Knowing the > methodology used that arrived to those figures is critical. Was the > thoughput decrease measured against no replication, or asynchronous > replication? How many clients were used? What was the workload like? > Was it CPU bound? I/O bound? Read-mostly? > We have asynchronous replication in production and thoughput has not > changed relative to no replication. I cannot see how making it > synchronous would change thoughput, as it only induces waiting time on > the clients, but no extra work. I can only assume the test didn't use > enough clients to saturate the hardware under high-latency situations, > or clients were somehow experiencing application-specific contention. Thank you for your experience and opinion. The workload is TPC-C-like write-heavy one; DBT-2. They compared the throughput of synchronous replication case against that of no replication case. Today, they told me that they ran the test on two virtual machines on a single physical machine. They also used pgpool-II in both cases. In addition, they may have ran the applications and pgpool-II on the same virtual machine as the database server. It sounded to me that the resource is so scarce that concurrency was low, or your assumption may be correct. I'll hear more about their environment from them. BTW it's pity that I cannot find any case study of performance of the flagship feature of PostgreSQL 9.0/9.1, streaming replication... Regards MauMau