Linux 記憶體調試：關鍵工具與技術

資訊科技數位 » recursos » Linux 記憶體調試：關鍵工具與技術

Linux 伺服器發生故障時，原因通常在於記憶體使用方式和偵錯工具，但如果您不知道該檢查什麼，一切都會顯得雜亂無章，如同一堆混亂的數字和進程。了解 RAM 的運作情況、程式的行為以及如何擷取記憶體轉儲，是避免每次出現奇怪錯誤或段錯誤時都盲目排查故障的關鍵。

本文將詳細介紹如何使用系統指令（free、vmstat、/proc/meminfo）、偵錯器（如 GDB）、記憶體分析器（如 Valgrind）以及 .NET 和其他環境的特定工具，在 Linux 系統中檢查記憶體、偵錯程式和分析轉儲檔案。目標是讓您掌握一套實用的工具，用於診斷伺服器和專業開發環境中的記憶體和 CPU 問題。

概述：Linux 中的記憶體以及為什麼你不應該執著於 100% 的記憶體使用率

在 Linux 伺服器上，RAM 可作為快速儲存介質，用於儲存系統需要盡快重複使用的資料和程式碼。存取 RAM 比存取磁碟快得多，因此核心利用這一特性，將其用作檔案、緩衝區和記憶體頁的緩存，以便日後再次使用。

對於運行 Apache 或 Nginx 等 Web 伺服器，或者 MySQL 或 MariaDB 等資料庫伺服器而言，了解記憶體使用情況、可用記憶體和快取記憶體對於合理調整服務規模以及理解命名空間和 cgroup至關重要。事實上，MySQLTuner等最佳化工具正是利用這些資料（以及其他資訊）來建議緩衝區、快取和連線設定。

理解一個常被人們誤解的概念至關重要：記憶體（RAM）的設計初衷就是為了被使用。看到 90% 甚至 100% 的使用率並不一定意味著有問題；Linux 會使用磁碟快取來填充內存，從而提升系統速度。真正令人擔憂的是出現記憶體不足錯誤、進程崩潰並顯示 OOM（記憶體不足）訊息，或服務凍結，而不僅僅是記憶體使用率圖表顯示「高使用率」。

只有當您發現伺服器變得不穩定、運行緩慢或由於記憶體使用過多而停止服務，或者當您知道即將出現流量高峰可能會使當前資源不堪重負時，採取積極的優化措施才是有意義的。

Linux 記憶體檢查基本命令

排查記憶體問題的第一步是了解您的總記憶體大小，以及已使用記憶體、可用記憶體、快取和交換空間之間的分配。 Linux 提供了多種工具來實現這一點，每個工具提供的詳細程度各不相同。

免費命令：快速概覽 RAM 和交換空間

最常用的快速查看指令是 尤其是有該參數時 -h 要以易於閱讀的格式顯示尺寸：有關解釋和優化這些指標的更多信息，請參閱 優化記憶體統計訊息.

free -h

典型的輸出結果會用幾行文字顯示RAM 和交換空間的總記憶體、已使用記憶體、可用記憶體、共享記憶體、緩衝區記憶體和快取記憶體。你會看到類似這樣的訊息：

總計 已使用 可用 共享 緩衝區 快取 記憶體：2.0G 1.5G 470M 300M 0B 414M -/+ 緩衝區/快取：1.1G 885M 交換空間：0B 0B 0B

線 -/+ buffers/cache 它尤其有用，因為它顯示了進程實際使用的記憶體（不包括緩衝區/快取）以及可供新應用程式使用的潛在記憶體。許多人看到第一行顯示的“可用內存”很少就感到恐慌，但實際上其中大部分只是緩存，可以… 再次使用，毫無戲劇性.

vmstat：活動記憶體、空閒記憶體和系統指標

當您需要更詳細的資訊時，vmstat可以提供更專業的系統技術概覽。

vmstat -s -S M

您將獲得一個列表，其中包含總記憶體、已使用記憶體、可用記憶體、活動記憶體、非活動記憶體、緩衝區、交換記憶體等資訊。例如：

總記憶體 2048 MB，已使用記憶體 1582 MB，活動記憶體 1124 MB，非活動記憶體 406 MB，可用記憶體 465 MB，緩衝記憶體 0 MB，交換快取 407 MB，交換空間總量 0 MB，已使用交換空間 0 MB，可用交換空間 0 MB

