Linux oom情況（32位元核心）

Question 1

不過，「大錘」方法是升級到 64 位元作業系統（這是 32 位元），因為區域的佈局有所不同。

好的，那麼在這裡我將嘗試回答為什麼您會在這裡經歷 OOM。這裡有很多因素在起作用。

請求的訂單大小以及核心如何處理某些訂單大小。
正在選擇的區域。
該區域使用的水印。
區域內的碎片化。

如果您查看 OOM 本身，顯然有大量可用內存，但 OOM-killer 被調用了？為什麼？

請求的訂單大小以及內核如何處理某些訂單大小

核心按順序分配記憶體。「訂單」是連續 RAM 的一個區域，必須滿足該區域才能使請求正常運作。使用演算法按數量級（因此稱為順序）排列訂單2^(ORDER + 12)。因此，階數 0 是 4096，階數 1 是 8192，階數 2 是 16384，依此類推。

內核具有被視為「高階」(> PAGE_ALLOC_COSTLY_ORDER) 的硬編碼值。這是 4 階及以上（64kb 或以上為高階）。

對於頁分配的滿足高階與低階不同。如果無法取得內存，則在現代核心上會進行高階分配。

嘗試執行記憶體壓縮例程以對記憶體進行碎片整理。
絕不呼叫 OOM-killer 來滿足請求。

您的訂單大小列於此處

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

順序 3 是低階請求中最高的，並且（如您所見）呼叫 OOM-killer 來嘗試滿足它。

請注意，大多數用戶空間分配不使用高階請求。通常，核心需要連續的記憶體區域。當用戶空間使用大頁面時可能是一個例外 - 但這裡的情況並非如此。

在您的情況下，核心會呼叫 3 階分配，希望將封包排隊到網路堆疊中 - 需要 32kb 分配才能執行此操作。

正在選擇的區域。

核心將記憶體區域劃分為多個區域。之所以進行這種分割，是因為在 x86 上某些記憶體區域只能由某些硬體定址。例如，較舊的硬體可能只能尋址「DMA」區域中的記憶體。當我們想要分配一些記憶體時，首先選擇一個區域並僅有的在做出分配決策時會考慮該區域的可用記憶體。

雖然我不完全了解區域選擇演算法，但典型的用例絕不是從 DMA 分配，而是通常選擇可以滿足請求的最低可尋址區域。

在 OOM 期間會吐出大量區域信息，這些信息也可以從/proc/zoneinfo.

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

您擁有的區域、DMA、Normal 和 HighMem 表示 32 位元平台，因為 HighMem 區域在 64 位元上不存在。同樣在 64 位元系統上，普通映射到 4GB 及以上，而在 32 位元系統上，它映射到 896Mb（儘管，在您的情況下，核心報告只管理比這更小的部分：- managed:587540kB。）

透過再次查看第一行，可以知道這個分配來自哪裡，gfp_mask=0x42d0告訴我們進行了什麼類型的分配。最後一個位元組 (0) 告訴我們這是來自正常區域的分配。 gfp 的意思位於內含/linux/gfp.h。

該區域使用的水印。

當記憶體不足時，水印指定回收記憶體的操作。他們出現在這裡：min:3044kB low:3804kB high:4564kB。如果可用記憶體達到“低”，則交換將會發生，直到我們通過“高”閾值。如果記憶體達到“min”，我們需要殺死一些東西，以便透過 OOM-killer 釋放記憶體。

區域內的碎片化。

為了查看是否可以滿足對特定順序記憶體的請求，核心會計算每個順序有多少空閒頁面和可用頁面。這是在中可讀的/proc/buddyinfo。 OOM-killer 報告也吐出 buddyinfo，如下所示：

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

為了滿足記憶體分配的要求必須是請求的訂單大小或更高分配的可用記憶體。低位有大量可用資料而高位沒有資料意味著您的記憶體是碎片化的。如果您獲得非常高階的分配，則可能由於沒有可用的高階頁面而無法滿足要求（即使有大量可用記憶體）。核心可以透過移動大量低階頁面來對記憶體進行碎片整理（這稱為記憶體壓縮），這樣它們就不會在可尋址的 RAM 空間中留下間隙。

