Red Hat Training

A Red Hat training course is available for RHEL 8

カーネルの管理、監視、更新 (機械翻訳)

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 8でLinuxカーネルを管理するためのガイド (機械翻訳)

Red Hat Customer Content Services

概要

この文書は、Linuxカーネルレベルでワークステーションを構成するために必要な情報をユーザーと管理者に提供します。このような調整により、パフォーマンスが向上し、トラブルシューティングが容易になり、システムが最適化されます。

Red Hat ドキュメントへのフィードバック (機械翻訳)

ご意見こ要望をお聞かせください。ドキュメントの改善点ございませんか。インストールするには、次を実行します。

  • 特定の文章に簡単なコメントを記入する場合は、ドキュメントが Multi-page HTML 形式になっ ているのを確認してください。コメントを追加する部分を強調表示し、そのテキストの下に表示される Add Feedback ポップアップをクリックし、表示された手順に従ってください。

  • より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

    1. Bugzilla の Web サイトにアクセスします。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 LinuxカーネルRPM (機械翻訳)

以下のセクションでは、Red Hatによって提供および管理されているLinuxカーネルRPMパッケージについて説明します。

1.1. RPMとは (機械翻訳)

RPMパッケージは、他のファイルとそのメタデータ（システムに必要なファイルに関する情報）を含むファイルです。

具体的には、RPMパッケージは cpio アーカイブ。

の cpio アーカイブに含まれるもの：

  • ファイル

  • RPMヘッダ（パッケージメタデータ）

    の rpm パッケージマネージャはこのメタデータを使って依存関係、ファイルのインストール先、その他の情報を決定します。

RPMパッケージの種類

RPMパッケージには2種類あります。どちらのタイプもファイル形式とツールを共有していますが、内容が異なり、目的も異なります。

  • ソースRPM（SRPM）

    SRPMには、ソースコードとSPECファイルが含まれています。SPECファイルには、ソースコードをバイナリRPMに構築する方法が記載されています。オプションで、ソースコードへのパッチも含まれています。

  • バイナリRPM

    バイナリRPMには、ソースとパッチから構築されたバイナリが含まれています。

1.2. LinuxカーネルRPMパッケージの概要 (機械翻訳)

の kernel RPMはファイルを含まないメタパッケージですが、次のサブパッケージが正しくインストールされていることを確認します。

  • kernel-core - コア機能に必要な最小限のカーネルモジュールが含まれています。このサブパッケージだけで、仮想化されたクラウド環境でRed Hat Enterprise Linux 8カーネルに短い起動時間と小さなディスクサイズのフットプリントを提供することができます。
  • kernel-modules - さらなるカーネルモジュールを含みます。
  • kernel-modules-extra - まれなハードウェア用のカーネルモジュールが含まれています。

小さい方 kernel サブパッケージは、特に仮想化およびクラウド環境において、システム管理者にメンテナンス面を減らすことを目的としています。

1.3. カーネルパッケージの内容を表示する (機械翻訳)

次の手順では、カーネルパッケージとそのサブパッケージの内容を、それらを使用してインストールせずに表示する方法について説明します。 rpm コマンド。

前提条件

  • CPU アーキテクチャー用に、RPM パッケージ kernel、kernel-core、kernel-modules、kernel-modules-extra を取得している。

手順

  • のリストモジュール kernel： 

    $ rpm -qlp <kernel_rpm> （ファイルは含まれていません）…

  • のリストモジュール kernel-core： 

    $ rpm -qlp <kernel-core_rpm> …​ /lib/modules/4.18.0-80.el8.x86_64/kernel/fs/udf/udf.ko.xz /lib/modules/4.18.0-80.el8.x86_64/kernel/fs/xfs / lib / modules /4.18.0-80.el8.x86_64/kernel/fs/xfs/xfs.ko.xz /lib/modules/4.18.0-80.el8.x86_64/kernel/kernel /lib/modules/4.18.0-80 .el8.x86_64 / kernel / kernel / trace /lib/modules/4.18.0-80.el8.x86_64/kernel/kernel/trace/ring_buffer_benchmark.ko.xz /lib/modules/4.18.0-80.el8.x86_64 / kernel / lib /lib/modules/4.18.0-80.el8.x86_64/kernel/lib/cordic.ko.xz…

  • のリストモジュール kernel-modules： 

    $ rpm -qlp <kernel-modules_rpm> …​ /lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/mlx4/mlx4_ib.ko.xz /lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband /hw/mlx5/mlx5_ib.ko.xz /lib/modules/4.18.0-80.el8.x86_64/kernel/ drivers /infiniband/hw/qedr/qedr.ko.xz /lib/modules/4.18.0-80 .el8.x86_64 / kernel / drivers / infiniband / hw / usnic / usnic_verbs.ko.xz /lib/modules/4.18.0-80.el8.x86_64/kernel/drivers/infiniband/hw/vmw_pvrdma/vmw_pvrdma.ko.xz …

  • のリストモジュール kernel-modules-extra： 

    $ rpm -qlp <kernel-modules-extra_rpm> …​ /lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_cbq.ko.xz /lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_choke.ko .xz /lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_drr.ko.xz /lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_dsmark .ko.xz /lib/modules/4.18.0-80.el8.x86_64/extra/net/sched/sch_gred.ko.xz…

関連資料

第2章 yumでカーネルを更新する (機械翻訳)

以下のセクションでは、Red Hatが提供および保守しているLinuxカーネル（Red Hatカーネル）、およびRed Hatカーネルを最新の状態に保つ方法について説明します。結果として、オペレーティングシステムには、最新のバグ修正、パフォーマンスの向上、および新しいハードウェアとの互換性を保証するパッチがすべて適用されます。

2.1. カーネルとは (機械翻訳)

カーネルは、システムリソースを管理し、ハードウェアアプリケーションとソフトウェアアプリケーションの間のインタフェースを提供するLinuxオペレーティングシステムの中核部分です。Red Hatカーネルはカスタムビルドで、上流のLinuxカーネルをベースにしており、安定性と最新の技術やハードウェアとの互換性を重視しています。

Red Hatが新しいカーネルバージョンをリリースする前に、カーネルは一連の厳密な品質保証テストに合格する必要があります。

Red HatカーネルはRPMフォーマットでパッケージされているので、アップグレードや検証は yum パッケージマネージャ

警告

Red Hat は、カスタムカーネルをサポートしていません。

2.2. yum とは (機械翻訳)

このセクションでは、yum package manager を説明します。

関連資料

2.3. カーネルの更新 (機械翻訳)

次の手順では、カーネルを使用してカーネルを更新する方法について説明します。 yum パッケージマネージャ

手順

  1. カーネルを更新するには、次のようにします。 

    # yum update kernel

    このコマンドは、すべての依存関係と共にカーネルを最新の利用可能なバージョンに更新します。

  2. 変更を有効にするためにシステムを再起動します。
重要

Red Hat Enterprise Linux 7からRed Hat Enterprise Linux 8にアップグレードする場合、Red HatはOS全体を再インストールすることを強く推奨します。必要なすべてのパッケージを更新することは理論的には可能ですが、システムが使用不能になる可能性があります。

2.4. カーネルのインストール (機械翻訳)

次の手順では、カーネルを使用してカーネルを更新またはインストールする方法について説明します。 yum パッケージマネージャ

手順

  • 特定のカーネルバージョンをインストールするには、次のようにします。 

    # yum install kernel-{version}
注記

の yum 常にパッケージマネージャ インストール 現在のカーネルを置き換える代わりに新しいカーネルを使用すると、システムが起動できなくなる可能性があります。

関連資料

  • 利用可能なカーネルの一覧は、Red Hat labs page を参照してください。
  • 各カーネルバージョンのリリース日の一覧は、this article を参照してください。

第3章 カーネルコマンドラインパラメータの設定 (機械翻訳)

システム管理者は、カーネルのコマンドラインパラメータを設定して、できるだけ早く設定およびロードできるようにすることができます。また、特定のカーネルコマンドラインパラメータはこの方法でしか調整できません。

重要

本番システムでカーネルのコマンドラインパラメータを設定するときは注意してください。ハザードの変更はカーネルを不安定にするかもしれず、システムはすべてのカーネルに対して再起動時に起動しないかもしれません。このため、知識を持ち、値を変更する前に有効なオプションを使用していることを確認してください。

3.1. ブートエントリとは (機械翻訳)

ブートエントリは、通常特定のカーネルバージョンに結び付けられている設定ファイルを形成するオプションの集まりです。実際には、システムにカーネルをインストールしたのと同じ数のブートエントリがあります。ブートエントリ設定ファイルは、次の場所にあります。 /boot/loader/entries/ ディレクトリとこのように見えることができます： 

6f9cc9cb7d7845d49698c9537337cedc-4.18.0-5.el8.x86_64.conf

上記のファイル名は、次の場所に保存されているマシンIDで構成されています。 /etc/machine-id ファイルとカーネルのバージョン。

ブートエントリ設定ファイルは、とりわけ、カーネルバージョン、初期RAMディスクイメージ、および kernelopts 変数。カーネルのコマンドラインパラメータを含みます。ブートエントリ設定の内容は以下の通りです： 

title Red Hat Enterprise Linux (4.18.0-74.el8.x86_64) 8.0 (Ootpa)
version 4.18.0-74.el8.x86_64
linux /vmlinuz-4.18.0-74.el8.x86_64
initrd /initramfs-4.18.0-74.el8.x86_64.img $tuned_initrd
options $kernelopts $tuned_params
id rhel-20190227183418-4.18.0-74.el8.x86_64
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

3.2. カーネルコマンドラインパラメータとは (機械翻訳)

このモジュールはカーネルコマンドラインパラメータの概念とシステム管理におけるそれらの役割を説明します。

カーネルコマンドラインパラメータは、カーネル引数とも呼ばれ、起動時の設定に使用されます。

  • Linuxカーネル
  • 初期RAMディスク
  • ユーザー空間の特徴

カーネルのコマンドラインパラメータは、デフォルト値を上書きしたり、カーネルがそのような情報を取得するのに問題がある場合にハードウェアパラメータについてカーネルに通知するためによく使用されます。

デフォルトでは、GRUB2ブートローダを使用するシステム用のカーネルコマンドラインパラメータは、 kernelopts の変数 /boot/grub2/grubenv すべてのカーネルブートエントリ用のファイル。

注記

IBM Zの場合、ziplブートローダーは環境変数をサポートしていないため、カーネルコマンドラインパラメータはブートエントリ設定ファイルに保存されます。このように kernelopts 使用できません。

関連資料

  • どのカーネルコマンドラインパラメータを変更できるかについての詳細は、以下をインストールしてください。 man-pages パッケージして見る kernel-command-line(7), 、bootparam(7) そして dracut.cmdline(7) マニュアルページ

3.3. グラビーとは (機械翻訳)

grubby ブートローダ固有の設定ファイルを操作するためのユーティリティです。

あなたが使用することができます grubby デフォルトのブートエントリを変更したり、GRUB2メニューエントリに引数を追加/削除するためにも使えます。

詳細については grubby(8) マニュアルページ

3.4. カーネルコマンドラインパラメータの設定 (機械翻訳)