空閒內存的概念很有意思：它指的是那些被認為正在使用但並未與任何活動進程關聯的內存，因此在實際應用中，它的行為就像系統可以回收的內存一樣。這有助於解釋為什麼 Linux 看起來似乎“佔用了所有空間”，但實際上，它還有空間在需要時釋放出來。

/proc/meminfo：原始內核詳細信息

如果你想了解核心處理的所有細節，你可以查看/proc/meminfo檔案：

cat /proc/meminfo

該檔案包含數十個與內部記憶體管理相關的欄位：總記憶體、可用記憶體、緩衝區、快取、slab、巨頁、可用記憶體等。它對自動化工具和監控腳本非常有用，但直接讀取它不如 `free` 或 `vmstat` 那樣用戶友好，並且需要透徹理解每個字段的含義。

控制面板及其“平行現實”

如果您使用cPanel、Plesk、VestaCP 或 Webmin等控制面板管理伺服器，您會發現它們通常會透過 Web 介面顯示已使用記憶體、可用記憶體和快取記憶體的圖表。這些數據雖然方便，但請注意，它們會定期更新，有時並不能反映準確的即時狀態。為了進行更全面的診斷和微調，最好始終使用終端機及其原生命令。

使用系統工具調試進程和記憶體

在了解可用記憶體量及其大致使用情況後，下一步是定位哪些進程異常消耗資源並分析其行為。這時就需要用到 ps、top、htop、strace 和 ltrace 等經典工具，以及有助於消除瓶頸的網路和磁碟指令。

ps、top 和 htop：進程和 CPU 的 X 光透視

`ps`指令用於顯示活動進程。結合篩選和排序功能，可以快速定位哪些進程正在佔用 CPU 資源。

ps aux --sort=-%cpu | head

這會顯示以CPU 使用率百分比排序的進程，以及記憶體使用情況、使用者和指令。當伺服器資源不足時，它非常適合作為快速定位主要問題進程的快照；熟練終端操作有助於您迅速採取行動。

另一方面，`top`及其更直覺的版本`htop`可以提供進程、CPU 使用率、記憶體使用率、狀態（R、S、D 等）和平均負載的即時視圖。 `top` 的啟動指令如下：

top -o %CPU

您可以專注於哪些進程佔用最多的 CPU 資源。除了這些數字之外，尋找規律也很重要：

• R 進程（運行中） 長期佔據榜首的位置。
• 負荷平均值的突然變化 這表示近期負載出現尖峰。
• CPU 分配 %us、%sy 和 %wa （使用者時間、系統時間和 I/O 等待時間）。
• 如果問題出在流程上 系統服務、特定使用者或守護程式.
• 如果消費穩定或 它上下劇烈地跳動。這可能表示存在批量任務或異常流量。

非常高的 %wa（I/O 等待）值表示瓶頸可能不在 CPU 上，而是在磁碟或儲存子系統中。

查看行程執行緒：top -H

對於多執行緒應用程式（Java、Python、Node 等），僅僅知道哪個行程佔用 CPU 是不夠的；還需要查看哪個特定執行緒執行失控。

top -H -p PID

您可以取得進程中每個執行緒的詳細資訊。如果其中一個執行緒的佔用率達到 100%，而其他執行緒都處於空閒狀態，則很可能是程式碼的該部分存在無限循環、奇怪的阻塞問題或設計不良的臨界區。

流程優先：nice 和 renice

如果某個資源密集型流程是必要的，但您希望防止它佔用過多系統資源，您可以調整其優先權（優先權設定） 。 `nice`和`renice`命令可讓您以較低的優先權啟動進程，或調整現有進程的優先權，從而使核心分配給它們的 CPU 時間少於其他關鍵任務。

其他關鍵指令：pidof、kill、strace 和 ltrace

當系統承受壓力時，能夠快速定位和控制過程就顯得特別重要：

• 皮多夫：根據進程名稱取得進程的 PID，非常適合腳本或快速介入。
• 殺：向進程發送訊號（TERM、KILL 等），使其有序關閉，或在進程卡住時終止作業。
• 痕跡：顯示 系統調用 執行進程；非常適合查看進程卡在哪裡（磁碟讀取、套接字等）。
• 追蹤與strace類似，但更側重於 致電書店可用於調試共享 API 使用問題。

