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（取得空閒頁面遮罩）的最低兩位構成所謂的區域掩模 告訴分配器從哪個區域取得內存：

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 核心分為三個區域：

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

在您的情況下，zonemask 為 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_FS和GFP_IO的標誌GFP_WAIT，因此不是特別挑剔。

那怎麼了ZONE_NORMAL？可以在 OOM 輸出中進一步找到一些通用統計資料：

[內核] [1772321.850770] 正常免費:8056kB 最低:8048kB 低:10060kB高：12072kB active_anon：0kB inactive_anon：0kB active_file：248kB inactive_file：388kB 不可取消：0kB 隔離（anon）：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*256kB 0*512kB 0*1024kB 0*256kB 0*512kB 0*1024kB 0*

基本上是說您有一個 4MB 的連續頁面，其餘部分嚴重碎片化，主要是 4KB 頁面。

那麼讓我們回顧一下：

您有一個用戶態進程 ( clamd) 從中獲取內存ZONE_NORMAL，而非特權內存分配通常會從ZONE_HIMEM
記憶體管理器在這個階段應該能夠提供所請求的 4K 頁面，儘管您似乎有很大的記憶體壓力ZONE_NORMAL
系統，依照kswapd規則，應該事先已經看到一些分頁活動，但沒有任何內容被換出，即使在記憶體壓力下ZONE_NORMAL，也沒有明顯的原因
上述都沒有給出明確的理由說明為什麼oom-killer被調用

所有這些看起來都很奇怪，但至少與中描述的內容有關John O'Gorman 的優秀著作《Understanding the Linux Virtual Memory Manager》的第 2.5 節：

由於核心可用的位址空間（ZONE_NORMAL）的大小有限，因此核心支援高記憶體的概念。 [...] 為了存取 1GiB 到 4GiB 範圍之間的內存，核心使用 kmap() 暫時將高階內存中的頁面對應到 ZONE_NORMAL。 [...]

這意味著要描述 1GiB 內存，大約需要 11MiB 核心內存。因此，對於 16GiB，會消耗 176MiB 內存，給 ZONE_NORMAL 帶來巨大壓力。在考慮使用 ZONE_NORMAL 的其他結構之前，這聽起來並不算太糟。即使是非常小的結構，例如頁表條目 (PTE)，在最壞的情況下也需要大約 16MiB。這使得 16GiB 成為 x86 上 Linux 可用實體記憶體的實際限制。

（重點是我的）

由於 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（取得空閒頁面遮罩）的最低兩位構成所謂的區域掩模 告訴分配器從哪個區域取得內存：

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 核心分為三個區域：

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

在您的情況下，zonemask 為 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_FS和GFP_IO的標誌GFP_WAIT，因此不是特別挑剔。

那怎麼了ZONE_NORMAL？可以在 OOM 輸出中進一步找到一些通用統計資料：

[內核] [1772321.850770] 正常免費:8056kB 最低:8048kB 低:10060kB高：12072kB active_anon：0kB inactive_anon：0kB active_file：248kB inactive_file：388kB 不可取消：0kB 隔離（anon）：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*256kB 0*512kB 0*1024kB 0*256kB 0*512kB 0*1024kB 0*

基本上是說您有一個 4MB 的連續頁面，其餘部分嚴重碎片化，主要是 4KB 頁面。

那麼讓我們回顧一下：

您有一個用戶態進程 ( clamd) 從中獲取內存ZONE_NORMAL，而非特權內存分配通常會從ZONE_HIMEM
記憶體管理器在這個階段應該能夠提供所請求的 4K 頁面，儘管您似乎有很大的記憶體壓力ZONE_NORMAL
系統，依照kswapd規則，應該事先已經看到一些分頁活動，但沒有任何內容被換出，即使在記憶體壓力下ZONE_NORMAL，也沒有明顯的原因
上述都沒有給出明確的理由說明為什麼oom-killer被調用

所有這些看起來都很奇怪，但至少與中描述的內容有關John O'Gorman 的優秀著作《Understanding the Linux Virtual Memory Manager》的第 2.5 節：

由於核心可用的位址空間（ZONE_NORMAL）的大小有限，因此核心支援高記憶體的概念。 [...] 為了存取 1GiB 到 4GiB 範圍之間的內存，核心使用 kmap() 暫時將高階內存中的頁面對應到 ZONE_NORMAL。 [...]

這意味著要描述 1GiB 內存，大約需要 11MiB 核心內存。因此，對於 16GiB，會消耗 176MiB 內存，給 ZONE_NORMAL 帶來巨大壓力。在考慮使用 ZONE_NORMAL 的其他結構之前，這聽起來並不算太糟。即使是非常小的結構，例如頁表條目 (PTE)，在最壞的情況下也需要大約 16MiB。這使得 16GiB 成為 x86 上 Linux 可用實體記憶體的實際限制。

（重點是我的）

