Is Managed Postgres 4GB sufficiently performant for Mastadon?
I'm currently using a Shared CPU 8GB Linode to run Mastodon, together with Linode Object Storage and the daily backup service. However, I've since found out that daily backups might not cover Postgres, and it's better to take daily backups using pg_dump etc. This places additional IO load on the server, which I'm keen to avoid.
I noticed that the Managed Postgres service includes daily backups, and I'm considering migrating the Mastodon database onto this (likely the 4GB Dedicated CPU single node option). Before I do this, however, I wanted to check the following details:
1) With my Linode, I'm able to invoke a specific backup (say if I'm about to perform an upgrade and want a snapshot). Am I able to do the same with the Managed Database?
2) With Mastodon, I've needed to do some tuning to how Postgres is initiated from the docker-compose file so that it consumes sufficient memory and has enough connections available. Am I correct in understanding that with the managed service, all this is done for me? If not, do I have access to postgres.conf to tune as needed?
3) Am I correct in understanding that my options are limited when it comes to moving to larger database setups in the future, and I'll likely have to backup the database before installing it in a larger node?
Many thanks for your help.
1 Reply
user153861
Linode Staff
Hey,
That sounds like a proper power user's setup, and thank you for sharing your details. I don't have much database experience, so it's eye-opening to read about different stacks and their integration and application. Here are my answers to your queries, back to front.
…backup the database before installing it in a larger node?
3. You have correctly understood one of the limitations of our Managed Database product: you'll need to backup and restore to expand.
…do I have access to postgres.conf to tune as needed?
2. You do not have access to postgres.conf. Customer Support and the administrators would serve as your text editors in the Managed DB context. max_connections is a commonly requested change.
…able to invoke a specific backup?
1. You can request the restoration of any one of the automatic backups which are taken daily and retained for 7 days.
I would like to suggest that you have a look at the Block Storage product as well. It's not immediately obvious to me whether this will suite your needs, but it's easy enough to test how pg_dump performs while on a mounted NVMe volume that I think it's worth a try. It would certainly and markedly increase the database's redundancy. I've included some data below to give you an idea, and would conclude with the final point that we always recommend making a separate backup of your data, for all of our products.
All the best,
block storage
one-large-file: (g=0): rw=write, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=libaio, iodepth=64
fio-3.33
Starting 1 process
one-large-file: Laying out IO file (1 file / 4096MiB)
one-large-file: (groupid=0, jobs=1): err= 0: pid=2659: Mon Jul 10 06:53:02 2023
write: IOPS=114, BW=525MiB/s (551MB/s)(1944MiB/3701msec); 0 zone resets
bw ( KiB/s): min=245760, max=827392, per=92.09%, avg=495338.00, stdev=198825.62, samples=7
iops : min= 60, max= 202, avg=120.86, stdev=48.52, samples=7
cpu : usr=1.03%, sys=0.16%, ctx=467, majf=0, minf=37
IO depths : 1=0.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=99.8%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.2%, >=64=0.0%
issued rwts: total=0,423,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
WRITE: bw=525MiB/s (551MB/s), 525MiB/s-525MiB/s (551MB/s-551MB/s), io=1944MiB (2038MB), run=3701-3701msec
Disk stats (read/write):
sdc: ios=0/3992, merge=0/41, ticks=0/1776547, in_queue=1776582, util=97.73%
Linode storage
test: (g=0): rw=write, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=libaio, iodepth=64
fio-3.33
Starting 1 process
test: Laying out IO file (1 file / 4096MiB)
test: (groupid=0, jobs=1): err= 0: pid=2751: Mon Jul 10 06:54:15 2023
write: IOPS=3644, BW=14.2GiB/s (15.3GB/s)(4096MiB/281msec); 0 zone resets
cpu : usr=32.86%, sys=3.93%, ctx=175, majf=0, minf=8
IO depths : 1=0.1%, 2=0.2%, 4=0.4%, 8=0.8%, 16=1.6%, 32=3.1%, >=64=93.8%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=99.9%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=0,1024,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
WRITE: bw=14.2GiB/s (15.3GB/s), 14.2GiB/s-14.2GiB/s (15.3GB/s-15.3GB/s), io=4096MiB (4295MB), run=281-281msec
Disk stats (read/write):
sda: ios=0/1021, merge=0/0, ticks=0/13426, in_queue=13426, util=30.52%