このセクションでは、AMD64およびIntel 64アーキテクチャー、64ビットARMアーキテクチャー、およびIBM Power Systemsのリトルエンディアン版のカーネルコマンドラインパラメーターを変更する方法について説明します。

3.4.1. すべてのブートエントリのカーネルコマンドラインパラメータを変更する (機械翻訳)

この手順では、システム上のすべてのブートエントリのカーネルコマンドラインパラメータを変更する方法について説明します。

前提条件
手順

  1. 新しいパラメータを追加するには、 grub2-editenv 次の例のようにコマンドを入力します。 

    # grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) <NEW_PARAMETER>"

    このコマンドは、グローバル変数のパラメータリスト全体に追加の引数を追加します。 kernelopts。その結果、カーネルのコマンドラインパラメータ NEW_PARAMETER システム上のすべてのブートエントリに設定されます。

  2. パラメータを削除するには、次のコマンドを使用します。 

    # grub2-editenv - set "$(grub2-editenv - list | grep kernelopts | sed -e 's/<PARAMETER_TO_REMOVE>//')"
  3. 変更を有効にするためにシステムを再起動します。

その結果、ブートローダは再設定され、指定したカーネルコマンドラインパラメータが適用されます。

注記

カーネルのコマンドラインパラメータを更新する別の方法は、 GRUB_CMDLINE_LINUX のパラメータ /etc/default/grub ファイルと実行 # grub2-mkconfig -o /boot/grub2/grub.cfg GRUB2設定ファイルを更新するコマンド。

関連資料
  • GRUB2設定ファイルを使ってカーネルパラメータを変更する方法の詳細については、 Editing a Menu Entry。

3.4.2. 単一ブートエントリ用のカーネルコマンドラインパラメータの変更 (機械翻訳)

この手順では、システム上の単一ブートエントリのカーネルコマンドラインパラメータを変更する方法について説明します。

前提条件
手順

  • パラメータを追加するには、次のコマンドを実行します。 

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="<NEW_PARAMETER>"

  • パラメータを削除するには、次のようにします。 

    # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --remove-args="<PARAMETER_TO_REMOVE>"
注記

デフォルトでは、 options 各カーネルブートエントリのパラメータ。 kernelopts 変数。この変数は、 /boot/grub2/grubenv 設定ファイル

重要

特定のブートエントリを変更すると、編集した内容が kernelopts 関連するカーネルブートエントリに保存されています。 /boot/loader/entries/<RELEVANT_KERNEL_BOOT_ENTRY.conf> そして今彼ら自身のコマンドラインを持っています。その結果、 kernelopts その特定のカーネルブートエントリには影響しません。

関連資料
  • 使用方法に関するその他の例 grubby 見る grubby tool。

第4章 カーネル調整パラメータの設定 (機械翻訳)

システム管理者は、システムパフォーマンスの向上など、さまざまな理由でカーネル調整パラメータを設定できます。この節では、カーネルチューナブルを設定する方法について説明します。 sysctl コマンドを使用して、設定ファイルを /etc/sysctl.d/ そして /proc/sys/ ディレクトリ

4.1. カーネル調整パラメータとは (機械翻訳)

カーネル調整パラメーターは、sysctl コマンド、または /proc/sys/ ディレクトリーにマウントした仮想ファイルシステムで処理されるカーネルパラメータです。調整パラメータを調整する/etc/sysctl.d/ ディレクトリで設定ファイルを使用することも可能です。システムの稼働中にカーネルパラメータを調整できます。変更を有効にするためにカーネルを再起動または再コンパイルする必要はありません。

調整パラメータは、カーネルサブシステムによってクラスに分けられます。Red Hat Enterprise Linuxには以下のクラスの調整パラメータがあります。

表4.1 sysctlクラスの表

調整パラメーターのクラスサブシステム

abi

実行ドメインと人格

crypto

暗号化インターフェース

debug

カーネルデバッグインタフェース

dev

デバイス固有の情報

fs

グローバルおよび特定のファイルシステム調整パラメータ

kernel

グローバルカーネル調整パラメータ

net

ネットワーク調整パラメータ

sunrpc

Sunリモートプロシージャコール（NFS）

user

ユーザーネームスペースの制限

vm

メモリ、バッファ、キャッシュの調整と管理

関連資料

  • sysctl の詳細は、man ページの sysctl(8) を参照してください。
  • /etc/sysctl.d/ の詳細は、man ページの sysctl.d(5) を参照してください。

4.2. カーネル調整パラメータの設定 (機械翻訳)

重要

本番システムでカーネル調整パラメータを設定するには、慎重な計画が必要です。計画外の変更によりカーネルが不安定になり、システムの再起動が必要になる場合があります。カーネル値を変更する前に、有効なオプションを使用していることを確認してください。

4.2.1. sysctlを使ったカーネル調整パラメータの一時的な設定 (機械翻訳)

次の手順では、 sysctl カーネル調整パラメータを一時的に設定するコマンド。このコマンドは、調整パラメータの一覧表示とフィルタリングにも役立ちます。

前提条件
手順

  1. すべての調整パラメータを一覧表示するには、次のようにします。 

    # sysctl -a
    注記

    # sysctl -a カーネル調整パラメータを表示します。これは実行時および起動時に調整できます。

  2. 調整パラメータを一時的に設定するには、次の例のようにコマンドを使用します。 

    # sysctl <TUNABLE_CLASS>.<TUNABLE>=<TARGET_VALUE>

    上記のサンプルコマンドは、システムの稼働中に調整パラメータの値を変更します。変更はすぐに有効になり、再起動する必要はありません。

    注記

    システムの再起動後、変更はデフォルトに戻ります。

関連資料
  • sysctl の詳細は、man ページの sysctl(8) を参照してください。
  • カーネル調整パラメータを恒久的に変更するには、 sysctl command に値を書き込む /etc/sysctl.conf ファイル内の設定ファイルを手動で変更する /etc/sysctl.d/ directory。

4.2.2. sysctlを使ってカーネル調整パラメータを恒久的に設定する (機械翻訳)

次の手順では、 sysctl カーネル調整パラメータを恒久的に設定するコマンド。

前提条件
手順

  1. すべての調整パラメータを一覧表示するには、次のようにします。 

    # sysctl -a

    このコマンドは、実行時に構成できるすべてのカーネル調整パラメータを表示します。

  2. 調整パラメータを恒久的に設定するには 

    # sysctl -w <TUNABLE_CLASS>.<TUNABLE>=<TARGET_VALUE> >> /etc/sysctl.conf

    サンプルコマンドは調整可能な値を変更し、それを /etc/sysctl.conf このファイルは、カーネル調整パラメータのデフォルト値を上書きします。変更はすぐに持続的に有効になり、再起動する必要はありません。

注記

カーネルの調整パラメータを恒久的に変更するために、あなたは手動で設定ファイルに変更を加えることもできます。 /etc/sysctl.d/ ディレクトリ。

関連資料
  • 詳細について sysctl, 、 見る sysctl(8) そして sysctl.conf(5) マニュアルページ
  • /etc/sysctl.d/ ディレクトリーで設定ファイルを使用して、カーネルの調整パラメーターを永続的に変更する方法は、Using configuration files in /etc/sysctl.d/ to adjust kernel tunables セクションを参照してください。

4.2.3. /etc/sysctl.d/にある設定ファイルを使ってカーネル調整パラメータを調整する (機械翻訳)

次の手順では、ファイル内の設定ファイルを手動で変更する方法について説明します。 /etc/sysctl.d/ カーネル調整パラメータを恒久的に設定するディレクトリ。

前提条件
手順

  1. /etc/sysctl.d/ に新しい設定ファイルを作成します。 

    # vim /etc/sysctl.d/<some_file.conf>

  2. 次のように、1行に1つずつカーネル調整パラメータを含めます。 

    <TUNABLE_CLASS>.<TUNABLE>=<TARGET_VALUE> <TUNABLE_CLASS>.<TUNABLE>=<TARGET_VALUE>
  3. 設定ファイルを保存します。

  4. 変更を有効にするためにマシンを再起動します。

    • あるいは、再起動せずに変更を適用するには、次のコマンドを実行します。 

      # sysctl -p /etc/sysctl.d/<some_file.conf>

      このコマンドを使用すると、以前に作成した設定ファイルから値を読み取ることができます。

関連資料
  • sysctl の詳細は、man ページの sysctl(8) を参照してください。
  • /etc/sysctl.d/ の詳細は、man ページの sysctl.d(5) を参照してください。

4.2.4. / proc / sys /を介してカーネル調整パラメータを一時的に設定する (機械翻訳)

次の手順では、仮想ファイルシステム内のファイルを使用してカーネル調整パラメータを一時的に設定する方法について説明します。 /proc/sys/ ディレクトリ。

前提条件
手順

  1. 設定したいカーネルチューナブルを特定します。 

    # ls -l /proc/sys/<TUNABLE_CLASS>/

    このコマンドによって返される書き込み可能ファイルは、カーネルの設定に使用できます。読み取り専用権限を持つファイルは、現在の設定に関するフィードバックを提供します。

  2. カーネルチューナブルにターゲット値を割り当てます。 

    # echo <TARGET_VALUE> > /proc/sys/<TUNABLE_CLASS>/<TUNABLE>

    このコマンドはシステムの再起動後に消える設定変更を行います。

  3. 必要に応じて、新しく設定したカーネル調整パラメータの値を確認します。 

    # cat /proc/sys/<TUNABLE_CLASS>/<TUNABLE>
関連資料

第5章 kdumpのインストールと設定 (機械翻訳)

5.1. kdumpとは何ですか (機械翻訳)

kdump クラッシュダンプメカニズムを提供するサービスです。このサービスにより、後で分析するためにシステムのメモリの内容を保存できます。 kdump を使用します kexec 2番目のカーネルで起動するためのシステムコール（ カーネルをキャプチャする）再起動せずにそしてクラッシュしたカーネルのメモリの内容を取得します。 クラッシュダンプ または vmcore）とそれを保存します。2番目のカーネルはシステムメモリの予約済み部分にあります。

重要

カーネルクラッシュダンプは、システム障害の場合に利用可能な唯一の情報です（重大なバグ）。したがって、 kdump 運用が重要である環境では重要です。Red Hat は、システム管理者が、通常のカーネル更新サイクルで、kexec-tools を定期的に更新してテストすることをお勧めします。これは、新しいカーネル機能が実装されるときに特に重要です。

5.2. kdumpのインストール (機械翻訳)

多くの場合、 kdump 新しいRed Hat Enterprise Linuxインストールでは、サービスはデフォルトでインストールされアクティブ化されます。の Anaconda インストーラは以下の画面を提供します。 kdump グラフィカルまたはテキストインタフェースを使用して対話式インストールを実行するときの設定。インストーラ画面のタイトルは Kdump そしてメインから利用可能です Installation Summary 画面に表示され、制限された設定のみが許可されます。 kdump が有効になっており、どのくらいのメモリが予約されています。

Enable kdump during RHEL installation

カスタムキックスタートインストールなどの一部のインストールオプションでは、インストールや有効化ができない場合があります。 kdump デフォルトでご使用のシステムでこれが当てはまる場合は、以下の手順に従って kdump をインストールしてください。

