Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

バックエンドのメモリリーク #10984

Open
syuilo opened this issue Jun 9, 2023 · 103 comments
Open

バックエンドのメモリリーク #10984

syuilo opened this issue Jun 9, 2023 · 103 comments
Labels
⚠️bug? This might be a bug 🔥high priority packages/backend Server side specific issue/PR 🐢Performance Efficiency related issue/PR ❓needs more investigation A bug whose causes are unknown

Comments

@syuilo
Copy link
Member

syuilo commented Jun 9, 2023

バックエンドにメモリリークがある可能性がある
@syuilo syuilo added packages/backend Server side specific issue/PR ⚠️bug? This might be a bug labels Jun 9, 2023
@EbiseLutica EbiseLutica added 🐢Performance Efficiency related issue/PR ❓needs more investigation A bug whose causes are unknown labels Jun 9, 2023
@syuilo
Copy link
Member Author

syuilo commented Jun 9, 2023

ローカル環境程度の規模では特定できなかった

@acid-chicken
Copy link
Member

メモリリークある？

@syuilo
Copy link
Member Author

syuilo commented Jun 10, 2023

らしい

@syuilo
Copy link
Member Author

syuilo commented Jun 10, 2023

からMisskeyプロセスを定期的に再起動しているという管理者を複数知ってる

@syuilo
Copy link
Member Author

syuilo commented Jun 10, 2023

キャッシュが溜まるのはあるけどそこまで膨れ上がるか？とも思う

@syuilo
Copy link
Member Author

syuilo commented Jun 10, 2023

実際にある程度の規模のサーバーのプロセスにデバッガー繋ぐしか特定する方法なさそう

@mattyatea
Copy link
Member

定期的に再起動しないとメモリ食い荒らしていきますね…（メモリリークかはわからないけど
あと起動しっぱなしだと重たくなるってのも聞いたことあります

@tamaina
Copy link
Member

tamaina commented Jun 10, 2023

p1.a9z.devだとそんなことない（多くて3GB程度で収まってる）んだけど、そもそも再起動回数が多いため当てにならない

image

@sim1222
Copy link
Contributor

sim1222 commented Jun 10, 2023

メモリ使用量は確認できていませんが、再起動せずに数百万ノートくらいノートするとcpu使用率が全体的に高めになる現象はあります

@nexryai
Copy link
Contributor

nexryai commented Jun 10, 2023 •
edited

自分のサーバー（misskey.sda1.net）では、起動後30分後の状態と1から2周間連続稼働の状態を比較すると1ワーカー辺りのメモリ使用率が起動後から3から4倍くらいになります。
またメモリが膨らむと同時にメモリ空きスペース自体には余裕があるのにswapが使われまくるみたいな現象が発生しています（メモリリークが関係あるかは謎ですがMisskeyを落とすとswapがほぼ全部開放されるのでMisskeyが使ってるのは確実）
image

@syuilo
Copy link
Member Author

syuilo commented Jun 10, 2023

とりあえずcache.tsに定期clean処理付けるか

@EbiseLutica
Copy link
Member

cache.tsのクリーン処理コミットできたらcherry-pickして自鯖で試してみます（自鯖はめちゃメモリ食われてるので）

@noellabo
Copy link
Contributor

のえすきーもやむを得ず、2プロセス交互で各1時間ごとの再起動やってます。
終了にやたら時間かかる（別の不具合？）ので再起動自体も大変で、キャッシュクリーンで改善するならありがたいです。

@sasagar
Copy link
Contributor

sasagar commented Jun 10, 2023

いかすきーも3時間に1回バックアップを立ち上げて差し替え再起動するという手順を踏んでます。
その結果解放されるのが2GBから3GB程度。
リークかどうかはわからないですが、何かしら対策をして頂けたら凄く助かります！

@GrapeApple0
Copy link
Contributor