這些工具不僅對查找記憶體洩漏或崩潰很有用，而且還廣泛用於網路安全、取證分析和調試奇怪的二進位行為。

檔案和磁碟命令：lsof、df、du、locate

當您懷疑儲存裝置出現問題時（例如，開啟的檔案過多或磁碟已滿），就需要使用其他指令：

• 的列出 進程打開的文件可用於尋找阻止檔案系統卸載的描述符或檔案洩漏。
• df：顯示 可用磁盤空間 按檔案系統進行檢查，可以 100% 排除導致級聯故障的磁碟。
• du：計算 目錄佔用的空間非常適合尋找不受控制地增長的資料夾（日誌、備份等）。
• 定位：允許您使用索引資料庫按名稱搜尋文件，在許多情況下比查找速度更快。

用於診斷的網路指令：nc、netstat、ab、tcpdump、wireshark、nmap

效能和記憶體問題通常伴隨著網路瓶頸或攻擊，因此最好手邊備有一些基本工具：

• nc（netcat）：一款真正的網路瑞士軍刀；可以打開套接字、發送和接收資料、進行服務測試，甚至可以建立臨時隧道。
• netstat命令：顯示活動連接、監聽套接字和網路統計訊息，有助於查看特定連接埠是否有大量連接。
• ab（Apache 基準測試）：對 Web 伺服器施加負載，以測量回應時間和壓力下的行為。
• tcpdump 和 Wireshark：擷取網路封包 深入分析交通狀況; 控制台中使用 tcpdump，圖形介面中使用 Wireshark。
• NMAP連接埠和服務掃描器，廣泛用於安全審計和檢查 伺服器暴露面.

GDB：經典的記憶體錯誤和運行時崩潰偵錯器

當 Linux 程式因段錯誤或其他重大錯誤而崩潰時，下一步合乎邏輯的做法是使用優秀的偵錯器。 GNU 世界中的明星工具是GDB（GNU 調試器），它允許您檢查程序的內部狀態，在任意位置停止程序，查看變量和內存使用情況，並逐步跟踪程序的執行過程。

GDB 最初是為 C 和 C++ 程式設計的，但後來擴展到其他語言，例如Rust 甚至彙編語言，以及處理程式庫路徑（例如LD_LIBRARY_PATH）。它在開發中至關重要，在網路安全領域也是如此，可用於逆向工程、查找漏洞以及開發或偵錯漏洞利用程式。

啟動 GDB 並運行程序

若要將 GDB 與可執行檔一起使用，建議先編譯程式。 偵錯資訊 使用選項 -g 來自 GCC：

gcc -g -Wall programa.c -o programa

然後使用以下命令啟動它：

gdb programa

在 GDB 中，該程式尚未運行。您可以使用以下命令啟動它：

• 運行啟動程式時，可以加入任何你想要的參數。
• 開始與 run 相同，但會在函數開始時停止。 main.

例如，如果您有一個名為“可執行檔”的文件， 蘇馬 如果你想查看它如何處理參數，你可以進入 GDB，然後使用 run 3 5 使用調試器中的這些參數啟動它。

斷點和監視點：在需要的地方暫停程序

斷點是原始程式碼中的停止點：當程式執行到斷點時，程式會暫停，您可以檢查其內部狀態。在 GDB 中，斷點可以透過以下命令定義：

break lugar

其中，「location」可以是函數名稱、行號或檔案:行號。一個典型的例子是：

break main

這樣，GDB 就會在程式進入主函數時立即停止。當程式在斷點處停止時，你可以使用`l`（列表）查看程式碼、檢查變數並瀏覽呼叫堆疊。

監視點的工作方式不同：它們不會在程式碼的特定位置停止，而是在變數值發生變化時停止。它們對於偵測記憶體損壞或關鍵結構的意外修改非常有用，而無需在程式碼中堆砌大量的列印語句。

精細流程控制：步驟、下一步、繼續、結束

程式在斷點處停止後，有幾種方法可以繼續執行：