前提条件

  • アクティブなRed Hat Enterprise Linuxサブスクリプション。
  • を含むリポジトリ kexec-tools あなたのシステムCPUアーキテクチャのためのパッケージ。
  • kdump requirements を満たしている。

手順

  1. 以下のコマンドを実行して、kdump がシステムにインストールされているかどうかを確認します。 

    $ rpm -q kexec-tools

    パッケージがインストールされている場合に出力されます。 

    kexec-tools-2.0.17-11.el8.x86_64

    パッケージがインストールされていない場合に出力されます。 

    package kexec-tools is not installed

  2. インストール kdump その他の必要なパッケージ： 

    # yum install kexec-tools
重要

Red Hat Enterprise Linux 7.4（kernel-3.10.0-693.el7）以降では、 Intel IOMMU ドライバはでサポートされています kdump。以前のバージョン、Red Hat Enterprise Linux 7.3（kernel-3.10.0-514 [.XYZ] .el7）以前の場合は、 Intel IOMMU サポートが無効になっている、そうでなければkdumpカーネルが応答しなくなる可能性があります。

関連資料

5.3. コマンドラインでkdumpを設定する (機械翻訳)

5.3.1. kdumpメモリ使用量の設定 (機械翻訳)

kdump 機能に予約されているメモリーは、システムの起動時には常に予約されています。メモリ容量は、システムのGRUB（Grand Unified Bootloader）2構成で指定されています。以下の手順では、コマンドラインから kdump に予約するメモリーの設定方法を説明します。

前提条件
手順
  1. を編集 /etc/default/grub root権限を使用してファイル

  2. をセットする crashkernel= 必要な値へのオプション。

    たとえば、128 MBのメモリを予約するには、次のようにします。 

    crashkernel=128M

    あるいは、取り付けられているメモリーの合計量に応じて、予約済みメモリーの量を変数に設定できます。変数へのメモリ予約の構文は次のとおりです。 crashkernel=<range1>:<size1>,<range2>:<size2>。以下に例を示します。 

    crashkernel=512M-2G:64M,2G-:128M

    上記の例では、システムメモリの合計容量が512 MB以上2 GB未満の場合、64 MBのメモリが予約されます。メモリの総量が2 GBを超える場合は、128 MBが予約されています。 kdump 代わりに。

    • 予約メモリをオフセットします。

      クラッシュカーネルの予約は非常に早いので、システムによっては特定の固定オフセットでメモリを予約する必要があり、特別な用途のために一部の領域を予約したいと考えています。オフセットが設定されている場合、予約メモリはそこから始まります。予約メモリをオフセットするには、次の構文を使用します。 

      crashkernel=128M@16M

      上記の例は、 kdump 16 MB（物理アドレス0x01000000）から始まる128 MBのメモリを予約します。offsetパラメータが0に設定されているか完全に省略されている場合、 kdump 予約メモリを自動的にオフセットします。この構文は、前述のように可変メモリ予約を設定するときにも使用できます。この場合、オフセットは常に最後に指定されます（たとえば、 crashkernel=512M-2G:64M,2G-:128M@16M）

  3. GRUB2設定ファイルを更新するには、次のコマンドを使用します。 

    # grub2-mkconfig -o /boot/grub2/grub.cfg
注記

メモリを設定するための代替方法 kdump を追加することです crashkernel=<SOME_VALUE> へのパラメータ kernelopts と変数 grub2-editenv これですべての起動エントリが更新されます。またはあなたが使用することができます grubby 1つのエントリのカーネルコマンドラインパラメータを更新するためのユーティリティ。

関連資料

5.3.2. kdumpターゲットの設定 (機械翻訳)

カーネルクラッシュが捕捉されると、コアダンプはローカルファイルシステムにファイルとして保存されるか、デバイスに直接書き込まれるか、または NFS （ネットワークファイルシステム）または SSH （Secure Shell）プロトコル。一度に設定できるオプションは1つだけです。デフォルトの動作では、vmcoreファイルは次の場所に保存されます。 /var/crash/ ローカルファイルシステムのディレクトリ。

前提条件
手順

コアダンプを保存するローカルディレクトリを変更するには、次のようにします。 root, 編集する /etc/kdump.conf 下記のように設定ファイル。

  1. #path /var/crash の行頭にあるハッシュ記号 ("#") を削除します。

  2. 値を目的のディレクトリパスに置き換えます。以下に例を示します。 

    path /usr/local/cores
    重要

    Red Hat Enterprise Linux 8では、kdumpターゲットとして定義されているディレクトリ path ディレクティブが存在する必要があります。 kdump systemdサービスが開始されます - そうでなければサービスは失敗します。この動作は、サービスの開始時にディレクトリが存在しない場合にディレクトリが自動的に作成されていた以前のリリースのRed Hat Enterprise Linuxとは異なります。

ファイルを別のパーティションに書き込むには、次のようにします。 root, 編集する /etc/kdump.conf 下記のように設定ファイル。

  1. 必要に応じて、#ext4 の行頭にあるハッシュ記号 ("#") を削除します。

    • デバイス名（ #ext4 /dev/vg/lv_kdump ライン）
    • ファイルシステムのラベル（ #ext4 LABEL=/boot ライン）
    • UUID（ #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937 ライン）

  2. ファイルシステムの種類とデバイス名、ラベル、またはUUIDを目的の値に変更します。以下に例を示します。 

    ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
    重要

    を使用してストレージデバイスを指定することをお勧めします。 LABEL= または UUID=。のようなディスクデバイス名 /dev/sda3 再起動後も一貫しているという保証はありません。

    重要

    IBM Zハードウェア上の直接アクセス記憶装置（DASD）にダンプするときは、ダンプ装置が次のように正しく指定されていることが重要です。 /etc/dasd.conf 続行する前に

ダンプを直接装置に書き込むには、以下のようにします。

  1. #raw /dev/vg/lv_kdump の行頭にあるハッシュ記号 ("#") を削除します。

  2. 値を目的のデバイス名に置き換えます。以下に例を示します。 

    raw /dev/sdb1

を使用してダンプをリモートマシンに保存するには NFS プロトコル：

  1. #nfs my.server.com:/export/tmp の行頭にあるハッシュ記号 ("#") を削除します。

  2. 値を有効なホスト名とディレクトリパスに置き換えます。以下に例を示します。 

    nfs penguin.example.com:/export/cores

を使用してダンプをリモートマシンに保存するには SSH プロトコル：

  1. #ssh user@my.server.com の行頭にあるハッシュ記号 ("#") を削除します。
  2. 値を有効なユーザー名とホスト名に置き換えます。

  3. あなたを含める SSH 設定を入力します。

    • #sshkey /root/.ssh/kdump_id_rsa の行頭にあるハッシュ記号を削除します。

    • ダンプしようとしているサーバーで有効なキーの場所に値を変更します。以下に例を示します。 

      ssh john@penguin.example.com
sshkey /root/.ssh/mykey
関連資料

5.3.3. コアコレクタの設定 (機械翻訳)

kdump 次のように指定されたプログラムを使用します。 core collector vmcoreをキャプチャします。現在、唯一の完全にサポートされている core collector それは makedumpfile 効用収集プロセスに影響を与える設定可能なオプションがいくつかあります。たとえば、収集されたデータの範囲、結果のvmcoreを圧縮する必要があるかどうかなどです。

有効にして設定するには core collector, 以下の手順に従ってください。

前提条件
手順
  1. root で、/etc/kdump.conf 設定ファイルを編集し、#core_collector makedumpfile -l --message-level 1 -d 31 の行頭にあるハッシュ記号 ("#") を削除します。

  2. を追加 -c パラメータ以下に例を示します。 

    core_collector makedumpfile -c

    上記のコマンドはダンプファイルの圧縮を有効にします。

  3. を追加 -d value パラメータ以下に例を示します。 

    core_collector makedumpfile -d 17 -c

    上記のコマンドは、ダンプからゼロページと空きページの両方を削除します。の 値 各ビットは特定の種類のメモリページに関連付けられており、その種類のページを収集するかどうかを決定します。各ビットの説明については、 「サポートされているkdumpフィルタリングレベル (機械翻訳)」。

関連資料
  • 利用可能なオプションの一覧は、man ページの makedumpfile(8) を参照してください。

5.3.4. kdumpのデフォルトの失敗応答の設定 (機械翻訳)

デフォルトでは、 kdump で指定されたターゲットの場所にvmcoreダンプファイルを作成できない 「kdumpターゲットの設定 (機械翻訳)」, システムが再起動し、その過程でダンプが失われます。この動作を変更するには、以下の手順に従ってください。

前提条件
手順
  1. root で、/etc/kdump.conf 設定ファイルの #default shell の行頭にあるハッシュ記号 ("#") を削除します。

  2. の説明に従って、値を目的のアクションに置き換えます。 「サポートされているデフォルトの失敗応答 (機械翻訳)」。以下に例を示します。 

    default poweroff

5.3.5. kdumpサービスの有効化と無効化 (機械翻訳)

を開始する kdump 起動時にサービスを受けるには、以下の手順に従ってください。

前提条件
  • kdump requirements を満たしている。
  • すべて configuration あなたのニーズに応じて設定されています。
手順

  1. 有効にする kdump サービス、次のコマンドを使用します。 

    # systemctl enable kdump.service

    これはのためのサービスを可能にします multi-user.target。

  2. 現在のセッションでサービスを開始するには、次のコマンドを使用します。 

    # systemctl start kdump.service

  3. を止める kdump serviceの場合は、次のコマンドを入力します。 

    # systemctl stop kdump.service

  4. 無効にする kdump serviceの場合は、次のコマンドを実行します。 

    # systemctl disable kdump.service
関連資料

5.4. Web コンソールを使用した kdump の設定 (機械翻訳)

以下のセクションでは、セットアップおよびテスト方法の概要を説明します。 kdump Red Hat Enterprise Linux Webコンソールを介した設定。WebコンソールはRed Hat Enterprise Linux 8のデフォルトインストールの一部であり、Red Hat Enterprise Linux 8を有効または無効にします。 kdump 起動時にサービス。さらに、Webコンソールを使用すると、予約済みのメモリを簡単に設定できます。 kdump;またはを選択します vmcore 場所を非圧縮または圧縮形式で保存します。

前提条件

5.4.1. Web コンソールを使用して kdump メモリーの使用量およびターゲットの場所の設定 (機械翻訳)

以下の手順は、使用方法を示しています。 Kernel Dump Red Hat Enterprise Linux Webコンソールインターフェースのタブをクリックして、kdumpカーネル用に予約されているメモリ容量を設定します。この手順では、vmcore ダンプファイルのターゲットの場所の指定方法と、設定のテスト方法についても説明します。

前提条件
手順
  1. 開く Kernel Dump タブを押して開始 kdump サービス。
  2. を設定 kdump メモリ使用量 command line。

  3. の横にあるリンクをクリックします。 Crash dump location オプション。

    web console initial screen

  4. を選択 Local Filesystem ドロップダウンからオプションを選択して、ダンプを保存するディレクトリを指定します。

    web console crashdump target

    • あるいは、 Remote over SSH SSHプロトコルを使用してリモートマシンにvmcoreを送信するためのドロップダウンからのオプション。

      記入する Server, 、ssh key, 、そして Directory リモートマシンのアドレス、SSHキーの場所、およびターゲットディレクトリを含むフィールド。

    • もう一つの選択は Remote over NFS ドロップダウンからオプションを選択して、 Mount NFSプロトコルを使用してvmcoreをリモートマシンに送信するためのフィールド。

      注記

      をチェック Compression vmcoreファイルのサイズを小さくするには、チェックボックスをオンにします。

  5. カーネルをクラッシュして、設定をテストします。

    web console test kdump config
    警告

    この手順は、カーネルの実行を中断し、システムクラッシュとデータの損失をもたらします。