こちらの方で一時間程度起動を続けた感じだと
screenshot 747
screenshot 748
のような感じでプロセスごとのメモリー使用量を見たところ、Master,Workerともにメモリーを消費し続けてる感じです
詳細は取れていませんが3日程度経過すると70%を超えてることも多いです

syuilo added a commit that referenced this issue Jun 10, 2023
@syuilo
fix(backend): キャッシュが溜まり続けないように
e8420ad 
Related #10984
@acid-chicken
Copy link
Member

  • メモリリークがあると感じているかどうか
  • 一日あたりのリモートを含めたノート増加数はどれくらいか
  • Docker 上で立てているかどうか
  • メモリ容量
  • OS
  • CPU アーキテクチャ

あたりでアンケートしたい感

@tamaina
Copy link
Member

tamaina commented Jun 10, 2023

そもそも: MisskeyサーバーでRAM使用量が（異常に）多いと感じるのはどのくらい？

https://p1.a9z.dev/notes/9ft3mdpuwj

@sasagar
Copy link
Contributor

sasagar commented Jun 10, 2023

  • メモリリークがあると感じているかどうか: メモリリークという確信はないけど、妙に増えていくメモリが有る印象は有る
  • 一日あたりのリモートを含めたノート増加数はどれくらいか: 1000前後
  • Docker 上で立てているかどうか: Yes
  • メモリ容量: 4GB + SWAP 10GB
  • OS: CentOS Stream 9
  • CPU アーキテクチャ: arm64

@tamaina
Copy link
Member

tamaina commented Jun 10, 2023

  • メモリリークがあると感じているかどうか
    いいえ
  • 一日あたりのリモートを含めたノート増加数はどれくらいか
    7万程度
  • Docker 上で立てているかどうか
    いいえ
  • メモリ容量
    24GB (使用量は11〜13%程度)
  • OS
    Ubuntu 22.04
  • CPU アーキテクチャ
    arm64

@kanasaki15
Copy link

  • メモリリークがあると感じているかどうか
    いいえ (メモリ使用量は気になっている(2日で約9G食っているので))
    ただ13.12と比べて13.13はメモリの消費具合は抑えられている気がする
  • 一日あたりのリモートを含めたノート増加数はどれくらいか
    約10万
  • Docker 上で立てているかどうか
    No
  • メモリ容量
    128G＋swap 64G
  • OS
    Arch Linux
  • CPU アーキテクチャ
    x86_64

蛇足：
clusterLimitを1から16に設定してからかなりメモリを食う気がします

@GrapeApple0
Copy link
Contributor

  • メモリリークがあると感じているかどうか
    • ややはい
  • 一日あたりのリモートを含めたノート増加数はどれくらいか
    • 約10万程度
  • Docker 上で立てているかどうか
    • いいえ
  • メモリ容量
    • 8GB
  • OS
    • Ubuntu 22.04 LTS
  • CPU アーキテクチャ
    • x86_64

@mattyatea
Copy link
Member

  • メモリリークがあると感じているかどうか

    • 感じている

  • 一日あたりのリモートを含めたノート増加数はどれくらいか

    • 14~20万くらい？

  • Docker 上で立てているかどうか

    • いいえ

  • メモリ容量

    • 4gb

  • OS

    • debian 11

  • CPU アーキテクチャ

    • arm

@nexryai
Copy link
Contributor

nexryai commented Jun 10, 2023 •
edited

misskey.sda1.net

メモリリークがあると感じているかどうか

はい

一日あたりのリモートを含めたノート増加数はどれくらいか

2から3万（ばらつきあり）

Docker 上で立てているかどうか

本体のみDocker、RedisとDBは別

メモリ容量

16GB

OS

Ubuntu Server 22.04 LTS

CPU アーキテクチャ

AMD64

@tamaina
Copy link
Member

tamaina commented Jun 10, 2023

MisskeyサーバーでRAM使用量が（異常に）多いと感じるのはどのくらい？

私は3GBは普通だと思っていたけど3GBで多く感じている人も一定数おり、結構そこらへんからして温度感に差がありそう

