[Linux] Faster Startup Times with Oracle Linux 7

原文はこちら。
https://blogs.oracle.com/linuxkernel/faster-startup-times-with-oracle-linux-7

---

Steve Sistareは、Oracleのカーネル開発アーキテクトです。 このエントリでは、システムの起動を高速化するためのヒントとテクニックを紹介します。

10月にPasha Tatashinが、特に大規模なシステム向けに、カーネルの起動を大幅に高速化するという成果をブログで公開しました。

Accelerating Linux Boot Time
https://blogs.oracle.com/linuxkernel/accelerating-linux-boot-time

しかし、カーネルの起動は、作業の一部にすぎません。というのも、ユーザランドでサービスを開始する必要があるためです。とはいえ、起動時間は重要なものであり、設定に依存します。Oracle Linuxは、デフォルトで幅広い要件を満たすように構成されていますが、構成を調整すれば、起動時間を大幅に短縮できます。

Silence the console

設定できる単一の改善ポイントは、カーネルのコマンドラインを "quiet"に設定することです。これにより、カーネルのメッセージがコンソールに表示されなくなります。これらのメッセージは、コンソールが低ボーレート設定のシリアルインターフェイス経由で接続されているときに、起動中に長時間かかることがあります。Oracle Linux 7を実行するx86システムではデフォルトのILOMシリアルコンソール速度が9600ボーなので、quietオプションを有効にすると、systemd-analyzeによって報告されたkernel + initrd + userspace時間が62.259秒から21.425秒に短縮されました。代わりにシリアルレートを115200ボーに増やすことができますが、それは面倒な作業を伴います。ILOM、BIOS、GRUB、およびカーネルのコマンドライン引数でシリアルレートを変更する必要があります。その設定をしたとしても、115200ボーよりもquietのほうが数秒速いです。また、カーネルメッセージは失われません。カーネルが正常に起動した場合には、dmesgとjournalコマンドで閲覧できます！失敗時にカーネルの出力を見る必要があるカーネル開発時は、quietを使用しないでください。最後に、（エミュレートされたコンソールデバイスとは対照的に）準仮想化コンソールデバイスを使用するVMをブートする場合、シリアルボーレートによって制限されないため、quietではほとんど改善されません。

quietオプションを有効化するには…

• /etc/default/grubを編集
• GRUB_CMDLINE_LINUX 文字列に"quiet"を追加
• "grub2-mkconfig -o /boot/grub2/grub.cfg"を実行

Use up-to-date packages

可能な限り最新のOracle Linuxアップデートを使用して、最新のパッケージと最適化を入手してください。たとえば、古いバージョンのNetworkManagerパッケージには、余計な「キャリア待機」タイムアウトが有効になっていて、起動を5秒遅らせるバグがありました。これはOL7.4で修正されました。同様に、グラフィカルコンソールを持たないKVMゲストで、kbdパッケージがPUT_FONT ioctlが成功するために5秒間待機していたため、待ち時間は無駄でした。さらに悪いことに、これはinitdブートフェーズ中、userspaceフェーズ中にそれぞれ1回ずつ発生し、結果として10秒の遅延が発生しました。これもOL7.4で修正されています。

Tune grub

grubの遅延を減らすか、またはなくしましょう。デフォルトでは、grubは5秒間休止するので、別のカーネルを選択したり、カーネルパラメータを変更することができますが、これは設定可能です。緊急時にこの補助が必要な場合は1に設定します。 KVMで実行している場合は0に設定します。カーネルのブートに失敗したときに、ゲストイメージを手動でマウントしてgrubファイルを直接編集するなど、パラメータを変更する他の方法があります。

タイムアウト設定を変更するには…

• /etc/default/grubを編集
• GRUB_TIMEOUT=5 を GRUB_TIMEOUT=1 (または 0)に変更
• "grub2-mkconfig -o /boot/grub2/grub.cfg"を実行

Check autofs

autofsが正しく設定されていることを確認しましょう。/etc/nsswitch.confのautomountエントリが誤って設定されていると、このパッケージの最近の変更によりブート時に10秒の遅延が発生し、"automount[969]: problem reading master map, maximum wait exceeded"（automount [969]：マスターマップの読み込みに問題があり、最大待機時間を超過しました）というメッセージがジャーナルに記録されます。詳細については以下のURLを参照してください。