関連資料
  • 現在サポートされているターゲットの完全なリストは kdump, 、 見る Supported kdump targets。
  • SSH サーバを設定し、キーベースの認証を設定する方法は、Red Hat Enterprise Linux の Configuring basic system settings を参照してください。

5.5. サポートされているkdumpの設定とターゲット (機械翻訳)

5.5.1. kdumpのメモリ要件 (機械翻訳)

のために kdump カーネルクラッシュダンプをキャプチャしてさらに分析するために保存できるようにするには、システムメモリの一部をキャプチャカーネル用に恒久的に予約する必要があります。予約されている場合、システムメモリのこの部分はメインカーネルに利用できません。

メモリ要件は、特定のシステムパラメータによって異なります。主な要因の1つは、システムのハードウェアアーキテクチャです。正確なマシンアーキテクチャー（Intel 64やAMD64、x86_64など）を見つけてそれを標準出力に出力するには、次のコマンドを使用します。 

$ uname -m

以下の表には、メモリサイズを自動的に確保するための最小メモリ要件のリストが含まれています。 kdump。サイズは、システムのアーキテクチャーおよび使用可能な総物理メモリーによって異なります。

表5.1 kdumpに必要な最小予約メモリ量

アーキテクチャー使用可能なメモリ最小予約メモリ

AMD64とIntel 64（x86_64）

1 GBから64 GB

160 MBのRAM

 

64 GBから1 TB

256 MBのRAM

 

1 TB以上

512 MBのRAM

64ビットARMアーキテクチャ（arm64）

2 GB以上

512 MBのRAM

IBMパワーシステムズ（ppc64le）

2 GBから4 GB

384 MBのRAM。

 

4 GBから16 GB

512 MBのRAM

 

16 GBから64 GB

1 GBのRAM

 

64 GBから128 GB

2 GBのRAM

 

128 GB以上

4 GBのRAM

IBM Z（s390x）

4 GBから64 GB

160 MBのRAM

 

64 GBから1 TB

256 MBのRAM

 

1 TB以上

512 MBのRAM

多くのシステムでは、 kdump 必要なメモリ量を見積もり、自動的に予約することができます。この動作はデフォルトで有効になっていますが、1つ以上の機能を持つシステムでのみ機能します。 certain amount of total available memory, システムアーキテクチャによって異なります。

重要

システム内の総メモリ量に基づいた予約済みメモリの自動設定は、ベストエフォート型の見積もりです。実際に必要なメモリは、I / Oデバイスなどの他の要因によって変わる場合があります。メモリが不足していると、カーネルパニックが発生した場合にデバッグカーネルがキャプチャカーネルとして起動できなくなる可能性があります。この問題を回避するには、クラッシュカーネルメモリを十分に増やします。

関連資料

5.5.2. 自動メモリー予約の最小しきい値 (機械翻訳)

いくつかのシステムでは、以下のためにメモリを割り当てることが可能です。 kdump を使用して自動的に crashkernel=auto ブートローダ設定ファイルでこのパラメータを使用するか、グラフィカル設定ユーティリティでこのオプションを有効にします。ただし、この自動予約が機能するためには、システムで一定量の合計メモリを使用できる必要があります。量はシステムのアーキテクチャによって異なります。

以下の表に、自動メモリ割り当てのしきい値を示します。システムがテーブルで指定されているよりも少ないメモリを持っている場合、メモリは reserved manually。

表5.2 自動メモリ予約に必要な最小メモリ量

アーキテクチャー必要メモリ

AMD64とIntel 64（x86_64）

2 GB

IBMパワーシステムズ（ppc64le）

2 GB

IBM Z（s390x）

4ギガバイト

関連資料

5.5.3. サポートされているkdumpターゲット (機械翻訳)

カーネルクラッシュがキャプチャされると、vmcoreダンプファイルはデバイスに直接書き込まれるか、ローカルファイルシステムにファイルとして保存されるか、またはネットワーク経由で送信されます。以下の表は、現在サポートされている、または明示的にサポートされていないダンプターゲットの完全なリストを含みます。 kdump。

表5.3 サポートされているkdumpターゲット

タイプサポートされているターゲットサポートされていないターゲット

ローデバイス

ローカルに接続されたすべてのRAWディスクとパーティション。

 

ローカルファイルシステム

ext2、 ext3, 、ext4, 、そして xfs 直接接続されたディスクドライブ、ハードウェアRAID論理ドライブ、LVMデバイス上のファイルシステム mdraid 配列

この表でサポートされていると明示的にリストされていないローカルファイルシステム。 auto タイプ（自動ファイルシステム検出）

リモートディレクトリ

を使用してアクセスしたリモートディレクトリ NFS または SSH プロトコルオーバー IPv4。

リモートディレクトリ rootfs ファイルシステムを使用してアクセス NFS プロトコル。

を使用してアクセスしたリモートディレクトリ iSCSI ハードウェアとソフトウェアの両方のイニシエータを介したプロトコル。

を使用してアクセスしたリモートディレクトリ iSCSI プロトコルオン be2iscsi ハードウェア

マルチパスベースのストレージ

 

経由でアクセスしたリモートディレクトリ IPv6。

 

を使用してアクセスしたリモートディレクトリ SMB または CIFS プロトコル。

 

を使用してアクセスしたリモートディレクトリ FCoE （イーサネット上のファイバチャネル）プロトコル。

 

ワイヤレスネットワークインタフェースを使用してアクセスされたリモートディレクトリ。

関連資料

5.5.4. サポートされているkdumpフィルタリングレベル (機械翻訳)

ダンプファイルのサイズを小さくするには、 kdump を使用します makedumpfile データを圧縮し、オプションで不要な情報を除外するためのコアコレクタ。以下の表は、現在サポートされているフィルタリングレベルの一覧です。 makedumpfile 効用

表5.4 サポートされているフィルタリングレベル

オプション説明

1

ゼロページ

2

キャッシュページ

4

プライベートキャッシュ

8

ユーザーページ

16

空きページ

注記

の makedumpfile このコマンドは、透明な巨大ページとhugetlbfsページの削除をサポートします。これら両方のタイプの巨大ページのユーザーページを検討し、それらを使用してそれらを削除します。 -8 レベル。

関連資料

5.5.5. サポートされているデフォルトの失敗応答 (機械翻訳)

デフォルトでは、 kdump コアダンプの作成に失敗すると、オペレーティングシステムが再起動します。ただし、設定はできます kdump コアダンプをプライマリターゲットに保存できなかった場合に別の操作を実行します。以下の表は、現在サポートされているすべてのデフォルトのアクションをリストしています。

表5.5 サポートされているデフォルトのアクション

オプション説明

dump_to_rootfs

コアダンプをルートファイルシステムに保存しようとしました。このオプションは、ネットワークターゲットと組み合わせて使用すると特に便利です。ネットワークターゲットにアクセスできない場合、このオプションはkdumpを設定してコアダンプをローカルに保存します。その後システムは再起動されます。

reboot

システムを再起動し、その過程でコアダンプを失います。

halt

システムを停止し、その過程でコアダンプを失います。

poweroff

システムの電源を切り、その過程でコアダンプを失います。

shell

initramfs内からシェルセッションを実行し、ユーザーがコアダンプを手動で記録できるようにします。

関連資料

5.5.6. kdumpサイズの見積もり (機械翻訳)

kdump環境を計画して構築するときは、ダンプファイルを作成する前に、ダンプファイルに必要な容量を知っておく必要があります。

の makedumpfile --mem-usage コマンドは、除外ページに関する有用なレポートを提供し、どのダンプ・レベルを割り当てるのかを決定するために使用できます。システムが代表的な負荷を受けているときにこのコマンドを実行します。 makedumpfile --mem-usage 実稼働環境で予想されるよりも小さい値を返します。 

[root@hostname ~]# makedumpfile --mem-usage /proc/kcore

TYPE            PAGES                   EXCLUDABLE      DESCRIPTION
----------------------------------------------------------------------
ZERO            501635                  yes             Pages filled with zero
CACHE           51657                   yes             Cache pages
CACHE_PRIVATE   5442                    yes             Cache pages + private
USER            16301                   yes             User process pages
FREE            77738211                yes             Free pages
KERN_DATA       1333192                 no              Dumpable kernel data
重要

の makedumpfile --mem-usage のコマンドレポート ページ数。つまり、カーネルページサイズに対して使用中のメモリサイズを計算する必要があります。デフォルトでは、Red Hat Enterprise LinuxカーネルはAMD64およびIntel 64アーキテクチャー用に4 KBサイズのページを使用し、IBM POWERアーキテクチャー用に64 KBサイズのページを使用します。

5.6. kdump設定のテスト (機械翻訳)

次の手順では、カーネルダンププロセスが機能し、マシンが運用に入る前に有効であることをテストする方法について説明します。

警告

以下のコマンドはカーネルをクラッシュさせます。これらの手順を実行するときは注意してください。アクティブな運用システムでは、不用意にそれらを使用しないでください。

手順

  1. でシステムを再起動します。 kdump enabled。

  2. それを確かめなさい kdump が走っています： 

    ~]# systemctl is-active kdump
active

  3. Linuxカーネルを強制的にクラッシュさせます。 

    echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger
    警告

    上記のコマンドはカーネルをクラッシュさせるので再起動が必要です。

    もう一度起動すると、 address-YYYY-MM-DD-HH:MM:SS/vmcore ファイルはあなたが持っている場所に作成されます。 specified に /etc/kdump.conf （デフォルトでは /var/crash/）

    注記

    構成の有効性を確認することに加えて、このアクションを使用して、代表的なロードが実行されている間にクラッシュダンプが完了するのにかかる時間を記録することができます。

5.7. コアダンプの分析 (機械翻訳)

システムクラッシュの原因を特定するには、 crash GNU Debugger（GDB）に非常によく似た対話式プロンプトを提供するユーティリティー。このユーティリティを使用すると、対話的に作成したコアダンプを分析できます。 kdump, 、netdump, 、diskdump または xendump 実行中のLinuxシステムと同様に。代わりに、あなたは使用するオプションがあります Kdump Helper または Kernel Oops Analyzer。

5.7.1. クラッシュユーティリティのインストール (機械翻訳)

次の手順では、インストール方法について説明します。 crash 分析ツール

手順

  1. 関連するを有効にする baseos そして appstream リポジトリ： 

    # subscription-manager repos --enable baseos repository
    # subscription-manager repos --enable appstream repository

  2. をインストール crash パッケージ： 

    # yum install crash

  3. をインストール kernel-debuginfo パッケージ： 

    # yum install kernel-debuginfo

    このパッケージは実行中のカーネルに対応し、ダンプ分析に必要なデータを提供します。

関連資料

