Rsync が 50 GB の単一ファイルで Linux OOM キラーをトリガーした

Question 1

それでは、oom-killer の出力を読んで、そこから何がわかるかを見てみましょう。

OOM キラーログを分析する場合、何がそれをトリガーしたかを確認することが重要です。ログの最初の行には、いくつかの手がかりがあります。

[カーネル] [1772321.850644] clamd が oom-killer を呼び出しました:gfp_mask=0x84d0、順序=0

order=0要求されているメモリの量を示しています。カーネルのメモリ管理では 2 の累乗のページ番号しか管理できないため、clamd は 2 ⁰ページ、つまり 4KB のメモリを要求しています。

GFP_MASK（空きページマスク取得）の下位2ビットは、いわゆるゾーンマスク アロケータにメモリをどのゾーンから取得するかを指示する:

Flag            value      Description
                0x00u      0 implicitly means allocate from ZONE_NORMAL
__GFP_DMA       0x01u      Allocate from ZONE_DMA if possible
__GFP_HIGHMEM   0x02u      Allocate from ZONE_HIGHMEM if possible

メモリゾーン主に互換性の理由から作成された概念です。簡略化すると、x86 カーネルには 3 つのゾーンがあります。

Memory range   Zone       Purpose 

0-16 MB        DMA        Hardware compatibility (devices)
16 - 896 MB    NORMAL     space directly addressable by the Kernel, userland 
> 896 MB       HIGHMEM    userland, space addressable by the Kernel via kmap() calls

あなたの場合、ゾーンマスクは 0 であり、clamd がからメモリを要求していることを意味しますZONE_NORMAL。

他のフラグは次のように解決されます

/*
 * Action modifiers - doesn't change the zoning
 *
 * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
 * _might_ fail.  This depends upon the particular VM implementation.
 *
 * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
 * cannot handle allocation failures.
 *
 * __GFP_NORETRY: The VM implementation must not retry indefinitely.
 */
#define __GFP_WAIT      0x10u   /* Can wait and reschedule? */
#define __GFP_HIGH      0x20u   /* Should access emergency pools? */
#define __GFP_IO        0x40u   /* Can start physical IO? */
#define __GFP_FS        0x80u   /* Can call down to low-level FS? */
#define __GFP_COLD      0x100u  /* Cache-cold page required */
#define __GFP_NOWARN    0x200u  /* Suppress page allocation failure warning */
#define __GFP_REPEAT    0x400u  /* Retry the allocation.  Might fail */
#define __GFP_NOFAIL    0x800u  /* Retry for ever.  Cannot fail */
#define __GFP_NORETRY   0x1000u /* Do not retry.  Might fail */
#define __GFP_NO_GROW   0x2000u /* Slab internal usage */
#define __GFP_COMP      0x4000u /* Add compound page metadata */
#define __GFP_ZERO      0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x10000u /* Don't use emergency reserves */
#define __GFP_NORECLAIM  0x20000u /* No realy zone reclaim during allocation */

によるLinux MM ドキュメントGFP_ZEROしたがって、リクエストには、、、およびGFP_REPEATのフラグが含まれており、特に厳密なものではありません。GFP_FSGFP_IOGFP_WAIT

では、はどうなっているのでしょうかZONE_NORMAL? OOM 出力のさらに先に、いくつかの一般的な統計情報があります。

[カーネル] [1772321.850770] 正常空き:8056kB 最小:8048kB 低:10060kB高さ:12072kB アクティブ匿名:0kB 非アクティブ匿名:0kB アクティブファイル:248kB 非アクティブファイル:388kB 非追放可能:0kB 隔離(匿名):0kB 隔離(ファイル):0kB 現在:890008kB

ここで注目すべきはfreeわずか8Kminそしてずっと下lowこれは、ホストのメモリマネージャが多少問題を抱えており、kswapdがすでにページをスワップアウトしていることを意味します。黄色以下のグラフの位相:

