Jemallocを使ってMisskeyのメモリ増加問題を緩和する

Posted on Aug 13, 2023

概要

Misskey v13はv12と比較してかなり多機能でデザインも改善されていますがリソース使用量が非常に多く特にメモリを食いまくるという欠点があります。
これを解決するために定時再起動している管理者の方も多いようです(私もその一人でした)
今回メモリアロケータを通常のglibcのmallocからjemallocを使うようにしたら緩和された感じがあるのでやり方だけ紹介しておきます。

導入方法

面倒な話は置いておいてとりあえずやり方を先に紹介します。
まずjemallocを入れます。これがないと始まりません。

# Debian系以外でも似たような名前でパッケージがあるはず
sudo apt install libjemalloc2

# libjemallocのバイナリを探す
#(Fedoraでは/usr/lib64/libjemalloc.so.2、Debianでは/usr/lib/x86_64-linux-gnu/libjemalloc.so.2でした)
sudo find / -name "*jemalloc*"

後はsystemdのサービスファイルで環境変数としてLD_PRELOAD=[先程見つけたバイナリのパス]を設定して再起動すれば設定完了です。

Dockerの場合

Dockerfileをこんな感じにすればok
やってることはaptでlibjemalloc2入れてENVにLD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2を追加しているだけです。

経緯

別のプロジェクトでgovipsというライブラリを扱っていたのですが、マルチスレッド化されたhttpサーバー内で使うとメモリ使用量が増加し続けるという問題に対してglibcのMallocとの相性が悪いせいと述べられていました。ここではMALLOC_ARENA_MAXという環境変数を設定しろと述べられていますが効果が思わしくなく、調べてみるとmuslベースのAlpineを使うかJemallocというメモリアロケータを使うようにすると解決する(意訳)という結論に辿り着きました。
Misskeyが画像処理周りに使っているSharpもlibvipsを使っていて、昨今言われているメモリ使用量問題もこれが一因なんじゃないかと思った訳です。

実際にどれくらい減るのか

厳密に検証した訳ではないので正確なことは言えませんがメモリ4GBの検証環境で試した限りはかなり落ち着くようになりました。通常だと起動後12時間も経たないうちにmasterが470MBくらい、workerが670MBくらい使用するのに対してJemalloc使用時だと起動後1.5日経過してもmasterが335MB、workerが435MBくらいで落ち着いています。
またMisskey v12のフォークで運用されている私のインスタンスでもUbuntuに直接インストールからMuslを使用するAlpineベースのDockerイメージで動かすようにしたworkerのメモリ使用量が半分くらいで安定するようになりました。
もっと長く動かさないと最終的にどうなるのかは分かりませんが確実にマシにはなっていると思います。