linux 內核分析工具 Dtrace、SystemTap、火焰圖、crash等

時間 2019-12-18

標籤 linux 內核分析工具 dtrace systemtap 火焰 crash 欄目 Linux 简体版

原文原文鏈接

<< System語言詳解 >> 關於 SystemTap 的書。linux

咱們在分析各類系統異常和故障的時候，一般會用到 pstack(jstack) /pldd/ lsof/ tcpdump/ gdb(jdb)/ netstat/vmstat/ mpstat/truss(strace)/iostat/sar/nmon(top)等系列工具，這些工具從某個方面爲咱們提供了診斷信息。但這些工具經常帶有各種「反作用」，好比 truss(見於 AIX/Solaris) 或者 strace(見於 Linux) 可以讓咱們檢測咱們應用的系統調用狀況，包括調用參數和返回值，可是卻會致使應用程序的性能降低；這對於診斷毫秒級響應的計費生產系統來講，影響巨大。有沒有一個工具，可以兼得上述全部工具的優勢，又沒有反作用呢？答案是有！對於 Solaris/BSD/OS X 系統來講，那就是 DTrace 工具（後來，Linux 也終於有了本身相似的工具，stap）。DTrace 的優點是什麼呢？能夠這麼講，若是你對於 OS 和應用熟悉，利用 DTrace 能夠診斷全部問題；沒錯，是「全部」，「全部」，「全部」，重要的事情說三遍！ios

書籍：DTrace-Dynamic-Tracing-in-Oracle-Solaris-Mac-OS-X-and-FreeBSD.pdfnginx

書籍：Solaris Dynamic Tracing Guide.pdf正則表達式

腳本工具集合：DTraceToolkit-0.99數據庫

動態追蹤技術（中） - Dtrace、SystemTap、火焰圖

說到動態追蹤就不能不提到DTrace(1)。DTrace 算是現代動態追蹤技術的鼻祖了，它於 21 世紀初誕生於 Solaris 操做系統，是由原來的 Sun Microsystems 公司的工程師編寫的。可能不少同窗都據說過 Solaris 系統和 Sun 公司的大名。緩存

最初產生的時候，我記得有這樣一個故事，當時 Solaris 操做系統的幾個工程師花了幾天幾夜去排查一個看似很是詭異的線上問題。開始他們覺得是很高級的問題，就特別賣力，結果折騰了幾天，最後發現實際上是一個很是愚蠢的、某個不起眼的地方的配置問題。自從那件事情以後，這些工程師就痛定思痛，創造了 DTrace 這樣一個很是高級的調試工具，來幫助他們在將來的工做當中避免把過多精力花費在愚蠢問題上面。畢竟大部分所謂的「詭異問題」其實都是低級問題，屬於那種「調不出來很鬱悶，調出來了更鬱悶」的類型。安全

應該說 DTrace 是一個很是通用的調試平臺，它提供了一種很像 C 語言的腳本語言，叫作 D。基於 DTrace 的調試工具都是使用這種語言編寫的。D 語言支持特殊的語法用以指定「探針」，這個「探針」一般有一個位置描述的信息。你能夠把它定位在某個內核函數的入口或出口，抑或是某個用戶態進程的函數入口或出口，甚至是任意一條程序語句或機器指令上面。編寫 D 語言的調試程序是須要對系統有必定的瞭解和知識的。這些調試程序是咱們重拾對複雜系統的洞察力的利器。Sun 公司有一位工程師叫作 Brendan Gregg，他是最初的 DTrace 的用戶，甚至早於 DTrace 被開源出來。Brendan 編寫了不少能夠複用的基於 DTrace 的調試工具，一齊放在一個叫作DTrace Toolkit(2)的開源項目中。Dtrace 是最先的動態追蹤框架，也是最有名的一個。性能優化

