我正在運行一個 Linux 伺服器，它顯示了我正在嘗試調查的奇怪的記憶體使用模式。
根據 munin 的說法，在正常操作期間，大約 200MB 的內存用於應用程序，但時不時地（可能每隔幾天），內存會突然增加約 1GB，如下圖所示：
我一直在嘗試找出導致此問題的原因，但我不確定可能是什麼。 munin 將這些記憶體歸因於「apps」這一事實向我表明，其中一個正在運行的進程只是使用了大量內存，但是當發生這種情況時查看頂部表明沒有一個進程使用幾乎同樣多的內存；事實上，當發生這種情況時，前 15 個記憶體消耗進程根本沒有變化，前 15 個進程僅使用 2.2% 的記憶體。另外，來自 ps 的內存資訊加起來幾乎沒有這麼多內存，而是大約 200MB。
增加的高度通常是相同的，如本例所示，幾個小時後就會消失。
我發現觸發此行為的可靠方法是使用 wget 透過網路上的 ssh 隧道將大檔案 (1.4G) 下載到本機磁碟（僅網路活動不會觸發它）。
為了更詳細地查看記憶體使用情況，我開始/proc/meminfo每 10 秒記錄一次並製作了一個包含此數據圖表的 tarball。導致相關行為的下載於 10:35:32 開始，並於 10:38:53 完成。原始日誌資料也包含在 tarball 中。
在 中/proc/meminfo，沒有任何值上升到足以解釋可用記憶體的大幅減少（這本質上是 munin 歸因於「應用程式」的原因），這讓我一無所知。 munin 報告的已使用內存量也是由 free 和 top 報告的，但進程列表中沒有進程可以解釋如此高的內存使用量，或者下載文件時突然增加。
我想理解的是：
- 如果沒有任何特定進程使用增加的內存，內存使用情況以這種方式運行是否正常？
- 中未考慮到的其他記憶體來源可能是什麼
/proc/meminfo？
或者這可能是系統受到損害的跡象？
答案1
munin 對於圖表來說非常有用，但它沒有告訴哪個應用程式導致了負載。
人們可以使用 atop - 高級頂部。
atop 記錄原始日誌文件，並且可以開啟這樣的文件並以互動方式及時來回查看某個特定時刻發生的情況。
ator -r /var/log/atop_oame_date與使用t和T鍵相比，您可以返回可疑活動的時間並查看那裡發生了什麼。
答案2
您的系統沒有物理記憶體壓力。因此，當您嘗試傳輸 1.4GB 檔案時，它會使用 1.4GB 記憶體。您的系統有兩種選擇——要么完全浪費內存，要么低效使用內存。它選擇了後者。這是正常行為。