GPUサービスで「Segmentation Fault 」に出会ったら~分析から解決までの実践アプローチ~

GPUサービスで「Segmentation Fault 」に出会ったら~分析から解決までの実践アプローチ~

こんにちは!

今日は仮想環境+GPUなサービスにおける「Segmentation Fault」について、分析と対処法について書いてみたいと思います。

Segmentation Faultの本質と特徴

Segmentation Faultは、プログラムが保護されたメモリ領域にアクセスしようとした際にOSが発生させる例外です。
今回は複数のGPUサービス(つまりGPUを使うプロセス)が動作していて、そのうちの1つを再起動したときに発生しました。
毎回発生するわけではありません。むしろ数百回の起動に1回程度ですが、1回でも発生すると絶望的な結果につながります。というのも、1つのGPUサービスの停止が SPOF となってサービス全体に影響が発生します。かつ、1回でも「Segmentation Fault」が発生してしまうと、その原因となったプロセスが二度と起動しなくなる、というやっかいな現象でした。

このように「普段は正常に動作しているのに突然動かなくなる」というのがデバッグを非常に難しくします。

とくにGPU+仮想化の組み合わせで従来のC++アプリよりも発生確率がぐっとあがる印象があります。

まとめると以下のような感じでしょうか

  • GPUを使用するサービス(画像認識、機械学習処理など)で発生頻度が高い
  • 長時間の稼働後に突然発生する傾向がある
  • CUDA unknown error との違いは、前者は時間を置いて再実行すると動くことがあるが、Segmentation Fault の場合、二度と起動しない。

(詳しい方ほどつっこみたくなるポイントとしてはSegmentation Fault というエラーはかなり原因がざっくりしてるので、「私たち遭遇した今回の一事例」の場合は、と読み替えていただければとおもいます)

Segmentation Fault の一般的な発生原因としては

  • NULLポインタへのアクセス
  • 解放済みメモリの参照
  • スタックオーバーフロー
  • 読み取り専用メモリへの書き込み

などがありますが、GPU+仮想化の環境だと、もはや何が原因だかわからないことがほとんどです。

実際の事例

さて、実際、先日、私たちが経験した事例をご紹介します。

GPUを使用するアプリケーションを実行しようとしたところ、以下のようなログが出力されました

import 'scipy.special._orthogonal' # <_frozen_importlib_external.SourceFileLoader object at 0x7fc006e862b0>
# /home/user/anaconda3/envs/image_recognition_env/lib/python3.9/site-packages/scipy/special/__pycache__/_spfun_stats.cpython-39.pyc matches ...
...
import 'yaml' # <_frozen_importlib_external.SourceFileLoader object at 0x7fc003d215e0>
...
Segmentation fault (core dumped)

●コアダンプ分析→問題の核心に迫る

GPUアプリケーション開発や運用において、特にC/C++、そしてPythonのC拡張モジュールを利用したプログラムを扱う際には、予期しないエラー「Segmentation fault」が発生することがあります。Cを特に意識しないPythonアプリでも裏でつかってるライブラリやCUDAまわりが原因で発生することもあります(最近はそれがおおいです)

このエラーは通常、「Segmentation fault (core dumped)」というメッセージと共に現れます。

ここで言う「コアダンプ(core dump)」とは一体何でしょうか?

コアダンプとは?

コアダンプとは、プログラムが異常終了した際のメモリの状態をそのままファイルとして保存したものです。これを分析することで、プログラムがどの時点で、どのような状態で停止したのかを詳細に把握でき、根本的な問題点を特定するのに役立ちます。

STEP 1: コアダンプの有効化

デフォルトではコアダンプの生成が制限されている場合があります。まず、これを解除しましょう。

# コアダンプサイズの制限を解除
ulimit -c unlimited

# コアダンプの保存場所とファイル名を指定(Ubuntu/Debianの場合)
echo '/tmp/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern

これにより、クラッシュ時にコアダンプファイルが /tmp ディレクトリに、プログラム名(%e)、プロセスID(%p)、タイムスタンプ(%t)を含む名前で保存されます。

STEP 2: GDBによるコアダンプ分析

GNUデバッガ(GDB)を使って、生成されたコアダンプを分析します。

# コアダンプの分析
# 例:pythonプログラムの場合
gdb python /tmp/core.python.12345.1620000000

GDBが起動すると、プロンプトが表示されます。この中で以下のコマンドを使用して、詳しく問題点を探ります。

STEP2-1. バックトレース(スタックトレース)表示

(gdb) bt full

このコマンドでプログラムがどこで停止したかの詳細なスタックトレースが表示されます。

STEP2-2. 特定のフレームへの移動

スタックトレースから特定の関数や処理を深掘りしたいときは、フレーム番号を指定して移動します。

(gdb) frame 3

STEP 2-3. 変数の検査

特定のフレーム内での変数の値を検査できます。

(gdb) print variable_name

STEP 2-4. メモリ内容の検査

メモリアドレスに何が格納されているのかを直接調べることができます。

(gdb) x/10x memory_address

実際のエラーケースの例

よくある実際のケースとして、PythonのC拡張やGPUライブラリを使った際に、以下のようなバックトレースを得ることができます

#0  0x00007f92d3b7c7a0 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f92d3b7e8fa in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f92d5a1c063 in THCudaCheck () from /usr/local/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so
#3  0x00007f92d5a2e4f5 in cudaLaunchKernel () from /usr/local/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so

CUDAのカーネルが起動した際に問題が起きていることがわかります

このように外部ライブラリが関わるケースでは、ライブラリの設定やGPUドライバのバージョン不一致などが原因になることが多いですが、完全な原因の特定はほぼ不可能(時間的に)です

STEP 3: システムログの分析

コアダンプ解析だけでなく、システムレベルのログも有効な情報を提供します。以下のコマンドで関連するログをチェックしましょう。

dmesg | grep -i segfault
journalctl | grep -i segfault

これによりカーネルレベルでのメッセージが取得でき、特にメモリや仮想環境特有の問題に関する情報が得られることがあります。ですが、ここまでやってるヒマはほとんどありません。

●仮想環境特有の問題と対策

さいきんシステムはDockerやVMなど、多層でミルフィーユ状の仮想化環境が一般的になっています。
これらの環境下では、特権レベルやリソースの制限、メモリアクセスの問題がより複雑になりデバッグのやる気を確実にそいでくれます。

STEP1.DockerにおけるPtraceの問題に対処する

Dockerコンテナ内でのデバッグ作業において、ptraceシステムコールを使ったデバッガ(例えばGDBなど)を利用しようとすると、許可が無いためにエラーが発生する場合があります。
これはDockerがデフォルトでセキュリティ上の理由からSYS_PTRACEケーパビリティを無効化しているためです。

この問題を解決するためには、明示的にSYS_PTRACEを許可する必要があります。次のようなコマンドで設定できます。

# コンテナ起動時にSYS_PTRACEを有効にする
docker run --cap-add=SYS_PTRACE image_name

# すでに起動済みのコンテナにSYS_PTRACEを追加適用
docker update --cap-add=SYS_PTRACE container_name

これにより、コンテナ内で安全かつ正しくデバッガが動作できるようになります。

STEP2.pstackによるスタックトレース取得

問題発生時にプロセスがどのような状態にあるかを確認することはデバッグ作業の基本です。pstackは実行中のプロセスのスタックトレースを簡単に取得できるツールです。特に動作がフリーズしたプロセスや異常終了の原因調査に役立ちます。

pstackは次のようにして導入・利用します。

sudo apt install pstack
pstack process_id

上記のコマンドを実行すると指定したプロセスの現在のスタックトレースを即座に表示します。得られた情報から関数呼び出しの履歴を確認し、バグの発生箇所を絞り込むことができます。