由於 3.2 比 2.6 在記憶體管理方面有許多進步，所以這不是一個明確的答案，而是我首先要追求的一個非常強烈的暗示。透過使用mem=核心參數或從伺服器中拆除一半 DIMM，將主機的可用記憶體減少到最多 16G 。

最終，使用 64 位元內核。

老兄，現在是2015年了。

Question 2

一些東西 ...

我對交換空間的經驗法則是至少擁有 2 倍的實體記憶體。這使得頁面/交換守護程序能夠有效地重組記憶體。

Server_B 有 32GB 內存，因此嘗試將其配置為 64GB 交換。 IMO，您的伺服器擁有的 2GB 交換空間是方式太低了，尤其是對於伺服器而言。

如果您沒有可以用作交換分割區的額外分割區，您可以透過建立一個檔案並將其安裝為交換分割區來測試它[這會很慢]。看https://www.maketecheasier.com/swap-partitions-on-linux/

由於 server_B 有足夠的磁碟空間，因此不需要 --inplace，並且可能不受歡迎，因為它可能是導致 rsync 使用 32GB 的原因。 --inplace 僅當您的檔案系統空間不足（實際上並非如此）或有一些特殊的效能要求時才真正有用。

我的猜測是 rsync 將需要使用 50GB 的 ram [檔案大小] 以及您目前的選項。通常，rsync 不需要那麼多記憶體來完成其工作，因此您的一個或多個選項可能會出現問題。我經常傳輸 200GB 的文件，沒有任何問題。

不使用任何選項進行一些測試運行。使用較小的檔案（例如 10GB）執行此操作 - 這應該可以防止核心恐慌，但仍然允許您監視導致問題的行為。監控 rsync 的記憶體使用情況。

逐漸地，一次添加一個選項，以查看哪個選項[或選項組合]導致 rsync 開始佔用 RAM（例如，在傳輸發生時，rsync 的 RAM 使用量與傳輸的文件資料量成比例增長， ETC。）。

如果您確實需要使 rsync 保留某些記憶體檔案映像的選項，則您將需要額外的交換空間，並且最大檔案大小將相應受到限制。

還有一些事情[更新]：

(1) 核心堆疊回溯顯示 rsync 在 mmap 區域上發生頁面錯誤。它可能正在映射文件。 mmap 不保證它將刷新到磁碟直到檔案關閉[與讀取/寫入不同]，它立即進入 FS 區塊快取[將被刷新]

(2) 當傳輸大小達到 RAM 大小時，就會發生核心崩潰/恐慌。顯然，rsync 正在透過 malloc 或 mmap 獲取大量非 fscache 記憶體。再次，使用您指定的選項，rsync 將分配 50GB 記憶體來傳輸 50GB 檔案。

(3) 傳輸24GB檔案。這可能會起作用。然後，以mem=16G啟動核心並再次進行24GB檔案測試。它會在 16GB 而不是 32GB 時爆發。這將確認 rsync 確實需要記憶體。

(4) 在你說添加交換是荒謬的之前，請嘗試添加一些[通過交換到文件的方法]。這比所有關於如何不需要交換的學術爭論更容易做到和測試。即使這不是解決方案，您也可以從中學到一些東西。我敢打賭 mem=16G 測試會成功，不會出現恐慌/崩潰。

(5) rsync 很可能是命中交換，但它發生得太快，無法在 OOM 啟動並終止 rsync 之前看到 top。當 rsync 達到 32GB 時，其他行程已經被迫進行交換，特別是當它們處於空閒狀態時。或許，「免費」和「頂級」的結合會為你帶來更好的畫面。

(6) rsync被殺死後，將mmap刷新到FS需要時間。對於 OOM 來說速度不夠快，並且它開始殺死其他東西（有些顯然是關鍵任務）。也就是說，mmap刷新和OOM正在競賽。或者，OOM 有一個錯誤。不然就不會發生車禍了。

(7) 根據我的經驗，一旦系統“撞到記憶體牆”，Linux需要很長時間才能完全恢復。而且，有時它永遠不會真正正確恢復，清除它的唯一方法是重新啟動。例如，我有 12GB 的 RAM。當我運行一個使用 40GB 記憶體的作業 [我有 120GB 交換空間來容納大型作業] 然後終止它時，系統需要大約 10 分鐘才能恢復正常響應能力 [磁碟指示燈一直亮起] 。

(8)運行rsync沒有選項。這會起作用。取得一個可供參考的基線範例。然後再增加 --inplace 並重新測試。然後執行 --append-verify 代替。然後，兩者都嘗試一下。找出哪個選項讓 rsync 執行巨大的 mmap。然後決定沒有它你是否可以生活。如果 --inplace 是罪魁禍首，那是理所當然的，因為你有足夠的磁碟空間。如果您必須有這個選項，則必須獲得交換空間來容納 rsync 將執行的 malloc/mmap。

第二次更新：

請執行上面的 mem= 和較小的檔案測試。

