【現場上級クラス】Linux_sysctl_iostat_systemd_研修PPT

Linuxサーバー管理 完全基礎 sysctl / iostat / システム起動原理 LPIC Level 2 準拠 ｜ 第二新卒エンジニア育成カリキュラム ｜ 2026

本日のアジェンダ PART 1 システム起動原理（BIOS→GRUB→systemd） PART 2 sysctl — カーネルパラメータ管理 PART 3 iostat — I/Oパフォーマンス計測 PART 4 systemd / サービス永続化 PART 5 クイズ総合演習（全10問）

Power ON → カーネル → systemd の全フロー PART 1 ｜ システム起動原理

Linux システム起動フロー（完全版） 1. BIOS/UEFI ハードウェア初期化 (POST)。ブートデバイスを探索する。 2. GRUB2 ブートローダー。カーネルイメージ(vmlinuz)と initrd を RAM へ展開。 3. カーネル initramfs でルートFS検出。システムコール・デバイスドライバ初期化。 4. systemd (PID 1) 全サービスの親プロセス。ユニットファイルを解析しターゲットへ到達。 5. ターゲット達成 multi-user.target / graphical.target に到達 → ログインプロンプト表示。

GRUB2 — 重要ファイルと設定 # GRUB2 設定ファイル（自動生成 — 直接編集しない） /boot/grub2/grub.cfg # 編集するのはこちら（テンプレート） /etc/default/grub GRUB_TIMEOUT=5 # 起動メニュー表示秒数 GRUB_CMDLINE_LINUX="..." # カーネル起動オプション # 設定を grub.cfg に反映（AlmaLinux/RHEL 系） sudo grub2-mkconfig -o /boot/grub2/grub.cfg # UEFI 環境の場合 sudo grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg # カーネル一覧確認 sudo grubby --info=ALL | grep "^kernel" 試験ポイント : grub.cfg は自動生成 — 直接編集すると上書きで消える

initramfs（初期RAMディスク）の役割 # initramfs = 仮の root ファイルシステム（RAMに展開） # 目的: 本物のrootFS(/, /etc, /home...)をマウントするための橋渡し # initramfs の内容確認 lsinitrd /boot/initramfs-$(uname -r).img | head -30 # initramfs を再生成（カーネル更新後など） sudo dracut --force # なぜ必要か？ # /proc /sys /dev が存在しない状態でカーネルが起動する # → initramfs に最低限のドライバ・ユーティリティを格納 # → rootFS (/, ext4/xfs) をマウントできる状態を作る # → 本物の / に switch_root で移行 # カーネルバージョン確認 uname -r # 例: 5.14.0-427.13.1.el9_4.x86_64 試験ポイント : dracut (RHEL 系) vs mkinitcpio (Arch) vs update-initramfs (Debian)

systemd ターゲット（旧 runlevel 対応表） 旧 runlevel systemd ターゲット 説明 0 poweroff.target シャットダウン 1 rescue.target シングルユーザーモード（メンテナン ス） 3 multi-user.target テキストモード（サーバー標準） 5 graphical.target GUI付きマルチユーザー 6 reboot.target 再起動

クイズ Q1 Linuxのシステム起動において、systemd が起動する直前に実行されるプロセスはどれか？ A) GRUB2 ブートローダー B) カーネル (vmlinuz) C) initramfs 内のshell D) getty（ログインプロンプト） 正解: B) カーネル (vmlinuz) 起動順序: BIOS/UEFI → GRUB2 → カーネル → systemd (PID 1)。 GRUB2 がカーネルを RAM にロードし、カーネルが初期化後に /sbin/init（= systemd）を呼び出す。

クイズ Q2 systemctl enable httpd を実行したとき、実際に作成されるものは何か？ A) httpd の設定ファイル /etc/httpd/conf/httpd.conf B) /etc/systemd/system/multi-user.target.wants/ 以下の シンボリックリンク C) /usr/lib/systemd/system/httpd.service の新規作成 D) crontab への @reboot エントリ 正解: B) シンボリックリンク（multi-user.target.wants/httpd.service） enable はシンボリックリンクを作成するだけ。 disable はそのリンクを削除する。start/stop は現在のセッションのみに影響し、リンクは変更しない。

