mastodonのサーバをメインで使うおひとり様用とは別に持っています。最近、そちらへの書き込みどころか見に行ってもいなかったのでわからなかったのですが、5日前からsidekiqのキューがたまったまま処理できていないため、アクセスすることもできなくなっていたことを今日知りました。
ひとまずVMを再起動することでwebからのアクセスとsshでのログインはできるようになったのですが、sidekiqのキューを確認してみると数百万件のキューが待機状態になっていました。まずは、この待機状態のキューをすべて終わらせないとactivitypubでつながっているサーバとかに色々迷惑がかかっているのではないかと思い、最優先でキューをすべて実行するようにしてみました。
まずは、sidekiqのスレッド数とDB接続数を100に上げてみました。
/etc/systemd/system/mastodon-sidekiq.service
Environment="DB_POOL=100" (中略) ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 100
このファイルを書き換えてから、sidekiqを再起動しました。
sudo systemctl daemon-reload
sudo systemctl restart mastodon-sidekiq
しかし、全然減りません。そこでそれぞれの数字を1000に上げてみました。それでもsidekiqのweb画面ではジョブ数が100以上行きません。「DB側の制限があるのか？」と思いググってみたところ、postgresqlの接続数のデフォルトが100であることを確認しました。そこで、postgresql.confの以下の値を書き換えました。
/etc/postgresql/10/main/postgresql.conf
max_connections = 1000 #100から1000に変更 (中略) shared_buffers = 1280MB #128MBから1280MBに変更
バッファサイズを変更したので、VMの割り当てメモリも8GBに増やしました。これでVMを再起動して様子を見たところ、ジョブ数が1000を行くようになって少しづつキューが減り始めました。
「これでいけるか？」と思ったのですが、15分くらいで今度はWebの応答がなくなりました。VMの再起動を3回ほどしてみましたが時間がたつと同じ状況になってしまいます。「次はたぶんnginxの設定だな」と思い、調べたところ扱えるファイル数を大きくしないとダメそうだということがわかりました。
/etc/nginx/nginx.conf
worker_rlimit_nofile 14096;
14096という数字はざっくりとしたもので、
cat /proc/sys/fs/file-max
で出た数字の1/10位指定すればシステムには影響ないだろうと勝手に判断したものです。
sudo systemctl restart nginx
としたところ、sidekiqのweb画面でポーリング間隔5秒につき500件が処理されていくことが確認できました。この後、全待機キューがはけるまで止まることはありませんでした。
ひとまず、キューは処理されたのでどうするか考えて、DBのmax_connectionsを110に、sidekiqの各数値を100にしました。DBのほうが多めになっているのは、夜間のスクリプトでDBバックアップをするために別途接続しに行っているからです。nginxのほうは4096で様子を見ています。これでVMの割り当てメモリを2GBに戻して数時間経過していますが今のところ異常は見られません。
VM自体がハングしているのかとも疑いましたが、夜間のバックアップ処理は毎日行われていたことが確認できていますのでそういうわけでもなさそうです。原因の調査は今後やっていきたいと思います。