ゾーンのメモリ断片化に関する詳細情報は、以下に記載されています。

[カーネル] [1772321.850795] 通常: 830*4kB 80*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 8056kB

基本的には、4MB の連続したページが 1 つあり、残りは主に 4KB のページに大きく断片化されていることを示しています。

では、要約してみましょう。

ユーザランドプロセス（clamd）がメモリを取得していますZONE_NORMALが、非特権メモリの割り当ては通常、ZONE_HIMEM
メモリマネージャはこの時点で要求された4Kページを処理できるはずですが、メモリ不足がかなり発生しているようです。ZONE_NORMAL
システムは、kswapdのルールにより、すべきZONE_NORMAL以前にページングアクティビティが見られましたが、明らかな理由もなく、メモリ不足の状態でもスワップアウトは行われませんでした。
上記のいずれも、なぜoom-killer呼び出されたのか明確な理由を示していない。

これらはすべてかなり奇妙に思えるが、少なくともJohn O'Gorman の優れた書籍「Linux 仮想メモリマネージャの理解」のセクション 2.5:

カーネルが使用できるアドレス空間 (ZONE_NORMAL) のサイズは限られているため、カーネルはハイメモリの概念をサポートしています。 [...] 1GiB から 4GiB の範囲のメモリにアクセスするために、カーネルは kmap() を使用して一時的にハイメモリから ZONE_NORMAL にページをマップします。 [...]

つまり、1GiB のメモリを記述するには、約 11MiB のカーネルメモリが必要です。したがって、16GiB では 176MiB のメモリが消費され、ZONE_NORMAL に大きな負担がかかります。ZONE_NORMAL を使用する他の構造を考慮するまでは、これはそれほど悪くないように思えます。ページテーブルエントリ (PTE) などの非常に小さな構造でも、最悪の場合、約 16MiB が必要です。これにより、x86 Linuxで利用可能な物理メモリの実質的な限界は16GiB程度となる。。

（強調は私によるものです）

3.2 では 2.6 に比べてメモリ管理がかなり進歩しているので、これは明確な答えではありませんが、私が最初に追求すべき非常に強力なヒントです。カーネルmem=パラメータを使用するか、サーバーから DIMM の半分を取り外すことによって、ホストの使用可能なメモリを最大 16G に減らします。

結局、64ビットカーネルを使用する。

おい、今は2015年だよ。

Answer

それでは、oom-killer の出力を読んで、そこから何がわかるかを見てみましょう。

OOM キラーログを分析する場合、何がそれをトリガーしたかを確認することが重要です。ログの最初の行には、いくつかの手がかりがあります。

[カーネル] [1772321.850644] clamd が oom-killer を呼び出しました:gfp_mask=0x84d0、順序=0

order=0要求されているメモリの量を示しています。カーネルのメモリ管理では 2 の累乗のページ番号しか管理できないため、clamd は 2 ⁰ページ、つまり 4KB のメモリを要求しています。

GFP_MASK（空きページマスク取得）の下位2ビットは、いわゆるゾーンマスク アロケータにメモリをどのゾーンから取得するかを指示する:

Flag            value      Description
                0x00u      0 implicitly means allocate from ZONE_NORMAL
__GFP_DMA       0x01u      Allocate from ZONE_DMA if possible
__GFP_HIGHMEM   0x02u      Allocate from ZONE_HIGHMEM if possible

メモリゾーン主に互換性の理由から作成された概念です。簡略化すると、x86 カーネルには 3 つのゾーンがあります。

Memory range   Zone       Purpose 

0-16 MB        DMA        Hardware compatibility (devices)
16 - 896 MB    NORMAL     space directly addressable by the Kernel, userland 
> 896 MB       HIGHMEM    userland, space addressable by the Kernel via kmap() calls