DTrace 的優點是它採起了跟操做系統內核緊密集成的一種方式。D 語言的實現實際上是一個虛擬機（VM），有點像 Java 虛擬機（JVM）。它的一個好處在於 D 語言的運行時是常駐內核的，並且很是小巧，因此每一個調試工具的啓動時間和退出時間都很短。可是我以爲 DTrace 也是有明顯缺點的。其中一個讓我很難受的缺點是 D 語言缺少循環結構，這致使許多針對目標進程中的複雜數據結構的分析工具很難編寫。雖然 DTrace 官方聲稱缺乏循環的緣由是爲了不過熱的循環，但顯然 DTrace 是能夠在 VM 級別上面有效限制每個循環的執行次數的。另一個較大的缺點是，DTrace 對於用戶態代碼的追蹤支持比較弱，沒有自動的加載用戶態調試符號的功能，須要本身在 D 語言裏面聲明用到的用戶態 C 語言結構體之類的類型。服務器

DTrace 的影響是很是大的，不少工程師把它移植到其餘的操做系統。比方說蘋果的 Mac OS X 操做系統上就有 DTrace 的移植。其實近些年發佈的每一臺蘋果筆記本或者臺式機上面，都有現成的 dtrace 命令行工具能夠調用，你們能夠去在蘋果機器的命令行終端上嘗試一下。這是蘋果系統上面的一個 DTrace 的移植。FreeBSD 操做系統也有這樣一個 DTrace 的移植。只不過它並非默認啓用的。你須要經過命令去加載 FreeBSD 的 DTrace 內核模塊。Oracle 也有在它本身的 Oracle Linux 操做系統發行版當中開始針對 Linux 內核進行 DTrace 移植。不過 Oracle 的移植工做好像一直沒有多少轉機，畢竟 Linux 內核並非 Oracle 控制的，而 DTrace 是須要和操做系統內核緊密集成的。出於相似的緣由，民間一些勇敢的工程師嘗試的 DTrace 的 Linux 移植也一直距離生產級別的要求很遠。網絡

相比 Solaris 上面原生的 DTrace，這些 DTrace 移植都或多或少的缺少某些高級特性，因此從能力上來講，還不及最本初的 DTrace。

DTrace 對 Linux 操做系統的另外一個影響反映在SystemTap(3)這個開源項目。這是由 Red Hat 公司的工程師建立的較爲獨立的動態追蹤框架。SystemTap 提供了本身的一種小語言(4)，和 D 語言並不相同。顯然，Red Hat 本身服務於很是多的企業級用戶，他們的工程師天天須要處理的各類線上的「詭異問題」天然也是極多的。這種技術的產生必然是現實需求激發的。我以爲 SystemTap 是目前 Linux 世界功能最強大，同時也是最實用的動態追蹤框架。我在本身的工做當中已經成功使用多年。SystemTap 的做者 Frank Ch. Eigler 和 Josh Stone 等人，都是很是熱情、同時很是聰明的工程師。我在 IRC 或者郵件列表裏的提問，他們通常都會很是快且很是詳盡地進行解答。值得一提的是，我也曾給 SystemTap 貢獻過一個較爲重要的新特性，使其能在任意的探針上下文中訪問用戶態的全局變量的取值。我當時合併到 SystemTap 主線的這個C++ 補丁(5)的規模達到了約一千行，多虧了 SystemTap 做者們的熱心幫助。這個新特性在我基於 SystemTap 實現的動態腳本語言（好比 Perl 和 Lua）的火焰圖(6)工具中扮演了關鍵角色。

SystemTap 的優勢是它有很是成熟的用戶態調試符號的自動加載，同時也有循環這樣的語言結構能夠去編寫比較複雜的探針處理程序，能夠支持不少很複雜的分析處理。因爲 SystemTap 早些年在實現上的不成熟，致使互聯網上充斥着不少針對它的已通過時了的詬病和批評。最近幾年 SystemTap 已然有了長足的進步。

