はじめに
Linuxで構築されたシステムを運用していると、カーネルパニックによる突然の再起動やOSのハング、OOM Killerの発動など、ログだけでは原因を特定できない障害に遭遇することがあります。
このような OSレベルの障害調査において重要となるのが「メモリダンプ」 です。
本記事では、初心者の方でも理解できるように、Linux OS におけるメモリダンプ取得の目的、kdump を用いた取得方法、そしてcrashを用いた基本的な解析方法について解説します。
障害対応やトラブルシューティングの第一歩として、ぜひ参考にしてください。
メモリダンプ取得の目的
メモリダンプとは、障害発生時点における Linux OS のメモリ状態をそのまま保存したものです。
これにより、プロセスの状態、カーネル内部のデータ構造、スラブキャッシュの使用状況などを、後から詳細に解析することができます。
通常の障害調査では、リソース使用状況や各種ログをもとに原因を調査します。しかし、OS がハングした場合や突然停止してしまった場合には、ログが十分に出力されず、原因特定につながる情報が欠落してしまうことがあります。そのような状況で有効となるのが、メモリダンプです。
メモリダンプを取得することで、以下のような情報を確認できます。
- カーネルメモリ
カーネル空間のメモリ全体（コード、データ、slab など）を取得できます。ページキャッシュやバッファキャッシュも含まれます。 - CPUレジスタの状態
クラッシュ発生時の CPU レジスタ情報（RIP（Instruction Pointer）、RSP（Stack Pointer）、FLAGS など）や、各 CPU の実行コンテキストを確認できます。 - カーネルスタックトレース
クラッシュした CPU のスタックトレースを取得できます。また、他の CPU や他タスクのカーネルスタックも確認可能です。 - カーネルモジュール
ロード済みのカーネルモジュール一覧、ロードアドレス、サイズ、依存関係などを確認できます。 - メモリ断片化の状態
メモリゾーン情報（DMA / Normal など）やページの空き状況、slab / slub の使用状況を確認できます。 - デバイス／ドライバの状態
IRQ（Interrupt Request）情報や、デバイスドライバの内部状態、I/O 関連のカーネルデータ構造を確認できます。 - カーネルログ（dmesg）
カーネルリングバッファはメモリ上に存在するため、メモリダンプから dmesg 相当のログを取得できます。
OS に異常が発生した際、自動的にメモリダンプを取得できるように設定しておくことで、障害発生後の原因調査をスムーズに進めることができますので、ぜひ事前に設定を有効化しておきましょう。詳細な設定方法については、後述します。
kdumpによるメモリダンプ取得
現在の Linux 環境において、最も一般的に利用されているメモリダンプの取得方式は kdump です。
他にも取得方式は存在しますが、特別な要件がない限り、kdump を選択しておけば問題ありません。
kdump 機能を有効にすると、通常のカーネルとは別に「ダンプキャプチャカーネル」と呼ばれる最小構成のカーネルが、あらかじめメモリ上に待機します。カーネルパニックなどの致命的な障害が発生し、通常のカーネルが実行を継続できなくなると、kdump によってダンプキャプチャカーネルが起動され、障害発生時点のメモリ内容（クラッシュダンプ）がストレージへ保存されます。
kdumpの設定
RHEL 系 OS では、デフォルトで kdump によるメモリダンプ取得が有効になっています。ただし、初期設定では /var/crash ディレクトリにダンプファイルが出力されるため、ディスク容量や運用方針に応じて保存先のパスを変更することを推奨します。可能であれば、OS の動作に使用しているパーティションとは別に専用のパーティションを用意し、そこをダンプ保存先として指定すると、障害時の安全性が向上します。/etc/kdump.confのpathを変更し、kdumpを再起動して設定を反映させてください。
[root@appserver-dev ~]# vi /etc/kdump.conf
[root@appserver-dev ~]#
[root@appserver-dev ~]#
[root@appserver-dev ~]# grep "path " /etc/kdump.conf
~~Truncated~~
#path /var/crash
path /mnt/crash
[root@appserver-dev ~]#
[root@appserver-dev ~]# systemctl restart kdump
[root@appserver-dev ~]# systemctl status kdump
● kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; preset: enabled)
Active: active (exited) since Mon 2025-12-15 06:33:34 JST; 1min 17s ago
Process: 1611 ExecCondition=/bin/sh -c grep -q -e "crashkernel" -e "fadump" /proc/cmdline (code=exited, status=0/SUCCESS)
Process: 1613 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
Main PID: 1613 (code=exited, status=0/SUCCESS)
CPU: 19.272s
~~Truncated~~
Dec 15 06:33:34 appserver-dev kdumpctl[1616]: kdump: Starting kdump: [OK]
Dec 15 06:33:34 appserver-dev systemd[1]: Finished Crash recovery kernel arming.
[root@appserver-dev ~]#
カーネルパニック発生時のメモリダンプ取得
それでは試しにカーネルパニックを発生させて、メモリダンプを取得してみましょう。
試験としてカーネルパニックを発生させるためには、SysRq（Magic SysRq）というLinux カーネルに直接命令を送るための仕組みを有効にすることで、実際にカーネルパニックが発生する挙動に近づけます。下記の通り一時的な設定変更をしたうえで、パニックを発生させてみてください。
[root@appserver-dev ~]# sysctl -w kernel.sysrq=1
kernel.sysrq = 1
[root@appserver-dev ~]# cat /proc/sys/kernel/sysrq
1
[root@appserver-dev ~]#
[root@appserver-dev ~]# echo c > /proc/sysrq-trigger
カーネルパニックを発生させると一時的に操作を受け付けられなくなります。しばらくした後に再接続して、vmcoreファイルが作成されていることを確認してください。
[root@appserver-dev ~]# ls -lh /mnt/crash/127.0.0.1-2025-12-15-06\:53\:37/
total 119M
-rw------- 1 root root 51K Dec 15 06:53 kexec-dmesg.log
-rw------- 1 root root 119M Dec 15 06:53 vmcore
-rw------- 1 root root 46K Dec 15 06:53 vmcore-dmesg.txt
[root@appserver-dev ~]#メモリダンプの解析
それでは最後に、メモリダンプの解析方法をご紹介します。
解析ツールのインストール
Linuxカーネルのメモリダンプを解析するための公式デバッガである crash コマンドを使って、実際に解析をしてみましょう。
kernel-debuginfoのインストール
まずはパッケージ「kernel-debuginfo」をインストールします。vmcore の中身はただの数値情報になりますが、crash コマンド実行時に kernel-debuginfo を指定することで、vmcore の中身が人間で理解できる形式に変換されます。
[root@appserver-dev ~]# uname -r
5.14.0-570.22.1.el9_6.x86_64
[root@appserver-dev ~]# dnf install https://vault.almalinux.org/9.6/BaseOS/debug/x86_64/Packages/kernel-debuginfo-common-x86_64-5.14.0-570.22.1.el9_6.x86_64.rpm
Last metadata expiration check: 0:02:26 ago on Thu Dec 18 06:59:43 2025.
kernel-debuginfo-common-x86_64-5.14.0-570.22.1.el9_6.x86_64.rpm 8.8 MB/s | 80 MB 00:09
Dependencies resolved.
=======================================================================================================================================================================
Package Architecture Version Repository Size
=======================================================================================================================================================================
Installing:
kernel-debuginfo-common-x86_64 x86_64 5.14.0-570.22.1.el9_6 @commandline 80 M
Transaction Summary
=======================================================================================================================================================================
Install 1 Package
Total size: 80 M
Installed size: 488 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : kernel-debuginfo-common-x86_64-5.14.0-570.22.1.el9_6.x86_64 1/1
Verifying : kernel-debuginfo-common-x86_64-5.14.0-570.22.1.el9_6.x86_64 1/1
Installed:
kernel-debuginfo-common-x86_64-5.14.0-570.22.1.el9_6.x86_64
Complete!
[root@appserver-dev ~]#
[root@appserver-dev ~]# dnf install https://vault.almalinux.org/9.6/BaseOS/debug/x86_64/Packages/kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64.rpm
Last metadata expiration check: 0:04:13 ago on Thu Dec 18 06:59:43 2025.
kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64.rpm 28 MB/s | 709 MB 00:25
Dependencies resolved.
=======================================================================================================================================================================
Package Architecture Version Repository Size
=======================================================================================================================================================================
Installing:
kernel-debuginfo x86_64 5.14.0-570.22.1.el9_6 @commandline 709 M
Transaction Summary
=======================================================================================================================================================================
Install 1 Package
Total size: 709 M
Installed size: 2.8 G
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64 1/1
Running scriptlet: kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64 1/1
Verifying : kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64 1/1
Installed:
kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64
Complete!
[root@appserver-dev ~]#crashのインストール
続いて、crash をインストールしてください。
[root@appserver-dev ~]# dnf install crash
Last metadata expiration check: 0:02:03 ago on Thu Dec 18 06:15:59 2025.
Dependencies resolved.
=======================================================================================================================================================================
Package Architecture Version Repository Size
=======================================================================================================================================================================
Installing:
crash x86_64 9.0.0-4.el9.alma.1 appstream 4.9 M
Transaction Summary
=======================================================================================================================================================================
Install 1 Package
Total download size: 4.9 M
Installed size: 14 M
Is this ok [y/N]: y
Downloading Packages:
crash-9.0.0-4.el9.alma.1.x86_64.rpm 1.1 MB/s | 4.9 MB 00:04
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 1.0 MB/s | 4.9 MB 00:05
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : crash-9.0.0-4.el9.alma.1.x86_64 1/1
Running scriptlet: crash-9.0.0-4.el9.alma.1.x86_64 1/1
Verifying : crash-9.0.0-4.el9.alma.1.x86_64 1/1
Installed:
crash-9.0.0-4.el9.alma.1.x86_64
Complete!
[root@appserver-dev ~]#
以上で、必要なツールのインストールは完了です。
crashによるvmcoreファイルの解析
crash コマンドを実行して vmcore ファイルを解析をしていきます。
下記の通り、crash> のプロンプトが返ってきたら成功です。
[root@appserver-dev ~]# crash /usr/lib/debug/usr/lib/modules/5.14.0-570.22.1.el9_6.x86_64/vmlinux /mnt/crash/127.0.0.1-2025-12-15-06\:53\:37/vmcore
crash 9.0.0-4.el9.alma.1
Copyright (C) 2002-2025 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011, 2020-2024 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
Copyright (C) 2015, 2021 VMware, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 16.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
KERNEL: /usr/lib/debug/usr/lib/modules/5.14.0-570.22.1.el9_6.x86_64/vmlinux
DUMPFILE: /mnt/crash/127.0.0.1-2025-12-15-06:53:37/vmcore [PARTIAL DUMP]
CPUS: 1
DATE: Mon Dec 15 06:53:28 JST 2025
UPTIME: 00:37:39
LOAD AVERAGE: 0.02, 0.04, 0.08
TASKS: 341
NODENAME: appserver-dev
RELEASE: 5.14.0-570.22.1.el9_6.x86_64
VERSION: #1 SMP PREEMPT_DYNAMIC Thu Jun 19 08:10:32 EDT 2025
MACHINE: x86_64 (2794 Mhz)
MEMORY: 4 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
PID: 1512
COMMAND: "bash"
TASK: ffff99b501edd280 [THREAD_INFO: ffff99b501edd280]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash>
解析に有効な各種コマンドを説明します。
sys
sys コマンドを実行することで、システム全体概要を把握することができます。PANIC の項目にパニックの理由が記載されています。
crash> sys
KERNEL: /usr/lib/debug/usr/lib/modules/5.14.0-570.22.1.el9_6.x86_64/vmlinux
DUMPFILE: /mnt/crash/127.0.0.1-2025-12-15-06:53:37/vmcore [PARTIAL DUMP]
CPUS: 1
DATE: Mon Dec 15 06:53:28 JST 2025
UPTIME: 00:37:39
LOAD AVERAGE: 0.02, 0.04, 0.08
TASKS: 341
NODENAME: appserver-dev
RELEASE: 5.14.0-570.22.1.el9_6.x86_64
VERSION: #1 SMP PREEMPT_DYNAMIC Thu Jun 19 08:10:32 EDT 2025
MACHINE: x86_64 (2794 Mhz)
MEMORY: 4 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
log
log コマンドを実行することで、パニック直前のログを確認することができます。
crash> log
[ 0.000000] Linux version 5.14.0-570.22.1.el9_6.x86_64 (mockbuild@x64-builder02.almalinux.org) (gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5), GNU ld version 2.35.2-63.el9) #1 SMP PREEMPT_DYNAMIC Thu Jun 19 08:10:32 EDT 2025
[ 0.000000] The list of certified hardware and cloud instances for Red Hat Enterprise Linux 9 can be viewed at the Red Hat Ecosystem Catalog, https://catalog.redhat.com.
[ 0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.14.0-570.22.1.el9_6.x86_64 root=/dev/mapper/almalinux-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap
[ 0.000000] [Firmware Bug]: TSC doesn't count with P0 frequency!
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000dffeffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000dfff0000-0x00000000dfffffff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000011fffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] APIC: Static calls initialized
[ 0.000000] SMBIOS 2.5 present.
[ 0.000000] DMI: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 0.000000] Hypervisor detected: KVM
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[ 0.000003] kvm-clock: using sched offset of 10798080598 cycles
~~Truncated~~
Kernel panic が発生する直前のログを確認することで、panicの発生原因を特定できることがありますので、確認してみてください。
[ 16.063243] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 16.335907] e1000: enp0s8 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 29.213133] block dm-0: the capability attribute has been deprecated.
[ 2260.314000] sysrq: Trigger a crash
[ 2260.314468] Kernel panic - not syncing: sysrq triggered crash
[ 2260.314914] CPU: 0 PID: 1512 Comm: bash Kdump: loaded Not tainted 5.14.0-570.22.1.el9_6.x86_64 #1
[ 2260.315346] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 2260.315772] Call Trace:
[ 2260.316137] <TASK>
[ 2260.316483] dump_stack_lvl+0x34/0x48
[ 2260.316988] panic+0x107/0x2bb
[ 2260.317425] ? _printk+0x58/0x73
[ 2260.317858] sysrq_handle_crash+0x16/0x20
[ 2260.318294] __handle_sysrq.cold+0x7c/0x115
[ 2260.318752] write_sysrq_trigger+0x24/0x40
[ 2260.319219] proc_reg_write+0x56/0xa0
[ 2260.319677] ? srso_return_thunk+0x5/0x5f
[ 2260.320115] vfs_write+0xee/0x480
[ 2260.320600] ? syscall_exit_work+0x103/0x130
[ 2260.321069] ? srso_return_thunk+0x5/0x5f
bt
bt コマンドを実行することで、バックトレース（呼び出された関数の履歴）を確認することができます。
crash> bt
PID: 1512 TASK: ffff99b501edd280 CPU: 0 COMMAND: "bash"
#0 [ffffbadf4148fc60] machine_kexec at ffffffffa9881637
#1 [ffffbadf4148fcb8] __crash_kexec at ffffffffa9a0c4aa
#2 [ffffbadf4148fd78] panic at ffffffffaa4c6fc4
#3 [ffffbadf4148fdf8] sysrq_handle_crash at ffffffffaa00a386
#4 [ffffbadf4148fe00] __handle_sysrq.cold at ffffffffaa4f99ea
#5 [ffffbadf4148fe30] write_sysrq_trigger at ffffffffaa00aea4
#6 [ffffbadf4148fe40] proc_reg_write at ffffffffa9d0c126
#7 [ffffbadf4148fe58] vfs_write at ffffffffa9c678de
#8 [ffffbadf4148fee8] ksys_write at ffffffffa9c67fbf
#9 [ffffbadf4148ff20] do_syscall_64 at ffffffffaa5208df
#10 [ffffbadf4148ff50] entry_SYSCALL_64_after_hwframe at ffffffffaa600130
RIP: 00007fe3d80fe067 RSP: 00007ffda0decad8 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fe3d80fe067
RDX: 0000000000000002 RSI: 00005562a423b3b0 RDI: 0000000000000001
RBP: 00005562a423b3b0 R8: 0000000000000000 R9: 00007fe3d8177aa0
R10: 00007fe3d81b0c40 R11: 0000000000000246 R12: 0000000000000002
R13: 00007fe3d81fa780 R14: 0000000000000002 R15: 00007fe3d81f59e0
ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b
crash>ps
ps コマンドを実行することで、パニック発生時に存在していたプロセスの一覧を確認することができます。
crash> ps
PID PPID CPU TASK ST %MEM VSZ RSS COMM
0 0 0 ffffffffab61a8c0 RU 0.0 0 0 [swapper/0]
1 0 0 ffff99b500235280 IN 0.3 105088 13524 systemd
2 0 0 ffff99b500230000 IN 0.0 0 0 [kthreadd]
3 2 0 ffff99b500233700 IN 0.0 0 0 [pool_workqueue_]
4 2 0 ffff99b500231b80 ID 0.0 0 0 [kworker/R-rcu_g]
5 2 0 ffff99b500263700 ID 0.0 0 0 [kworker/R-sync_]
6 2 0 ffff99b500261b80 ID 0.0 0 0 [kworker/R-slub_]
7 2 0 ffff99b500265280 ID 0.0 0 0 [kworker/R-netns]
10 2 0 ffff99b500268000 RU 0.0 0 0 [kworker/u4:0]
11 2 0 ffff99b50026b700 ID 0.0 0 0 [kworker/R-mm_pe]
13 2 0 ffff99b500290000 ID 0.0 0 0 [rcu_tasks_kthre]
14 2 0 ffff99b500293700 ID 0.0 0 0 [rcu_tasks_rude_]
15 2 0 ffff99b500291b80 ID 0.0 0 0 [rcu_tasks_trace]
16 2 0 ffff99b500295280 IN 0.0 0 0 [ksoftirqd/0]
17 2 0 ffff99b5002b1b80 ID 0.0 0 0 [rcu_preempt]
task “PID”
task コマンドを実行することで、特定の PID のタスクの状態を確認することができます。
下記は PID 1 である systemd の状態を確認しています。
本例では、__state = 1（TASK_INTERRUPTIBLE）なので、正常な待ち状態であったことが分かります。
crash> task 1
PID: 1 TASK: ffff99b500235280 CPU: 0 COMMAND: "systemd"
struct task_struct {
thread_info = {
flags = 2,
syscall_work = 0,
status = 0,
cpu = 0,
preempt_lazy_count = 0
},
__state = 1,
stack = 0xffffbadf40010000,
usage = {
refs = {
counter = 1
}
},
flags = 4194560,
ptrace = 0,
on_cpu = 0,
wake_entry = {
llist = {
next = 0x0
},
{
u_flags = 48,
kmem
kmem コマンドを実行することで、パニック発生時のメモリ使用に関する情報を確認することができます。
kmem -i コマンドを実行することで、OS全体のメモリ使用に関する情報を確認できます。
crash> kmem -i
PAGES TOTAL PERCENTAGE
TOTAL MEM 935936 3.6 GB ----
FREE 708275 2.7 GB 75% of TOTAL MEM
USED 227661 889.3 MB 24% of TOTAL MEM
BUFFERS 737 2.9 MB 0% of TOTAL MEM
CACHED 82091 320.7 MB 8% of TOTAL MEM
SLAB 15562 60.8 MB 1% of TOTAL MEM
TOTAL HUGE 0 0 ----
HUGE FREE 0 0 0% of TOTAL HUGE
TOTAL SWAP 541695 2.1 GB ----
SWAP USED 0 0 0% of TOTAL SWAP
SWAP FREE 541695 2.1 GB 100% of TOTAL SWAP
COMMIT LIMIT 1009663 3.9 GB ----
COMMITTED 465654 1.8 GB 46% of TOTAL LIMIT
crash>kmem -s コマンドを実行することで、カーネル内部（slab）のメモリ使用量を確認することができます。メモリを大量に使用している原因を特定する際に有効です。
crash> kmem -s
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
ffff99b507ba8200 232 0 0 0 4k nf_conntrack_expect
ffff99b507ba8800 248 14 32 2 4k nf_conntrack
ffff99b50a1b6000 200 0 0 0 4k nf-frags
ffff99b50a1b6600 152 0 0 0 4k fuse_request
ffff99b50a1b6a00 888 0 0 0 8k fuse_inode
ffff99b50a1b6300 528 0 0 0 8k xfs_dqtrx
ffff99b50a1b6700 480 0 0 0 4k xfs_dquot
ffff99b50a1b6900 176 0 23 1 4k xfs_iul_item
ffff99b50a1b6100 208 0 0 0 4k xfs_attri_item
ffff99b50a1b6d00 176 0 0 0 4k xfs_attrd_item
ffff99b50a1b6e00 208 0 285 15 4k xfs_bui_item
ffff99b50a1b6200 176 0 23 1 4k xfs_bud_item
ffff99b50a1b6800 432 0 72 8 4k xfs_cui_item
ffff99b50a1b6c00 176 0 23 1 4k xfs_cud_item
ffff99b50a1b6400 688 0 0 0 16k xfs_rui_item
ffff99b50a1b6500 176 0 0 0 4k xfs_rud_item
ffff99b50a1b6b00 184 0 22 1 4k xfs_icr
ffff99b50a1b6f00 200 596 1260 63 4k xfs_ili
ffff99b50a1c6b00 1032 4671 5370 358 16k xfs_inode
ffff99b50a1c6f00 432 0 45 5 4k xfs_efi_item
ffff99b50a1c6000 440 0 9 1 4k xfs_efd_item
ffff99b50a1c6600 272 0 90 6 4k xfs_buf_itemまとめ
本記事では、Linux における メモリダンプ（vmcore）の取得と crash コマンドによる基本的な解析方法を解説しました。
kdump を使うことで、カーネルパニックやハング時でもメモリダンプを取得でき、取得した vmcore は kernel-debuginfo と crash を組み合わせることで初めて解析可能になります。
解析では、bt によるバックトレース確認や、task・ps によるプロセス状態の把握、kmem -i / kmem -s によるメモリ使用状況の確認といった基本コマンドを押さえることで、障害発生時の状況を段階的に切り分けられます。
カーネルダンプ解析は難解に見えますが、全体把握 → 詳細確認の順で進めることで、実務でも十分に活用できますので、ぜひ理解しておいてください。
Japanese 
English
コメント