あなたの場合、ゾーンマスクは 0 であり、clamd がからメモリを要求していることを意味しますZONE_NORMAL。

他のフラグは次のように解決されます

/*
 * Action modifiers - doesn't change the zoning
 *
 * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
 * _might_ fail.  This depends upon the particular VM implementation.
 *
 * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
 * cannot handle allocation failures.
 *
 * __GFP_NORETRY: The VM implementation must not retry indefinitely.
 */
#define __GFP_WAIT      0x10u   /* Can wait and reschedule? */
#define __GFP_HIGH      0x20u   /* Should access emergency pools? */
#define __GFP_IO        0x40u   /* Can start physical IO? */
#define __GFP_FS        0x80u   /* Can call down to low-level FS? */
#define __GFP_COLD      0x100u  /* Cache-cold page required */
#define __GFP_NOWARN    0x200u  /* Suppress page allocation failure warning */
#define __GFP_REPEAT    0x400u  /* Retry the allocation.  Might fail */
#define __GFP_NOFAIL    0x800u  /* Retry for ever.  Cannot fail */
#define __GFP_NORETRY   0x1000u /* Do not retry.  Might fail */
#define __GFP_NO_GROW   0x2000u /* Slab internal usage */
#define __GFP_COMP      0x4000u /* Add compound page metadata */
#define __GFP_ZERO      0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x10000u /* Don't use emergency reserves */
#define __GFP_NORECLAIM  0x20000u /* No realy zone reclaim during allocation */

によるLinux MM ドキュメントGFP_ZEROしたがって、リクエストには、、、およびGFP_REPEATのフラグが含まれており、特に厳密なものではありません。GFP_FSGFP_IOGFP_WAIT

では、はどうなっているのでしょうかZONE_NORMAL? OOM 出力のさらに先に、いくつかの一般的な統計情報があります。

[カーネル] [1772321.850770] 正常空き:8056kB 最小:8048kB 低:10060kB高さ:12072kB アクティブ匿名:0kB 非アクティブ匿名:0kB アクティブファイル:248kB 非アクティブファイル:388kB 非追放可能:0kB 隔離(匿名):0kB 隔離(ファイル):0kB 現在:890008kB

ここで注目すべきはfreeわずか8Kminそしてずっと下lowこれは、ホストのメモリマネージャが多少問題を抱えており、kswapdがすでにページをスワップアウトしていることを意味します。黄色以下のグラフの位相:

ゾーンのメモリ断片化に関する詳細情報は、以下に記載されています。

[カーネル] [1772321.850795] 通常: 830*4kB 80*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 8056kB

基本的には、4MB の連続したページが 1 つあり、残りは主に 4KB のページに大きく断片化されていることを示しています。

では、要約してみましょう。

ユーザランドプロセス（clamd）がメモリを取得していますZONE_NORMALが、非特権メモリの割り当ては通常、ZONE_HIMEM
メモリマネージャはこの時点で要求された4Kページを処理できるはずですが、メモリ不足がかなり発生しているようです。ZONE_NORMAL
システムは、kswapdのルールにより、すべきZONE_NORMAL以前にページングアクティビティが見られましたが、明らかな理由もなく、メモリ不足の状態でもスワップアウトは行われませんでした。
上記のいずれも、なぜoom-killer呼び出されたのか明確な理由を示していない。

これらはすべてかなり奇妙に思えるが、少なくともJohn O'Gorman の優れた書籍「Linux 仮想メモリマネージャの理解」のセクション 2.5:

カーネルが使用できるアドレス空間 (ZONE_NORMAL) のサイズは限られているため、カーネルはハイメモリの概念をサポートしています。 [...] 1GiB から 4GiB の範囲のメモリにアクセスするために、カーネルは kmap() を使用して一時的にハイメモリから ZONE_NORMAL にページをマップします。 [...]

