よっしー
こんにちは。よっしーです(^^)
本日は、Go言語のパフォーマンス分析ついて解説しています。
スポンサーリンク
背景
Go言語でアプリケーションを開発していると、必ずと言っていいほど直面するのがパフォーマンスの問題や予期しないバグです。「なぜこんなにメモリを消費しているのか？」「どこで処理が遅くなっているのか？」「このゴルーチンはなぜデッドロックしているのか？」—— こうした疑問に答えるために、Goのエコシステムには強力な診断ツール群が用意されています。
しかし、これらのツールは種類が多く、それぞれ異なる目的と特性を持っているため、どのような場面でどのツールを使うべきか迷ってしまうことも少なくありません。プロファイリング、トレーシング、デバッギング、ランタイム統計…それぞれのツールが解決できる問題は異なり、時には相互に干渉し合うこともあります。
本記事では、Go公式ドキュメントの診断ツールに関する解説を日本語で紹介しながら、実際の開発現場でどのように活用できるかを探っていきます。適切なツールを選択し、効果的に問題を診断することで、より高品質で高性能なGoアプリケーションの開発が可能になるはずです。特に、パフォーマンスのボトルネックを特定し改善することは、ユーザー体験の向上やインフラコストの削減に直結する重要なスキルと言えるでしょう。
Goプログラムで事後分析デバッグは可能ですか？
コアダンプファイルは、実行中のプロセスのメモリダンプとそのプロセス状態を含むファイルです。主にプログラムの事後分析デバッグと、実行中の状態を理解するために使用されます。これら2つのケースにより、コアダンプのデバッグは、本番サービスの事後分析と分析のための優れた診断支援となります。Goプログラムからコアファイルを取得し、delveまたはgdbを使用してデバッグすることが可能です。ステップバイステップガイドについては、コアダンプデバッグページを参照してください。
事後分析デバッグ – プログラムの「検死解剖」
事後分析デバッグとは？
例え: 飛行機事故のブラックボックス解析や、事件現場の鑑識調査のようなもの
プログラムがクラッシュした後、その「遺体」（コアダンプ）を調べて原因を特定する作業です。
コアダンプとは何か？
プログラム実行中の完全なスナップショット：
┌─────────────────────────┐
│ メモリの内容 │
├─────────────────────────┤
│ 変数の値 │
├─────────────────────────┤
│ スタックトレース │
├─────────────────────────┤
│ レジスタの状態 │
├─────────────────────────┤
│ ゴルーチンの情報 │
└─────────────────────────┘
コアダンプを生成する方法
1. 環境変数の設定
# GOTRACEBACK設定値と効果
export GOTRACEBACK=crash # コアダンプを生成
# その他の設定値
# GOTRACEBACK=none # パニック情報なし
# GOTRACEBACK=single # 現在のゴルーチンのみ（デフォルト）
# GOTRACEBACK=all # 全ゴルーチンのスタック
# GOTRACEBACK=system # システムゴルーチンも含む
# GOTRACEBACK=crash # コアダンプ生成
2. プログラムでの設定
package main
import (
"fmt"
"os"
"runtime/debug"
)
func init() {
// プログラム内でコアダンプを有効化
debug.SetTraceback("crash")
}
func problematicFunction(data []int) {
// 意図的にパニックを起こす
fmt.Println(data[100]) // index out of range
}
func main() {
// コアダンプのサイズ制限を解除（Linux）
// ulimit -c unlimited と同等
data := []int{1, 2, 3}
problematicFunction(data)
}
コアダンプの取得と準備
Linux環境での設定
# コアダンプのサイズ制限を確認
$ ulimit -c
0 # 0の場合、コアダンプが生成されない
# 制限を解除
$ ulimit -c unlimited
# コアダンプの保存場所を設定
$ sudo sysctl kernel.core_pattern=/tmp/core-%e-%p-%t
# %e: 実行ファイル名
# %p: プロセスID
# %t: タイムスタンプ
# 確認
$ cat /proc/sys/kernel/core_pattern
/tmp/core-%e-%p-%t
macOS環境での設定
# コアダンプを有効化
$ sudo sysctl kern.coredump=1
# 保存場所の確認
$ sysctl kern.corefile
kern.corefile: /cores/core.%P
# サイズ制限解除
$ ulimit -c unlimited
Delveでの事後分析デバッグ
基本的な手順
# プログラムのクラッシュ
$ GOTRACEBACK=crash ./myapp
panic: runtime error: index out of range [100] with length 3
goroutine 1 [running]:
main.problematicFunction(...)
/home/user/myapp/main.go:15
main.main()
/home/user/myapp/main.go:20 +0x45
Aborted (core dumped)
# コアダンプファイルの確認
$ ls /tmp/core-*
/tmp/core-myapp-12345-1634567890
# Delveでコアダンプを開く
$ dlv core ./myapp /tmp/core-myapp-12345-1634567890
Delveでの調査
(dlv) bt # バックトレース
0 0x0000000000463741 in runtime.raise
1 0x0000000000447e65 in runtime.dieFromSignal
2 0x0000000000447f4e in runtime.sigfwdgo
3 0x00000000004476a9 in runtime.sigtrampgo
4 0x0000000000461c90 in runtime.sigtramp
5 0x00000000004a3456 in main.problematicFunction
at ./main.go:15
6 0x00000000004a3567 in main.main
at ./main.go:20
(dlv) frame 5 # 問題のフレームに移動
> runtime.raise() runtime/sys_linux_amd64.s:150 (PC: 0x463741)
Frame 5: ./main.go:15 (PC: 4a3456)
(dlv) locals # ローカル変数を確認
data = []int len: 3, cap: 3, [1,2,3]
(dlv) print data[100] # 問題の原因を確認
panic: runtime error: index out of range [100]
(dlv) goroutines # 全ゴルーチンの確認
[8 goroutines]
* Goroutine 1 - User: ./main.go:15 main.problematicFunction
Goroutine 2 - User: runtime/proc.go:363 runtime.gopark
...
GDBでの事後分析
# GDBでコアダンプを開く
$ gdb ./myapp /tmp/core-myapp-12345
(gdb) bt # バックトレース
#0 runtime.raise () at runtime/sys_linux_amd64.s:150
#1 main.problematicFunction () at main.go:15
#2 main.main () at main.go:20
(gdb) frame 1 # フレーム1に移動
#1 main.problematicFunction () at main.go:15
(gdb) info locals # ローカル変数
data = {array = 0xc000010240, len = 3, cap = 3}
(gdb) p data # 変数の内容を表示
$1 = {array = 0xc000010240, len = 3, cap = 3}
実践的な事後分析シナリオ
シナリオ1: メモリリークの調査
package main
import (
"fmt"
"runtime"
"time"
)
type BigData struct {
data [1024 * 1024]byte // 1MB
next *BigData
}
var leaked []*BigData
func leakyFunction() {
for i := 0; i < 1000; i++ {
bd := &BigData{}
leaked = append(leaked, bd)
if i == 999 {
// メモリ状態を記録してクラッシュ
var m runtime.MemStats
runtime.ReadMemStats(&m)
panic(fmt.Sprintf("Memory leak detected: Alloc=%v MB",
m.Alloc/1024/1024))
}
}
}
func main() {
leakyFunction()
}
コアダンプから調査：
$ dlv core ./leaky core.12345
(dlv) print leaked
[]main.BigData len: 1000, cap: 1024, [...]
(dlv) print len(leaked)
1000
(dlv) print leaked[0]
main.BigData {
data: [1048576]uint8 [0,0,0,...],
next: *main.BigData nil
}
シナリオ2: デッドロックの調査
package main
import (
"sync"
"time"
)
func deadlockExample() {
var mu1, mu2 sync.Mutex
go func() {
mu1.Lock()
time.Sleep(100 * time.Millisecond)
mu2.Lock() // デッドロック
mu2.Unlock()
mu1.Unlock()
}()
go func() {
mu2.Lock()
time.Sleep(100 * time.Millisecond)
mu1.Lock() // デッドロック
mu1.Unlock()
mu2.Unlock()
}()
time.Sleep(5 * time.Second)
panic("Deadlock detected!")
}
本番環境での活用
自動コアダンプ収集システム
#!/bin/bash
# collect_coredumps.sh
CORE_DIR="/var/coredumps"
ARCHIVE_DIR="/var/coredumps/archive"
MAX_CORES=10
# コアダンプの収集
collect_core() {
local corefile=$1
local binary=$2
local timestamp=$(date +%Y%m%d_%H%M%S)
# メタデータ収集
cat > "${corefile}.info" <<EOF
Timestamp: ${timestamp}
Binary: ${binary}
Hostname: $(hostname)
Kernel: $(uname -r)
Memory: $(free -h)
EOF
# 圧縮して保存
tar czf "${ARCHIVE_DIR}/core_${timestamp}.tar.gz" \
"${corefile}" "${corefile}.info" "${binary}"
# 古いコアダンプを削除
find ${ARCHIVE_DIR} -name "core_*.tar.gz" -mtime +7 -delete
}
# 監視ループ
inotifywait -m ${CORE_DIR} -e create |
while read dir action file; do
if [[ "$file" =~ ^core-.* ]]; then
echo "New core dump detected: $file"
collect_core "${dir}/${file}" "/usr/local/bin/myapp"
# アラート送信
send_alert "Core dump generated: $file"
fi
done
トラブルシューティングガイド
コアダンプが生成されない場合
# チェックリスト
□ ulimit -c unlimited を実行したか？
□ GOTRACEBACK=crash を設定したか？
□ ディスク容量は十分か？
□ 書き込み権限はあるか？
□ systemdの設定は正しいか？
# systemdサービスの場合
[Service]
LimitCORE=infinity
Environment="GOTRACEBACK=crash"
コアダンプが大きすぎる場合
// メモリ使用量を制限
import "runtime/debug"
func init() {
// 最大ヒープサイズを1GBに制限
debug.SetMemoryLimit(1 << 30)
}
ベストプラクティス
- 本番環境での準備
production_settings: core_dumps: enabled storage: dedicated_volume retention: 7_days compression: gzip alerts: enabled - デバッグ情報の保持
# ビルド時にデバッグ情報を保持 go build -gcflags="all=-N -l" -o myapp.debug # 本番用は軽量化 go build -ldflags="-s -w" -o myapp # デバッグ時は.debugバイナリを使用 dlv core myapp.debug core.12345 - 自動分析スクリプト
# analyze_core.sh #!/bin/bash dlv core $1 $2 <<EOF | tee analysis.txt bt goroutines stack -full exit EOF
メトリクスとモニタリング
// コアダンプ生成を検知して通知
package monitor
import (
"os"
"path/filepath"
"time"
)
func MonitorCoreFiles(dir string) {
ticker := time.NewTicker(1 * time.Minute)
defer ticker.Stop()
for range ticker.C {
files, _ := filepath.Glob(filepath.Join(dir, "core-*"))
if len(files) > 0 {
// アラート送信
sendAlert("Core dumps detected", files)
// メトリクス更新
updateMetrics("core_dumps_total", len(files))
}
}
}
事後分析デバッグは、本番環境で発生した問題を「タイムマシン」のように遡って調査できる強力な手法です。適切に設定しておけば、深夜のクラッシュも翌朝ゆっくり分析できます！
おわりに
本日は、Go言語のパフォーマンス分析について解説しました。
よっしー
何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。
それでは、また明日お会いしましょう(^^)
コメント