固然，SystemTap 也是有缺點的。首先，它並非 Linux 內核的一部分，就是說它並無與內核緊密集成，因此它須要一直不停地追趕主線內核的變化。另外一個缺點是，它一般是把它的「小語言」腳本（有點像 D 語言哦）動態編譯成一個 Linux 內核模塊的 C 源碼，所以常常須要在線部署 C 編譯器工具鏈和 Linux 內核的頭文件，同時須要動態地加載這些編譯出來的內核模塊，以運行咱們的調試邏輯。在咱們的調試工具運行完畢以後，又存在動態卸載 Linux 內核模塊的問題。出於這些緣由，SystemTap 腳本的啓動相比 DTrace 要慢得多，和 JVM 的啓動時間倒有幾分相似。雖然存在這些缺點，但總的來講，SystemTap 仍是一個很是成熟的動態追蹤框架。

不管是 DTrace 仍是 SystemTap，其實都不支持編寫完整的調試工具，由於它們都缺乏方便的命令行交互的原語。因此咱們纔看到現實世界中許多基於它們的工具，其實最外面都有一個 Perl、Python 或者 Shell 腳本編寫的包裹。爲了便於使用一種乾淨的語言編寫完整的調試工具，我曾經給 SystemTap 語言進行了擴展，實現了一個更高層的「宏語言」，叫作stap++(7)。我本身用 Perl 實現的 stap++ 解釋器能夠直接解釋執行 stap++ 源碼，並在內部調用 SystemTap 命令行工具。有興趣的朋友能夠查看我開源在 GitHub 上面的 stapxx 這個代碼倉庫。這個倉庫裏面也包含了不少直接使用個人 stap++ 宏語言實現的完整的調試工具。

SystemTap 在生產上的應用

DTrace 有今天這麼大的影響離不開著名的 DTrace 佈道士Brendan Gregg(8)老師。前面咱們也提到了他的名字。他最初是在 Sun Microsystems 公司，工做在 Solaris 的文件系統優化團隊，是最先的 DTrace 用戶。他寫過好幾本有關 DTrace 和性能優化方面的書，也寫過不少動態追蹤方面的博客文章。

2011 年我離開淘寶之後，曾經在福州過了一年所謂的「田園生活」。在田園生活的最後幾個月當中，我經過 Brendan 的公開博客(9)較爲系統地學習了 DTrace 和動態追蹤技術。其實最先據說 DTrace 是由於一位微博好友的評論，他只提到了 DTrace 這個名字。因而我便想了解一下這到底是什麼東西。誰知，不瞭解不知道，一瞭解嚇一跳。這居然是一個全新的世界，完全改變了我對整個計算世界的見解。因而我就花了很是多的時間，一篇一篇地仔細精讀 Brendan 的我的博客。後來終於有一天，我有了一種大徹大悟的感受，終於能夠融會貫通，掌握到了動態追蹤技術的精妙。

2012 年我結束了在福州的「田園生活」，來到美國加入目前這家 CDN 公司。而後我就當即開始着手把 SystemTap 以及我已領悟到的動態追蹤的一整套方法，應用到這家 CDN 公司的全球網絡當中去，用於解決那些很是詭異很是奇怪的線上問題。我在這家公司觀察到其實不少工程師在排查線上問題的時候，常常會本身在軟件系統裏面埋點。這主要是在業務代碼裏，乃至於像 Nginx 這樣的系統軟件的代碼基（code base）裏，本身去作修改，添加一些計數器，或者去埋下一些記錄日誌的點。經過這種方式，大量的日誌會在線上被實時地採集起來，進入專門的數據庫，而後再進行離線分析。顯然這種作法的成本是巨大的，不只涉及業務系統自己的修改和維護成本的陡然提升，並且全量採集和存儲大量的埋點信息的在線開銷，也是很是可觀的。並且常常出現的狀況是，張三今天在業務代碼裏面埋了一個採集點，李四明天又埋下另外一個類似的點，過後可能這些點又都被遺忘在了代碼基裏面，而沒有人再去理會。最後這種點會愈來愈多，把代碼基搞得愈來愈凌亂。這種侵入式的修改，會致使相應的軟件，不管是系統軟件仍是業務代碼，變得愈來愈難以維護。