つまり、1GiB のメモリを記述するには、約 11MiB のカーネルメモリが必要です。したがって、16GiB では 176MiB のメモリが消費され、ZONE_NORMAL に大きな負担がかかります。ZONE_NORMAL を使用する他の構造を考慮するまでは、これはそれほど悪くないように思えます。ページテーブルエントリ (PTE) などの非常に小さな構造でも、最悪の場合、約 16MiB が必要です。これにより、x86 Linuxで利用可能な物理メモリの実質的な限界は16GiB程度となる。。

（強調は私によるものです）

3.2 では 2.6 に比べてメモリ管理がかなり進歩しているので、これは明確な答えではありませんが、私が最初に追求すべき非常に強力なヒントです。カーネルmem=パラメータを使用するか、サーバーから DIMM の半分を取り外すことによって、ホストの使用可能なメモリを最大 16G に減らします。

結局、64ビットカーネルを使用する。

おい、今は2015年だよ。

Question 2

いくつかのこと...

私の経験則では、スワップスペースは物理 RAM の少なくとも 2 倍の容量にする必要があります。これにより、ページ/スワップデーモンがメモリを効率的に再編成できるようになります。

Server_Bには32GBのRAMがあるので、64GBのスワップを設定してみてください。私の意見では、あなたのサーバーの2GBのスワップスペースは方法特にサーバーにとっては低すぎます。

スワップパーティションにできる余分なパーティションがない場合は、ファイルを作成してそれをスワップパーティションとしてマウントすることでテストできます[遅くなります]。https://www.maketecheasier.com/swap-partitions-on-linux/

server_B には十分なディスク容量があるため、--inplace は必要ありません。また、rsync が 32GB を使用する原因となっている可能性があるため、--inplace は望ましくない可能性があります。--inplace は、ファイルシステムの容量が不足している場合 (実際には不足していません)、または特別なパフォーマンス要件がある場合にのみ役立ちます。

私の推測では、現在のオプションでは rsync は 50GB の RAM [ファイルサイズ] を使用するでしょう。通常、rsync はジョブを実行するためにそれほど多くのメモリを必要としないので、1 つ以上のオプションに問題がある可能性があります。私は 200GB のファイルを問題なく定期的に転送しています。

オプションなしでテスト実行をいくつか実行します。10 GB などの小さいファイルでこれを実行します。これによりカーネルパニックを回避できるだけでなく、問題の原因となっている動作を監視できます。rsync のメモリ使用量を監視します。

徐々にオプションを 1 つずつ追加していき、どのオプション [またはオプションの組み合わせ] が rsync に RAM の消費を大量に引き起こすかを確認します (たとえば、転送中に、rsync の RAM 使用量は転送されるファイルデータの量に比例して増加するなど)。

rsync が RAM 内のファイルイメージを保持するオプションが本当に必要な場合は、追加のスワップ領域が必要になり、最大ファイルサイズがそれに応じて制限されます。

さらにいくつか[更新済み]:

(1) カーネルスタックのトレースバックは、rsyncがmmap領域でページフォールトを起こしていることを示しています。おそらくファイルをmmapしているのでしょう。mmapはディスクにフラッシュする保証はありません。それまでファイルは閉じられ（読み取り/書き込みとは異なり）、すぐに FS ブロックキャッシュに送られます（そこでフラッシュされます）。

(2) カーネルのクラッシュ/パニックは、転送サイズが RAM のサイズに達したときに発生します。明らかに、rsync は malloc または mmap を介してその量の非 fscache メモリを取得しています。もう一度、指定したオプションを使用すると、rsync は 50 GB のファイルを転送するために 50 GB のメモリを割り当てます。

(3) 24GB のファイルを転送します。おそらくこれでうまくいくでしょう。次に、カーネルを mem=16G で起動し、24GB のファイルテストを再度実行します。32GB ではなく 16GB でオーバーフローします。これにより、rsync に本当にメモリが必要であることが確認できます。