OOM-killer 被呼叫了嗎？為什麼？

因此，如果我們考慮到這些因素，我們可以說：

嘗試了 32kB 連續分配。從正常區域。
所選區域中有足夠的可用記憶體。
有 3、5 和 6 階記憶體可用13*32kB (MR) 1*128kB (R) 1*256kB (R)

那麼，如果有曾是空閒內存，其他命令可以滿足要求。發生了什麼事？

好吧，從訂單進行分配不僅僅是檢查該訂單或更高訂單可用的可用內存量。核心有效地從總空閒行中減去所有低位元內存，然後對剩餘的內容執行最小水印檢查。

在您的情況下，會檢查我們必須執行的該區域的可用記憶體。

115000 - (5360*4) - (3667*8) - (3964*16) = 800

這個可用內存量會根據min浮水印進行檢查，即 3044。這就是您呼叫 OOM-killer 的原因。

定影

有兩個修復。升級到 64 位元會更改您的區域分區，例如「正常」為 4GB 到 36GB，因此您最終不會將記憶體分配「預設」到可能會出現嚴重碎片的區域。並不是說您有更多的可尋址記憶體來解決此問題（因為您已經在使用 PAE），而只是您選擇的區域有更多的可尋址記憶體。

第二種方法（我從未測試過）是嘗試讓核心更積極地壓縮記憶體。

如果將值vm.extfrag_threshold從 500 更改為 100，則更有可能壓縮記憶體以嘗試實現高階分配。雖然，我以前從未弄亂過這個值 - 它也取決於您的碎片索引，該索引在/sys/kernel/debug/extfrag/extfrag_index.我目前沒有一個帶有足夠新內核的盒子來查看它所顯示的內容是否提供了比這更多的功能。

或者，您可以運行某種 cron 作業（這非常非常難看），透過寫入/proc/sys/vm/compact_memory.

但老實說，我認為確實沒有辦法調整系統來避免這個問題——記憶體分配器的本質就是以這種方式運作。改變你使用的平台的架構可能是唯一從根本解決的解決方案。

Answer

不過，「大錘」方法是升級到 64 位元作業系統（這是 32 位元），因為區域的佈局有所不同。

好的，那麼在這裡我將嘗試回答為什麼您會在這裡經歷 OOM。這裡有很多因素在起作用。

請求的訂單大小以及核心如何處理某些訂單大小。
正在選擇的區域。
該區域使用的水印。
區域內的碎片化。

如果您查看 OOM 本身，顯然有大量可用內存，但 OOM-killer 被調用了？為什麼？

請求的訂單大小以及內核如何處理某些訂單大小

核心按順序分配記憶體。「訂單」是連續 RAM 的一個區域，必須滿足該區域才能使請求正常運作。使用演算法按數量級（因此稱為順序）排列訂單2^(ORDER + 12)。因此，階數 0 是 4096，階數 1 是 8192，階數 2 是 16384，依此類推。

內核具有被視為「高階」(> PAGE_ALLOC_COSTLY_ORDER) 的硬編碼值。這是 4 階及以上（64kb 或以上為高階）。

對於頁分配的滿足高階與低階不同。如果無法取得內存，則在現代核心上會進行高階分配。

嘗試執行記憶體壓縮例程以對記憶體進行碎片整理。
絕不呼叫 OOM-killer 來滿足請求。

您的訂單大小列於此處

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

順序 3 是低階請求中最高的，並且（如您所見）呼叫 OOM-killer 來嘗試滿足它。

請注意，大多數用戶空間分配不使用高階請求。通常，核心需要連續的記憶體區域。當用戶空間使用大頁面時可能是一個例外 - 但這裡的情況並非如此。

在您的情況下，核心會呼叫 3 階分配，希望將封包排隊到網路堆疊中 - 需要 32kb 分配才能執行此操作。

正在選擇的區域。

核心將記憶體區域劃分為多個區域。之所以進行這種分割，是因為在 x86 上某些記憶體區域只能由某些硬體定址。例如，較舊的硬體可能只能尋址「DMA」區域中的記憶體。當我們想要分配一些記憶體時，首先選擇一個區域並僅有的在做出分配決策時會考慮該區域的可用記憶體。

