Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dozrc-0001Pw-F2 for pgsql-performance@arkaria.postgresql.org; Mon, 04 Sep 2017 22:29:04 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dozrb-0007FG-2q for pgsql-performance@arkaria.postgresql.org; Mon, 04 Sep 2017 22:29:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dozpr-00048O-Kk for pgsql-performance@postgresql.org; Mon, 04 Sep 2017 22:27:15 +0000 Received: from mail-qt0-x233.google.com ([2607:f8b0:400d:c0d::233]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dozpk-0007bJ-IF for pgsql-performance@postgresql.org; Mon, 04 Sep 2017 22:27:14 +0000 Received: by mail-qt0-x233.google.com with SMTP id q8so2050374qtb.5 for ; Mon, 04 Sep 2017 15:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3f3xOfIKjnhhU4A+X8B+2u6r7W2gX/Qj1cx3KdDIoww=; b=iLIwg1BKOHXGX90gIBsMngBF26pqwzSS1lXRqq4d4/Vt7q4BHFofdOgf7eA2XzoVHr pM9ifao3bJCQIZlXpzfNPD6+N5LTm+rl767EXH+1z95NqnB5cdDYevFqjQr9b8ORHr9I PY59OZNr/IBD+pstuJ+cbVcTDyvR+WAwTKSsmLws2tqn7wiiUA5+FWmP5lOyliKhYmwb K4+3FM3DXbRZ+KiNFu1SLpkJQENSCmIth9TnF9hCt0rcgjdqg5poMa2QJphaDeIhX6+j GaJACkjuipiPray6attlfcmgE+DCmRTwJPYiTmL0OwU7Xo2URyqonuCziRos1b/X0f/+ w7EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3f3xOfIKjnhhU4A+X8B+2u6r7W2gX/Qj1cx3KdDIoww=; b=mFztx4qYCJ9n13QtS4D/uY0sE3lJXc5RH3cqys4oltcBDZK1VLAbpN4DrZBoAT2wq7 q1xjp93NtUudlMcwA/k3jGEaJWB3x0NvTkSpTcn5rGE88aO66UXWaMN91Bzziu1sNSid 79sk7OA2rZQr0G18JcRcnbvWhqqc2B2zLTUgu+G87xBkZ0LnyMB1g4L1OcWaZhKjn1xI q4eAw7dDPfj1rxaD1eC0L911jRWtkFsdnoFoWaMaqzGK6x9zD8v6mIMIyZ0znd4XT46s 8P74Vkm9q8INOeWYPaUGOP4Ui21CdcVzENxHDl65VShhRtGw/gxT66RKXGNnDUzKnmHN y3Cw== X-Gm-Message-State: AHPjjUikAgCQm9wGg/yv1JuF6/DEqnfIGxewVvcWvJiZ6TlZZyUzpPAG JPTu3t3GfpWHaepk/PxIF1TdCPg+XA== X-Google-Smtp-Source: ADKCNb5XBSIgxzmlghhi5UMgWlE63ENX/oYr+EkuMWk/eeEPyRdUiyufWts+/ecvM0LkyTiQ0ZO0rpCDpE+jiO4+Zrg= X-Received: by 10.200.40.154 with SMTP id i26mr2587998qti.153.1504564026669; Mon, 04 Sep 2017 15:27:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.84.35 with HTTP; Mon, 4 Sep 2017 15:27:06 -0700 (PDT) In-Reply-To: References: From: Jeff Janes Date: Mon, 4 Sep 2017 15:27:06 -0700 Message-ID: Subject: Re: Handling small inserts from many connections. To: =?UTF-8?B?7Jqw7ISx66+8?= Cc: "pgsql-performance@postgresql.org" Content-Type: multipart/alternative; boundary="001a113f19765a01f50558649c40" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --001a113f19765a01f50558649c40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 4, 2017 at 1:14 AM, =EC=9A=B0=EC=84=B1=EB=AF=BC wrote: > Hi team, > > I'm trying to configure postgres and pgbouncer to handle many inserts fro= m > many connections. > > Here's some details about what i want to achieve : > > We have more than 3000 client connections, and my server program forks > backend process for each client connections. > If backend processes send a request to its connected client, the client > send some text data(about 3000 bytes) to the backend process and wait for > next request. > The backend process execute insert text data using PQexec from libpq > lbirary, if PQexec is done, backend process send request to > client again. > > All the inserts using one, same table. > > The problem is, clients wait too long due to insert process is too slow. > It seems to working fine at first, but getting slows down after couple of > hours, > each insert query takes 3000+ ms and keep growing. > If it takes a couple hours for it to slow down, then it sounds like you have a leak somewhere in your code. Run "top" and see who is using the CPU time (or the io wait time, if that is what it is, and the memory) Cheers, Jeff --001a113f19765a01f50558649c40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Sep 4, 2017 at 1:14 AM, =EC=9A=B0=EC=84=B1=EB=AF=BC &= lt;dntjdals0513= @gmail.com> wrote:
Hi team,

I'm trying to configure= postgres and pgbouncer to handle many inserts from many connections.
=

Here's some details about what i want to achieve :<= /div>

=C2=A0 We have more than 3000 client connections, = and my server program forks backend process for each client connections.
=C2=A0 If backend processes send a request to its connected client,= the client send some text data(about 3000 bytes) to the backend process an= d wait for
=C2=A0 next request.
=C2=A0 The bac= kend process execute insert text data using PQexec from libpq lbirary, if P= Qexec is done, backend process send request to
=C2=A0 client= again.

=C2=A0 All the inserts using one, same tab= le.

The problem is, clients wait too long due = to insert process is too slow.
It seems to working fine at first,= but getting slows down after couple of hours,
each insert query = takes 3000+ ms and keep growing.

If it takes a couple hours for it to slow down, then it sounds like y= ou have a leak somewhere in your code.

Run "t= op" and see who is using the CPU time (or the io wait time, if that is= what it is, and the memory)
=C2=A0
Cheers,
<= br>
Jeff
--001a113f19765a01f50558649c40--