(4) スワップを追加するのは馬鹿げていると言う前に、[スワップからファイルへの方法で] スワップを追加してみてください。これは、スワップが不要であるというすべての学術的な議論よりもはるかに簡単に実行およびテストできます。これが解決策ではないとしても、そこから何かを学べるかもしれません。mem=16G テストはパニックやクラッシュなしで成功するでしょう。

（５）rsyncははスワップにヒットしますが、OOM が起動して rsync を終了する前に top で確認するには速すぎます。rsync が 32GB に達するまでには、他のプロセスは既にスワップに追い出されています (特にアイドル状態の場合)。おそらく、「free」と「top」を組み合わせると、より正確な状況がわかるでしょう。

(6) rsync が強制終了された後、mmap を FS にフラッシュするのに時間がかかります。OOM には十分な速さではなく、他の処理を強制終了し始めます (明らかにミッションクリティカルなものもあります)。つまり、mmap フラッシュと OOM が競合しています。または、OOM にバグがあります。そうでなければ、クラッシュは発生しません。

(7) 私の経験では、システムが「メモリの壁にぶつかる」と、Linux が完全に回復するまでに長い時間がかかります。また、完全に回復しないことがあり、それを解消するには再起動するしかありません。たとえば、私の RAM は 12GB です。40GB のメモリを使用するジョブ (大規模なジョブに対応するために 120GB のスワップがあります) を実行してからそれを強制終了すると、システムが通常の応答性に戻るまで約 10 分かかります (その間、ディスクライトは点灯したままです)。

（8）rsyncを実行するそれなしオプション。これでうまくいきます。作業のベースライン例を入手します。次に、--inplace を戻して再テストします。次に、代わりに --append-verify を実行します。次に、両方を試します。どのオプションで rsync が巨大な mmap を実行するかを調べます。次に、それなしでも問題ないかを判断します。--inplace が原因である場合は、ディスク領域が十分にあるため、考える必要はありません。オプションが必要な場合は、rsync が実行する malloc/mmap に対応するためにスワップ領域を取得する必要があります。

2回目の更新:

上記の mem= および小さいファイルのテストを行ってください。

中心的な質問: rsync が OOM によって強制終了されるのはなぜですか? メモリを消費しているのは誰/何ですか?

システムが 32 ビットであることを読みましたが、忘れていました。したがって、rsync が直接原因ではない可能性があり (malloc/mmap 経由 - glibc は匿名/プライベート mmap 経由で大規模な malloc を実装)、rsync の mmap ページフォールトが偶然 OOM をトリガーしただけであることに同意します。次に、OOM は rsync によって直接的および間接的に消費されるメモリの合計 (FS キャッシュ、ソケットバッファなど) を計算し、それが主な候補であると判断します。したがって、メモリ使用量の合計を監視すると役立つ場合があります。ファイル転送と同じ速度で徐々に増加すると思われます。明らかに、そうすべきではありません。

/proc または /proc/rsync_pid で監視できる項目は、高速ループ内の perl または python スクリプト (bash スクリプトではおそらく世界終焉イベントには十分速くない) で、次のすべてを 1 秒あたり数百回監視できます。これを rsync よりも高い優先度で実行して RAM 内に保持し、クラッシュ直前やできれば OOM 中に監視して、OOM がおかしくなる理由を確認できます。

/proc/meminfo -- 「衝撃の時点」でのスワップ使用量をより詳細に取得します。実際には、合計でどのくらいの RAM が使用されているかの最終的な数値を取得する方が便利です。top はこれを提供しますが、「ビッグバン」の直前の宇宙の状態 (たとえば、最後の 10 ミリ秒) を表示するには速度が足りない可能性があります。

/proc/rsync_pid/fd ディレクトリ。シンボリックリンクを読むことで、ターゲットファイルで開かれている fd を識別できます (例: /proc/rsync_pid/fd/5 の readlink --> target_file)。これはおそらく、fd 番号を取得するために 1 回だけ実行する必要があります [固定されたままになるはずです]