STEP3.動作中プロセスの軽量診断とメモリスナップショット取得

動作中のプロセスが予期しない挙動を見せた場合、メモリの状態を含む完全なスナップショットを取ることで、後で詳細な調査が可能になります。この目的で使用されるのがgcoreです。gcoreは指定したプロセスの現在の状態をコアダンプとして保存します。

利用方法は以下の通りです。

gcore process_id  # 指定プロセスのコアダンプを生成

コアダンプが生成されると、後ほどGDBなどのデバッガを用いてその時点のプロセスメモリの内容やスタック状況を深く分析できます。これにより動作中のプロセスを停止することなく問題点の特定を進めることができます。

こんな感じで仮想環境特有のデバッグ問題は適切なツールと気合があれば比較的効果的に対処できます。とくにDockerでは特にケーパビリティの管理が重要であり、プロセス診断ツール(pstackやgcore)を併用することで根気よく問題を特定し、解決できる場合もあります。

●再発防止のためのシステム設計

さて、Segmentation Fault のような突発的で予測困難なエラーに対しては、発生自体を完全に防ぐことは難しく、エラー発生時の影響を最小化する仕組みを設けるほうが現実解といえるのではないでしょうか。

再起動とウォッチドッグプロセスの実装

「結局それかいっ!」ってなりますが、結局「再起動」がいちばん効果的なんです。

GPUを用いるサービスにおいて、プロセスが突然停止するリスクに備える最も基本的で効果的な方法は、プロセスの生存を監視し、停止した場合に自動的に再起動を試みるウォッチドッグの実装してみましょう。

以下に、Pythonを用いたシンプルなウォッチドッグのシンプルな実装例を示します。

import subprocess
import time
import logging

def run_with_watchdog(command, max_retries=3, wait_time=5):
    for attempt in range(max_retries):
        try:
            process = subprocess.Popen(command, shell=True)
            return_code = process.wait()
            if return_code == 0:
                return True
            logging.warning(f"プロセスが終了コード {return_code} で終了しました。再試行 {attempt + 1}/{max_retries}")
        except Exception as e:
            logging.error(f"例外が発生しました: {e}. 再試行 {attempt + 1}/{max_retries}")
        time.sleep(wait_time)
    return False

# 使用例
run_with_watchdog("CUDA_VISIBLE_DEVICES=1 python image_recognition_server.py")

このようなウォッチドッグは特にサービス運用中に役立ち、Segmentation Fault による一時的な停止をリカバリーできます

systemdを利用したサービス監視

Linux環境では、より堅牢で標準的なプロセス管理方法として、systemdを利用したサービス自動再起動の仕組みが推奨です

以下にsystemdの設定例を示します。

# /etc/systemd/system/image-recognition.service
[Unit]
Description=Image Recognition Service
After=network.target

[Service]
User=app_user
WorkingDirectory=/opt/app
ExecStart=/usr/bin/python3 /opt/app/image_recognition_server.py
Restart=on-failure
RestartSec=5s
Environment="CUDA_VISIBLE_DEVICES=0"
Environment="PYTHONPATH=/opt/app"

[Install]
WantedBy=multi-user.target

systemdを用いることで、プロセスが異常終了した際に自動的に再起動され、サービスの可用性がキープできますね

GPUおよびプロセスメモリ使用状況の把握

GPUおよびプロセスのメモリ使用状況をモニタリングすることで、メモリの断片化やリソースの枯渇を早期に察知できます。

# GPUメモリ状況の確認
nvidia-smi

# プロセスのメモリマップ確認
cat /proc/<PID>/maps

メモリエラー検出ツールの活用

# AddressSanitizer(メモリリーク・オーバーフロー検出)
PYTHONMALLOC=malloc ASAN_OPTIONS=detect_leaks=0 python -m pip install --no-binary :all: problematic_package

