🌟

Mastodonの弱小インスタンスを運用するのに設定したこと

2021/08/11に公開

Mastodon

tech

前提

環境

Ubuntu 18.04LTS
Mastodon （バージョン 2.4.3 でスタート。随時正式版に追従）

構成

すべて自宅サーバー上の Hyper-V 仮想マシン (Ryzen 7 1700, 32GB メモリ, Windows Server 2016)

Mastodon サーバー (3 コア, 4GB メモリ)
Ceph (2 コア 4GB, 1 コア 1.5GB * 2)

Ceph に関してはオーバースペック。ただの興味で動かしているだけです。以前は minio を使っていました。

将来的にクラウドに移行することを考慮して、最初から画像系は分離しています。

セットアップ回り

これに従っています。なので docker は使っていません。

監視回り

Raspberry Pi 上で動いている zabbix により監視しています。

現在の監視項目は以下の通り

ロードアベレージ
ディスク残量
Sidekiq ジョブ（https://github.com/ken-washikita/zbx-templates-mstdn)
Redis（https://github.com/ken-washikita/zbx-templates-mstdn)
postgres (https://share.zabbix.com/databases/db_postgresql/mamonsu-monitoring-agent-for-postgresql)

参考資料

大規模 Mastodon インスタンスを運用するコツ

バージョンが古いけれどもやってることは基本一緒なはず。実体験でも Sidekiq が詰まってしまうと色々と障害を引き起こしたので

Sidekiq 重要。

設定変更内容

Sidekiq

default キューを処理するのがキモなようなので、default キュー専業のプロセスを作成。

元の全部のキューを処理するプロセスはそのままにすることで、忙しくなったら 2 プロセスで default キューを処理してくれることを

期待している。足りなければスレッドを増やせばよいだろうというくらいの気持ち。

全キュー対象のプロセスのスレッド数増加

# /etc/systemd/system/mastodon-sidekiq.service
# 変更点のみ
Environment="DB_POOL=7"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 10 -q default -q（略）

# ファイル作成後、以下を実行
systemctl restart mastodon-sidekiq

default キュー対象のプロセス新規追加

default キューが滞留すると重いに直結するので、default キューだけを処理するプロセスを立ち上げる。

これで、ダッシュボード上の表示は 2 プロセスになる。

# /etc/systemd/system/mastodon-sidekiq.service をコピーして mastodon-sidekiq-default.serviceを作成
# 変更点のみ
Environment="DB_POOL=5"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 5 -q default

# ファイル作成後、以下を実行
systemctl start mastodon-sidekiq-default
systemctl enable mastodon-sidekiq-default

PostgreSQL のバッファ増量

2018/09/29 追記

https://pgtune.leopard.in.ua/ ここに"postgres が使用してよい"メモリ量を入れると、適切な config が生成されるので便利。

デフォルトだと 128MB になっているが、あまりに頼りないので増量。

メモリ自体は 2GB くらい空いているので増量しても問題ないと判断した。

# /etc/postgresql/10/main/postgresql.conf
shared_buffers = 512MB    # 元は128MB

ulimit 増加

Sidekiq のエラー部に、Too many open files が記録されていたので増量

`/etc/security/limits.conf
# 末尾に追加
      *    soft nofile 65536
      *    hard nofile 65536

備考

DB_POOL 5 => 7 処理スレッド数を増やしたので DB 接続がそれだけ必要になるだろうから増加
sidekiq スレッド数 5 => 10、CPU 負荷に余裕があったので倍増。スレッド数が足りずに Sidekiq のキューが伸びてレイテンシが上がってしまったタイミングがあったため（ダッシュボードで見れます）

事件記録

画像アップロード用サーバーの FW 設定ミスで接続蹴ってた事件

もうそのまんま。画像がアップロードできない状態になると、連合から飛んでくる画像も保存できずに Sidekiq のキューが伸びる。

結果、リモートフォローが失敗したり、プロフィール画像変更すると象が出てきたりした。

サイレンスと同時に画像もブロックしたら画像表示されなかった事件

連合の流れが速すぎるので上位 3 インスタンス(jp, nico, pawoo)をサイレンスにした際に、画像もブロックにしたら

該当インスタンスをフォローしている場合に画像が表示されなくなった問題。画像はブロックしないにして解決。

2018/09/29 追記 Sidekiq のメモリ使用量削減

Rails+Sidekiq 環境でメモリ使用量を減らす

↑（これ、mstdn.jp の運営引き継いだ会社の方ですね）

簡単に言えば jemalloc を使うことでメモリの無駄な領域を削減でき、驚くほどの効果がある。らしいです。 Sidekiq の作者が登場して、これ良いよって言っているのでそれほどの効果なんでしょう。

https://github.com/tootsuite/mastodon/issues/7257 (英語)

https://techracho.bpsinc.jp/hachi8833/2017_12_28/50109 （仕組み：日本語）

なお、docker だと jemalloc は適用できない。みたいなことが issue で語られています。

jemalloc の適用は下記がすごくわかりやすいです

2018/10/03 追記

こちらの Redis を UNIX ソケット経由接続に変更を適用しました。

少しでも負荷を削れるなら削りたいですよね。