埋點的方式主要存在兩大問題，一個是「太多」的問題，一個是「太少」的問題。「太多」是指咱們每每會採集一些根本不須要的信息，只是一時貪多貪全，從而形成沒必要要的採集和存儲開銷。不少時候咱們經過採樣就能進行分析的問題，可能會習慣性的進行全網全量的採集，這種代價累積起來顯然是很是昂貴的。那「太少」的問題是指，咱們每每很難在一開始就規劃好所需的全部信息採集點，畢竟沒有人是先知，能夠預知將來須要排查的問題。因此當咱們遇到新問題時，現有的採集點蒐集到的信息幾乎老是不夠用的。這就致使頻繁地修改軟件系統，頻繁地進行上線操做，大大增長了開發工程師和運維工程師的工做量，同時增長了線上發生更大故障的風險。

另一種暴力調試的作法也是咱們某些運維工程師常常採用的，即把機器拉下線，而後設置一系列臨時的防火牆規則，以屏蔽用戶流量或者本身的監控流量，而後在生產機上各類折騰。這是很繁瑣影響很大的過程。首先它會讓機器不能再繼續服務，下降了整個在線系統的總的吞吐能力。同時有些只有真實流量才能復現的問題，此時再也沒法復現了。能夠想象這些粗暴的作法有多麼讓人頭疼。

實際上運用 SystemTap 動態追蹤技術能夠很好地解決這樣的問題，有「潤物細無聲」之妙。首先咱們不須要去修改咱們的軟件棧（software stack）自己，無論是系統軟件仍是業務軟件。我常常會編寫一些有針對性的工具，而後在一些關鍵的系統「穴位」上面放置一些通過仔細安排的探針。這些探針會採集各自的信息，同時調試工具會把這些信息彙總起來輸出到終端。用這種方式我能夠在某一臺機器或某幾臺機器上面，經過採樣的方式，很快地獲得我想要的關鍵信息，從而快速地回答一些很是基本的問題，給後續的調試工做指明方向。

正如我前面提到的，與其在生產系統裏面人工去埋點去記日誌，再蒐集日誌入庫，還不如把整個生產系統自己當作是一個能夠直接查詢的「數據庫」，咱們直接從這個「數據庫」裏安全快捷地獲得咱們想要的信息，並且毫不留痕跡，毫不去採集咱們不須要的信息。利用這種思想，我編寫了不少調試工具，絕大部分已經開源在了 GitHub 上面，不少是針對像 Nginx、LuaJIT 和操做系統內核這樣的系統軟件，也有一些是針對更高層面的像 OpenResty 這樣的 Web 框架。有興趣的朋友能夠查看 GitHub 上面的nginx-systemtap-toolkit(10)、perl-systemtap-toolkit(11)和stappxx(12)這幾個代碼倉庫。

　　　　　　　　　　　　　　　　　　　　　　　　個人 SystemTap 工具雲

利用這些工具，我成功地定位了數不清的線上問題，有些問題甚至是我意外發現的。下面就隨便舉幾個例子吧。

第一個例子是，我使用基於 SystemTap 的火焰圖工具分析咱們線上的 Nginx 進程，結果發現有至關一部分 CPU 時間花費在了一條很是奇怪的代碼路徑上面。這實際上是我一位同事在好久以前調試一個老問題時遺留下來的臨時的調試代碼，有點兒像咱們前面提到的「埋點代碼」。結果它就這樣被遺忘在了線上，遺忘在了公司代碼倉庫裏，雖然當時那個問題其實早已解決。因爲這個代價高昂的「埋點代碼」一直沒有去除，因此一直都產生着較大的性能損耗，而一直都沒有人注意到。因此可謂是我意外的發現。當時我就是經過採樣的方式，讓工具自動繪製出一張火焰圖。我一看這張圖就能夠發現問題並能採起措施。這是很是很是有效的方式。

