💭

misskeyを快適にしよう

に公開
Misskey
tech

おことわり

  • これは私がメモ代わりに書いたものなので、実際に使用する際は自分の環境に合わせて調整してください。
  • あくまで参考程度にしてください。

効果がありそうな人

  • サーバースペックが低い(ラズパイ単体とか)
  • 大人数で使う・連合が多いサーバー
    (dbがでかくなってる人はポスグレの最適化だけしたらいい感じになるかも？)

PostgreSQLの最適化

基本的にはpgtuneでマシンの値を入力して出てきた設定をpostgresql.confに使用しています。
https://pgtune.leopard.in.ua/

これは人それぞれだと思いますが、小規模サーバーであればConnectionsは128で十分だと思います。

例えば、Misskeyしか動かさないマシンであれば、そのままの値を入力して問題ありません。
他のアプリケーションも動かすのであれば、CPU/メモリの値を減らしたり、1/2にするといいでしょう。

設定を変更したら、PostgreSQLを再起動することで新しい設定が読み込まれます。

影響する細かい部分

主に以下のパラメータがパフォーマンスに関わってきます。

  • effective_cache_size
  • shared_buffers

PostgreSQLでは、effective_cache_size + shared_buffersで指定したメモリ量までしか使用しません。

effective_cache_size

オペレーティングシステムのファイルシステムキャッシュで利用可能と想定されるメモリ量を指定します。
推奨値: システムの空きメモリの50-75%
(例: メモリ32GBのシステムなら16-24GB)

このパラメータはクエリプランナの見積もりにのみ影響し、実際のメモリ割り当ては行いません。
この値を小さく設定してしまうと、キャッシュが少なくなりディスクI/Oが発生し、パフォーマンスが低下します。

shared_buffers

PostgreSQLが共有メモリバッファとして使用するメモリ量を指定します。
推奨値: システムメモリの25%程度
(例: メモリ32GBのシステムなら8GB)

このパラメータは実際のメモリ割り当てを行うため、大きすぎる値を設定すると問題が発生する可能性があります。
PostgreSQLのデータアクセス時にメモリ上に展開し、キャッシュしておくことで、何度もアクセスが発生する場合のパフォーマンスが向上します。

WALファイル周りの話もありますが、大抵は生成した設定をそのまま使っておけば問題ありません。
(急にマシンの電源が落ちるなどの問題がなければ...)

Vacuum

PostgreSQLを動かしていると不要な領域が出てくるので、定期的なVacuumの実行を推奨します。
データベースのサイズが大きいと時間がかかります。

サーバーを稼働したまま実行する場合はこちら:

VACUUM VERBOSE;

サーバーを停止する必要がありますが、空いた領域をOS側に返却させる際はこちらを実行してください。
(実行中はテーブルがロックされます)

VACUUM FULL VERBOSE;

RedisからValkeyへ

Valkeyとは？

Redisのコミュニティ主導のオープンソースフォークです。Redisのライセンス変更（RSALv2およびSSPLv1への移行）を受け、Linux Foundationの支援のもと、AWS、Google Cloud、Oracleなどの主要企業が協力して立ち上げました。

Redis 7.2.4をベースにしており、長年にわたるRedisの安定性とパフォーマンスを引き継ぎつつ、オープンソースとしてコミュニティ主導での開発を継続することを目的としています。マルチスレッドI/Oなどのパフォーマンス向上機能も取り込まれており、Redisとの高い互換性を維持しています。

より詳しい背景やValkeyプロジェクトについては、公式サイトをご参照ください。
https://valkey.io/

Valkeyへの移行

RedisからValkeyへの移行は簡単です。Redisと完全な互換性があるため、基本的にはイメージを置き換えるだけで機能します。

以下のように、compose.ymlのRedisイメージを:

redis:
  image: redis:7-alpine

Valkeyイメージに置き換えます:

redis:
  image: valkey/valkey:7-alpine

ValkeyはRedisのドロップイン置き換えとして機能するため、既存のRedisクライアントやアプリケーションコードを変更する必要はありません。

Misskeyのコンフィグ

ここで言うコンフィグは.config/default.ymlのことです。

clusterLimit

セットアップに必要なところ以外を触っていない状態であれば、clusterLimitがコメントアウトされていると思います。
基本的にはCPUのコア数と同じ値を入れておけばいいです。
ワーカー1つあたり400~500MB程度のメモリを使用するようになるので、メモリが少ない人は注意してください。

Job Concurrency(触らなくていい)

「jobなんたらって何？」と思うかもしれませんが、これはワーカー1つあたりが処理を行うジョブ数を決めます。

私の環境では以下のように設定しています。

deliverJobConcurrency: 256
inboxJobConcurrency: 256

job rate limiterやjob attemptsは触っていません。
concurrencyを触らないのであれば、ここも変更する必要はありません。

メモ

小規模サーバーから大規模サーバーまでのPostgreSQLのチューニング設定が載っています。
https://scrapbox.io/cookie-ramen/Misskey運用におけるPostgreSQLのチューニング

Discussion