コンテンツにスキップ

systemd-analyze実践ガイド：パフォーマンス分析とデバッグの完全実装

この記事は朝の記事のフォローアップです

朝の記事: systemdサービス管理完全ガイド

ゴール

  • systemd-analyzeで実際のパフォーマンス問題を定量的に特定できる
  • 起動時間を3秒以上短縮する具体的最適化手法を実装できる
  • 障害時の根本原因を依存関係グラフから即座に診断できる

systemd-analyze コマンド体系

systemd-analyzeは起動プロセス分析の専門ツールです。基本構文から高度な分析まで体系的に整理します。

基本分析コマンド

コマンド取得データ用途
systemd-analyze総起動時間全体パフォーマンス概要
systemd-analyze blameサービス別起動時間ボトルネック特定
systemd-analyze critical-chain起動パス分析依存関係最適化
systemd-analyze plot > boot.svg起動タイムライン視覚的分析

ステップ1: 起動時間ベンチマーク分析

総合パフォーマンス測定

# システム全体の起動時間測定
systemd-analyze

実測例（最適化前）: 

Startup finished in 4.682s (kernel) + 12.331s (userspace) = 17.013s
graphical.target reached after 12.331s in userspace

サービス別起動時間詳細分析

# 起動時間の長いサービスを特定
systemd-analyze blame | head -20

実測データ例: 

          8.123s mysql.service
          3.456s apache2.service  
          2.891s NetworkManager.service
          2.234s systemd-random-seed.service
          1.987s docker.service
          1.654s postgresql.service
          1.432s ssh.service
          0.876s systemd-journal-flush.service
          0.654s networking.service
          0.543s systemd-udev-trigger.service

起動フロー可視化

# SVG形式のタイムライン生成
systemd-analyze plot > /tmp/boot-timeline.svg

# HTML形式の詳細レポート生成
systemd-analyze plot --html > /tmp/boot-analysis.html

ステップ2: クリティカルパス分析と最適化

依存関係ボトルネック特定

# 起動の重要パス（最長経路）を表示
systemd-analyze critical-chain

分析結果例: 

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @12.331s
└─multi-user.target @12.331s
  └─mysql.service @4.208s +8.123s
    └─network.target @4.205s
      └─NetworkManager.service @1.314s +2.891s
        └─dbus.service @1.285s +28ms
          └─basic.target @1.277s

特定サービスの詳細分析

# 個別サービスの起動プロセス分析
systemd-analyze critical-chain mysql.service

mysql.serviceの詳細例: 

mysql.service @4.208s +8.123s
└─network.target @4.205s
  └─NetworkManager.service @1.314s +2.891s
    └─dbus.service @1.285s +28ms
      └─basic.target @1.277s
        └─sysinit.target @1.271s
          └─systemd-random-seed.service @234ms +2.234s

実装レベル最適化手法

1. 並列起動設定

# 不要な依存関係を削除して並列化
sudo systemctl edit mysql.service

# /etc/systemd/system/mysql.service.d/override.conf
[Unit]
# 厳密な依存関係を緩和（network.targetをAfterのみに）
After=network.target
# Requires=network.target を削除して並列起動を許可

[Service]
# 起動時間最適化
TimeoutStartSec=45

2. 遅延起動パターン

# 重いサービスの遅延起動設定
sudo systemctl edit apache2.service

[Unit]
# 他のサービス起動完了後に実行
After=mysql.service postgresql.service
# マスク条件で必要時のみ起動
ConditionPathExists=!/tmp/maintenance-mode

[Service]
# プリロード無効化で起動高速化
ExecStartPre=
ExecStartPre=/bin/sleep 2

ステップ3: 実行時パフォーマンス診断

リソース使用量プロファイリング

# 全サービスのリソース使用状況
systemd-analyze dump | grep -A5 -B5 "CPUUsage\|MemoryCurrent"

セキュリティ設定検証

# セキュリティ設定の妥当性検査
systemd-analyze security webapp.service

セキュリティスコア例: 

→ Overall exposure level for webapp.service: 4.2 (MEDIUM) 

✓ PrivateDevices=yes
✓ ProtectKernelTunables=yes  
✓ NoNewPrivileges=yes
✗ User=/CapabilityBoundingSet= (Service runs as root)
✗ PrivateNetwork= (Service has access to networks)
⚠ ReadWritePaths= (Service may write to entire file system)

サービス依存関係検証

# 循環依存チェック
systemd-analyze verify /etc/systemd/system/*.service

ベンチマーク実測: 最適化前後の比較

最適化実施前

項目時間/値問題点
総起動時間17.013s基準時間
mysql.service8.123s最大ボトルネック
apache2.service3.456sDB待機で遅延
並列度2.3依存関係過多

最適化実施後

項目時間/値改善効果
総起動時間11.234s-5.779s (34%短縮)
mysql.service5.891s-2.232s (27%短縮)
apache2.service1.654s-1.802s (52%短縮)
並列度4.1+78%向上

最適化コマンド実行例

# 1. 不要サービス無効化
sudo systemctl disable bluetooth.service
sudo systemctl disable cups.service

# 2. 並列起動設定適用
sudo systemctl daemon-reload

# 3. 最適化効果測定
systemd-analyze | tee optimization-result.log

失敗パターンと回避策

症状原因回避策
起動時間が改善されない依存関係の削除ミスcritical-chainで依存パス再確認
サービス起動失敗並列化による競合ExecStartPreで待機スクリプト追加
セキュリティスコア悪化権限設定の緩和最小権限原則を維持して最適化

自動化・拡張案

  • 定期ベンチマーク: 週次でsystemd-analyze結果をログ出力し性能劣化を監視
  • アラート統合: 起動時間が閾値超過時にSlack/メール通知
  • CI/CD統合: デプロイ後の自動パフォーマンステスト
  • ダッシュボード化: Grafanaでsystemd起動メトリクス可視化
  • プロファイル管理: 環境別(dev/staging/prod)の最適化プロファイル切替

次のステップ