[pgpool-hackers: 4394] Tps not increasing after enabling Load Balancing

Salman Ahmed salman.ahmed at stormatics.tech
Wed Sep 13 19:58:39 JST 2023


Dear pgpool-hackers,


We are facing an issue with our 3-Node HA PostgreSQL cluster: TPS remains
similar with or without load balancing. Sometimes it is even lesser with
load balancing enabled, compared to when load balancing is disabled.

We ran the test in two phases. First we disabled load balancing by turning
load_balance_mode to off and changing backend_weight0 to 1, backend_weight1
to 0 and backend_weight2 to 0.

We executed the the following command from client machine:
pgbench -i -p 9999 -h 172.30.237.3 -U postgres -d postgres

This was the output of the query mentioned above.

dropping old tables...

NOTICE:  table "pgbench_accounts" does not exist, skipping

NOTICE:  table "pgbench_branches" does not exist, skipping

NOTICE:  table "pgbench_history" does not exist, skipping

NOTICE:  table "pgbench_tellers" does not exist, skipping

creating tables...

generating data (client-side)...

100000 of 100000 tuples (100%) done (elapsed 9.53 s, remaining 0.00 s)

vacuuming...

creating primary keys...

done in 19.25 s (drop tables 0.10 s, create tables 0.82 s, client-side
generate 17.39 s, vacuum 0.49 s, primary keys 0.45 s).

We then executed the following command from client machine:

pgbench -p 9999 -j 2 -c 10 -t 1000 -h 172.30.237.3 -U postgres -d postgres

This was the output of the query mentioned above

transaction type: <builtin: TPC-B (sort of)>

scaling factor: 1

query mode: simple

number of clients: 10

number of threads: 2

maximum number of tries: 1

number of transactions per client: 1000

number of transactions actually processed: 10000/10000

number of failed transactions: 0 (0.000%)

latency average = 1258.453 ms

initial connection time = 1584.503 ms

tps = 7.946265 (without initial connection time)

We then enabled load balancing by turning  load_balance_mode to on and
changing backend_weight0 to 0, backend_weight1 to 0.5 and backend_weight2
to 0.5.


We executed the following query from client machine:
pgbench -i -p 9999 -h 172.30.237.3 -U postgres -d postgres

This was the output of the query mentioned above

dropping old tables...

NOTICE:  table "pgbench_accounts" does not exist, skipping

NOTICE:  table "pgbench_branches" does not exist, skipping

NOTICE:  table "pgbench_history" does not exist, skipping

NOTICE:  table "pgbench_tellers" does not exist, skipping

creating tables...

generating data (client-side)...

100000 of 100000 tuples (100%) done (elapsed 1.50 s, remaining 0.00 s)

vacuuming...

creating primary keys...

done in 13.21 s (drop tables 0.21 s, create tables 0.54 s, client-side
generate 11.34 s, vacuum 0.55 s, primary keys 0.57 s).

We then executed the following query from client machine:
pgbench -p 9999 -j 2 -c 10 -t 1000 -h 172.30.237.3 -U postgres -d postgres

This was the output of query mentioned above:

transaction type: <builtin: TPC-B (sort of)>

scaling factor: 1

query mode: simple

number of clients: 10

number of threads: 2

maximum number of tries: 1

number of transactions per client: 1000

number of transactions actually processed: 10000/10000

number of failed transactions: 0 (0.000%)

latency average = 1595.227 ms

initial connection time = 4172.761 ms

tps = 6.268699 (without initial connection time)

I have attached our pgpool.conf file with and without load balancing
enabled. I have also attached the postgresql.conf file.

To view our source code please go to:
https://github.com/stormatics/pg_cirrus

While the queries mentioned above were being executed, we used htop to
monitor system stats on our pgpool node and we saw these logs which seem
strange.

pgpool: wait for connection request

pgpool: PCP: wait for connection request

pgpool: postgres postgres 115.186.134.230 (49986) idle

pgpool: postgres postgres 115.186.134.230 (49979) idle in transaction

We were using 4 VMs all with 1 core, 2 gb ram and ubuntu 22.04.

One VM is used as pgpool node, one is used as primary node, one is used as
standby node 1 and one is used as standby node 2.


Kindly help us in resolving this issue. Thanks!

Salman Ahmed
Stormatics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-hackers/attachments/20230913/9531e035/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postgresql.conf
Type: application/octet-stream
Size: 29565 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-hackers/attachments/20230913/9531e035/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: without lb pgpool.conf
Type: application/octet-stream
Size: 50112 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-hackers/attachments/20230913/9531e035/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: with lb pgpool.conf
Type: application/octet-stream
Size: 50115 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-hackers/attachments/20230913/9531e035/attachment-0005.obj>


More information about the pgpool-hackers mailing list