postgres: pgtune configs for m5a/t3a types and pgbench testing on separate machine #29
Conversation
|
Used those configs to get the pgbench numbers on supabase/benchmarks#9 (comment) |
Also move postgrest pgtune settings to config file
postgresql/postgres.nix
Outdated
| min_wal_size = "2GB"; | ||
| }; | ||
| "m5a.8xlarge" = { | ||
| max_connections = 300; |
There was a problem hiding this comment.
I've been using slightly hand-tuned numbers for the instances above, adapted from what we use in prod, rather than pgtune's default output. Notice that the max_conns is dropping down from 4xl here to 8xl
There was a problem hiding this comment.
I've modified these with bigger max_connections
| <!--pgrbench-all-pg-instances repeat 3 pgrbench-pgbench -c 100 > PGBENCH_RESULTS.md --> | ||
|
|
||
| Running on a m5a.large |
There was a problem hiding this comment.
Uploaded the results obtained by this command:
pgrbench-all-pg-instances repeat 3 pgrbench-pgbench -c 100 > PGBENCH_RESULTS.md
There was a problem hiding this comment.
Also corrected supabase/benchmarks#9 (comment)
There was a problem hiding this comment.
Looks a lot better :) There's a few more things I'd like to try here but I can do that as a follow-up at some point:
- testing varying the number of connections being used
- increasing the client size (typically, I'd want the machine driving the load to be at least as big as the target, to avoid any chance that we're bottlenecking on the client)
True. In fact this might already be happening because I'm now unable to get more TPS past Will follow up on this on a new PR. |
steve-chavez
changed the title
Also move postgrest pgtune settings to config file