• 步驟：執行以下程式碼行並進入被呼叫的函數。
• 下：執行以下行而不進入函數（一次性運行所有函數）。
• 繼續：繼續執行，直到遇到下一個斷點或程式終止。
• 完：持續執行，直到當前函數返回，然後返回調用它的位置。

這樣你就可以逐步檢查可疑程式碼，而無需「吞下」整個程式。一個方便的小技巧：在 GDB 中， 按下回車鍵會重複執行上一個指令。非常適合製作許多 next o step 然後打字量就減少了。

呼叫堆疊和幀：看看我們是如何到達這裡的

要了解某個特定時刻發生故障的原因，關鍵在於查看在此之前呼叫了哪些函數。儲存這些資訊的結構稱為呼叫堆疊。 GDB 提供了幾個用於管理呼叫堆疊的命令：

• bt （回溯）：顯示完整的堆疊，包括巢狀函數清單和幀號。
• up：向上移動堆疊的一級，到達呼叫目前函數的位置。
• 向下：向下移動一級，到達正在運行的函數。
• fr （幀）：顯示目前幀，或允許您透過指定幀號來切換到另一個幀。

這樣，你就可以把自己定位在呼叫的不同層級（例如，從內部函數跳到main 函數），並查看變數在每個位置的狀態。

與記憶體互動：設定、返回、回溯 yx

GDB 的一大優點在於，它允許你在程式停止運行時讀取和修改記憶體。一些常用的操作包括：

• 套：在執行期間更改變數的值，非常適合在不重新編譯的情況下測試場景。
• 傳回值：強制目前函數傳回指定的值，而不繼續執行其程式碼。
• backtrace：已查看，以顯示目前呼叫堆疊。
• x：檢查從某個位址開始的記憶體內容，支援不同的格式和大小（例如， x/4xw 0x7fffffffe000 （以十六進制形式查看四個單字）。

借助這些選項，您可以重現錯誤，檢查危險的輸入是否會導致溢出，或者檢查堆疊或堆疊上的複雜資料結構。

利用核心轉儲進行事後調試

當進程因 SIGSEGV 等訊號崩潰時， Linux 可以產生核心轉儲檔案。此檔案包含進程崩潰時的完整狀態：記憶體、暫存器、堆疊等。要在會話中啟用此功能，只需：

ulimit -c unlimited

若要為使用者永久啟用這些功能，您可以編輯/etc/security/limits.conf檔案並新增以下一行：

* soft core unlimited

程式崩潰時，通常會在工作目錄中產生一個名為「core」的檔案。然後，您可以使用 GDB 像這樣分析它：

gdb ejecutable core

這樣就可以像程式仍在運行時一樣進行事後分析，這在故障無法按需重現時非常理想。

Valgrind：尋找記憶體洩漏和錯誤

對於 C/C++（以及類似語言）中的許多記憶體問題，GDB 並不勝任，因為它並非設計用於自動偵測非法讀取、記憶體洩漏或未初始化的記憶體使用。這時Valgrind就派上了用場——它是一個調試和性能分析系統，可以模擬處理器並監控每一次記憶體存取。

Valgrind 包含多個工具，但最常用的是Memcheck，它用自己的記憶體管理器取代了 C 語言的標準記憶體管理器，並在已分配的記憶體區塊周圍設置了保護區。這使得它可以檢測：

• 未初始化的記憶體使用 （在賦值之前使用的變數）。
• 自由閱讀/寫作之後 （釋放後使用）。
• 進入邊界之外 一塊記憶體。
• 內存洩漏 （malloc 未釋放記憶體、遺失指標等）。

無錯誤範例：在 Memcheck 下的「乾淨」程序

假設你編譯了一個有除錯資訊的「hello world」小程式：

gcc -Wall -gstabs valgrind_hello_good.c -o valgrind_hello_good

如果你在 Valgrind 下運行它：

valgrind --tool=memcheck --leak-check=full -v ./valgrind_hello_good

您將獲得一份追蹤報告，其中錯誤摘要顯示沒有錯誤，也沒有報告任何記憶體洩漏。這驗證了至少從 Memcheck 的角度來看，該程式沒有表現出記憶體異常。

檢測記憶體洩漏

如果修改程式碼，使其執行malloc 但不釋放記憶體（例如，保留一個位元組但不釋放它），然後重新編譯：

