0

I have setup a Citus environment: (Citus 7.2.2, Postgres 10.12) 1) 1x coordinator node 2) 5x worker nodes 3) (2GB mem and 2cores VM's for each of the 6 nodes)

I used pgbench with built-in sql (e.g. simple-update, select-only, tpc-b). As I added worker nodes from one to 5 the tps only increase about less than 1-10% (depends on # of client and WAL on hdd or ssd).

When benchmarking with SELECT, the coordinator VM load can go up to 60+, with other 2 type of SQL the load is only 2 or so. The worker nodes load always about 1 and disk io is between 500 and 2000 io/sec

Does this result sound right? Anything I can do to improve the performance?

Thanks, David

David Fang
  • 1
  • Does pgbench accurately reflect what your real workload will be? Why do you care what the TPS is for unrealistic transactions run in unrealistic ways? There is no point in trying to make it faster until you have a good reason to care. – jjanes Mar 17 '20 at 16:14
  • What scale factor did you use? I'd expect the best benefit to come when the data does not fit in the RAM of one node, but does easily fit in the RAM of all nodes combined. But I also don't think the tiny transactions of tpc-b is the best benchmark type for showcasing Citus. – jjanes Mar 17 '20 at 16:19
  • Hi @jjanes, Thanks for your comments. At this stage, I am trying to understand basics of Citus and comparing it with Postgres in our environment. We have been using Postgres for a while and like to see how can Citus help us scale out in near future. After this basic setup I cannot see how it scales out at all for us. So I like to get some feedback before jump into the conclusion for Citus. I also did the same pgbench run on a single node postgres built on similar VM. The single node is showing few times of tps of Citus cluster. Am I missing anything? – David Fang Mar 17 '20 at 17:44
  • And my scaling factor was set to 30. – David Fang Mar 17 '20 at 17:56
  • For tiny transactions like tpc-b-like, it isn't surprising that the overhead of routing them to the right node is higher than the benefit. Especially since at a scale of 30, all data should fit in the RAM of a single node. – jjanes Mar 17 '20 at 18:05

1 Answers1

0

For a scale factor of 1 the tables will have:

table                   # of rows
---------------------------------
pgbench_branches        1
pgbench_tellers         10
pgbench_accounts        100000
pgbench_history         0

https://www.postgresql.org/docs/current/pgbench.html

So scaling factor 30 will have 3M rows in pgbench_accounts, which will probably fit into memory of a single node as suggested by jjanes.

And you have 5 worker nodes so you can definitely increase the scaling factor much more. When the data doesn't fit to a memory of a single node, you should see the difference with citus.

heisenberg302
  • 1