カーネルパラメータをランタイムで操作する PART 2 ｜ sysctl

sysctl とは何か ■ 定義 実行中の Linux カーネルのパラメータを読み書きするインターフェース。 再起動不要でカーネル動作をチューニングできる。 ■ /proc/sys との関係 sysctl は /proc/sys/ 以下のファイルを操作するラッパー。 例: net.ipv4.ip_forward ←→ /proc/sys/net/ipv4/ip_forward ■ 主なカテゴリ kernel.* — カーネル全般（hostname, pid_max, panic など） net.* — ネットワークスタック（フォワーディング, バッファサイズ） vm.* — 仮想メモリ管理（swappiness, dirty_ratio） fs.* — ファイルシステム（file-max, inotify）

sysctl — 基本コマンド操作 # 全パラメータ一覧 sysctl -a # 特定パラメータ確認 sysctl net.ipv4.ip_forward sysctl kernel.hostname # 一時変更（再起動で元に戻る） sudo sysctl -w net.ipv4.ip_forward=1 sudo sysctl -w net.core.somaxconn=1024 # /proc/sys 経由での直接確認（同等） cat /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv4/ip_forward # root のみ # 永続化（再起動後も有効） sudo vim /etc/sysctl.conf # または sudo vim /etc/sysctl.d/99-custom.conf # ← 推奨（ファイル分離） # 設定ファイルを即時反映 試験ポイント : -w は一時変更、 -p は設定ファイル反映。 /etc/sysctl.d/*.conf は数字順に処理される sudo sysctl -p # /etc/sysctl.conf を読む

sysctl — 重要パラメータ一覧（試験頻出） # ネットワーク net.ipv4.ip_forward = 1 # IPルーティング有効（ルーター/NAT に必須） net.ipv4.tcp_syncookies = 1 # SYN Flood 攻撃対策 net.core.somaxconn = 1024 # TCP バックログキューの最大数 net.ipv4.tcp_max_syn_backlog = 2048 net.core.rmem_max = 16777216 # 受信バッファ最大サイズ（byte） net.core.wmem_max = 16777216 # 送信バッファ最大サイズ # 仮想メモリ vm.swappiness = 10 vm.dirty_ratio = 20 vm.overcommit_memory = 1 # スワップ使用の積極度（0=使わない, 100=積極的） # ダーティページが全RAMの20%に達したら書き込み # メモリ過剰コミット許可（Redisなど向け） # カーネル kernel.pid_max = 65536 kernel.panic = 30 kernel.sysrq = 0 # 最大PID数 # パニック後30秒で自動再起動 # Magic SysRq 無効（本番推奨） # ファイルシステム fs.file-max = 2097152 # 全プロセス合計のオープン可能ファイル数上限 vm.swappiness=0 はスワップ禁止ではなくOOMを優先させる設定（誤解多い）

sysctl — セキュリティ強化設定例（/etc/sysctl.d/） # /etc/sysctl.d/99-security.conf # IPv4 フォワーディング無効（一般サーバー） net.ipv4.ip_forward = 0 # ソースルーティング拒否 net.ipv4.conf.all.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 # ICMP リダイレクト無視 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 # SYN Cookie（SYN Flood対策） net.ipv4.tcp_syncookies = 1 # ブロードキャスト ping 無視（Smurf 攻撃対策） net.ipv4.icmp_echo_ignore_broadcasts = 1 # ログ: 不正パケット net.ipv4.conf.all.log_martians = 1 CIS Benchmark や DISA STIG でも同様の設定が要求される