@popkirby
Copy link
Contributor

popkirby commented Jul 5, 2023

体感ですが、nodeはnsfwjsのバックエンドにいるTensorflowのメモリ管理には手出ししていないこともあり、glibcの話は nsfwjs 周りでは関係なさそうです ( MALLOC_TRIM_THRESHOLD_, MALLOC_MMAP_THRESHOLD_ を 16KBに固定しても動作に変化なし )

@ghost
Copy link

ghost commented Jul 31, 2023

13.14.2にアップデートしてから、Misskeyがメモリ不足でクラッシュするようになりました。

@nexryai
Copy link
Contributor

nexryai commented Aug 10, 2023 •
edited

あくまで可能性としてですが、Sharp（というかlibvips）がglibcを使っているのでそれ周りかもしれません。sharpのissueにもいくつかメモリ使用量が増加し続けるという趣旨のissueが上がっています。またgovipsなど他の言語のlibvipsを使ってるライブラリでも同様の問題に言及されています。
公式ドキュメントによればメモリアロケータの問題（？）らしく一般的なLinuxシステムが使用するメモリアロケータとマルチスレッド化されたプログラムの相性が悪いことが問題だと言われていました 。
もしこれが原因であればDockerコンテナをメモリアロケータが一般的なlinuxとは異なるAlpineベースにするとメモリ使用量が落ち着くかもしれません。 （Firefishでの話ですが、実際にUbuntuで直接動かしていたときよりmuslベースのAlpineを元にしたDockerコンテナで運用していたときのほうがメモリ使用量が圧倒的に安定するようになりました）

Ubuntu環境でもJemallocというメモリアロケータを使うよう環境変数を設定すれば同様に問題を回避できる可能性があります。(libjemalloc2を入れてLD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2すれば設定できるというのを見かけましたが本当かどうかは検証していません)

追記

検証環境でLD_PRELOADをjemallocのものに設定すると実際にメモリ使用量が落ち着くことを確認しました

@sasagar
Copy link
Contributor

sasagar commented Aug 16, 2023

#10984 (comment)
こちらを実施したところ、かなりメモリ（特にSWAP）の使用量が改善されたように思われます。

環境: CentOS Stream 9 / Systemd版 & Docker版ともに

@syobocat
Copy link

syobocat commented Aug 16, 2023 •
edited

tcmallocやmimallocが高パフォーマンスを謳っているので、メモリアロケータを変更するのであればそれらも検討すると良いかと思われます

私の管理しているサーバーでは規模が小さすぎて比較にならないのでどなたか検証していただけませんか

@fruitriin
Copy link
Contributor

私やってみようか
同接続100前後のサーバーと400前後のサーバーあるから

@GrapeApple0
Copy link
Contributor

こちらもjemalloc導入後は1.3GB程度で安定しています
screenshot 817

@kanade
Copy link

kanade commented Aug 16, 2023 •
edited

Ubuntu環境です。
Jemallocに切り替えてから3時間あまりの経過ですが、再起動後のメモリ使用量の上昇がかなり緩やかになり（1.2GB前後で安定）、スワップがほぼゼロになりました。

上がJemalloc導入前、下がJemalloc導入後のグラフです。
導入後半日ほど経過しましたがメモリ使用量は再起動後ずっと安定しています。
20230817

@popkirby
Copy link
Contributor

popkirby commented Aug 16, 2023 •
edited

nodejs/node#8871 (comment)
nodejs/node#21973

nodejs自体でメモリ確保が行われる際にもメモリ消費量が多くなることがあり（メモリの断片化が原因？）、workaroundとして jemalloc の利用が効果的になる場合もあるそうです。

@tai-cha
Copy link
Member

tai-cha commented Aug 17, 2023 •
edited

dockerだとこんな感じでjemalloc導入してみましたがたしかにうちの使用率も1.4GB程度で安定してる
https://github.com/nadesuki/nadesskey/pull/9/files