雖然我不完全了解區域選擇演算法，但典型的用例絕不是從 DMA 分配，而是通常選擇可以滿足請求的最低可尋址區域。

在 OOM 期間會吐出大量區域信息，這些信息也可以從/proc/zoneinfo.

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

您擁有的區域、DMA、Normal 和 HighMem 表示 32 位元平台，因為 HighMem 區域在 64 位元上不存在。同樣在 64 位元系統上，普通映射到 4GB 及以上，而在 32 位元系統上，它映射到 896Mb（儘管，在您的情況下，核心報告只管理比這更小的部分：- managed:587540kB。）

透過再次查看第一行，可以知道這個分配來自哪裡，gfp_mask=0x42d0告訴我們進行了什麼類型的分配。最後一個位元組 (0) 告訴我們這是來自正常區域的分配。 gfp 的意思位於內含/linux/gfp.h。

該區域使用的水印。

當記憶體不足時，水印指定回收記憶體的操作。他們出現在這裡：min:3044kB low:3804kB high:4564kB。如果可用記憶體達到“低”，則交換將會發生，直到我們通過“高”閾值。如果記憶體達到“min”，我們需要殺死一些東西，以便透過 OOM-killer 釋放記憶體。

區域內的碎片化。

為了查看是否可以滿足對特定順序記憶體的請求，核心會計算每個順序有多少空閒頁面和可用頁面。這是在中可讀的/proc/buddyinfo。 OOM-killer 報告也吐出 buddyinfo，如下所示：

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

為了滿足記憶體分配的要求必須是請求的訂單大小或更高分配的可用記憶體。低位有大量可用資料而高位沒有資料意味著您的記憶體是碎片化的。如果您獲得非常高階的分配，則可能由於沒有可用的高階頁面而無法滿足要求（即使有大量可用記憶體）。核心可以透過移動大量低階頁面來對記憶體進行碎片整理（這稱為記憶體壓縮），這樣它們就不會在可尋址的 RAM 空間中留下間隙。

OOM-killer 被呼叫了嗎？為什麼？

因此，如果我們考慮到這些因素，我們可以說：

嘗試了 32kB 連續分配。從正常區域。
所選區域中有足夠的可用記憶體。
有 3、5 和 6 階記憶體可用13*32kB (MR) 1*128kB (R) 1*256kB (R)

那麼，如果有曾是空閒內存，其他命令可以滿足要求。發生了什麼事？

好吧，從訂單進行分配不僅僅是檢查該訂單或更高訂單可用的可用內存量。核心有效地從總空閒行中減去所有低位元內存，然後對剩餘的內容執行最小水印檢查。

在您的情況下，會檢查我們必須執行的該區域的可用記憶體。

115000 - (5360*4) - (3667*8) - (3964*16) = 800

這個可用內存量會根據min浮水印進行檢查，即 3044。這就是您呼叫 OOM-killer 的原因。

定影

有兩個修復。升級到 64 位元會更改您的區域分區，例如「正常」為 4GB 到 36GB，因此您最終不會將記憶體分配「預設」到可能會出現嚴重碎片的區域。並不是說您有更多的可尋址記憶體來解決此問題（因為您已經在使用 PAE），而只是您選擇的區域有更多的可尋址記憶體。

第二種方法（我從未測試過）是嘗試讓核心更積極地壓縮記憶體。

如果將值vm.extfrag_threshold從 500 更改為 100，則更有可能壓縮記憶體以嘗試實現高階分配。雖然，我以前從未弄亂過這個值 - 它也取決於您的碎片索引，該索引在/sys/kernel/debug/extfrag/extfrag_index.我目前沒有一個帶有足夠新內核的盒子來查看它所顯示的內容是否提供了比這更多的功能。

或者，您可以運行某種 cron 作業（這非常非常難看），透過寫入/proc/sys/vm/compact_memory.

但老實說，我認為確實沒有辦法調整系統來避免這個問題——記憶體分配器的本質就是以這種方式運作。改變你使用的平台的架構可能是唯一從根本解決的解決方案。

Question 2

