8.6. カーネル

大規模なシステムでは、システム起動が失敗することがある

起動プロセス時に、udev デバイスマネージャーにより、大規模なシステム上に非常に多くのルールが生成されることがあります。たとえば、32 TB のメモリーと 192 CPU のシステムでこの問題が発生しています。これにより、システムの起動プロセスが応答しなくなるか、タイムアウトになり、緊急シェルに切り替わります。

この問題を回避するには、udev.children-max の値を増やします。

  1. udev.children-max=1000 オプションを、/etc/default/grub ファイルのカーネルコマンドラインに追加します。udev.renrenren-max で別の値を試して、システムで最も速い起動になる値を確認してください。
  2. kdump カーネルの udev.children-max 値を制限します。

    /etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_REMOVE 行に udev.children-max オプションを追加します。

    kdump オプションを指定しないと、システムは、IBM POWER システムで kdump または fadump がキャプチャーした後に緊急モードに入る場合があります。

  3. kdump サービスを再起動します。

    # systemctl restart kdump

これにより、システムが正常に起動するようになります。

(BZ#1722855)

mirror セグメントの種類により、スタック化された設定でシステムのデッドロックが発生

mirror セグメントの種類を使用して、その上に論理ボリュームを配置すると、スタック済みの設定でシステムのデッドロックが発生します。この問題を回避するために、Red Hat は、セグメントタイプ raid1 で、RAID 1 論理ボリュームを使用することを推奨します。

mirror デバイスを raid1 に変換するには、ミラー化 LVM デバイスの RAID1 デバイスへの変換 を参照してください。

(BZ#1772107)

zlib 圧縮形式により vmcore キャプチャーが遅くなる可能性がある

kdump 設定ファイルは、デフォルトで lzo 圧縮形式 (makedumpfile -l) を使用します。zlib 圧縮形式 (makedumpfile -c) を使用するように設定ファイルを変更すると、vmcore キャプチャープロセスの速度が遅くなるため、圧縮要因が向上する可能性が高くなります。これにより、zliblzo と比較されると、kdump の約 4 倍の時間で vmcore をキャプチャーできます。これにより、速度が主な要因である場合に、Red Hat はデフォルトの lzo を使用することを推奨します。ただし、ターゲットマシンで利用可能な領域が少ない場合は、zlib の方が適しています。

(BZ#1737111)

Bridge-over-VLAN トポロジーの使用時に、ice ドライバーを使用する Intel ネットワークデバイスがトラフィックを通過しない

Eathernet デバイスでは、以下の条件すべてを満たしている場合には、Internet Control Message Protocol (ICMP) の echo 要求および応答トラフィックが送信されません。

  • Eathernet デバイスが ice Intel ドライバーを使用する。
  • Ethernet デバイスがブリッジのメンバーである。
  • ブリッジが 802.1Q プロトコルに準拠した VLAN タグ付けを使用する

これにより、ネットワークインターフェイスコントローラー (NIC) は上記のネットワークトポロジーへのトラフィックを通過させません。この問題に対する回避策はありません。

(BZ#1787295)