5.7.2. クラッシュユーティリティの実行と終了 (機械翻訳)

次の手順では、システムクラッシュの原因を分析するためのクラッシュユーティリティの起動方法について説明します。

前提条件
  • 現在実行しているカーネルを確認します（たとえば 4.18.0-5.el8.x86_64）
手順

  1. を開始する crash ユーティリティには、2つの必要なパラメータをコマンドに渡す必要があります。

    • debug-info（解凍されたvmlinuzイメージ）、例えば /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux 特定のものを通して提供される kernel-debuginfo パッケージ。

    • 実際のvmcoreファイル、たとえば /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

      結果として crash するとcommandは次のようになります。 

      # crash /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

      kdump で取得したのと同じ <kernel> のバージョンを使用します。

      例5.1 クラッシュユーティリティの実行

      次の例は、4.18.0-5.el8.x86_64カーネルを使用して、2018年10月6日午後14時5分に作成されたコアダンプの分析を示しています。 

      ...
WARNING: kernel relocated [202MB]: patching 90160 gdb minimal_symbol values

      KERNEL: /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux
    DUMPFILE: /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore  [PARTIAL DUMP]
        CPUS: 2
        DATE: Sat Oct  6 14:05:16 2018
      UPTIME: 01:03:57
LOAD AVERAGE: 0.00, 0.00, 0.00
       TASKS: 586
    NODENAME: localhost.localdomain
     RELEASE: 4.18.0-5.el8.x86_64
     VERSION: #1 SMP Wed Aug 29 11:51:55 UTC 2018
     MACHINE: x86_64  (2904 Mhz)
      MEMORY: 2.9 GB
       PANIC: "sysrq: SysRq : Trigger a crash"
         PID: 10635
     COMMAND: "bash"
        TASK: ffff8d6c84271800  [THREAD_INFO: ffff8d6c84271800]
         CPU: 1
       STATE: TASK_RUNNING (SYSRQ)

crash>

  2. 対話型プロンプトを終了して crash を終了するには、exit または qを使用します。

    例5.2 クラッシュユーティリティを終了する

    crash> exit
~]#
注記

の crash commandは、ライブシステムをデバッグするための強力なツールとしても使用できます。ただし、システムを壊さないように注意して使用してください。

5.7.3. クラッシュユーティリティでのメッセージバッファ、バックトレース、およびその他のインジケータの表示 (機械翻訳)

次の手順では、クラッシュユーティリティの使用方法と、カーネルメッセージバッファ、バックトレース、プロセスステータス、仮想メモリ情報、オープンファイルなどのさまざまなインジケータの表示方法について説明します。

メッセージバッファの表示

  • カーネルメッセージバッファを表示するには、次のように入力します。 log 次の例に示すように、インタラクティブプロンプトでコマンドを入力します。

    例5.3 カーネルメッセージバッファの表示

    crash> log
... several lines omitted ...
EIP: 0060:[<c068124f>] EFLAGS: 00010096 CPU: 2
EIP is at sysrq_handle_crash+0xf/0x20
EAX: 00000063 EBX: 00000063 ECX: c09e1c8c EDX: 00000000
ESI: c0a09ca0 EDI: 00000286 EBP: 00000000 ESP: ef4dbf24
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process bash (pid: 5591, ti=ef4da000 task=f196d560 task.ti=ef4da000)
Stack:
 c068146b c0960891 c0968653 00000003 00000000 00000002 efade5c0 c06814d0
<0> fffffffb c068150f b7776000 f2600c40 c0569ec4 ef4dbf9c 00000002 b7776000
<0> efade5c0 00000002 b7776000 c0569e60 c051de50 ef4dbf9c f196d560 ef4dbfb4
Call Trace:
 [<c068146b>] ? __handle_sysrq+0xfb/0x160
 [<c06814d0>] ? write_sysrq_trigger+0x0/0x50
 [<c068150f>] ? write_sysrq_trigger+0x3f/0x50
 [<c0569ec4>] ? proc_reg_write+0x64/0xa0
 [<c0569e60>] ? proc_reg_write+0x0/0xa0
 [<c051de50>] ? vfs_write+0xa0/0x190
 [<c051e8d1>] ? sys_write+0x41/0x70
 [<c0409adc>] ? syscall_call+0x7/0xb
Code: a0 c0 01 0f b6 41 03 19 d2 f7 d2 83 e2 03 83 e0 cf c1 e2 04 09 d0 88 41 03 f3 c3 90 c7 05 c8 1b 9e c0 01 00 00 00 0f ae f8 89 f6 <c6> 05 00 00 00 00 01 c3 89 f6 8d bc 27 00 00 00 00 8d 50 d0 83
EIP: [<c068124f>] sysrq_handle_crash+0xf/0x20 SS:ESP 0068:ef4dbf24
CR2: 0000000000000000

    タイプ help log コマンド使用法の詳細については。

    注記

    カーネルメッセージバッファには、システムクラッシュに関する最も重要な情報が含まれています。そのため、常に最初にダンプされます。 vmcore-dmesg.txt ファイル。満杯にしようとするときに便利です。 vmcore ターゲットの場所にスペースがないなどの理由で、ファイルが失敗しました。デフォルトでは、 vmcore-dmesg.txt に位置しています /var/crash/ ディレクトリ。

5.7.3.1. バックトレースを表示する (機械翻訳)

  • カーネルスタックトレースを表示するには、 bt コマンド。

    例5.4 カーネルスタックトレースの表示

    crash> bt
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
 #0 [ef4dbdcc] crash_kexec at c0494922
 #1 [ef4dbe20] oops_end at c080e402
 #2 [ef4dbe34] no_context at c043089d
 #3 [ef4dbe58] bad_area at c0430b26
 #4 [ef4dbe6c] do_page_fault at c080fb9b
 #5 [ef4dbee4] error_code (via page_fault) at c080d809
    EAX: 00000063  EBX: 00000063  ECX: c09e1c8c  EDX: 00000000  EBP: 00000000
    DS:  007b      ESI: c0a09ca0  ES:  007b      EDI: 00000286  GS:  00e0
    CS:  0060      EIP: c068124f  ERR: ffffffff  EFLAGS: 00010096
 #6 [ef4dbf18] sysrq_handle_crash at c068124f
 #7 [ef4dbf24] __handle_sysrq at c0681469
 #8 [ef4dbf48] write_sysrq_trigger at c068150a
 #9 [ef4dbf54] proc_reg_write at c0569ec2
#10 [ef4dbf74] vfs_write at c051de4e
#11 [ef4dbf94] sys_write at c051e8cc
#12 [ef4dbfb0] system_call at c0409ad5
    EAX: ffffffda  EBX: 00000001  ECX: b7776000  EDX: 00000002
    DS:  007b      ESI: 00000002  ES:  007b      EDI: b7776000
    SS:  007b      ESP: bfcb2088  EBP: bfcb20b4  GS:  0033
    CS:  0073      EIP: 00edc416  ERR: 00000004  EFLAGS: 00000246

    bt <pid> を入力して特定のプロセスのバックトレースを表示するか、help bt を入力して、bt 使用方法の詳細を表示します。

5.7.3.2. プロセス状況の表示 (機械翻訳)

  • システム内のプロセスのステータスを表示するには、 ps コマンド。

    例5.5 システム内のプロセスの状況を表示する

    crash> ps
   PID    PPID  CPU   TASK    ST  %MEM     VSZ    RSS  COMM
>     0      0   0  c09dc560  RU   0.0       0      0  [swapper]
>     0      0   1  f7072030  RU   0.0       0      0  [swapper]
      0      0   2  f70a3a90  RU   0.0       0      0  [swapper]
>     0      0   3  f70ac560  RU   0.0       0      0  [swapper]
      1      0   1  f705ba90  IN   0.0    2828   1424  init
... several lines omitted ...
   5566      1   1  f2592560  IN   0.0   12876    784  auditd
   5567      1   2  ef427560  IN   0.0   12876    784  auditd
   5587   5132   0  f196d030  IN   0.0   11064   3184  sshd
>  5591   5587   2  f196d560  RU   0.0    5084   1648  bash

    ps <pid> を使用して、1 つのプロセスのステータスを表示します。psの詳細な使用方法は、help ps を実行します。

5.7.3.3. 仮想メモリ情報の表示 (機械翻訳)

  • 基本的な仮想メモリ情報を表示するには、次のように入力します。 vm 対話式プロンプトでコマンドを入力します。

    例5.6 現在のコンテキストの仮想メモリ情報を表示する

    crash> vm
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
   MM       PGD      RSS    TOTAL_VM
f19b5900  ef9c6000  1648k    5084k
  VMA       START      END    FLAGS  FILE
f1bb0310    242000    260000 8000875  /lib/ld-2.12.so
f26af0b8    260000    261000 8100871  /lib/ld-2.12.so
efbc275c    261000    262000 8100873  /lib/ld-2.12.so
efbc2a18    268000    3ed000 8000075  /lib/libc-2.12.so
efbc23d8    3ed000    3ee000 8000070  /lib/libc-2.12.so
efbc2888    3ee000    3f0000 8100071  /lib/libc-2.12.so
efbc2cd4    3f0000    3f1000 8100073  /lib/libc-2.12.so
efbc243c    3f1000    3f4000 100073
efbc28ec    3f6000    3f9000 8000075  /lib/libdl-2.12.so
efbc2568    3f9000    3fa000 8100071  /lib/libdl-2.12.so
efbc2f2c    3fa000    3fb000 8100073  /lib/libdl-2.12.so
f26af888    7e6000    7fc000 8000075  /lib/libtinfo.so.5.7
f26aff2c    7fc000    7ff000 8100073  /lib/libtinfo.so.5.7
efbc211c    d83000    d8f000 8000075  /lib/libnss_files-2.12.so
efbc2504    d8f000    d90000 8100071  /lib/libnss_files-2.12.so
efbc2950    d90000    d91000 8100073  /lib/libnss_files-2.12.so
f26afe00    edc000    edd000 4040075
f1bb0a18   8047000   8118000 8001875  /bin/bash
f1bb01e4   8118000   811d000 8101873  /bin/bash
f1bb0c70   811d000   8122000 100073
f26afae0   9fd9000   9ffa000 100073
... several lines omitted ...

    vm <pid>を実行して、1 つのプロセスの情報を表示するか、help vm を実行して、vm の使用方法を表示します。

5.7.3.4. 開いているファイルを表示する (機械翻訳)

  • 開いているファイルに関する情報を表示するには、 files コマンド。

    例5.7 現在のコンテキストのオープンファイルに関する情報を表示する

    crash> files
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
ROOT: /    CWD: /root
 FD    FILE     DENTRY    INODE    TYPE  PATH
  0  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
  1  efade5c0  eee14090  f00431d4  REG   /proc/sysrq-trigger
  2  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
 10  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
255  f734f640  eedc2c6c  eecd6048  CHR   /pts/0

    files <pid> を実行して、選択した 1 つのプロセスが開いたファイルを表示するか、help files を実行して、files の使用方法を表示します。

5.7.4. Kernel Oops Analyzer の使用 (機械翻訳)

Kernel Oops Analyzerは、oopsメッセージをナレッジベースの既知の問題と比較することでクラッシュダンプを分析するツールです。