fd 番号がわかったら、/proc/rsync_pid/fdinfo/fd を確認します。これは次のようなテキストファイルです。

pos: <ファイル位置>
フラグ: blah_blah
mnt_id: blah_blah

「pos」値を監視すると、「最後のファイル位置」が役に立つ場合があります。さまざまなサイズと mem= オプションを使用して複数のテストを実行する場合、最後のファイル位置はこれらのいずれかを追跡しますか [どのように]? 通常の疑い: ファイル位置 == 使用可能な RAM

しかし、最も簡単な方法は、「rsync local_file server:remote_file」から始めて、それが機能するかどうかを確認することです。「ssh server rsync file_a file_b」を実行すると、同様の（ただしより高速な）結果が得られる場合があります（最初に 50 GB の file_a を作成する必要があります）。file_a を作成する簡単な方法は、scp local_system:original_file server:file_a です。これはそれ自体興味深いかもしれません（たとえば、rsync がクラッシュしたときにこれが機能するかどうか？ scp は機能するが rsync が失敗する場合は、これが rsync を指します。scp が失敗する場合は、NIC ドライバーなどの他のものを指します）。ssh rsync を実行すると、NIC も方程式から外れるようになり、役立つ場合があります。これがシステムを台無しにする場合は、何かが本当に間違っています。成功した場合は、[前述したように] オプションを 1 つずつ追加し直してください。

この点について繰り返し述べるのは気が進みませんが、swap-to-file 経由でスワップを追加すると、クラッシュの動作が変わったり遅延したりすることがあり、診断ツールとして役立つ可能性があります。たとえば、16 GB のスワップを追加するとクラッシュが 32 GB から 46 GB に遅延する (メモリ使用量またはターゲットファイルの位置で測定) 場合、それは何かを物語っています。

特定のプロセスではなく、メモリを消費している誤ったカーネルドライバーである可能性があります。カーネルの内部 vmalloc がリソースを割り当て、スワップアウトできます。私の記憶が正しければ、あらゆる状況でアドレス指定可能性に制限されるわけではありません。

明らかに、OOM は混乱/パニックに陥っています。つまり、rsync を強制終了しても、メモリがタイムリーに解放されたことに気づかず、他の犠牲者を探し始めます。犠牲者の中には、システムの動作に重大な影響を与えるものもあるでしょう。

malloc/mmap は別として、これはフラッシュされていない FS キャッシュに長い時間がかかることが原因で発生する可能性があります (たとえば、フラッシュされていないデータが 30 GB あり、ディスク速度が 300 MB/秒と仮定すると、フラッシュに 100 秒かかる可能性があります)。その速度でも、OOM が急ぎすぎる可能性があります。または、OOM が rsync を強制終了しても、FS フラッシュが十分に速く開始されない (またはまったく開始されない) 可能性があります。または、FS フラッシュは十分に速く行われますが、ページが空きプールに戻される「遅延」リリースがあります。FS キャッシュの動作を制御するために設定できる /proc オプションがいくつかあります (それが何だったか思い出せません)。

mem=4G または他の小さな数値で起動してみてください。これにより、FS キャッシュが削減され、フラッシュ時間が短縮されて、OOM が他の処理を探す必要がなくなります (たとえば、フラッシュ時間が 100 秒から 1 秒未満に短縮されます)。また、32 ビットシステムなどで 4GB を超える物理 RAM を処理できない OOM バグが明らかになる可能性もあります。

また、重要な点として、非ルートとして実行します。ルートユーザーはリソースを消費することがないため、より寛容な制限が与えられます (例: メモリの 99% に対して、非ルートユーザーの場合は 95%)。これが、OOM がこのような状態になっている理由かもしれません。また、これにより、OOM などがメモリを再利用するための余裕が生まれます。

Answer