# Valgrindによるメモリリーク詳細調査
valgrind --leak-check=full python script.py

# 実行中プロセスのスタックトレース取得
pstack process_id

●実践的な解決案

さんざん書いてきましたが、結局、再起動が最強です。

再起動といっても、段階的なアプローチを使いましょう

STEP1. 環境変数の微調整による再実行

CUDA_VISIBLE_DEVICES=1 python script.py
CUDA_VISIBLE_DEVICES=0 PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128 python script.py

STEP2. 仮想環境またはコンテナの再起動

Dockerの場合:

docker restart container_name

WSLの場合:

wsl --shutdown

STEP3. ホストシステム全体の再起動

Linux:

sudo reboot

Windows:

再起動を選択

このように段階的に再起動を試します。
GPU+仮想環境+Segmentation Fault のときに経験的にもっとバランスがいいのが STEP2 のコンテナ・仮想環境の再起動です。今回の事例のように、複数のプロセスが1つのGPUのメモリを共有しているとき、1つのプロセスがSegmentation Fault になったとき、そのプロセスを再起動しても復旧しないことが多いです。おそらく複数のプロセスによる複雑なメモリの断片化などがGPU内で起こっているためだとおもわまれう。このとき、コンテナ・仮想環境の再起動をすることで、GPUメモリを食っているプロセスをいったんすべて引きはがすことができるからです。OS再起動に比べ、比較的高速にサービスを復旧できる点も魅力的です。

●定期メンテナンスによる再発防止

さて、突発的な問題の発生を防ぐには、そもそも定期的な再起動やメンテナンス計画を組むこともがそもそも基本ですね。

まとめ

さて今回は Segmentation Fault からはじめて、
その原因、分析方法、発生してしまったときの対処方法、予防についてざざっとかいてみました。Segmentation Faultの対応では、根本原因を完全に突き止めることは難しい場合がありますが、分析と予防の両面から階層的なアプローチを組み合わせることで、高い実用性とシステムの可用性をキープできるよう、引き続き取り組んでいきたいとおもいます。今回も「結局、再起動かーい」になってしまいましたが、エンジニアリングの本質は、複雑な問題に対してシンプルで堅牢な解決策を選ぶことだとおもっており、適切な監視、自動化、定期的なメンテナンスを組み合わせて問題の影響を最小化できるよう努力していきたいとおもいます。

関連記事

本番運用におけるPyTorch+CUDAサーバーでの「Unknown Error」問題とその対策
https://blog.qualiteg.com/how_to_address_cuda_unknown_error/

Read more

AIエージェント時代の新たな番人「ガーディアンエージェント」とは?

AIエージェント時代の新たな番人「ガーディアンエージェント」とは?

こんにちは!今日は先日ガートナーが発表したガーディアンエージェントについて解説します ガートナーの公式定義 ハイプカーブで有名なガートナーは2025年6月に、ガーディアンエージェントに関する見解を発表しました。ガーディアン・エージェントとは、AIとの安全で信頼できるやりとりを支援するために設計されたAIベースのテクノロジです。 ざっくりいうと、 「AIエージェントが来るよ」と予言したガートナー社は、次は、「ガーディアンエージェントが来るよ」と予言しました。なぜガーディアンエージェントが来るのでしょうか?本稿では、そのあたりを考察していきたいと思います。 なぜ今、AIの「監視役」が必要なのか 2025年、私たちは本格的なAIエージェント時代の入り口に立っています。AIが単なるツールから、自律的に判断し行動する「エージェント」へと進化する中で、新たな課題が浮上しています。 従来のAIとエージェント型AIの違い さて、ガーディアンエージェントが必要になる理由として、生成AI(以後AIと呼びます)の急速な進化があげられます。従来のAIとエージェント型AIの違いを思い出

By Qualiteg コンサルティング
LLM推論基盤プロビジョニング講座 第4回 推論エンジンの選定