@fruitriin
Copy link
Contributor

fruitriin commented Aug 17, 2023 •
edited

misskey.gamelore.fun（同時接続400人くらい）
RAM
Total: 11.7GB
Used: 2GB
Free: 9.7GB
スクリーンショット 2023-08-17 14 22 23

入れる前の半分くらいになったかな？劇的に効いてそう

@EbiseLutica
Copy link
Member

Arch環境にてjemalloc導入しました。

メモリ4GBをフルに使い切って大きなGCが働いていたのが、現在1/2くらいのメモリ使用率で安定し続けています。効果絶大です。

@kanarikanaru
Copy link
Contributor

Ubuntu環境です
導入後7GB弱メモリ使用量が落ちました
clusterlimitは10です

@fruitriin
Copy link
Contributor

fruitriin commented Aug 17, 2023 •
edited

そういえばNewRelicで時系列グラフとってたのだわ
(misskey.gamelore.fun)
スクリーンショット 2023-08-17 15 25 34
朝4時再起動

@tamaina
Copy link
Member

tamaina commented Aug 17, 2023

https://sharp.pixelplumbing.com/install#linux-memory-allocator
lovell/sharp#1803

（ドキュメントに書いてあったわね）

@tamaina
Copy link
Member

tamaina commented Aug 17, 2023

なんでみんなそんなメモリ食ってんだろと思ってたら #8605 の時にjemalloc導入してたわ…

@tamaina
Copy link
Member

tamaina commented Aug 17, 2023

（皮肉にも1年以上運用して特にバグがないことがわかった）

@mendakon
Copy link

常に8GB使ってたのが4GBに！約半分になり人生が変わりました！

@syobocat
Copy link

jemalloc以外のメモリアロケータがどうしても気になったのでglibc malloc/jemalloc/mimalloc/tcmallocで比較をしようとしたのですが、仮想環境ではメモリ使用量の減少を再現できず断念しました…

@acid-chicken
Copy link
Member

image

@kanade
Copy link

kanade commented Aug 18, 2023

私の環境だけかもしれませんが、jemallocに変えたタイミングから、LTLを取得するAPIがレスポンスを返してくるまでの時間が改善されました。（5分ごとに監視しています）
20230818-195253

@syuilo
Copy link
Member Author

syuilo commented Sep 3, 2023

解決した方に報奨金を進呈

@tamaina
Copy link
Member

tamaina commented Sep 12, 2023

Dockerイメージにjemallocを含むようにすると親切かも

https://github.com/nadesuki/nadesskey/pull/9/files

syuilo added a commit that referenced this issue Sep 13, 2023
@syuilo
enhance(docker): Dockerイメージにjemallocを含むように
0d505f8 
#10984
@syuilo
Copy link
Member Author

syuilo commented Sep 19, 2023

アーキテクチャによっては使えないらしい

@syuilo
Copy link
Member Author

syuilo commented Sep 19, 2023

解決方法はありそう
#11847 (comment)

@syuilo
Copy link
Member Author

syuilo commented Sep 19, 2023

解決した方に報奨金を進呈(再掲)

@popkirby
Copy link
Contributor

popkirby commented Sep 19, 2023 •
edited by tamaina

entrypoint.sh みたいなのを作って

LD_PRELOAD=`pkg-config jemalloc --variable libdir`/libjemalloc`pkg-config jemalloc --variable install_suffix`.so

とかどうですか

@tamaina
Copy link
Member

tamaina commented Sep 19, 2023

アーキテクチャが増えて書き換えが発生するよりはそのほうがスマートだわね

@tamaina
Copy link
Member

tamaina commented Sep 19, 2023

（というかアーキテクチャでわざわざパスを分けるのやめてほしい）

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
⚠️bug? This might be a bug 🔥high priority packages/backend Server side specific issue/PR 🐢Performance Efficiency related issue/PR ❓needs more investigation A bug whose causes are unknown
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests