Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1na7DI-0006vh-Jf for pgsql-performance@arkaria.postgresql.org; Fri, 01 Apr 2022 02:40:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1na7DG-0005h3-Aw for pgsql-performance@arkaria.postgresql.org; Fri, 01 Apr 2022 02:40:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1na7DF-0005gt-W1 for pgsql-performance@lists.postgresql.org; Fri, 01 Apr 2022 02:40:34 +0000 Received: from mail-qv1-xf36.google.com ([2607:f8b0:4864:20::f36]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1na7DB-0003lX-DI for pgsql-performance@lists.postgresql.org; Fri, 01 Apr 2022 02:40:33 +0000 Received: by mail-qv1-xf36.google.com with SMTP id ke15so1041267qvb.11 for ; Thu, 31 Mar 2022 19:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=DwWihXGbeVzaPOkfC1jQQm5tVnJoAQkTQqQm6jf9cxc=; b=INrBQXcbJbOaodOaWTdVbOXVyq6YPL2i97nmQMyPkgBQFFABdh3BFzOdFpIKYLfGbf EEB5GhaeASotzL8GjWbLAKngcRpiYuctAXpyoulksgXdNuJx9Lw97weHKaQhl9rwheXC tGs1YcqUXRcq8hff5UDx9PO0Tu8xPW2KR3K/t0sOKaZkM+m2O2MXNofvnFskEsJ0Bc82 SHOlyRV4n1EJUHO4S/ub/4PMVfw1lHv7cvChdvSwxLZhTsjxM9B6NGmtS09ePZuUKq3T n3PQQ8BvFIdQ1RaUPAD5z/fglhDiHR/W42PSBO9DS9JI+g4nmYPu/qCLs6VahCb71Fa7 yeZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=DwWihXGbeVzaPOkfC1jQQm5tVnJoAQkTQqQm6jf9cxc=; b=iiZ7L4kI4n3zGqzs4YfXjo+ouPElfQaTcbPa0ARQ2JYG059w/lMv5WARE3hwrzTV0T 0+Im2lG7OFTaRzxlddeHmS72FN84YXvGQBKYOTJbyzpH5freSe4lzJC5WWQeMCPHF/Oz oN89hemeBacuXbOy+Y17D/LpBhcsw/5eOt6WV7rQIMMFZ1KElDpNBC7nAEoB4RQ9D2CI tTL6AQYvUDfmviDWh5J/4GQE3tnLkwZ6+uckvSXPgJZirWv8mXmOe8VFVc8d5j0BpxwY w5QDQvZG/ASXrs7EHoyzJNZakeSUJOXw4ttHu80H3aI0L9n/ShtTmTED70F/M3QNw66q xZtg== X-Gm-Message-State: AOAM530X9IQ+gmtozMuFLx4bmYCbHmriG6diqS+YnOAWsy0DQY2r+15z Us5NLOAArNlVee5tkDrH8gFyZ58sXwyMKQ== X-Google-Smtp-Source: ABdhPJy8I0UDSaiJtsy7kmh+rCTbmJADT7j+LcxP5IttE3Qn3iRoaSvl+/LqTCzoEk0Lz4Ww6ckbLA== X-Received: by 2002:a05:6214:3016:b0:441:4091:17c1 with SMTP id ke22-20020a056214301600b00441409117c1mr6721650qvb.33.1648780826963; Thu, 31 Mar 2022 19:40:26 -0700 (PDT) Received: from [192.168.2.100] (pool-72-79-19-93.nwrknj.east.verizon.net. [72.79.19.93]) by smtp.gmail.com with ESMTPSA id n8-20020ac85a08000000b002e06aa02021sm877382qta.49.2022.03.31.19.40.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Mar 2022 19:40:26 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------6IFgwHr0AaKjM9jT2c0WpmV7" Message-ID: <44e64451-73a0-b8de-4d88-25d642c62f6d@gmail.com> Date: Thu, 31 Mar 2022 22:40:25 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Postgresql TPS Bottleneck Content-Language: en-US To: pgsql-performance@lists.postgresql.org References: From: Mladen Gogala In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------6IFgwHr0AaKjM9jT2c0WpmV7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/31/22 07:50, wakandavision@outlook.com wrote: > Hi everyone, > > I am a bachelor's student and writing my thesis about the scaling and > performance of an application. The application is using postgresql as a > database but we can't scale any further currently as it seems postgres > is hitting the limit. > > With the application, as well as with pgbench, we don't get more than > (max) 70k TPS on postgres. But the servers' resources are not utilized > completely (more below). I would try monitoring using "perf top" and "atop -d" to see what is going on on the system. Also, try using sar to figure out what's going on. Are you paging, waiting for I/O or having some other kind of bottleneck. Once you figure where is your system spending time, you can address the problem. In addition to that, analyze the log files with pgbadger to find out which queries are time consuming and try optimizing them. -- Mladen Gogala Database Consultant Tel: (347) 321-1217 https://dbwhisperer.wordpress.com --------------6IFgwHr0AaKjM9jT2c0WpmV7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 3/31/22 07:50, wakandavision@outlook.com wrote:
Hi everyone,

I am a bachelor's student and writing my thesis about the scaling and
performance of an application. The application is using postgresql as a
database but we can't scale any further currently as it seems postgres
is hitting the limit.

With the application, as well as with pgbench, we don't get more than
(max) 70k TPS on postgres. But the servers' resources are not utilized
completely (more below).

I would try monitoring using "perf top" and "atop -d" to see what is going on on the system. Also, try using sar to figure out what's going on. Are you paging, waiting for I/O or having some other kind of bottleneck. Once you figure where is your system spending time, you can address the problem. In addition to that, analyze the log files with pgbadger to find out which queries are time consuming and try optimizing them.

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
--------------6IFgwHr0AaKjM9jT2c0WpmV7--