第二個例子是，不多量的請求存在延時較長的問題，即所謂的「長尾請求」。這些請求數目很低，但可能達到「秒級」這樣的延時。當時有同事亂猜說是個人 OpenResty 有 bug，我不服氣，因而當即編寫了一個 SystemTap 工具去在線進行採樣，對那些超過一秒總延時的請求進行分析。該工具會直接測試這些問題請求內部的時間分佈，包括請求處理過程當中各個典型 I/O 操做的延時以及純 CPU 計算延時。結果很快定位到是 OpenResty 在訪問 Go 編寫的 DNS 服務器時，出現延時緩慢。而後我再讓個人工具輸出這些長尾 DNS 查詢的具體內容，發現都是涉及 CNAME 展開。顯然，這與OpenResty 無關了，而進一步的排查和優化也有了明確的方向。

第三個例子是，咱們曾注意到某一個機房的機器存在比例明顯高於其餘機房的網絡超時的問題，但也只有 1% 的比例。一開始咱們很天然的去懷疑網絡協議棧方面的細節。但後來我經過一系列專門的 SystemTap 工具直接分析那些超時請求的內部細節，便定位到了是硬盤配置方面的問題。從網絡到硬盤，這種調試是很是有趣的。第一手的數據讓咱們快速走上正確的軌道。

還有一個例子是，咱們曾經經過火焰圖在 Nginx 進程裏觀察到文件的打開和關閉操做佔用了較多的 CPU 時間，因而咱們很天然地啓用了 Nginx 自身的文件句柄緩存配置，可是優化效果並不明顯。因而再作出一張新的火焰圖，便發現由於這回輪到 Nginx 的文件句柄緩存的元數據所使用的「自旋鎖」佔用不少 CPU 時間了。這是由於咱們雖然啓用了緩存，但把緩存的大小設置得過大，因此致使元數據的自旋鎖的開銷抵消掉了緩存帶來的好處。這一切都能在火焰圖上面一目瞭然地看出來。假設咱們沒有火焰圖，而只是盲目地試驗，極可能會得出 Nginx 的文件句柄緩存沒用的錯誤結論，而不會去想到去調整緩存的參數。

最後一個例子是，咱們在某一次上線操做以後，在線上最新的火焰圖中觀察到正則表達式的編譯操做佔用了不少 CPU 時間，但其實咱們已經在線上啓用了正則編譯結果的緩存。很顯然，咱們業務系統中用到的正則表達式的數量，已然超出了咱們最初設置的緩存大小，因而很天然地想到把線上的正則緩存調的更大一些。而後，咱們在線上的火焰圖中便再看不到正則編譯操做了。

經過這些例子咱們其實能夠看到，不一樣的數據中心，不一樣的機器，乃至同一臺機器的不一樣時段，都會產生本身特有的一些新問題。咱們須要的是直接對問題自己進行分析，進行採樣，而不是胡亂去猜想去試錯。有了強大的工具，排錯實際上是一個事半功倍的事情。

火焰圖

前面咱們已經屢次提到了火焰圖（Flame Graph）這種東西(systemtap 能夠製做火焰圖, perf 命令也能夠製做火焰圖)，那麼火焰圖是什麼呢？它實際上是一個很是了不得的可視化方法，是由前面已經反覆提到的 Brendan Gregg 同窗發明的。

火焰圖就像是給一個軟件系統拍的 X 光照片，能夠很天然地把時間和空間兩個維度上的信息融合在一張圖上，以很是直觀的形式展示出來，從而反映系統在性能方面的不少定量的統計規律。

Nginx 的 C 級別 on-CPU 火焰圖示例

比方說，最經典的火焰圖是統計某一個軟件的全部代碼路徑在 CPU 上面的時間分佈。經過這張分佈圖咱們就能夠直觀地看出哪些代碼路徑花費的 CPU 時間較多，而哪些則是可有可無的。進一步地，咱們能夠在不一樣的軟件層面上生成火焰圖，好比說能夠在系統軟件的 C/C++ 語言層面上畫出一張圖，而後再在更高的——好比說——動態腳本語言的層面，例如 Lua 和 Perl 代碼的層面，畫出火焰圖。不一樣層面的火焰圖經常會提供不一樣的視角，從而反映出不一樣層面上的代碼熱點。

