Re: sizing / capacity planning tipps related to expected request or transactions per second

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Dirk Krautschick <Dirk(dot)Krautschick(at)trivadis(dot)com>
Cc: "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: sizing / capacity planning tipps related to expected request or transactions per second
Date: 2020-08-24 16:51:59
Message-ID: CAFj8pRDDyVOZtx8ZidpdV0NS9gzzcXj7KZTPnbrLyAVL17H3OA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi

po 24. 8. 2020 v 18:40 odesílatel Dirk Krautschick <
Dirk(dot)Krautschick(at)trivadis(dot)com> napsal:

> Hi,
>
> are there any nice rules of thumb about capacity planning in relation the
> expected
> amount of transactions or request per second?
>
> For example, if I have around 100 000 transactions per second on a 5 TB
> database.
> With what amount of Memory and CPUs/Cores and which settings would you
> basically
> Start to evaluate the performance.
>

You have to know the duration of a typical query - if it is 1ms, then one
cpu can do 1000 tps and you need 100 cpu. If duration is 10 ms, then you
need 1000 cpu.

as minimum RAM for OLTP is 10% of database size, in your case 500GB RAM.

Any time, when I see a request higher than 20-30K tps, then it is good to
think about horizontal scaling or about sharding.

Regards

Pavel

> Or are there any other recommendations or experiences here?
>
> Thanks and best regards
>
> Dirk
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2020-08-24 17:58:15 Re: CPU hogged by concurrent SELECT..FOR UPDATE SKIP LOCKED
Previous Message MichaelDBA 2020-08-24 16:49:21 Re: sizing / capacity planning tipps related to expected request or transactions per second