gcc -Wall -gstabs valgrind_hello_bad.c -o valgrind_hello_bad

運行時：

valgrind --tool=memcheck --leak-check=full -v ./valgrind_hello_bad

Valgrind 將顯示一個堆概要，其中包含一個非零的「退出時正在使用」值，表示未釋放的記憶體量。此外，「肯定遺失」部分將顯示洩漏的位元組數和區塊數，以及導致洩漏的呼叫追蹤資訊（函數、檔案和程式碼行）。

對於更複雜的情況，例如使用濾波器的情況， leak() 函數中洩漏了 100 位元組從瓦爾格林德出來的出口會清楚地指引你前往… malloc 有問題，允許添加 free 隨後進行核實，確認匯總資料是否恢復為零洩漏。

非法契約和超出範圍的訪問

Memcheck 偵測到的另一個典型錯誤是寫入無效位址，例如寫入記憶體位址 0（NULL）或陣列結尾以外的位址。如果您編譯的程式執行了非法寫入操作：

gcc -gstabs -Wall valgrind_illegal_read_write.c -o valgrind_illegal_read_write

然後運行：

valgrind -v ./valgrind_illegal_read_write

你會看到類似這樣的訊息：

在 0x80483C4 寫入大小為 4 的無效資料：main (valgrind_illegal_read_write.c:8) 位址 0x0 未置入堆疊中、未透過 malloc 分配或（最近）釋放。

這可以準確地告訴你非法寫入發生在哪裡以及寫入的大小，而這種情況在正常執行中通常表現為簡單的“段錯誤”，沒有任何其他線索。

未初始化的變數及其值依賴關係

Memcheck 也會在以下情況提醒您： 控制決策取決於一個未初始化的變數如果你編譯一個程序，其中包含一個從未初始化且在程式中使用的局部變量，那麼程式就會崩潰。 if:

gcc -gstabs -Wall valgrind_unitialized.c -o valgrind_unitialized

然後你用以下命令運行它：

valgrind -v --track-origins=yes ./valgrind_unitialized

輸出結果將包含類似以下內容：

條件跳轉或移動取決於 0x80483F2 處的未初始化值：main (valgrind_unialized.c:9) 未初始化的值是由 0x80483EA 處的堆疊分配所建立的：main (valgrind_unialized.c:7)

參數–track-origins=yes有助於定位未初始化變數最初建立的位置，從而大大加快程式碼修正速度。

堆中釋放和錯誤檢測的濫用

Valgrind 也證實了這一點。 free 函數僅對有效指標呼叫。如果你嘗試釋放的記憶體並非來自… malloc或者，如果您雙擊同一個方塊，您會看到類似這樣的訊息：

無效的 free() / delete / delete[] / realloc() 調用，位址為 0x402B06C：free (...) 由 0x8048449 呼叫：main (valgrind_illegal_free.c:11)

在很多情況下，它甚至會告訴你你撥打電話的地址。 free 它位於一個已被釋放的區塊之後，因此可以識別。 指針計算錯誤或雙重釋放.

總而言之，當您懷疑本地程式中存在記憶體洩漏、釋放後使用或記憶體損壞時，Valgrind 是必不可少的工具，而將其與 GDB 結合使用，則可以非常有效地查看應用程式的內部狀態。

Linux 和 Windows 系統中的核心轉儲與分析

在現代應用程式中，尤其是在.NET Core中，分析複雜的記憶體或效能問題通常需要捕獲記憶體轉儲，以便在另一台機器上進行仔細分析。這些轉儲會將進程狀態凍結在特定時間點，就像傳統的核心轉儲一樣。

使用 dotnet-dump 和 LLDB 分析 Linux 上的 .NET 轉儲文件

在 Linux 上的 .NET Core 環境中，建議使用的工具之一是dotnet-dump。捕獲到轉儲檔案後，即可開始分析：

dotnet-dump analyze <dump-file>

重要的是，分析必須在與產生轉儲檔案的環境具有相同架構和 Linux 發行版的機器上進行。 dotnet-dump 主要針對託管的 .NET 程式碼；要分析本機程式碼（C/C++），更適合使用LLDB以及SOS擴充功能。

