大規模システムでの Linux のメモリ管理
(This post is also available in English.)
この記事は Linux memory management at scale を 著者の Chris Down さんの許可 を得て Hiroaki Nakamura が日本語に翻訳したものです。 原文のライセンス は CC BY-SA 4.0 であり、翻訳のライセンスも同じく CC BY 4.0 とします。
cgroup2 プロジェクトでの私の仕事の一部として Linux システムのリソース管理についてエンジニアと話すことに多くの時間をかけてきました。 これらの会話を通じてどんどん明らかになってきた 1 つの事実は多くのエンジニアは、シニア SRE たちでさえも、 Linux のメモリ管理についていくつかのよくある誤解を持っていて、そしてそれが彼らがサポートするサービスやシステムが本来確実に稼働したり効率的に稼働したりできていたはずのところをそうできていない原因になっているということです。
ですので、これらの誤解の一部に踏み込む講演を行いました。 そこではメモリのこととなると一見そう見えるよりも事態がなぜ微妙なニュアンスを持つのかに踏み込んでいます。 さらに私はこの新しい知識を使ってより信頼性が高くスケーラブルなシステムをどうやって構成するかについても調べ、 Facebook でどのようにシステムを管理しているか、そしてあなた自身のシステムを改善するためにこの知識をどう応用することができるかについても話しています。
私は光栄にも SREcon でこの講演をしました。 これが役に立つことを願っています。 質問やコメントがあればご自由に私に e-mail を送ってください。
鍵となるタイムスタンプ
各セクションがその次のセクションを構成するのに役立ちますので講演全体を見ることをお勧めしますが、いくつかのキーポイントとなる箇所を以下に示します。
- 2:18: リソース管理は重要であり、信頼性と効率性の両方のために必要です
- 6:34: 単一のリソースだけにリミットをかけると、事態は悪化するかもしれません
- 7:28: リソース管理は一見するよりもはるかに複雑なものです
- 12:56: 多くの人々が誤解していますが、「回収可能」であるということは保証ではなく、キャッシュやバッファはフリーメモリのようには振る舞いません
- 14:54: 私たちは RSS を計測しそれに意味があるふりをしていますが、それは簡単に計測できるからであって、有用な何かを測れるものだからではありません
- 16:12: 巨大なメモリを持つマシンでさえ、スワップは重要です
- 18:59: OOM キラーは OOM の状況下でもあなたの友達ではないですし、あなたが期待するようにはたぶん動かないでしょう
- 22:10: メモリ回収の異なる種別となぜそれが重要か
- 25:05: システムがメモリを使い果たしたかをどのように知るか(単に MemAvailable あるいは MemFree + Buffers + Cached を見てもわかりません)
- 29:30: どのようにして OOM キラーの前に迫りつつある OOM を検知するか
- 30:49: I/O リソースの分離に有用なメトリックの決定
- 34:42: 何かにリミットをかけることは一般的にはうまく行かないので代わりに保護を作りましょう
- 37:21: これらのプリミティブを全て組み合わせれば効率の良いハイアベイラビリティなシステムを作れます
- 46:09: Facebook での本番運用での結果
- 48:03: これらの新しい概念のいくつかを使って Android の改善に役立てる
- 48:53: この講演のアドバイスをあなた自身でどのようにして実際に利用するか