前提条件
  • 次の手順に従って、Oopsメッセージを保護してKernel Oopsアナライザにフィードします。 Red Hat Labs。
手順
  1. に従ってください Kernel Oops Analyzer ツールにアクセスするためのリンク。

  2. を押して、oopsメッセージを探します。 ブラウズ ボタン。

    Kernel oops analyzer
  3. クリック 検出 からの情報に基づいてoopsメッセージを比較するボタン makedumpfile 既知の解決策に対して。

関連資料

  • kdump.conf(5) - /etc/kdump.conf 設定ファイルのマニュアルページ。利用可能なオプションの完全なドキュメントを含みます。
  • zipl.conf（5） - のマニュアルページ /etc/zipl.conf 設定ファイル
  • zipl（8） - のマニュアルページ zipl IBM System z用のブートローダユーティリティ。
  • makedumpfile（8） - のマニュアルページ makedumpfile コアコレクター。
  • ケクセック（8） - のマニュアルページ kexec。
  • クラッシュ（8） - のマニュアルページ crash 効用
  • /usr/share/doc/kexec-tools/kexec-kdump-howto.txt - の概要 kdump そして kexec インストールと使用方法
  • kexec 設定および kdump 設定の詳細は、Red Hat Knowledgebase article を参照してください。
  • サポートされているの詳細については kdump ターゲットは Red Hat Knowledgebase article。

第6章 kpatchを使ったカーネルパッチの適用 (機械翻訳)

の kpatch ライブカーネルパッチソリューションでは、プロセスを再起動または再起動することなく、実行中のカーネルにパッチを適用できます。 kpatch システム管理者は、長時間のタスクが完了するまで、ユーザーがログオフするまで、またはスケジュールされたダウンタイムを待つことなく、重要なセキュリティパッチをすぐにカーネルに適用できます。セキュリティや安定性を犠牲にすることなく、稼働時間をより細かく制御できます。

警告

いくつかの非互換性が kpatch そして他のカーネルサブコンポーネント。読む 「kpatchの制限 (機械翻訳)」 使用する前に慎重に kpatch。

6.1. カーネルパッチへのアクセス (機械翻訳)

ライブカーネルパッチ適用機能はカーネルモジュールとして実装されています（kmod）RPMパッケージとして配布されています。の kpatch ユーティリティは、ライブカーネルパッチのカーネルモジュールのインストールと削除に使用されます。

Premiumサブスクリプションをお持ちのお客様は、Red Hatサポートからの迅速な修正ソリューションの一部としてライブカーネルパッチを要求することができます。

リブートを必要とする「ホットフィックス」カーネルを通常使用していた適格顧客は、ダウンタイムを必要としないkpatchパッチを今すぐ要求できます。kpatchパッチは、リリースされた修正が含まれている問題の30日後にサポートされます。

迅速な修正オプションを必要とするお客様はサポートケースを開く必要があります Red Hat Customer Portal そして適切な加速修正オプションについて話し合います。最速のサポートのために、パッチを当てるべき正確なカーネルバージョンと同様にCVE IDまたはバグ番号を含めてください。を使用してカーネルバージョンを取得します。 uname -r コマンド。

6.2. kpatchのコンポーネント (機械翻訳)

のコンポーネント kpatch 以下の通り：

kpatch.service
A systemd に必要なサービス multiuser.target これをロードします kpatch ブート時にモジュール
パッチモジュール

  • 新しいカーネルコードの配送メカニズム。
  • これは、適用されているパッチに一致する別のカーネルモジュールです。
  • パッチモジュールには、カーネルに必要な修正プログラムのコードが含まれています。
  • パッチモジュールは livepatch カーネルサブシステムと置き換えられるオリジナルの関数についての情報を、置き換え関数への対応するポインタと共に提供します。
の kpatch 効用
パッチモジュールを管理するためのコマンドラインツール。

6.3. kpatchのしくみ (機械翻訳)

の kpatch カーネルパッチソリューションは livepatch 古い機能を新しい機能にリダイレクトするカーネルサブシステム。ライブカーネルパッチをシステムに適用すると、次のことが起こります。

  1. モジュールでコンパイルした新しいコードは、/var/lib/kpatch/ ディレクトリーにコピーされ、次回の起動時に systemd を介して、カーネルへの再適用として登録されます。
  2. kpatchモジュールが実行中のカーネルにロードされ、新しい関数が ftrace 新しいコードのメモリ内の場所へのポインタを持つメカニズム。
  3. カーネルがパッチを当てられた関数にアクセスすると、それは以下によってリダイレクトされます。 ftrace 元の関数をバイパスし、カーネルをパッチを当てたバージョンの関数にリダイレクトするメカニズム。

図6.1 kpatchのしくみ

rhel kpatch overview

6.4. kpatchモジュールのインストール (機械翻訳)

この手順では、kpatchユーティリティーを使用して、kpatch モジュールをインストールする方法を説明します。

警告

kpatch モジュールは、お客様の特殊な用途のために Red Hat が提供しているものではないため、Red Hat は、kpatch モジュールを使用しないことを強くお勧めします。

前提条件

  • インストール済み kpatch 効用インストールする kpatch, 次のコマンドを実行してください。 

    # yum install kpatch

  • とRPMパッケージ kpatch モジュール。

    kpatchモジュールを入手するには、サポートケースを開いてください。サポートケースでは、kpatchパッチが必要であることを示してください。コマンドによって返されるカーネルのバージョンについても通知します。 

    $ uname -r

    kpatchにより修正される必要がある Bugzilla の問題も表示できます。

    サポートケースを作成する方法は、How do I open and manage a support case on the Customer Portal? を参照してください。

手順

  1. インストールされているkpatchモジュールを一覧表示して、パッチがインストールされているかどうかを確認します。 

    # kpatch list
Loaded patch modules:
kpatch_4_18_0_100_1_1
Installed patch modules:
kpatch_4_18_0_100_1_1 (4.18.0-100.el8.x86_64)
kpatch_4_18_0_200_1_1 (4.18.0-200.el8.x86_64)

    出力は、モジュールがカーネルにロードされたことを示しています。つまり、カーネルには最新の修正プログラムが適用されています。 kpatch-patch- 4_18_0_100-1-1.el8.x86_64.rpm パッケージ。それはまたそれがに保存されたことを示します /var/lib/kpatch/ によってロードされるディレクトリ systemd 将来、カーネル4.18.0-100と4.18.0-200に再起動します。

  2. kpatchモジュールをインストールしてください。

    • kpatchモジュールがインストールされていない場合は、RPMパッケージを次のようにインストールしてください。 yum。たとえば、インストールするには kpatch-patch-4.18.0-100.el8.x86_64.rpm, 次のコマンドを発行します。 

      # yum install kpatch-patch-4_18_0_100-1-1.el8.x86_64.rpm

      上記のコマンド例は、kpatchモジュールをインストールしてロードします。

    • 古いバージョンのkpatchモジュールがインストールされている場合は、次のコマンドを使って更新します。 yum。たとえば、 kpatch-patch-4_18_0_100-1-2.el8.x86_64.rpm 実行します。 

      # yum update kpatch-patch-4_18_0_100-1-2.el8.x86_64.rpm

      RPMパッケージをアップグレードすると、実行中のカーネル内の関連するカーネルモジュールが自動的に置き換えられ、 /var/lib/kpatch/ 構造

      注記

      RPMパッケージのkpatchモジュールは累積的です。したがって、kpatch-patch-4_18_0_100-1-1のインストールをスキップして、利用可能であればkpatch-patch-4_18_0_100-1-2のインストールを開始することもできます。

  3. kpatchモジュールをロードします。 

    # kpatch load kpatch_4_18_0_200_1_1

    上記のコマンド例は、インストールされているkpatchモジュールをロードする方法を示しています。

  4. 次のコマンドを実行して、kpatchモジュールがロードされたかどうかを確認します。 

    # kpatch list

6.5. kpatchモジュールを削除する (機械翻訳)

この手順では、インストール済みのkpatchモジュールを削除する方法について説明します。 kpatch 効用

手順

  1. インストールされているkpatchモジュールを一覧表示します。 

    # kpatch list
Loaded patch modules:
kpatch_4_18_0_100_1_1
Installed patch modules:
kpatch_4_18_0_100_1_1 (4.18.0-100.el8.x86_64)
kpatch_4_18_0_200_1_1 (4.18.0-200.el8.x86_64)

    上記の出力例は、 kpatch_4_18_0_100_1_1 そして kpatch_4_18_0_200_1_1 kpatchモジュールがインストールされています。

  2. 適切なkpatchモジュールをアンロードします。 

    # kpatch unload kpatch-4_18_0_100-1-2

  3. kpatchモジュールをアンインストールします。

    • kpatchを使う： 

      # kpatch uninstall kpatch-4_18_0_100-1-2

      上記のコマンドは、からkpatchモジュールをアンインストールします。 /var/lib/kpatch/ ディレクトリ。

      このコマンドのデフォルトの動作は、アンインストールです。 kpatch 現在のカーネルバージョンに対応するカーネルから。ただし、別のカーネルバージョンを指定することができます。 kernel-version オプション： 

      # kpatch uninstall --kernel-version 4.18.0-200.el8.x86_64 kpatch-4_18_0_200-1-1

    • yumを使う： 

      # yum erase kpatch-patch-4_18_0_100-1-1.el8.x86_64

      上記のコマンドはkpatch RPMパッケージをアンインストールし、パッチモジュールも削除します。 /var/lib/kpatch/。

6.6. kpatchのサポート (機械翻訳)

  • ライブカーネルは、プレミアムSLAサブスクリプションをお持ちのお客様にサポートされています。
  • ライブカーネルパッチは、現在の非同期エラータフェーズ内のアクティブなRed Hat Enterprise Linux 8メンテナンスストリームでのみサポートされています。見る Red Hat Enterprise Linux Life Cycle 現在のサポートフェーズについては。
  • 現時点では、ライブカーネルパッチはExtended Update Support（EUS）で利用できません。
  • ライブカーネルパッチは、Red Hat Enterprise Linux for Real Time（RT）カーネルではサポートされていません。
  • Red Hatは、1つのカーネルバージョンにつき1つのカーネルモジュールを含む1つのRPMをサポートしています。たとえば、お客様が1つのカーネルバージョンに対して複数のパッチを要求した場合、それらのパッチは1つのRPMにまとめられます。
  • ハードウェアの有効化を含め、すべての問題がライブカーネルパッチ適用の対象となるとは限りません。

6.7. サードパーティ製のライブパッチのサポート (機械翻訳)

kpatch Red Hatがサポートしている唯一のライブカーネルパッチ適用ユーティリティは、Red Hatサポート契約を通じて提供されるRPMモジュールです。Red Hatは、Red Hat自体が提供していないライブカーネルパッチをサポートしません。

サードパーティ製のライブパッチで発生する問題のサポートが必要な場合は、根本的な原因の特定が必要な調査の最初に、ライブカーネルパッチ適用ベンダーと一緒にケースを開くことをお勧めします。これにより、ベンダーが許可する場合にはソースコードを提供することができ、またその調査組織は調査をRed Hatサポートにエスカレートする前に根本原因の特定を支援することができます。