LLDB 可讓您偵錯託管程式碼和本機程式碼，借助dotnet-sos，您可以安裝 SOS 擴展，該擴展提供針對 .NET 的特定命令。要正確載入 .NET Core 轉儲，LLDB 和 SOS 需要轉儲建立環境中的某些二進位檔案：

1. libmscordaccore.so
2. libcoreclr.so
3. 點網 （用於啟動應用程式的主機）

這些二進位檔案通常可以使用dotnet-symbol工具下載。如果是私有版本或它們不在符號伺服器上，您可以隨時從原始機器複製它們。如果轉儲檔案中未包含這些二進位文件，您可以在 LLDB/SOS 中使用下列命令：

• setclrpath <ruta> 指示 .NET Core 二進位檔案所在的位置。
• setsymbolserver -directory <ruta> 指定符號的位置。

準備好所有需要的檔案後，將轉儲檔案載入到 LLDB 中，並將 dotnet 主機指定為要偵錯的可執行檔：

lldb --core <dump-file> <host-program>

這裡 這是通往傾倒場的路線， 它通常是二進制的。 dotnet除非它是獨立應用程序，在這種情況下，它將是應用程式本身的可執行檔（沒有 .dll 副檔名）。

在LLDB中，通常需要配置正確的符號伺服器。 setsymbolserver -ms 使用微軟伺服器，或者 setsymbolserver -directory <ruta> 對於本地目錄，並運行 loadsymbols 載入本地符號。之後，您可以使用常用的 SOS 指令來分析託管堆、執行緒、異常等。

從 Windows 進行 Linux 轉儲分析

Linux 系統中產生的轉儲檔案不僅限於在同一系統上進行分析；它們也可以在Windows 系統中使用 Visual Studio、WinDbg 或 dotnet-dump 等工具開啟。具體功能有所不同：

• 視覺工作室允許使用混合物清理垃圾掩埋場 原生程式碼和託管程式碼它擁有非常人性化的圖形介面。建議查閱相關指南。 偵錯 Visual Studio 記憶體轉儲.
• WinDbg的對用戶轉儲的高級支持，包括 Linux 轉儲文件 工作流程與 Windows 類似。對於來自 Linux x64 或 Arm64 環境的轉儲文件，必須使用 x64 版本的 WinDbg；對於 x86 轉儲文件，則必須使用 x86 版本。
• dotnet-dump 在 Windows 系統上：它的使用方式與 Linux 系統上相同，使用方法如下： dotnet-dump analyze請記住根據轉儲檔案的架構選擇工具的 x64 或 x86 版本。

專業診斷 CPU 和記憶體使用率過高的問題

除了特定的工具之外，Linux 中的記憶體清理通常涉及結構化的工作流程，以避免隨意操作。以下是一個適用於伺服器的實用方案：

• Mirar 最佳 偵測可疑的裝載模式和流程。
• 確認 ps 佔用 CPU 和記憶體最多的進程。
• 檢查消費是否合乎邏輯（編譯、批次、索引），或是否有異常行為。
• 使用分析線程 top -H -p PID 當涉及到多執行緒進程時。
• 要審查 服務日誌 使用 journalctl 或 tail 指令。
• 檢查問題是否真的與 CPU 相關，還是隱藏在其他方面… 磁碟 I/O 使用 iostat。

要確定瓶頸是在 CPU 還是磁碟上，iostat -xz 1 3非常有用：如果您看到磁碟利用率高、等待時間長，以及top 命令中 %wa 值很高，那麼問題可能不是 CPU 而是儲存。

透過應用此工作流程，可以更輕鬆地診斷以下病例：

• 機器人或惡意流量 觸發 php-fpm 進程並導致 Web 伺服器過載。
• Un Java 微服務中存在一個無限循環的線程 消耗整個核心。
• 一個看似受 CPU 限制的 Python 進程，但實際上 磁碟已鎖定，等待磁碟 在循環的每次迭代中。

透過結合系統工具（ps、top、vmstat、free）、調試器（GDB、LLDB、dotnet-dump）、內存分析器（Valgrind）以及網路和磁碟命令，您可以創建一種工作方式，使 Linux 中的內存和性能問題不再是一個黑盒，而是可以通過方法和耐心，以相當高的準確度來識別和糾正。