LLM推論基盤プロビジョニング講座 第4回 推論エンジンの選定

こんにちは!前回までの講座では、LLMサービス構築に必要なリクエスト数の見積もりや、使用モデルの推論時消費メモリ計算について詳しく解説してきました。今回は7ステッププロセスの4番目、「推論エンジンの選定」について詳しく掘り下げていきます。 推論エンジンとは何か 推論エンジンとは、GPU上でLLMモデルの推論計算(テキスト生成)を効率的に行うために設計された専用のソフトウェアプログラムです。一般的なディープラーニングフレームワーク(PyTorch、TensorFlowなど)でも推論は可能ですが、実運用環境では専用の推論エンジンを使用することで、大幅なパフォーマンス向上とリソース効率化が期待できます。 推論エンジンは単なる実行環境ではなく、様々な最適化技術を実装しています。特定のモデルアーキテクチャに特化した最適化機能を実装したものや、推論速度の高速化に特化したもの、前回解説したKVキャッシュのメモリ効率化機能を備えたものなど、それぞれ特徴が異なります。そのため、自社で採用したLLMモデルや運用環境、要件に合致した推論エンジンを選定することが重要です。 推論エンジン選定のアプロ

By Qualiteg コンサルティング
発話音声からリアルなリップシンクを生成する技術 第1回:音素とwav2vec

発話音声からリアルなリップシンクを生成する技術 第1回:音素とwav2vec

こんにちは! 今日は当社のMotionVox でも実際に使っている「リップシンク」技術について総合的に解説してみたいとおもいます。 音声に合わせて自然な口の動きを生成するリップシンク技術は、AIアバターや3Dアニメーション制作においても重要な技術です。 本記事では、最新のディープラーニング技術を活用したリップシンク学習の基礎から実装まで、技術的な観点から詳しく解説します。 1. リップシンク学習の基礎概念 1.1 問題設定 リップシンク学習とは、音声データから対応する口の動きを予測する回帰問題ととらえることができます f: 音声特徴量(t) → 口の動きパラメータ(t) この問題のコアは 音韻(音の特徴)と視素(視覚的な口の形)の対応関係を学習する ことにあります。 1.2 音韻-視素マッピングの複雑性 ただし! 人間の発話における音と口の形の関係は、単純な1対1マッピングではないんです。 同じ音でも文脈で変化 「あ」の発音でも: - 「か」の後の「あ」→ 口がやや狭めから開く - 「ん」の後の「あ」→ 口が閉じた状態から大きく開く 調音結合

By Qualiteg 研究部, Qualiteg コンサルティング
LLM推論基盤プロビジョニング講座 第3回 使用モデルの推論時消費メモリ見積もり

LLM推論基盤プロビジョニング講座 第3回 使用モデルの推論時消費メモリ見積もり

こんにちは!前回はLLMサービスへのリクエスト数見積もりについて解説しました。今回は7ステッププロセスの3番目、「使用モデルの推論時消費メモリ見積もり」について詳しく掘り下げていきます。 GPUメモリがリクエスト処理能力を決定する LLMサービス構築において、GPUが同時に処理できるリクエスト数はGPUメモリの消費量によって制約されます。 つまり、利用可能なGPUメモリがどれだけあるかによって、同時に何件のリクエストを処理できるかがほぼ決まります。 では、その具体例として、Llama3 8B(80億パラメータ)モデルをNVIDIA RTX A5000(24GB)にロードするケースを考えてみましょう。 このGPUには24GBのGPUメモリがありますが、すべてをリクエスト処理に使えるわけではありません。最初にモデル自体が一定量のメモリを消費し、残りの領域で実際のリクエスト処理を行います。 GPUメモリ消費の二大要素 GPUの消費メモリ量は主に以下の2つの要素によって決まります 1. モデルのフットプリント LLMをGPUに読み込んだときに最初に消費されるメモリ

By Qualiteg コンサルティング