Zenn
💭

misskeyを快適にしよう

2024/12/31に公開
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からKeyDBへ

Redis 7.xからKeyDBに移行する人

こちらのissueで一応移行のやり方が書いてありました。
私は怖いので試してません。
https://github.com/Snapchat/KeyDB/issues/527

KeyDBとは？

Redisのフォーク版です。
主に、マルチスレッドや高スループットなどのパフォーマンスを求めた改良を行っています。
プロトコルなどは全く変わらないため、Redisとの互換性があります。

パフォーマンスの違いは公式のドキュメントで紹介されているので、そちらを参照してください。
(めっちゃ早いよ！ってことが書いてあります)
https://docs.keydb.dev/blog/2020/09/29/blog-post/

もう一つ、Redis互換としてDragonflyがありますが、大規模サーバーなどで性能を発揮するだけなので今回は紹介しません。
I/O周りの技術は採用しているようです。

Redis/KeyDB/Dragonfly/Skytableの比較がこちらにあるので、詳しく知りたい方はどうぞ。
https://news.ycombinator.com/item?id=31796311

KeyDBへの移行

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

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

redis:
  image: redis:7-alpine

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

redis:
  image: eqalpha/keydb:alpine

KeyDBは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