一開始：你應該真的選擇 64 位元作業系統。您有充分的理由繼續使用 32 位元嗎？

如果不更仔細地查看系統（最好是在系統發生故障時），則很難診斷此問題，因此我的（快速）帖子或多或少一般針對 32 位元系統上的記憶體問題。我有沒有提到使用 64 位元會讓這一切消失？

你的問題有三個面向。

首先，即使在 PAE 核心上，每個進程的位址空間也限制為 4GiB[1]。這意味著您的魷魚實例每個進程將永遠無法使用超過 4GiB 的 RAM。我對魷魚不太熟悉，但如果這是您的主要代理伺服器，那麼這可能還不夠。

其次，在具有大量 RAM 的 32 位元系統上，所謂「ZONE_NORMAL」中的大量記憶體用於儲存使用 ZONE_HIGHMEM 中的記憶體所需的資料結構。這些資料結構本身無法移動到 ZONE_HIGHMEM 中，因為核心用於其自身目的的記憶體必須始終位於 ZONE_NORMAL 中（即在第一個 1GiB 左右）。 ZONE_HIGHMEM 中的記憶體越多（在您的情況下很多），問題就越大，因為核心需要 ZONE_NORMAL 中越來越多的記憶體來管理 ZONE_HIGHMEM。隨著 ZONE_NORMAL 中的可用記憶體量耗盡，您的系統可能會在執行某些任務時失敗，因為 ZONE_NORMAL 是很多很多事情發生在 32 位元系統上。例如，所有與核心相關的記憶體操作；）

第三，即使ZONE_NORMAL中還剩下一些記憶體（我沒有詳細查看你的日誌），一些記憶體操作也將需要未碎片化的記憶體。例如，如果您的所有記憶體都被分成非常小的碎片，則某些需要更多記憶體的操作將會失敗。 [3] 簡單檢視您的日誌確實顯示 ZONE_DMA 和 ZONE_NORMAL 中存在相當大量的碎片。

編輯：上面 Mlfe 的答案對它的工作原理有一個很好的詳細解釋。

再次強調：在 64 位元系統上，所有記憶體都位於 ZONE_NORMAL 中。 64 位元系統上沒有 HIGHMEM 區域。問題解決了。

編輯：你可以看這裡 [4] 看看你是否可以告訴 oom-killer 不要管你的重要進程。這並不能解決所有問題（如果有的話），但可能值得一試。

[1]http://en.wikipedia.org/wiki/Physical_address_extension#Design

[2]http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.html和https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Datas/waresect-Oinux_for_Oracle_9i_and_10g_Datas/waresect-Oakper_for_Oracle_0g els-a32_bit_Architecture_and_the_hugeme m_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Answer

一開始：你應該真的選擇 64 位元作業系統。您有充分的理由繼續使用 32 位元嗎？

如果不更仔細地查看系統（最好是在系統發生故障時），則很難診斷此問題，因此我的（快速）帖子或多或少一般針對 32 位元系統上的記憶體問題。我有沒有提到使用 64 位元會讓這一切消失？

你的問題有三個面向。

首先，即使在 PAE 核心上，每個進程的位址空間也限制為 4GiB[1]。這意味著您的魷魚實例每個進程將永遠無法使用超過 4GiB 的 RAM。我對魷魚不太熟悉，但如果這是您的主要代理伺服器，那麼這可能還不夠。

其次，在具有大量 RAM 的 32 位元系統上，所謂「ZONE_NORMAL」中的大量記憶體用於儲存使用 ZONE_HIGHMEM 中的記憶體所需的資料結構。這些資料結構本身無法移動到 ZONE_HIGHMEM 中，因為核心用於其自身目的的記憶體必須始終位於 ZONE_NORMAL 中（即在第一個 1GiB 左右）。 ZONE_HIGHMEM 中的記憶體越多（在您的情況下很多），問題就越大，因為核心需要 ZONE_NORMAL 中越來越多的記憶體來管理 ZONE_HIGHMEM。隨著 ZONE_NORMAL 中的可用記憶體量耗盡，您的系統可能會在執行某些任務時失敗，因為 ZONE_NORMAL 是很多很多事情發生在 32 位元系統上。例如，所有與核心相關的記憶體操作；）

