☰

使用 /var/log/messages 調試記憶體不足

tag-icon • tag-icon linux logs memory out-of-memory
使用 /var/log/messages 調試記憶體不足

我的訊息日誌中拋出以下報告：

kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB

httpd如果這個問題是針對的，mysqld或者postfix但我很好奇如何繼續調試該問題，這並不重要。

我怎麼才能獲得更多關於為什麼 PID 9163 被殺死的信息，我不確定 linux 是否在某處保留了終止 PID 的歷史記錄。

如果您的訊息日誌檔案中出現這種情況，您將如何逐步解決此問題？

# free -m

             total       used       free     shared    buffers     cached
Mem:          1655        934        721          0         10         52
-/+ buffers/cache:        871        784
Swap:          109          6        103`

答案1

在此發生之前，核心將記錄一堆內容，但其中大部分可能不會記錄在 中/var/log/messages，具體取決於您的(r)syslogd配置方式。嘗試：

grep oom /var/log/*
grep total_vm /var/log/*

前者應該會出現很多次，而後者只出現一兩個地方。這就是您要查看的文件。

在也包含total_vm.在該行之前三十秒到一分鐘（可能更多，可能更少），您會發現類似以下內容：

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

您還應該在該行和“內存不足”行之間找到一個表，其標題如下：

[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

這可能不會告訴您比您已經知道的更多的信息，但這些字段是：

  • PID進程 ID。
  • uid用戶身份。
  • tgid線程組 ID。
  • 總虛擬機器數虛擬記憶體使用（以 4 kB 頁為單位）
  • RSS常駐記憶體使用（以 4 kB 頁為單位）
  • nr_ptes頁表條目
  • 交換貨幣交換條目
  • oom_score_adj通常為 0；較低的數字表示呼叫 OOM Killer 時進程終止的可能性較小。

你基本上可以忽略nr_ptes，swapents儘管我相信這些是決定誰被殺的因素。這不一定是使用最多記憶體的進程，但很可能是。有關選擇過程的更多信息，看這裡。基本上，最終獲得最高 oom 分數的進程將被終止——這是「記憶體不足」行上報告的「分數」；不幸的是，其他分數沒有報告，但該表提供了一些因素方面的線索。

再說一次，這可能只會說明一個顯而易見的事實：系統記憶體不足並被mysqld選擇死亡因為殺死它會釋放最多的資源。這並不一定意味著mysqld做錯了什麼。您可以查看該表，看看當時是否有任何其他問題，但可能沒有任何明顯的罪魁禍首：系統可能會耗盡內存，僅僅是因為您錯誤判斷或錯誤配置了正在運行的進程。

答案2

關鍵在於訊息本身 -記憶體不足。當 Linux 核心缺乏虛擬記憶體（實體 RAM 加交換）時，它會開始殺死進程，而這正是這裡發生的情況。看起來mysqld使用了超過 2GB 的虛擬記憶體。

系統有多少 RAM 和交換空間？我會考慮添加額外的內存，或者如果不可能的話，添加額外的交換空間。作為至少防止進程終止的快速修復，您可以新增交換文件。

更新：查看您擁有的 RAM 量，您可以立即看到問題所在。你有大約 1.6GB 的 RAM 和 100MB 的交換空間，但 MySQL 使用的 RAM 比這多得多。這解釋了為什麼您會看到進程被終止。

相關內容