サードパーティ製のライブカーネルパッチを使用して実行されているシステムの場合、Red HatはRed Hatの出荷およびサポートされているソフトウェアによる複製を求める権利を留保します。これが不可能な場合は、ライブパッチを適用せずに同様のシステムとワークロードをテスト環境に展開し、同じ動作が見られるかどうかを確認する必要があります。

サードパーティのソフトウェアサポートポリシーの詳細については、 How does Red Hat Global Support Services handle third-party software, drivers, and/or uncertified hardware/hypervisors or guest operating systems?

6.8. kpatchの制限 (機械翻訳)

  • kpatch 汎用のカーネルアップグレードメカニズムではありません。システムの再起動がすぐには不可能な場合に、単純なセキュリティとバグ修正の更新を適用するために使用されます。
  • 使用しないでください SystemTap または kprobe パッチのロード中またはロード後のツール。このようなプローブが削除されるまでパッチは有効にならない可能性があります。
  • 使用中にシステムを一時停止または休止状態にしないでください。 kpatch。これにより、パッチが一時的に無効になる可能性があります。

第7章 アプリケーションの制限を設定する (機械翻訳)

システム管理者は、制御グループのカーネル機能を使用して、システム上のアプリケーションが安定してメモリ不足にならないように、制限を設定し、プロセスのハードウェアリソースに優先順位を付け、または分離します。

7.1. コントロールグループとは (機械翻訳)

コントロールグループ プロセスを階層的に順序付けられたグループにまとめることを可能にするLinuxカーネルの機能です - cgroups。階層（コントロールグループツリー）は、以下の構造を提供することによって定義されます。 cgroups デフォルトでマウントされている仮想ファイルシステム /sys/fs/cgroup/ ディレクトリ。それはサブディレクトリを作成して削除することによって手動で行われます /sys/fs/cgroup/。代わりに、 systemd システムおよびサービスマネージャ

次にリソースコントローラ（カーネルコンポーネント）は、次のプロセスの動作を変更します。 cgroups これらのプロセスのシステムリソース（CPU時間、メモリ、ネットワーク帯域幅、またはさまざまな組み合わせなど）を制限、優先順位付け、または割り当てることによって。

の付加価値 cgroups アプリケーションとユーザーの間でハードウェアリソースの分割を可能にするプロセス集約です。それによって、全体的な効率、安定性およびユーザの環境の安全性の向上を達成することができる。

7.1.1. 制御グループのバージョン1 (機械翻訳)

制御グループのバージョン1 （cgroups-v1）リソースごとのコントローラ階層を提供します。つまり、CPU、メモリ、I / Oなどの各リソースには、独自の制御グループ階層があります。1つのコントローラーがそれぞれのリソースを管理する際に別のコントローラーと調整できるように、異なる制御グループ階層を組み合わせることができます。ただし、2つのコントローラが異なるプロセス階層に属している可能性があるため、適切な調整ができません。

の cgroups-v1 コントローラは長い期間にわたって開発されたものであり、その結果、制御ファイルの動作と命名は統一されていません。

このサブセクションは、Devconf.cz 2019プレゼンテーションに基づいています。[1]

7.1.2. コントロールグループバージョン2 (機械翻訳)

階層の柔軟性に起因するコントローラの調整に関する問題は、 制御グループのバージョン2。

コントロールグループバージョン2 （cgroups-v2）は、すべてのリソースコントローラがマウントされる単一の制御グループ階層を提供します。

制御ファイルの動作と命名は、異なるコントローラ間で一貫しています。

このサブセクションは、Devconf.cz 2019プレゼンテーションに基づいています。[2]

警告

Red Hat Enterprise Linux 8が提供します cgroups-v2 限られた数のリソースコントローラを使用したテクノロジプレビューとして。関連するリソースコントローラの詳細については、 cgroups-v2 release note。

関連資料

  • リソースコントローラの詳細については、 What are kernel resource controllers セクションと cgroups(7) マニュアルページ
  • cgroups の階層と cgroups バージョンの詳細は、man ページの cgroups(7) を参照してください。

7.2. カーネルリソースコントローラとは (機械翻訳)

この節では、Linuxカーネルのリソースコントローラの概念と、そのためにサポートされているコントローラの一覧を示します。 制御グループのバージョン1 （cgroups-v1）と 制御グループのバージョン2 （cgroups-v2Red Hat Enterprise Linux 8では、

リソースコントローラ。 cgroup サブシステムは、CPU時間、メモリ、ネットワーク帯域幅、ディスクI / Oなどの単一のリソースを表します。Linuxカーネルは、さまざまなリソースコントローラを提供しています。 systemd システムおよびサービスマネージャ現在マウントされているリソースコントローラのリストを /proc/cgroups エントリ。

以下のコントローラが利用可能です。 cgroups-v1：

  • blkio - ブロックデバイスとの間の入出力アクセスに制限を設定します。
  • cpu - CPUスケジューラを使用して、制御グループタスクにCPUへのアクセスを提供します。それは一緒にマウントされています cpuacct 同じマウント上のコントローラ。
  • cpuacct - 制御グループ内のタスクによって使用されるCPUリソースに関する自動レポートを作成します。それは一緒にマウントされています cpu 同じマウント上のコントローラ。
  • cpuset - マルチコアシステム上の個々のCPUとメモリノードを制御グループ内のタスクに割り当てます。
  • devices - 制御グループ内のタスクに対するデバイスへのアクセスを許可または拒否します。
  • freezer - 制御グループ内のタスクを中断または再開する。
  • memory - 制御グループ内のタスクによるメモリ使用量の制限を設定し、それらのタスクによって使用されるメモリリソースに関する自動レポートを生成します。
  • net_cls - ネットワークパケットをクラス識別子でタグ付けします（classidLinuxトラフィックコントローラを有効にします。 tc 特定のコントロールグループタスクから発信されたパケットを識別するため）のサブシステム net_cls, 、 net_filter （iptables）は、このタグを使ってそのようなパケットに対してアクションを実行することもできます。の net_filter ネットワークソケットにファイアウォール識別子をタグ付けします（fwidLinuxのファイアウォール（ iptables 特定のコントロールグループタスクから発信されたパケットを識別するため）
  • net_prio - ネットワークトラフィックの優先順位を設定します。
  • pids - コントロールグループ内のプロセスとその子の数に制限を設定します。
  • perf_event - モニタリングを可能にします cgroups とともに perf ツール。
  • rdma - コントロールグループ内のリモートダイレクトメモリアクセス/ InfiniBand固有のリソースに制限を設定します。
  • hugetlb - 大容量の仮想メモリページを使用し、これらのページにリソース制限を強制することができます。

以下のコントローラが利用可能です。 cgroups-v2：

  • io - フォローアップ blkio の cgroups-v1
  • memory - フォローアップ memory の cgroups-v1
  • pids - と同じ pids に cgroups-v1
  • rdma - と同じ rdma に cgroups-v1
  • cpu - フォローアップ cpu そして cpuacct の cgroups-v1
重要

特定のリソースコントローラは、次のいずれかで使用できます。 cgroups-v1 階層または cgroups-v2 両方に同時にはありません。

関連資料

  • 一般的なリソースコントローラの詳細については、 cgroups(7) マニュアルページ
  • 特定のリソースコントローラーの詳細は、/usr/share/doc/kernel-doc-<kernel_version>/Documentation/cgroups-v1/ ディレクトリーのドキュメントを参照してください。
  • cgroups-v2 の詳細は、man ページの cgroups(7) を参照してください。

7.3. 名前空間とは (機械翻訳)

このセクションでは、名前空間の概念、およびそれらとの関係について説明します。 対照群 そして資源管理。

ネームスペースはカーネル機能であり、これを使用して分離されたシステムリソースを仮想的に表示できます。 /proc/self/ns/cgroup インタフェース。プロセスをシステムリソースから分離することで、プロセスが対話できるものを指定して制御できます。

その目的は、グローバルネームスペースから特定の場所への特権データの漏洩を防ぐことです。 cgroup コンテナの移行など、他の機能も有効にします。

以下の名前空間がサポートされています。

  • Mount

    • mount名前空間はファイルシステムのマウントポイントを分離し、各プロセスが動作するために別々のファイルシステムスペースを持つことを可能にします。

  • UTS

    • ホスト名とNISドメイン名

  • IPC

    • System V IPC、POSIXメッセージ待ち行列

  • PID

    • プロセスID

  • Network

    • ネットワーク機器、スタック、ポートなど

  • User

    • ユーザーIDとグループID

  • Control groups

    • cgroupを分離します

関連資料

  • ネームスペースの詳細については、 namespaces(7) そして cgroup_namespaces(7) マニュアルページ
  • 詳細について cgroups, 、 見る What are control groups。

7.4. 仮想ファイルシステムを介した制御グループの使用 (機械翻訳)

次のセクションでは、の作成、変更、および削除に関連するタスクの概要を説明します。 対照群 （cgroupsを使用して /sys/fs/ 仮想ファイルシステム

7.4.1. cgroups-v1によるアプリケーションへのメモリ制限の設定 (機械翻訳)

この手順では、 /sys/fs/ アプリケーションへのメモリ制限を設定するための仮想ファイルシステム 制御グループのバージョン1 （cgroups-v1）

前提条件
手順

  1. メモリリソースコントローラディレクトリにサブディレクトリを作成します。 

    ＃mkdir / sys / fs / cgroup / memory / example /

    上記のディレクトリは、特定のプロセスを配置し、そのプロセスに特定のメモリ制限を適用できる制御グループを表します。

  2. 必要に応じて、新しく作成されたコントロールグループを調べます。 

    # ll /sys/fs/cgroup/memory/example/ -rw-r—​r--.1 root root 0 Apr 25 16:34 cgroup.clone_children --w—​w—​w-.1 root root 0 Apr 25 16:34 cgroup.event_control -rw-r—​r--.1 root root 0 Apr 25 16:42 cgroup.procs …​

    出力例では、 example 親リソースコントローラから継承した制御グループ。デフォルトでは、新しく作成されたコントロールグループは、制限なしでシステムのメモリ全体へのアクセスを継承しました。

  3. コントロールグループのメモリ制限を設定します。 

    # echo 700000 > /sys/fs/cgroup/memory/example/memory.limit_in_bytes

    このコマンド例では、メモリ制限を700キロバイトに設定しています。

  4. 制限を確認してください。 

    # cat /sys/fs/cgroup/memory/example/memory.limit_in_bytes 696320

    出力例では、メモリ制限値を4096バイトの倍数 - 1カーネルページサイズとして表示しています。

  5. アプリケーションのPIDをコントロールグループに追加します。 

    # echo 23453 > /sys/fs/cgroup/memory/example/cgroup.procs

    このコマンド例では、目的のアプリケーションがコントロールグループで設定されているメモリ制限を超えないようにします。あなたのPIDはシステムの既存のプロセスから来るべきです、 PID 23453 これは架空のものです。

  6. アプリケーションが指定されたコントロールグループで実行されていることを確認します。 

    ＃ps -o cgroup 23453 CGROUP 11：メモリ：/ example、5：デバイス：/system.slice/example.service,4：pids：/system.slice/example.service,1：name = systemd：/system.slice /example.service

    上記の出力例は、目的のアプリケーションのプロセスが example アプリケーションのプロセスにメモリ制限を適用するコントロールグループ。

