Misskey運用におけるPostgreSQLのチューニング
MisskeyのレスポンスはPostgreSQLをインストールしているサーバーのスペックに大きく左右され、一番負荷がかかるのもMisskey本体ではなくPostgreSQLです。（12.75.0で大幅に改善）
このスレッドではPostgreSQLのチューニングについて実際の設定を用いて解説します。
※設定例はPostgreSQLをMisskeyやRedisと別のマシンとして独立させた場合です。
まず、想定ユーザー数1~100人、CPU 2コア2スレッド、RAM 2GB、SATA SSDの構成例です。
code:postgres.conf
max_connections = 64
shared_buffers = 512MB
effective_cache_size = 1536MB
maintenance_work_mem = 128MB
checkpoint_completion_target = 0.7
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 300
work_mem = 8MB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 2
max_parallel_workers_per_gather = 1
max_parallel_workers = 2
max_parallel_maintenance_workers = 1
詳細な解説は省きますが、少ないメモリと非力なCPUでもMisskeyを効率よく運用できる設定です。
特にeffective_cache_sizeを高めに設定することでシーケンシャルスキャンを減らしリソースを削減しています。
次は想定ユーザー数は100~300人、CPU 4コア4スレッド、RAM 8GB、 SATA SSDの構成例です。
code:postgres.conf
max_connections = 128
shared_buffers = 2GB
effective_cache_size = 6GB
maintenance_work_mem = 512MB
checkpoint_completion_target = 0.7
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 300
work_mem = 8MB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 4
max_parallel_workers_per_gather = 2
max_parallel_workers = 4
max_parallel_maintenance_workers = 2
ここでもeffective_cache_sizeを多めに設定したり、shared_buffersを増やすことでインデックスを有効活用しリソースを削減しています。
shared_buffersはもう少し大きめに設定して良いように見えますが、これ以上大きくしてもバッファー検索に時間がかかったり、OSが利用出来るバッファーが足りなくなりディスクスワップが発生し逆に性能が低下します。
オマケ - Misskey.ioの設定
想定ユーザー数5,000~50,000人、CPU 48コア96スレッド、RAM 768GB、NVMe SSD
code:postgres.conf
max_connections = 256
shared_buffers = 128GB
effective_cache_size = 384GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.7
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 128MB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 96
max_parallel_workers_per_gather = 4
max_parallel_workers = 96
max_parallel_maintenance_workers = 4