第三，即使ZONE_NORMAL中還剩下一些記憶體（我沒有詳細查看你的日誌），一些記憶體操作也將需要未碎片化的記憶體。例如，如果您的所有記憶體都被分成非常小的碎片，則某些需要更多記憶體的操作將會失敗。 [3] 簡單檢視您的日誌確實顯示 ZONE_DMA 和 ZONE_NORMAL 中存在相當大量的碎片。

編輯：上面 Mlfe 的答案對它的工作原理有一個很好的詳細解釋。

再次強調：在 64 位元系統上，所有記憶體都位於 ZONE_NORMAL 中。 64 位元系統上沒有 HIGHMEM 區域。問題解決了。

編輯：你可以看這裡 [4] 看看你是否可以告訴 oom-killer 不要管你的重要進程。這並不能解決所有問題（如果有的話），但可能值得一試。

[1]http://en.wikipedia.org/wiki/Physical_address_extension#Design

[2]http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.html和https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Datas/waresect-Oinux_for_Oracle_9i_and_10g_Datas/waresect-Oakper_for_Oracle_0g els-a32_bit_Architecture_and_the_hugeme m_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Question 3

@MIfe 已經提供關於如何處理核心中的記憶體分配的優秀文章並且還為您提供了適當的解決方案，例如切換到 64 位元作業系統以及透過/proc/sys/vm/compact_memoryin手動記憶體壓縮等令人討厭的駭客攻擊cron。

我的 2 美分將是另一種可能對您有幫助的解決方法：
我注意到您tcp_tso_segment在核心回溯中，所以這樣做：

# ethtool -K ethX tso off gso off lro off

mm可以透過迫使其使用較低的訂單來減輕壓力。

聚苯乙烯。所有卸載的清單可以透過取得# ethtool -k ethX

Answer

@MIfe 已經提供關於如何處理核心中的記憶體分配的優秀文章並且還為您提供了適當的解決方案，例如切換到 64 位元作業系統以及透過/proc/sys/vm/compact_memoryin手動記憶體壓縮等令人討厭的駭客攻擊cron。

我的 2 美分將是另一種可能對您有幫助的解決方法：
我注意到您tcp_tso_segment在核心回溯中，所以這樣做：

# ethtool -K ethX tso off gso off lro off

mm可以透過迫使其使用較低的訂單來減輕壓力。

聚苯乙烯。所有卸載的清單可以透過取得# ethtool -k ethX

Question 4

恐慌是因為設定了 sysctl“vm.panic_on_oom = 1”——其想法是重新啟動系統將其恢復到正常狀態。您可以在 sysctl.conf 中更改此設定。

在頂部我們讀到魷魚叫了 oom Killer。您可以檢查您的魷魚配置及其最大記憶體使用量（或只是轉移到 64 位元作業系統）。

/proc/meminfo 顯示正在使用的高記憶體區域，因此您正在運行具有 36GB 記憶體的 32 位元核心。也可以看到，在正常區域，為了滿足squid對記憶體的需求，內核掃描了982頁，但沒有成功：

pages_scanned:982 all_unreclaimable? yes

Answer

恐慌是因為設定了 sysctl“vm.panic_on_oom = 1”——其想法是重新啟動系統將其恢復到正常狀態。您可以在 sysctl.conf 中更改此設定。

在頂部我們讀到魷魚叫了 oom Killer。您可以檢查您的魷魚配置及其最大記憶體使用量（或只是轉移到 64 位元作業系統）。

/proc/meminfo 顯示正在使用的高記憶體區域，因此您正在運行具有 36GB 記憶體的 32 位元核心。也可以看到，在正常區域，為了滿足squid對記憶體的需求，內核掃描了982頁，但沒有成功：

pages_scanned:982 all_unreclaimable? yes

Linux oom情況（32位元核心）

答案1

請求的訂單大小以及內核如何處理某些訂單大小

正在選擇的區域。

該區域使用的水印。

區域內的碎片化。

OOM-killer 被呼叫了嗎？為什麼？

定影

答案2

答案3

答案4

相關內容