由於我本身維護着 OpenResty 這樣的開源軟件的社區，咱們有本身的郵件列表，我常常會鼓勵報告問題的用戶主動提供本身繪製的火焰圖，這樣咱們就能夠愜意地看圖說話(13)，幫助用戶快速地進行性能問題的定位，而不至於反覆地試錯，和用戶一塊兒去胡亂猜想，從而節約彼此大量的時間，皆大歡喜。

這裏值得注意的是，即便是遇到咱們並不瞭解的陌生程序，經過看火焰圖，也能夠大體推出性能問題的所在，即便從未閱讀過它的一行源碼。這是一件很是了不得的事情。由於大部分程序實際上是編寫良好的，也就是說它每每在軟件構造的時候就使用了抽象層次，好比經過函數。這些函數的名稱一般會包含語義上的信息，並在火焰圖上面直接顯示出來。經過這些函數名，咱們能夠大體推測出對應的函數，乃至對應的某一條代碼路徑，大體是作什麼事情的，從而推斷出這個程序所存在的性能問題。因此，又回到那句老話，程序代碼中的命名很是重要，不只有助於閱讀源碼，也有助於調試問題。而反過來，火焰圖也爲咱們提供了一條學習陌生的軟件系統的捷徑。畢竟重要的代碼路徑，幾乎老是花費時間較多的那些，因此值得咱們重點研究；不然的話，這個軟件的構造方式必然存在很大的問題。

火焰圖其實能夠拓展到其餘維度，好比剛纔咱們講的火焰圖是看程序運行在 CPU 上的時間在全部代碼路徑上的分佈，這是 on-CPU 時間這個維度。相似地，某一個進程不運行在任何 CPU 上的時間其實也是很是有趣的，咱們稱之爲 off-CPU 時間。off-CPU 時間通常是這個進程由於某種緣由處於休眠狀態，好比說在等待某一個系統級別的鎖，或者被一個很是繁忙的進程調度器（scheduler）強行剝奪 CPU 時間片。這些狀況都會致使這個進程沒法運行在 CPU 上，可是仍然花費不少的掛鐘時間。經過這個維度的火焰圖咱們能夠獲得另外一幅很不同的圖景。經過這個維度上的信息，咱們能夠分析系統鎖方面的開銷（好比sem_wait這樣的系統調用），某些阻塞的 I/O 操做（例如open、read之類），還能夠分析進程或線程之間爭用 CPU 的問題。經過 off-CPU 火焰圖，都一目瞭然。

應該說 off-CPU 火焰圖也算是我本身的一個大膽嘗試。記得最初我在加州和內華達州之間的一個叫作 Tahoe 的湖泊邊，閱讀 Brendan 關於 off-CPU 時間的一篇博客文章(14)。我固然就想到，或許能夠把 off-CPU 時間代替 on-CPU 時間應用到火焰圖這種展示方式上去。因而回來後我就在公司的生產系統中作了這樣一個嘗試，使用 SystemTap 繪製出了 Nginx 進程的 off-CPU 火焰圖。我在推特上公佈了這個成功嘗試以後，Brendan 還專門聯繫到我，說他本身以前也嘗試過這種方式，但效果並不理想。我估計這是由於他當時將之應用於多線程的程序，好比 MySQL，而多線程的程序由於線程同步方面的緣由，off-CPU 圖上會有不少噪音，容易掩蓋真正有趣的那些部分。而我應用 off-CPU 火焰圖的場景是像 Nginx 這樣的單線程程序，因此 off-CPU 火焰圖裏每每會當即指示出那些阻塞 Nginx 事件循環的系統調用，抑或是sem_wait之類的鎖操做，又或者是搶佔式的進程調度器的強行介入，因而能夠很是好地幫助分析一大類的性能問題。在這樣的 off-CPU 火焰圖中，惟一的「噪音」其實就是 Nginx 事件循環自己的epoll_wait這樣的系統調用，很容易識別並忽略掉。

