Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uj9bH-003bTv-DC for pgsql-admin@arkaria.postgresql.org; Tue, 05 Aug 2025 04:48:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uj9bF-007A0J-Af for pgsql-admin@arkaria.postgresql.org; Tue, 05 Aug 2025 04:48:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uj9bE-007A0B-Qq for pgsql-admin@lists.postgresql.org; Tue, 05 Aug 2025 04:48:32 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uj9bB-000nax-2k for pgsql-admin@lists.postgresql.org; Tue, 05 Aug 2025 04:48:31 +0000 Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-61592ff5df8so6396176a12.1 for ; Mon, 04 Aug 2025 21:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754369307; x=1754974107; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=XArZ0ERbQnOQ+t+NtX8AstDDy5oP16o2oomkUoVWOic=; b=S3d0aQHPgh5a9iJpYI6c1zInJWeczY3X1BJMxSncG5sKn8ZavTi2serEFpwsbPbUwl NCk8Ju/sACTxqDewIrTfwVjjQ3UW+rhmICXy4QSR1w8nATGvMDPDfnfjr7PN+rm233sD 9oPFgNtwL0P6BezuO8QfOnAkjqE6UK8c1Qw6kPjkLuwDqmntCKc7+Ml3vC7HJSh706vF zTU9anMmZh8fUb0q94lh+YbLCT374wAUxGXIE40bjNdpQnvGKUMWfsxdXXOLp/srxOrP Q/6p9SQob989Fv5nPeF0vFENvLT/CeKjQnsxMDwFrrk3Z1y+qqkbcyR5C2v/YlgNGLFm AUcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754369307; x=1754974107; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=XArZ0ERbQnOQ+t+NtX8AstDDy5oP16o2oomkUoVWOic=; b=R944w279zRAC2bcSrVGPXYQPUjIRzBkTEYQTXuRPeyXoOA18+oyY4GoQ2a9wFAwbAq aYmzfvdNY+jPRfq5Ip/hHz+JHhbrOvfQuzZpf6PnYbKpB/nuQBudbYdLrq/o6BFaf1OG uXBjx7Qr3Mh3b/tRVVVmA9xiknuxBIgeTHuQRxuvDlJcKlZmc7+LBDDdZWWoJX4CmCzB Wa8nVJQ2AbZtgHVfOM4g/zIN4ZJiNAt8WsLmPUVZXJevgDTkLDLZN77SPhXmeUEXrDzL VtszeUmJM7lOG8ZKqG7vcuvsbZ/TG1fbo7JDExZlWt0Ehffz6ej6zMYuJz+vpU7o/6kz 3SsA== X-Gm-Message-State: AOJu0YxFYvleZbTKOTYPbWXN0QliMp6FDsbJiOd3EqV9Am/lSmNh5Aik uqIj6To8A+fMfjP7z13+kS4bS8iZeAxQEC56GSE7q9TjiIZHPPgMKOd8Nyg2Vb6oM2jyFM17OO3 XC8xfMYFKY5Y5TEeJjK+oxPyTut76jx5aLO1T X-Gm-Gg: ASbGncsNp7QMxOFckD5VC9qJwGScQIN5Brp06Jc0qQImd8kNBngudX86C3biszBF0Du xAEPUz7v1QDq8wTgOk81udr07I8E6MB3NLUs4qSAPEQjTRr5FaYx19yHi5/zl0emM+cpnliOoTP h4tHds4B8LAOBm5i1zApZd5ZKvJ+xXmobBNF37RC7vTSNKqWGUGwej5ZNBHtcXDMlAPwpHjbsuB XMZvcSR X-Google-Smtp-Source: AGHT+IFTKQfvQvPkuvh1JMdbfkZDgwaNgxyQbvKh/EEJ3fY6wLx67UlefExUSCv7hOiOdp79g772ad32kW0+WLajgwI= X-Received: by 2002:a05:6402:5d97:b0:615:77cf:782e with SMTP id 4fb4d7f45d1cf-615e7164e09mr6763354a12.25.1754369306498; Mon, 04 Aug 2025 21:48:26 -0700 (PDT) MIME-Version: 1.0 From: Siraj G Date: Tue, 5 Aug 2025 10:18:15 +0530 X-Gm-Features: Ac12FXzPFPbVd0DmkeJdwOKm_8CygoXPvWPsc1twSjzg63XS-P-AsQBiI0P_UwE Message-ID: Subject: DB load balancer To: Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000519ac9063b96ef87" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000519ac9063b96ef87 Content-Type: text/plain; charset="UTF-8" Hello Experts! We have a multi tenant model DB with a Primary and a Secondary. There are 3x or 4x connections flowing to Secondary as the application is read intensive. Accordingly we have allocated more number of resources to the VM hosting the secondary/replica DB. Spec:- Primary: 48 CPUs, 48GB memory Secondary: 80 CPUs, 128GB memory PG version: 12.22 (we have already started the upgrade process) OS: Ubuntu The problem very frequently we are experiencing is that the CPU load on the SECONDARY is going very very high causing the app slowness. Also, frequently the postgres is crashing due to OOM. I was thinking of these (please give feedback): 1. Have a DB level balancer for the load balancing in the DB level, meaning primary will also receive the READ traffic 2. Add a second REPLICA and configure load balancer for the connection load balancing What do we do for load balancing at the DB level, in postgres? If there are any suggestions, please let me know. Regards Siraj --000000000000519ac9063b96ef87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Experts!

We have a multi tenant m= odel DB with a Primary and a Secondary. There are 3x or 4x connections flow= ing to Secondary as the application is read intensive. Accordingly we have = allocated more number of resources to the VM hosting the secondary/replica = DB.=C2=A0

Spec:-=C2=A0
Primary: 48 CPUs,= 48GB memory
Secondary: 80 CPUs, 128GB memory
PG versio= n: 12.22 (we have already started the upgrade process)
OS: Ubuntu=

The problem very frequently we are experiencing i= s that the CPU load on the SECONDARY is going very very high causing the ap= p slowness. Also, frequently the postgres is crashing due to OOM.

I was thinking of these (please give feedback):
1= . Have a DB level balancer for the load balancing in the DB level, meaning = primary will also receive the READ traffic
2. Add a second REPLIC= A and configure load balancer for the connection load balancing
<= br>
What do we do for load balancing at the DB level, in postgres= ?

If there are any suggestions, please=C2=A0let me= know.

Regards
Siraj
--000000000000519ac9063b96ef87--