核心問題：為什麼 rsync 會被 OOM 殺死？誰/什麼是咀嚼記憶？

我讀到[但忘記了]系統是 32 位元的。所以，我同意，rsync可能不直接負責（透過malloc/mmap——glibc透過匿名/私有mmap實現大型malloc），而rsync的mmap頁面錯誤只是巧合地觸發了OOM。然後，OOM 計算 rsync 直接和間接消耗的總記憶體 [FS 快取、套接字緩衝區等]，並決定它是主要候選者。因此，監控總記憶體使用情況可能會有所幫助。我懷疑它的成長速度與檔案傳輸的速度相同。顯然，不應該。

您可以透過快速循環中的 perl 或 python 腳本在 /proc 或 /proc/rsync_pid 中監視某些內容 [bash 腳本對於世界末日事件可能不夠快] 可以監視所有以下數百次/秒。你可以以比rsync 更高的優先權運行它，這樣它就會保持在RAM 中並運行，這樣你就可以在崩潰之前監控事情，並希望在OOM 期間監控，這樣你就可以明白為什麼OOM 會變得瘋狂：

/proc/meminfo－在「影響點」獲得更細粒度的交換使用情況。實際上，獲得 RAM 總使用量的最終數字可能更有用。雖然 top 提供了這一點，但它可能不夠快，無法顯示「大爆炸」之前的宇宙狀態（例如最後 10 毫秒）

/proc/rsync_pid/fd 目錄。讀取符號連結將允許您識別目標檔案上開啟的 fd（例如 /proc/rsync_pid/fd/5 --> target_file 的 readlink）。這可能只需要完成一次即可取得 fd 編號 [它應該保持固定]

知道fd號碼後，請查看/proc/rsync_pid/fdinfo/fd。這是一個文字文件，如下所示：

位置：<檔案位置>
標誌：blah_blah
mnt_id：blah_blah

監視“pos”值可能會有所幫助，因為“最後一個檔案位置”可能很有用。如果您使用不同的大小和 mem= 選項進行多次測試，則最後一個檔案位置是否追蹤其中的任何一個[以及如何]？通常的懷疑：檔案位置==可用RAM

但是，最簡單的方法是從「rsync local_file server:remote_file」開始並驗證是否有效。透過執行「ssh server rsync file_a file_b」[您需要先建立一個 50GB file_a]，您也許可以獲得類似[但更快]的結果。建立file_a 的一個簡單方法是scp local_system:original_file server:file_a 這本身可能很有趣（例如，當rsync 崩潰時，這是否有效？如果scp 有效，但rsync 失敗，則指向rsync。如果scp 失敗，則指向rsync ）到其他東西，例如 NIC 驅動程式）。執行 ssh rsync 也會將 NIC 排除在外，這可能會有所幫助。如果這對系統造成了影響，那麼就真的出了問題。如果成功，[正如我所提到的]開始一一添加回選項。

我不想詳細說明這一點，但透過交換到文件添加一些交換可能會改變/延遲崩潰行為，並且可能作為診斷工具很有用。如果新增（例如 16GB）交換區可以將崩潰延遲（透過記憶體使用或目標檔案位置衡量）從 32GB 延遲到 46GB，那麼這就說明了一些問題。

它可能不是任何特定的進程，而是一個正在佔用記憶體的錯誤內核驅動程式。內核的內部 vmalloc 會分配一些東西並且可以將其換出。 IIRC，它在所有情況下都不受可尋址性的約束。

顯然，OOM 正在變得困惑/恐慌。也就是說，它殺死了 rsync，但沒有看到及時釋放的內存，並開始尋找其他受害者。其中一些可能對系統運作至關重要。

除了 malloc/mmap 之外，這可能是由於未刷新的 FS 快取需要很長時間造成的（例如，對於 30GB 未刷新的數據，假設磁碟速率為 300 MB/秒，刷新可能需要 100 秒）。即使以這個速度，OOM 可能太不耐煩了。或者，OOM 終止 rsync 無法足夠快地啟動 FS 刷新 [或根本]。或者 FS 刷新發生得足夠快，但它會「延遲」地將頁面釋放回空閒池。您可以設定一些 /proc 選項來控制 FS 快取行為 [我不記得它們是什麼了]。

嘗試使用 mem=4G 或其他一些小數字啟動。這可能會減少 FS 快取並縮短其刷新時間，以防止 OOM 尋找其他要殺死的東西（例如，刷新時間從 100 秒減少到 < 1 秒）。它還可能揭示 OOM 錯誤，該錯誤無法在 32 位元系統或其他系統上處理大於 4GB 的實體記憶體。

另外，還有一點很重要：以非 root 身分運作。根用戶永遠不會佔用資源，因此他們被賦予了更寬鬆的限制（例如，99% 的記憶體與非根用戶的 95% 相比）。這也許可以解釋為什麼OOM會處於這樣的狀態。此外，這也給出了 OOM 等。等人。有更多空間來完成回收記憶體的工作。

Answer