関連資料
  • リソースコントローラの詳細については、 What are kernel resource controllers セクションと cgroups(7) マニュアルページ
  • /sys/fs/ の詳細は、man ページの sysfs(5) を参照してください。

[1] Linux Control Group v2 - はじめに、Waiman LongによるDevconf.cz 2019プレゼンテーション
[2] Linux Control Group v2 - はじめに、Waiman LongによるDevconf.cz 2019プレゼンテーション

第8章 BPF Compiler Collectionを使用したシステムパフォーマンスの分析 (機械翻訳)

システム管理者として、BPF Compiler Collection（BCC）ライブラリーを使用して、ご使用のLinuxオペレーティング・システムのパフォーマンスを分析し、情報を収集するためのツールを作成します。これらのツールは他のインターフェースでは入手困難です。

重要

BCCライブラリはRed Hat Enterprise Linux 8のテクノロジープレビューです。詳細は Technology Preview Features Support Scope を参照してください。

8.1. BCC (機械翻訳)

BPF Compiler Collection（BCC）は、拡張Berkeley Packet Filter（eBPF）プログラムの作成を容易にするライブラリーです。彼らの主なユーティリティは、オーバーヘッドやセキュリティの問題を経験することなく、OSパフォーマンスとネットワークパフォーマンスを分析することです。

BCCは、ユーザーがeBPFの深い技術的詳細を知る必要性を排除し、次のようなすぐに使える多くの出発点を提供します。 bcc-tools あらかじめ作成されたeBPFプログラムを含むパッケージ。

注記

eBPFプログラムは、ディスクI / O、TCP接続、プロセス作成などのイベントでトリガーされます。カーネル内の安全な仮想マシンで実行されるため、プログラムによってカーネルがクラッシュ、ループ、または応答しなくなることは考えられません。

関連資料

  • BCCの詳細については、 /usr/share/doc/bcc/README.md ファイル。

8.2. BCCのインストール (機械翻訳)

このセクションでは、インストール方法について説明します。 bcc-tools BPF Compiler Collection（BCC）ライブラリーを含むパッケージ。

前提条件

手順

  1. インストール bcc-tools： 

    # yum install bcc-tools

    インストールが完了すると、ツールは /usr/share/bcc/tools/ ディレクトリ。

  2. 必要に応じて、ツールを調べます。 

    # ll /usr/share/bcc/tools/
...
-rwxr-xr-x. 1 root root  4198 Dec 14 17:53 dcsnoop
-rwxr-xr-x. 1 root root  3931 Dec 14 17:53 dcstat
-rwxr-xr-x. 1 root root 20040 Dec 14 17:53 deadlock_detector
-rw-r--r--. 1 root root  7105 Dec 14 17:53 deadlock_detector.c
drwxr-xr-x. 3 root root  8192 Mar 11 10:28 doc
-rwxr-xr-x. 1 root root  7588 Dec 14 17:53 execsnoop
-rwxr-xr-x. 1 root root  6373 Dec 14 17:53 ext4dist
-rwxr-xr-x. 1 root root 10401 Dec 14 17:53 ext4slower
...

    の doc 上記のリストのディレクトリには、各ツールのドキュメントが含まれています。

8.3. パフォーマンス分析のための選択されたbccツールの使用 (機械翻訳)

このセクションでは、BPF Compiler Collection（BCC）ライブラリーから作成された特定のプログラムを使用して、イベントごとにシステムのパフォーマンスを効率的かつ安全に分析する方法について説明します。BCCライブラリ内の事前作成プログラムのセットは、追加プログラム作成のための例として役立ちます。

前提条件

execsnoopを使ってシステムプロセスを調べる

  1. 実行する execsnoop 1つの端末でプログラム 

    # /usr/share/bcc/tools/execsnoop

  2. 別の端末で例えば以下を実行してください。 

    $ ls /usr/share/bcc/tools/doc/

    これにより、ls コマンドの短命プロセスが作成されます。

  3. 実行中の端末 execsnoop 次のような出力が表示されます。 

    PCOMM	PID    PPID   RET ARGS
ls   	8382   8287     0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/
sed 	8385   8383     0 /usr/bin/sed s/^ *[0-9]\+ *//
...

    の execsnoop programは、新しいプロセスごとに1行の出力を表示し、それがシステムリソースを消費します。このような非常にすぐに実行されるプログラムのプロセスさえ検出します。 ls, ほとんどの監視ツールはそれらを登録しません。

    上記の結果は、親プロセス名（ls）、そのプロセスID（5076）、親プロセスID（2931）の戻り値 exec() システムコール（0プログラムコードを新しいプロセスにロードします。最後に、出力は引数付きで起動したプログラムの場所を表示します。/usr/bin/ls --color=auto /usr/share/bcc/tools/doc/）

execsnoopの詳細、例、およびオプションを表示するには、/usr/share/bcc/tools/doc/execsnoop_example.txt ファイルを参照してください。

詳細について exec(), 、 見る exec(3) マニュアルページ

opensnoopを使用してコマンドがオープンしたファイルを追跡する

  1. 実行する opensnoop 1つの端末でプログラム 

    # /usr/share/bcc/tools/opensnoop -n uname

    上記のファイルの出力を印刷します。 uname コマンド。

  2. 別の端末で次のコマンドを実行してください。 

     $ uname

    上記のコマンドは、次のステップで取り込まれる特定のファイルを開きます。

  3. 実行中の端末 opensnoop 次のような出力が表示されます。 

    PID    COMM 	FD ERR PATH
8596   uname 	3  0   /etc/ld.so.cache
8596   uname 	3  0   /lib64/libc.so.6
8596   uname 	3  0   /usr/lib/locale/locale-archive
...

    の opensnoop プログラムは open() システム全体に渡ってシステムコールを実行し、ファイルごとに1行の出力を表示します。 uname 途中で開こうとしました。

    上記の結果は、プロセス ID (PID)、プロセス名 (COMM)、およびファイル記述子 (FD) を表示します。open() が返す値は、開いているファイルを参照してください。最後に、出力にエラーの列が表示されます（ERR）ファイルの場所 open() 開こうとします（PATH）

    コマンドが存在しないファイルを読み込もうとすると、 FD カラムリターン -1 そしてその ERR columnは関連するエラーに対応する値を表示します。結果として、 opensnoop 正しく動作しないアプリケーションを特定するのに役立ちます。

opensnoopの詳細、例、およびオプションを表示するには、/usr/share/bcc/tools/doc/opensnoop_example.txt ファイルを参照してください。

詳細について open(), 、 見る open(2) マニュアルページ

biotopを使用してディスク上の入出力操作を調べる

  1. 実行する biotop 1つの端末でプログラム 

    # /usr/share/bcc/tools/biotop 30

    このコマンドを使用すると、ディスク上のI / O操作を実行する最上位プロセスを監視できます。引数は、コマンドが30秒の要約を生成することを保証します。

    注記

    引数が指定されていない場合、出力画面はデフォルトで1秒ごとに更新されます。

  2. 別の端末で例えば以下を実行してください。 

    # dd if=/dev/vda of=/dev/zero

    上記のコマンドは、ローカルハードディスクデバイスからコンテンツを読み取り、その出力を /dev/zero ファイル。この手順では、説明のために特定のI / Oトラフィックを生成します。 biotop。

  3. 実行中の端末 biotop 次のような出力が表示されます。 

    PID    COMM             D MAJ MIN DISK       I/O  Kbytes     AVGms
9568   dd               R 252 0   vda      16294 14440636.0  3.69
48     kswapd0          W 252 0   vda       1763 120696.0    1.65
7571   gnome-shell      R 252 0   vda        834 83612.0     0.33
1891   gnome-shell      R 252 0   vda       1379 19792.0     0.15
7515   Xorg             R 252 0   vda        280  9940.0     0.28
7579   llvmpipe-1       R 252 0   vda        228  6928.0     0.19
9515   gnome-control-c  R 252 0   vda         62  6444.0     0.43
8112   gnome-terminal-  R 252 0   vda         67  2572.0     1.54
7807   gnome-software   R 252 0   vda         31  2336.0     0.73
9578   awk              R 252 0   vda         17  2228.0     0.66
7578   llvmpipe-0       R 252 0   vda        156  2204.0     0.07
9581   pgrep            R 252 0   vda         58  1748.0     0.42
7531   InputThread      R 252 0   vda         30  1200.0     0.48
7504   gdbus            R 252 0   vda          3  1164.0     0.30
1983   llvmpipe-1       R 252 0   vda         39   724.0     0.08
1982   llvmpipe-0       R 252 0   vda         36   652.0     0.06
...

    その結果、 dd プロセス、プロセスID 9568で、16,294の読み取り操作を実行しました。 vda ディスク。読み取り操作は、平均入出力時間3.69ミリ秒で合計14,440,636キロバイトに達しました。

biotopの詳細、例、およびオプションを表示するには、/usr/share/bcc/tools/doc/biotop_example.txt ファイルを参照してください。

詳細について dd, 、 見る dd(1) マニュアルページ

xfsslowerを使用して予想外に遅いファイルシステム操作を公開する

  1. 実行する xfsslower 1つの端末でプログラム 

    # /usr/share/bcc/tools/xfsslower 1

    上記のコマンドは、XFSファイルシステムが読み取り、書き込み、開く、または同期の実行に費やす時間を測定します（fsync） オペレーション。の 1 引数を指定すると、プログラムは1ミリ秒より遅い操作のみを表示します。

    注記

    引数が指定されていない場合は、 xfsslower デフォルトでは10 msより遅い操作を表示します。

  2. 他の端末では、例えば以下のように実行します。 

    $ vim text

    上記のコマンドは、テキストファイルを vim XFSファイルシステムとの対話を開始するためのエディタ。

  3. 実行中の端末 xfsslower 前の手順でファイルを保存したときに似たようなものが表示されます。 

    TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
13:07:14 b'bash'        4754   R 256     0           7.11 b'vim'
13:07:14 b'vim'         4754   R 832     0           4.03 b'libgpm.so.2.1.0'
13:07:14 b'vim'         4754   R 32      20          1.04 b'libgpm.so.2.1.0'
13:07:14 b'vim'         4754   R 1982    0           2.30 b'vimrc'
13:07:14 b'vim'         4754   R 1393    0           2.52 b'getscriptPlugin.vim'
13:07:45 b'vim'         4754   S 0       0           6.71 b'text'
13:07:45 b'pool'        2588   R 16      0           5.58 b'text'
...

    上記の各行はファイルシステム内の操作を表しており、一定のしきい値を超える時間がかかりました。 xfsslower 予想外に遅い操作の形をとることができる、起こりうるファイルシステムの問題を明らかにするのが得意です。

    の T 列は操作タイプを表します（Read /W儀式/S（） OFF_KB ファイルオフセット（KB）です。 FILENAME プロセスファイル（COMM）が読み取り、書き込み、または同期しようとしています。

xfsslowerの詳細、例、およびオプションを表示するには、/usr/share/bcc/tools/doc/xfsslower_example.txt ファイルを参照してください。

詳細について fsync, 、 見る fsync(2) マニュアルページ

法律上の通知

Copyright © 2019 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.