- Linux では、メモリと CPU の実際の使用状況を検査し、使用済みメモリ、空きメモリ、キャッシュされたメモリを区別するための free、vmstat、ps、top などのコマンドが提供されています。
- GDB や Valgrind などのツールを使用すると、ネイティブ プログラム内のセグメンテーション エラー、メモリ リーク、不正アクセス、初期化されていない変数を検出できます。
- .NET Core 環境では、dotnet-dump、LLDB、SOS を組み合わせることで、Linux と Windows の両方でメモリ ダンプの詳細な分析が可能になります。
- システム メトリック、ログ、ダンプ分析を組み合わせた整然とした診断ワークフローにより、メモリの問題を特定して修正する時間が大幅に短縮されます。
Linuxサーバーで問題が発生した場合、原因はメモリの使用方法やデバッグツールにあることが多いのですが、何を探すべきかが分からないと、すべてが数字とプロセスの混沌とした塊のように見えてしまいます。RAM内で何が起こっているのか、プログラムがどのように動作しているのか、そしてメモリダンプを取得する方法を理解することが、奇妙なエラーやセグメンテーション違反が発生するたびに闇雲にトラブルシューティングを行うことを避けるための鍵となります。
この記事では、Linux でシステムコマンド (free、vmstat、/proc/meminfo)、GDB などのデバッガ、Valgrind などのメモリアナライザ、および .NET やその他の環境に特化したユーティリティを使用して、メモリの検査、プログラムのデバッグ、ダンプの分析を行う方法を、詳細かつ分かりやすく解説します。この記事の目的は、サーバーやプロフェッショナルな開発環境におけるメモリと CPU の問題を診断するための実践的なツールを身につけていただくことです。
概要: Linuxのメモリと100%にこだわるべきではない理由
Linuxサーバーでは、RAMはシステムがすぐに再利用する必要のあるデータやコードを高速に保存する役割を果たします。RAMへのアクセスはディスクへのアクセスよりもはるかに高速であるため、カーネルはこの利点を活かして、すぐに再び必要になる可能性のあるファイル、バッファ、メモリページなどのキャッシュとしてRAMを使用します。
ApacheやNginxなどのWebサーバー、あるいはMySQLやMariaDBなどのデータベースサーバーにおいては、使用中のメモリ量、空きメモリ量、キャッシュされているメモリ量を把握することは、サービスの適切なサイジングや、名前空間およびcgroupの理解に不可欠です。実際、MySQLTunerなどの最適化ツールは、このデータ（およびその他の情報）を使用して、バッファ、キャッシュ、接続の設定を提案します。
最初は多くの人が驚く概念ですが、RAMは使用されることを前提に設計されているということを理解することが重要です。使用率が90%や100%になっても、必ずしも問題ではありません。Linuxはシステムの高速化のために、ディスクキャッシュでRAMを埋めます。本当に問題なのは、単にグラフに「使用率が高い」と表示されるのではなく、メモリ不足エラーが発生したり、プロセスがOOM（Out Of Memory）メッセージでクラッシュしたり、サービスがフリーズしたりする場合です。
サーバーが不安定になったり、動作が遅くなったり、過剰なメモリ使用量によってサービスが停止したりする場合、または現在のリソースでは対応しきれないほどのトラフィックの急増が予想される場合にのみ、積極的な最適化に踏み切るのが賢明です。
Linuxでメモリを検査するための基本コマンド
メモリの問題をトラブルシューティングする最初のステップは、総RAM容量と、それが使用済みメモリ、空きメモリ、キャッシュ、スワップ領域にどのように配分されているかを理解することです。Linuxには、このためのユーティリティがいくつか用意されており、それぞれ詳細度が異なります。
freeコマンド: 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 M、使用メモリ 1582 M、アクティブメモリ 1124 M、非アクティブメモリ 406 M、空きメモリ 465 M、バッファメモリ 407 M、スワップキャッシュ 0 M、合計スワップ 0 M、使用スワップ 0 M、空きスワップ 0 M
アイドルメモリという概念は興味深いものです。これは使用中とみなされるメモリですが、アクティブなプロセスに関連付けられていないため、実際にはシステムが解放できるメモリのように動作します。このことから、Linuxが「すべての領域を使い切っている」ように見える理由が説明できますが、実際には必要に応じて解放できる余地があるのです。
/proc/meminfo: カーネルの生の詳細
カーネルが処理するすべての詳細情報が必要な場合は、 /proc/meminfoファイルを参照してください。
cat /proc/meminfo
このファイルには、内部メモリ管理に関連する数十のフィールドが含まれています。例えば、合計メモリ、空きメモリ、バッファ、キャッシュ、スラブ、ヒュージページ、利用可能なメモリなどです。自動化ツールや監視スクリプトにとって非常に便利ですが、直接読み込む場合は`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
プロセス内の各スレッドの詳細が表示されます。もし1つのスレッドが100%で、残りがアイドル状態になっている場合、そのコード部分に無限ループ、奇妙なブロッキング問題、または設計の不適切なクリティカルセクションが存在する可能性があります。
プロセスの優先度: niceとrenice
リソースを大量に消費するプロセスであっても、それが正当な処理であるにもかかわらず、システム全体に過負荷をかけないようにしたい場合は、そのプロセスの優先度（nice値）を調整できます。`nice`コマンドと`renice`コマンドを使用すると、優先度を低く設定したプロセスを開始したり、既存のプロセスの優先度を調整したりできるため、カーネルは他の重要なタスクと比較して、これらのプロセスに割り当てるCPU時間を少なくすることができます。
その他の主要コマンド: pidof、kill、strace、ltrace
システムに負荷がかかっている場合、プロセスを迅速に特定して制御できると便利です。
- ピドフ: プロセスの名前からプロセスの PID を取得します。スクリプトや迅速な介入に最適です。
- kill: プロセスに信号 (TERM、KILL など) を送信して、プロセスが停止した場合に、順番にシャットダウンするか、ジョブを途中で終了させます。
- ストラス: は システムコール プロセスを実行します。何が停止しているかを確認するのに最適です (ディスクの読み取り、ソケットなど)。
- 追跡するstraceに似ていますが、 書店への電話共有 API の使用に関する問題のデバッグに役立ちます。
これらのツールは、メモリリークやクラッシュの検出に役立つだけでなく、サイバーセキュリティ、フォレンジック分析、異常なバイナリ動作のデバッグにも広く使用されています。
ファイルとディスクのコマンド: lsof、df、du、locate
ストレージに問題があると思われる場合 (たとえば、開いているファイルが多い、ディスクがいっぱいなど)、他のコマンドが役立ちます。
- lsof: リスト プロセスによって開かれたファイルファイルシステムのアンマウントを妨げる記述子またはファイルのリークを見つけるのに役立ちます。
- df: は 空きディスク容量 ファイルシステムごとに、連鎖障害の原因となるディスクを 100% 排除するために不可欠です。
- du: 計算します ディレクトリで使用されるスペース制御不能に増大するフォルダー (ログ、バックアップなど) を見つけるのに非常に便利です。
- locate: インデックス付きデータベースを使用して名前でファイルを検索できます。多くの場合、find よりも高速です。
診断用のネットワークコマンド: nc、netstat、ab、tcpdump、wireshark、nmap
パフォーマンスやメモリの問題は、ネットワークのボトルネックや攻撃を伴うことが多いため、基本的なツールをいくつか手元に用意しておくと良いでしょう。
- nc (ネットキャット): まさにネットワークの万能ナイフです。ソケットを開き、データを送受信し、サービスのテストや即席のトンネルの作成もできます。
- 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内では、プログラムはまだ実行されていません。次のコマンドで起動できます。
- ラン必要な引数を指定してプログラムを起動します。
- start: run と同じですが、関数の先頭で停止します
main.
たとえば、次のような実行ファイルがあるとします。 須磨 そして、引数がどのように処理されるかを確認したい場合は、GDBで次のようにします。 run 3 5 デバッガーからのパラメータを使用して起動します。
ブレークポイントとウォッチポイント: 必要な場所でプログラムを一時停止する
ブレークポイントはソースコード内の停止点です。実行がブレークポイントに到達すると、プログラムは一時停止し、内部状態を調べることができます。GDBでは、以下のコマンドでブレークポイントを定義します。
break lugar
ここで「場所」は、関数名、行番号、またはファイル:行のいずれかになります。典型的な例は次のとおりです。
break main
これにより、GDBはメイン関数に入った瞬間に停止します。プログラムがブレークポイントで停止すると、l（リスト）コマンドでコードを表示したり、変数を確認したり、コールスタックをたどったりすることができます。
ウォッチポイントは動作が異なります。コードの特定の位置で停止するのではなく、変数の値が変更されたときに停止します。メモリ破損や重要な構造体への予期せぬ変更を検出するのに非常に役立ち、コード全体にprint文を大量に書き込む必要がありません。
細かいフロー制御: ステップ、次へ、続行、終了
プログラムがブレークポイントで停止したら、続行する方法はいくつかあります。
- 手順: 次の行を実行し、呼び出された関数に入ります。
- 次の: 関数に入らずに次の行を実行します (すべてを一度に実行します)。
- 続ける: 次のブレークポイントまで、またはプログラムが終了するまで実行を再開します。
- 仕上げ: 現在の関数が返されるまで継続し、呼び出されたポイントに戻ります。
これにより、プログラム全体を「飲み込む」ことなく、疑わしいコードを段階的に検査できます。便利なトリック：GDBでは、 Enterキーを押すと最後のコマンドが繰り返されますたくさん作るのに最適 next o step 続いて入力が少なくなります。
コールスタックとフレーム: ここに至るまでの経緯
ある時点でエラーが発生した理由を理解するには、その時点に至るまでにどの関数が呼び出されたかを確認することが不可欠です。この情報を格納する構造はコールスタックです。GDBには、コールスタックを管理するためのいくつかのコマンドが用意されています。
- bt (バックトレース): ネストされた関数とフレーム番号のリストを含む完全なスタックを表示します。
- up: スタック内の 1 レベル上の、現在の関数を呼び出したポイントまで移動します。
- ダウン: 1 レベル下に移動して、実行されていた関数に戻ります。
- fr (フレーム): 現在のフレームを表示するか、番号を指定して別のフレームに変更することができます。
これにより、呼び出しのさまざまなレベル（たとえば、内部関数からメイン関数へジャンプするなど）に自分の位置を設定し、それぞれの場所で変数がどのように扱われていたかを確認できます。
メモリとの相互作用: 設定、戻り、バックトレース yx
GDBの大きな利点の1つは、プログラムが停止している間でもメモリの読み取りと変更が可能であることです。便利な操作には以下のようなものがあります。
- セッションに: 実行中に変数の値を変更します。再コンパイルせずにシナリオをテストするのに最適です。
- 戻り値: 現在の関数に、コードの実行を継続せずに指定された値を返すように強制します。
- バックトレース: すでに表示されています。現在の呼び出しスタックを表示します。
- x: アドレスから始まるメモリの内容を調べます。形式やサイズは異なります（例：
x/4xw 0x7fffffffe0004 つの単語を 16 進数で表示します。
これらのオプションを使用すると、エラーを再現したり、危険な入力がオーバーフローを引き起こすかどうかを確認したり、スタックまたはヒープ上の複雑なデータ構造を検査したりできます。
コアダンプによる事後デバッグ
Linuxは、SIGSEGVなどのシグナルによってプロセスがクラッシュした場合にコアファイルを生成できます。このファイルには、クラッシュ時のプロセスの完全な状態（メモリ、レジスタ、スタックなど）が含まれています。セッションでこれを有効にするには、次のようにします。
ulimit -c unlimited
ユーザーに対してこれらの制限をより永続的に有効にするには、/etc/security/ limits.conf を編集して、次のような行を追加します。
* soft core unlimited
プログラムがクラッシュすると、通常「core」という名前のファイルが作業ディレクトリに生成されます。GDB を使用すると、次のようにしてそのファイルを解析できます。
gdb ejecutable core
これにより、まるでプログラムがまだ稼働しているかのように事後分析を実行できるため、障害が容易に再現できない場合に最適です。
Valgrind: メモリリークとエラーの検出
C/C++（および類似言語）における多くのメモリ問題に対して、GDBは不十分です。なぜなら、 GDBは不正な読み取り、メモリリーク、または初期化されていないメモリ使用を自動的に検出するように設計されていないからです。そこで登場するのがValgrindです。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
トレースを実行すると、最後に「エラー概要」にエラーが0件と表示され、メモリリークも報告されていないことがわかります。これは、少なくともMemcheckの観点からは、プログラムにメモリ異常がないことを示しています。
メモリリークを検出する
コードを修正して、解放せずにmallocを実行するようにした場合（例えば、1バイトを予約して決して解放しないなど）、再コンパイルすると次のようになります。
gcc -Wall -gstabs valgrind_hello_bad.c -o valgrind_hello_bad
実行時:
valgrind --tool=memcheck --leak-check=full -v ./valgrind_hello_bad
Valgrindは、解放されていないメモリ量を示す「終了時に使用中」の値がゼロ以外のヒープサマリーを表示します。さらに、「確実に失われた」セクションには、リークしたバイト数とブロック数、およびリークの原因となった呼び出しトレース（関数、ファイル、コード行）が表示されます。
より複雑なケースでは、例えばフィルターが使用される場合、 leak() 関数で100バイトValgrindからの出口は、 malloc 問題があり、 free 対応し、その後、要約がリークゼロに戻ることを確認します。
違法行為と範囲外アクセス
Memcheckが検出するもう1つの典型的なエラーは、無効なアドレスへの書き込みです。たとえば、メモリ位置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_unitialized.c:9) 初期化されていない値は、0x80483EA のスタック割り当てによって作成されました: main (valgrind_unitialized.c:7)
パラメータ「–track-origins=yes」は、初期化されていない変数が最初に作成された場所を特定するのに役立ち、コード修正を大幅に高速化します。
ヒープ内の空き領域とエラー検出の誤用
Valgrindは以下も検証しています freeは有効なポインタに対してのみ呼び出されますメモリを解放しようとすると、 mallocまたは、同じブロックをダブルクリックすると、次のようなメッセージが表示されます。
0x402B06C の free() / delete / delete[] / realloc() が無効です: free (...) by 0x8048449: main (valgrind_illegal_free.c:11)
多くの場合、電話をかけているアドレスが free すでに解放されたブロックの直後に配置されているため、識別が可能 ポインタの計算エラーまたは二重リリース.
要約すると、Valgrindはネイティブプログラムにおけるメモリリーク、解放後使用、またはメモリ破損が疑われる場合に不可欠なツールであり、GDBと組み合わせることでアプリケーションの内部状態を非常に強力に把握することができます。
LinuxとWindowsのコアダンプと分析
現代のアプリケーション、特に.NET Coreでは、複雑なメモリやパフォーマンスの問題を分析する際に、メモリダンプを取得して別のマシンで詳細に分析することがよくあります。これらのダンプは、従来のコアダンプと同様に、特定の時点でのプロセスの状態を固定します。
dotnet-dump と LLDB を使用して Linux 上の .NET ダンプを分析する
Linux 上の .NET Core 環境では、 dotnet-dump が推奨ツールの 1 つです。ダンプを取得した後、以下のコマンドで分析を開始できます。
dotnet-dump analyze <dump-file>
ダンプが生成された環境と同じアーキテクチャとLinuxディストリビューションを持つマシンで分析を実行することが重要です。dotnet-dumpはマネージド.NETコード向けに設計されています。ネイティブコード（C/C++）も分析するには、 LLDBとSOS拡張機能を使用する方が適切です。
LLDB を使用すると、マネージド コードとネイティブ コードの両方をデバッグできます。また、 dotnet-sos を使用すると、.NET 専用のコマンドを提供する SOS 拡張機能をインストールできます。.NET Core ダンプを正しく読み込むには、LLDB と SOS は、ダンプが作成された環境から特定のバイナリを必要とします。
- libmscordaccore.so
- libcoreclr.so
- ドットネット (アプリケーションの起動に使用されるホスト)
これらのバイナリは通常、 dotnet-symbolツールを使用してダウンロードできます。プライベートビルドの場合、またはシンボルサーバーにない場合は、元のマシンからコピーすることもできます。バイナリがダンプファイルに含まれていない場合は、LLDB/SOSで以下を使用できます。
setclrpath <ruta>.NET Core バイナリが配置されている場所を示します。setsymbolserver -directory <ruta>シンボルの位置を指定します。
必要なものがすべて揃ったら、デバッグする実行可能ファイルとして dotnet ホストを指定して、ダンプを LLDB にロードします。
lldb --core <dump-file> <host-program>
ここで それは投棄への道であり 通常はバイナリです。 dotnetただし、自己完結型アプリケーションの場合は、アプリ独自の実行可能ファイル (.dll 拡張子なし) になります。
LLDBでは、正しいシンボルサーバを設定する必要があることがよくあります。 setsymbolserver -ms Microsoftサーバーを使用するか、 setsymbolserver -directory <ruta> ローカルディレクトリの場合は、 loadsymbols ネイティブシンボルをロードします。そこから、通常のSOSコマンドを使用して、マネージドヒープ、スレッド、例外などを分析できます。
WindowsからのLinuxダンプ解析
Linuxで生成されたダンプファイルは、同じシステム上で分析するだけでなく、Visual Studio、WinDbg、dotnet-dumpなどのツールを使用してWindowsから開くこともできます。その機能は様々です。
- Visual Studioの: 混合したダンプを清掃できます ネイティブコードとマネージドコード非常にユーザーフレンドリーなグラフィカルインターフェースを備えています。 Visual Studio のメモリダンプのデバッグ.
- WinDbgユーザーダンプの高度なサポート、以下を含む Linuxダンプ Windowsと同様のワークフローです。Linux x64またはArm64環境からのダンプにはWinDbgのx64バージョンを使用し、x86ダンプにはx86バージョンを使用する必要があります。
- ドットネットダンプ Windowsの場合：Linuxと同じように使用し、
dotnet-dump analyzeダンプのアーキテクチャに応じて、ツールの x64 バージョンまたは x86 バージョンを選択してください。
CPUとメモリの高使用率の専門的な診断
Linuxにおけるメモリクリーンアップは、特定のツール以外にも、無秩序な操作を避けるために構造化されたワークフローを伴うのが一般的です。サーバーにおける実用的な手順は以下のとおりです。
- 見る top 疑わしい読み込みパターンとプロセスを検出します。
- 確認する ps CPU とメモリを最も多く使用するプロセス。
- 消費が論理的であるか (コンパイル、バッチ、インデックス)、または異常な動作の可能性があるかどうかを確認します。
- スレッドを分析する トップ -H -p PID マルチスレッドプロセスの場合。
- レビューする サービスログ journalctl または tail を使用します。
- 問題が本当に CPU に関連しているのか、それとも隠れているのかを確認します... ディスクI/O iostat を使用します。
ボトルネックがCPUにあるのかディスクにあるのかを判断するには、iostat -xz 1 3が非常に役立ちます。topで高い %waとともに、ディスクの使用率が高く、待ち時間が長い場合、問題はおそらく CPU ではなくストレージにあります。
このワークフローを適用すると、次のようなケースの診断が容易になります。
- ボットまたは悪意のあるトラフィック php-fpm プロセスをトリガーし、Web サーバーに過負荷をかけます。
- Un 無限ループ内のスレッドを持つ Java マイクロサービス コア全体を消費します。
- CPU依存に見えるが実際には ディスクを待ってロックされています ループの各反復で。
システムツール（ps、top、vmstat、free）、デバッガ（GDB、LLDB、dotnet-dump）、メモリアナライザー（Valgrind）、ネットワークコマンド、ディスクコマンドを組み合わせることで、Linuxにおけるメモリやパフォーマンスの問題がブラックボックスではなくなり、適切な方法と忍耐力があれば、かなりの精度で特定し修正できるような作業方法を構築できます。