[ANNOUNCE] autofs 5.1.3 release
https://lkml.org/lkml/2017/5/26/64

上記のTipsに従った後、私たちがどうやっているかを見てみましょう。systemd-analyzeコマンドを使用して、全体の起動時間と最上位のサービスが使用した時間を確認します。ここでは、Intel Xeon Platinum CPU上のOL7.4 KVMゲストを起動します。

<... boot and login to the console ...>

# systemd-analyze
Startup finished in 697ms (kernel) + 879ms (initrd) + 3.877s (userspace) = 5.454s

# systemd-analyze blame
           1.799s kdump.service
           1.166s NetworkManager-wait-online.service
           396ms postfix.service
           321ms network.service
           247ms systemd-udev-settle.service
           244ms tuned.service
           151ms dev-mapper-ol\x2droot.device
           148ms lvm2-monitor.service
           119ms lvm2-pvscan@251:2.service
          113ms plymouth-quit.service
           112ms plymouth-quit-wait.service
           104ms systemd-vconsole-setup.service
           ...

Tune the bridge

次に、ホストとゲスト間はブリッジインターフェイスでKVMを使用しており、ネットワークトポロジにループがないことがわかっている場合は、ブリッジ上のSTP（Spanning Tree Protocol）を無効にします。これにより、2秒以上のゲストブート時間が節約されます。STPが有効の場合、ブリッジは、転送遅延が切れるまで、新しく検出されたアドレスから受信したすべてのパケットをドロップします。これは、ループが存在するときにパケットのフラッディングを回避するためです。したがって、ゲストのDHCP要求パケットは廃棄され、dhclientタイムアウトと再試行につながります。

ブリッジを確認するには…

# brctl show
    bridge name     bridge id               STP enabled     interfaces
    virbr0          8000.525400fe7ca3       yes             virbr0-nic

転送遅延を確認するには…

# brctl showstp virbr0 | grep forward
    forward delay       2.00       bridge forward delay       2.00

STPを無効化するには…

# brctl stp virbr0 off

libvirtをお使いの場合、デフォルトの設定でSTPを無効化し、変更を永続化するためにホストを再起動します。

# virsh net-edit default
"<bridge name='virbr0' stp='on' delay='0'/>を見つけて、onをoffに変更

（一見すると、delay = '0'で問題が解決すると思うかもしれませんが、カーネルは最小値2秒を強制します）。

STPを無効にすると、起動時間は以下のようになりました。DHCPの遅延をなくしたため、NetworkManager-wait-onlineの時間がはるかに小さいことに着目してください。

$ systemd-analyze
Startup finished in 678ms (kernel) + 903ms (initrd) + 2.746s (userspace) = 4.328s
$ systemd-analyze blame 
          1.700s kdump.service
           397ms postfix.service
           294ms network.service
           252ms systemd-udev-settle.service
           206ms tuned.service
           203ms dev-mapper-ol\x2droot.device
           168ms NetworkManager-wait-online.service
           157ms plymouth-quit-wait.service
           157ms plymouth-quit.service
           135ms lvm2-monitor.service
            95ms systemd-vconsole-setup.service
           ...

Disable optional services

"systemctl disable <name.service>"を使用して、不要なサービスを無効にします。 上記のように、"systemd-analyze blame"コマンドを使用して候補を表示しましょう。たとえば、パニック後にカーネルクラッシュダンプを取得する必要がない場合や、問題が発生して初めて有効化したい場合は、kdump.serviceを無効にすると、起動時間が約2秒短縮されます。メールサーバーを実行していない場合は、postfix.serviceを無効にします。tuned.serviceは目立つチューニングをしていないと確信しているなら、無効にしましょう。

全部まとめると、こんな感じです。

$ systemctl disable kdump.service
$ systemctl disable postfix.service
$ systemctl disable tuned.service

<... 再起動してコンソールにログイン ...>

$ systemd-analyze
Startup finished in 681ms (kernel) + 863ms (initrd) + 1.136s (userspace) = 2.681s

$ systemd-analyze blame
           299ms network.service
           273ms systemd-udev-settle.service
           178ms dev-mapper-ol\x2droot.device
           160ms NetworkManager-wait-online.service
           149ms lvm2-monitor.service
           148ms plymouth-quit-wait.service
           136ms plymouth-quit.service
            94ms systemd-vconsole-setup.service
           ...