クイズ Q3 sysctl -w net.ipv4.ip_forward=1 を実行した。再起動後も有効にするために必要な操作はどれか？ A) /etc/sysctl.conf に net.ipv4.ip_forward=1 を記載し sysctl -p を実行 B) systemctl restart networking を実行する C) iptables -t nat -A POSTROUTING を実行する D) 再起動するだけで自動的に保存される 正解: A) /etc/sysctl.conf（または /etc/sysctl.d/*.conf）に追記して sysctl -p -w は一時変更のみ（再起動で消える）。永続化には設定ファイルへの記載が必要。 /etc/sysctl.d/99-*.conf に記載するのが現代的なベストプラクティス。

CPU / ディスクI/O パフォーマンスの計測と分析 PART 3 ｜ iostat

iostat とは何か ■ 定義 CPU 使用率とブロックデバイス（HDD/SSD/NVMe）の I/O 統計を表示するツール。 パッケージ: sysstat（sudo dnf install sysstat） ■ 何が分かるか • ディスクがボトルネックかどうか • 読み書きのスループット（MB/s） • 1秒あたりのI/O要求数（IOPS） • ディスクの利用率（%util） • I/O待ち時間（await ms） ■ いつ使うか • 「CPU は余裕があるのにサーバーが重い」 → I/O 待ち疑い • データベース・ログサーバーのパフォーマンス調査 • 本番ディスク交換前後の性能比較

iostat — 基本コマンドと出力 # インストール sudo dnf install -y sysstat sudo apt install sysstat # AlmaLinux/RHEL 系 # Ubuntu 系 # 基本実行（1回のみ） iostat # 拡張統計（-x）を2秒間隔で5回表示 iostat -x 2 5 # MB/s 単位で表示（-m） iostat -xm 2 # 特定デバイスのみ iostat -x sda 1 # 典型的な出力（-x オプション）: # Device r/s w/s rMB/s wMB/s # sda 10.2 45.3 0.5 2.1 # nvme0n1 ... rrqm/s 0.1 wrqm/s 5.2 await 3.1 iostat の最初の出力行は起動時からの累計値 — 定常状態を見るには2行目以降を参照 r_await 2.8 w_await 3.2 util% 8.5%

iostat -x 出力フィールド解説 フィールド 意味 判断基準 r/s 1秒あたりの読み込み要求数 (IOPS) HDD: ~100-200 IOPS / SSD: 数万 w/s 1秒あたりの書き込み要求数 (IOPS) 同上 rMB/s 読み込みスループット (MB/s) SATA SSD: ~500 MB/s wMB/s 書き込みスループット (MB/s) 同上 await I/O 待ち時間 (ms) — 平均応答時間 < 10ms: 正常 / > 50ms: 要注意 r_await 読み込みの応答時間 (ms) 同上 w_await 書き込みの応答時間 (ms) 同上 %util デバイス利用率 (%) < 70%: 正常 / > 90%: ボトルネック

iostat — 実務でのトラブルシューティング例 # シナリオ: DBサーバーが重い → iostat で確認 $ iostat -xm 2 Device sda r/s 5.2 w/s 820.5 rMB/s 0.1 wMB/s 120.3 await 85.2 %util 98.5 ← 危険 # 分析: # - %util = 98.5% → ディスクがほぼ飽和状態 # - await = 85.2ms → I/O 応答が遅い（正常は <10ms） # - wMB/s = 120 MB/s, w/s = 820 → 大量の小さい書き込みが発生 # 対策の方向性: # 1. ストレージを SSD/NVMe に変更 # 2. DB の write buffer を増加（innodb_buffer_pool_size） # 3. ログのローテーションポリシー見直し # 4. RAID や LVM ストライピングでスループット増強 # sar と組み合わせて傾向確認（sysstat が必要） sar -b 1 10 # ブロックI/O統計を1秒間隔で10回 sar -d 1 10 # デバイス別詳細 await が高いが %util が低い場合はネットワークストレージ (NFS/iSCSI) のレイテンシを疑う

クイズ Q4 iostat -x の出力で %util が 95% を超えている。このとき最も可能性が高い状況はどれか？ A) CPU がボトルネックになっている B) メモリが不足してスワップが発生している C) ディスクI/O が飽和しボトルネックになっている D) ネットワーク帯域が不足している 正解: C) ディスクI/O が飽和しボトルネックになっている %util はデバイスが処理に費やした時間の割合。 90%以上は飽和状態の目安。awarit (ms) も合わせて確認する。 CPU は mpstat/top、メモリは vmstat/free、ネットは sar -n DEV で確認する。

クイズ Q5 iostat の出力で最初の行の値が、その後の行と大きく異なることがある。理由はどれか？ A) iostat のバグである B) 最初の行はシステム起動からの累計統計値だから C) 最初の行は予測値だから D) デバイスが初期化中だから 正解: B) 最初の行はシステム起動からの累計統計値 iostat の初回出力はブート時からの累積平均。 リアルタイムの状況を見るには 2行目以降（インターバル指定）を参照する。 例: iostat -x 2 → 2秒ごとの差分値が出る

enable --now / firewalld --permanent の実践 PART 4 ｜ systemd & サービス永続化

systemd — アーキテクチャの全体像 ■ systemd = PID 1 全プロセスの親。カーネルが最初に起動するユーザー空間プロセス。 依存関係グラフに基づいて並列起動するため、SysVinit より高速。 ■ ユニット（Unit）の種類 • .service — サービスプロセス（httpd, sshd など） • .socket — ソケット起動（要求時に .service を起動） • .target — グループ化（multi-user.target など） • .timer — 定期実行（cron の代替） • .mount — マウントポイント管理 • .path — ファイルパス監視 ■ ユニットファイルの場所 /usr/lib/systemd/system/ ← パッケージ提供（編集しない） /etc/systemd/system/ ← 管理者カスタマイズ（優先）

systemctl — 完全コマンドリファレンス # 現在セッションのみ（再起動で元に戻る） sudo systemctl start httpd # 起動 sudo systemctl stop httpd # 停止 sudo systemctl restart httpd # 再起動（設定再読込） sudo systemctl reload httpd # プロセス維持で設定のみ再読込 # 永続設定（再起動後も有効） sudo systemctl enable httpd # 自動起動 ON sudo systemctl disable httpd # 自動起動 OFF sudo systemctl enable --now httpd # ★実務定番: 起動+自動起動を同時 # 状態確認 sudo systemctl status httpd # 詳細（Active + Loaded の両方） sudo systemctl is-active httpd # active / inactive sudo systemctl is-enabled httpd # enabled / disabled / static # システム全体 sudo systemctl list-units --type=service --state=running sudo systemctl list-unit-files --type=service | grep enabled sudo systemctl daemon-reload # ユニットファイル変更後に必須 sudo systemctl reboot / poweroff / halt — 設定変更後は必ず実行 daemon-reload を忘れると古いユニット定義が使われたまま

start / enable の 4 状態マトリクス（試験頻出） Active（現在） Enabled（次回） 状態説明 対処コマンド running enabled 理想状態 — 今も動き次回も動 く （何もしない） dead enabled 次回は起動するが今は停止中 systemctl start httpd running disabled 今は動いているが再起動で止ま る systemctl enable httpd dead disabled 今も動かず次回も起動しない systemctl enable --now httpd

firewalld — 永続化の正しいパターン # 間違い: 再起動で消える（メモリのみ変更） sudo firewall-cmd --add-service=http --zone=public # 正解パターン1: 永続 → reload で即時反映 sudo firewall-cmd --add-service=http --zone=public --permanent sudo firewall-cmd --reload # 正解パターン2: 即時反映 + 永続を別々に sudo firewall-cmd --add-service=http --zone=public # 即時 sudo firewall-cmd --add-service=http --zone=public --permanent # よく使うコマンド一覧 sudo firewall-cmd --list-all # ゾーンの全設定確認 sudo firewall-cmd --list-services # 許可サービス一覧 sudo firewall-cmd --get-active-zones # アクティブゾーン確認 sudo firewall-cmd --add-port=8080/tcp --permanent # ポート指定 sudo firewall-cmd --remove-service=http --permanent # 削除 sudo firewall-cmd --zone=public --query-service=http # firewalld が停止している場合 sudo systemctl enable --now firewalld --permanent は設定ファイル書き込みのみ。 --reload しないと現在のルールに反映されない

クイズ Q6 firewall-cmd --add-service=https --zone=public --permanent を実行した後、 設定を即時反映させるコマンドはどれか？ A) firewall-cmd --restart B) firewall-cmd --reload C) systemctl restart firewalld D) firewall-cmd --apply 正解: B) firewall-cmd --reload --reload は firewalld を再起動せずにルールセットだけを再読み込みする。 systemctl restart firewalld でも反映されるが既存セッションが切断される場合がある。 A/D は存在しないオプション。

クイズ Q7 システム管理者が systemctl enable --now nginx を実行した。 このコマンドの効果として正しいものはどれか？ A) nginx を今すぐ起動し、かつ次回起動時にも自動起 動するよう設定する B) nginx をインストールして起動する C) nginx を今すぐ起動するが、自動起動は設定しない D) nginx の設定ファイルを検証してから起動する 正解: A) 今すぐ起動（start）＋ 自動起動設定（enable）を1コマンドで実行 --now オプションを付けると enable (永続設定) と start (即時起動) を同時に行う。 インストールは dnf/apt が担当。設定検証は nginx -t コマンド。

実技試験レベルの総仕上げ PART 5 ｜ 総合クイズ演習

クイズ Q8 AlmaLinux 9 で GRUB2 の設定を変更した後に設定を反映させるコマンドはどれか？ A) grub-update B) grub2-mkconfig -o /boot/grub2/grub.cfg C) update-grub D) grub2-install /dev/sda 正解: B) grub2-mkconfig -o /boot/grub2/grub.cfg RHEL/AlmaLinux 系は grub2-mkconfig。Ubuntu/Debian 系は update-grub（内部で同じコマンドを呼ぶ）。 grub2-install はブートローダー本体をMBRに書き込むコマンド（設定反映ではない）。

クイズ Q9 次の sysctl 設定はどのような効果をもたらすか？ net.ipv4.tcp_syncookies = 1 A) TCP ポートのスキャンを記録する B) SYN Flood 攻撃に対する防御を有効にする C) 全TCPパケットのログを残す D) TCP タイムアウトを1秒に設定する 正解: B) SYN Flood 攻撃（DDoS）に対する防御（SYN Cookie）を有効にする SYN Flood攻撃: 大量の SYN パケットを送り込みサーバーの接続待ちキューを枯渇させる。 SYN Cookie: バックログ不使用でコネクション情報をクッキーに符号化することでキュー枯渇を回避する。 RFC 4987 参照。

クイズ Q10 本番サーバーのディスク性能を調査している。 `iostat -x 2 5` を実行したとき、分析すべき行はどれか？ A) 1行目のみ（累計値が正確） B) 2〜5行目（インターバルの差分値） C) 最後の5行目だけ（最新値） D) 全行の平均を手動計算する 正解: B) 2〜5行目（2秒ごとの差分値）を分析する iostat の1行目はシステム起動からの累計平均値（バイアスがかかっている）。 2行目以降が指定インターバルごとのリアルタイム差分値。 現状のI/O負荷を正確に把握するには 2行目以降を使う。

本日のまとめ — 必須知識チェックリスト 起動原理 BIOS→GRUB2→カーネル→initramfs→systemd(PID1)→ターゲット GRUB2 設定変更後は grub2-mkconfig で反映。grub.cfg は直接編集しない sysctl -w は一時変更。永続化は /etc/sysctl.d/*.conf に記載 → sysctl -p 重要パラメータ ip_forward=1(ルーター) / swappiness / somaxconn / syncookies iostat -x で拡張表示。%util>90% / await>50ms はボトルネックの目安 iostat注意 1行目は起動時からの累計。2行目以降がインターバル差分値 systemctl enable --now が実務定番（start + enable を同時実行） firewalld --permanent + --reload をセットで使う

参考資料 / 公式ドキュメント systemd 公式 https://learning.lpi.org/ja/learning-materials/102-500/108/108.2/ kernel.org — sysctl https://www.kernel.org/doc/html/latest/admin-guide/sysctl/ sysstat / iostat man page https://github.com/sysstat/sysstat firewalld 公式 https://firewalld.org/documentation/ LPIC-2 試験概要 https://www.lpi.org/ja/our-certifications/lpic-2-overview/ Linux Standard Base https://refspecs.linuxfoundation.org/lsb.shtml LPI-Japan 標準教科書 https://linuc.org/textbooks/server/ © 2026 Linux Training — LPIC Level 2 Curriculum

• https://learning.lpi.org/ja/learning-materials/102-500/108/108.2/
• https://www.kernel.org/doc/html/latest/admin-guide/sysctl/
• https://github.com/sysstat/sysstat
• https://firewalld.org/documentation/
• https://www.lpi.org/ja/our-certifications/lpic-2-overview/
• https://refspecs.linuxfoundation.org/lsb.shtml
• https://linuc.org/textbooks/server/