內核的內存轉儲機制

因爲 Linux 的開放性的緣故，在 Linux 下有好幾種內存轉儲機制。下面將對它們分別作簡要的介紹。

LKCD

LKCD(Linux Kernel Crash Dump) 是 Linux 下第一個內核崩潰內存轉儲項目，它最初由 SGI 的工程師開發和維護。它提供了一種可靠的方法來發現、保存和檢查系統的崩潰。LKCD 做爲 Linux 內核的一個補丁，它一直以來都沒有被接收進入內核的主線。目前該項目已經徹底中止開發。

Diskdump

Diskdump 是另一個內核崩潰內存轉儲的內核補丁，它由塔高 (Takao Indoh) 在 2004 年開發出來。與 LKCD 相比，Diskdump 更加簡單。當系統崩潰時，Diskdump 對系統有徹底的控制。爲避免混亂，它首先關閉全部的中斷；在 SMP 系統上，它還會把其餘的 CPU 停掉。而後它校驗它本身的代碼，若是代碼與初始化時不同。它會認爲它已經被破壞，並拒絕繼續運行。而後 Diskdump 選擇一個位置來存放內存轉儲。Diskdump 做爲一個內核的補丁，也沒有被接收進入內核的主線。在衆多的發行版中，它也只獲得了 RedHat 的支持。

Netdump

RedHat 在它的 Linux 高級服務器 2.1 的版本中，提供了它本身的第一個內核崩潰內存轉儲機制：Netdump。與 LKCD 和 Diskdump 將內存轉儲保存在本地磁盤不一樣，當系統崩潰時，Netdump 將內存轉儲文件經過網絡保存到遠程機器中。RedHat 認爲採用網絡方式比採用磁盤保的方式要簡單，由於當系統崩潰時，能夠在沒有中斷的狀況下使用網卡的論詢模式來進行網絡數據傳送。同時，網絡方式對內存轉儲文件提供了更好的管理支持。與 Diskdump 同樣，Netdump 沒有被接收進入內核的主線，目前也只有 RedHat 的發行版對 Netdump 提供支持。

Kdump

Kdump 是一種基於 kexec 的內存轉儲工具，目前它已經被內核主線接收，成爲了內核的一部分，它也由此得到了絕大多數 Linux 發行版的支持。與傳統的內存轉儲機制不一樣不一樣，基於 Kdump 的系統工做的時候須要兩個內核，一個稱爲系統內核，即系統正常工做時運行的內核；另一個稱爲捕獲內核，即正常內核崩潰時，用來進行內存轉儲的內核。在本文稍後的內容中，將會介紹如何設置 kump。

MKdump

MKdump(mini kernel dump) 是 NTT 數據和 VA Linux 開發另外一個內核內存轉儲工具，它與 Kdump 相似，都是基於 kexec，都須要使用兩個內核來工做。其中一個是系統內核；另一個是 mini 內核，用來進行內存轉儲。與 Kdump 相比，它有如下特色：

將內存保存到磁盤。
能夠將內存轉儲鏡像轉換到 lcrash 支持格式。
經過 kexec 啓動時，mini 內核覆蓋第一個內核。

各類內存轉儲分析工具

與具備衆多的內存轉儲機制同樣，Linux 下也有衆多的內存轉儲分析工具，下面將會逐一作簡單介紹。

Lcrash

Lcrash 是隨 LKCD 一塊兒發佈的一個內內存儲分析工具。隨着 LKCD 開發的中止，lcrash 的開發也同時中止了。目前它的代碼已經被合併進入 Crash 工具中。

Alicia

Alicia (Advanced Linux Crash-dump Interactive Analyzer，高級 Linux 崩潰內存轉儲交互分析器 ) 是一個創建在 lcrash 和 Crash 工具之上的一個內存轉儲分析工具。它使用 Perl 語言封裝了 Lcrash 和 Crash 的底層命令，向用戶提供了一個更加友好的交互方式和界面。Alicia 目前的開發也已經停滯。