Menu Close
Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
パフォーマンスチューニングガイド
RHEL 7 でサブシステムのスループットの監視および最適化
概要
第1章 はじめに
- 設定前のバックアップ
- Red Hat Enterprise Linux 7 のデフォルト設定は、負荷がそれほど大きくない状態で実行されているほとんどのサービスに適しています。特定のサブシステムのパフォーマンスを向上させると、別のシステムに悪い影響が及ぶことがあります。システムをチューニングする前に、すべてのデータおよび設定情報をバックアップしてください。
- 本番稼働用でない設定のテスト
- 『パフォーマンスチューニングガイド』で示されている手順は Red Hat エンジニアによってラボと現場で入念にテストされています。ただし、Red Hat は、これらの設定を本番稼働システムに適用する前に、計画されたすべての設定を安全なテスト環境でテストすることをお勧めします
本書の対象読者
- システム管理者
- 『パフォーマンスチューニングガイド』では、システム管理者が特定の目的のために Red Hat Enterprise Linux 7 を最適化できるよう各設定オプションの効果について詳しく説明します。本書の手順は Red Hat Certified Engineer (RHCE) 認定書または同等の経験 (3〜5 年の Linux ベースシステムのデプロイおよび管理経験) を持つシステム管理者向けです。
- システムおよびビジネスアナリスト
- 本書では、Red Hat Enterprise Linux 7 のパフォーマンス機能について高度な説明をします。特定の負荷でサブシステムのパフォーマンスがどのように変化するかについての情報が提供されるため、アナリストは Red Hat Enterprise Linux 7 が各ユースケースに適しているかどうかを判断できます。可能な場合、『パフォーマンスチューニングガイド』では、読者に詳細なドキュメンテーションが紹介されます。これにより、読者は、インフラストラクチャーとデプロイメントの提案に必要な詳細なデプロイメントおよび最適化ストラテジーを作成するのに必要となる詳しい知識を得ることができます。
第2章 パフォーマンス監視ツール
2.1. /proc
proc
「ファイルシステム」は、Linux カーネルの現在の状態を表すファイル階層で構成されるディレクトリーになります。ユーザーやアプリケーションはこのファイルシステムでシステムのカーネル状態を確認することができます。
proc
ディレクトリーには、システムのハードウェアおよび実行中のプロセスに関する情報も格納されています。これらファイルのほとんどは読み取り専用ですが、一部のファイル (主に /proc/sys
内のファイル) はユーザーやアプリケーションが操作することで、設定変更をカーネルに伝達できるものもあります。
proc
ディレクトリー内のファイルの表示および編集に関する詳細は『Red Hat Enterprise Linux 7 システム管理者のガイド』 を参照してください。
2.2. GNOME システムモニター
- システム
- このタブには、システムのハードウェアおよびソフトウェアに関する基本的な情報が表示されます。
- プロセス
- 実行中のプロセスおよびそれらプロセスの関係に関する詳細情報を表示します。表示されたプロセスにフィルターをかけ特定のプロセスを見つけやすくすることができます。また、表示されたプロセスに起動、停止、強制終了、優先順位の変更などの動作を実行することもできます。
- リソース
- このタブには、現在の CPU 時間の使用状況、メモリーおよびスワップ領域の使用量、およびネットワーク使用量が表示されます。
- ファイルシステム
- マウントされているファイルシステムの全一覧、ファイルシステムのタイプやマウントポイント、メモリー使用量など各ファイルシステムの基本情報が表示されます。
2.3. ビルトインのコマンドラインツール
2.3.1. top
$ man top
2.3.2. ps
$ man ps
2.3.3. 仮想メモリーの統計 (vmstat)
$ man vmstat
2.3.4. System Activity Reporter (sar)
-i
オプションを使って間隔を秒単位で設定することもできます。sar -i 60 と指定すると sar は CPU の使用量を毎分チェックすることになります。
$ man sar
2.4. perf
2.5. turbostat
- 不変タイムスタンプカウンター
- APERF モデル固有のレジスター
- MPERF モデル固有のレジスター
$ man turbostat
2.6. iostat
await
値とその値が多くなる原因の詳細については、Red Hat ナレッジベースの記事「iostat によって報告される await 値は何を示していますか?」を参照してください。
2.7. irqbalance
$ man irqbalance
2.8. ss
$ man ss
2.9. numastat
numa_hit
値と低い numa_miss
値で示されます。Numastat ではシステム内の NUMA ノード全体でシステムおよびプロセスメモリーがどのように分散されているかを表示するコマンドラインオプションも用意されています。
$ man numastat
2.10. numad
/proc
ファイルシステム内の情報に定期的にアクセスしてノードごとに使用可能なシステムリソースを監視します。指定されたリソース使用量のレベルを維持、必要に応じて NUMA ノード間でプロセスを移動しリソース割り当てバランスの再調整を行います。システムの NUMA ノードのサブセットで使用量が著しいプロセスを特定し隔離することで最適な NUMA パフォーマンスの実現を目指します。
$ man numad
2.11. SystemTap
2.12. OProfile
- パフォーマンスのモニタリングサンプルが正確ではない場合があります。プロセッサーは順番通りに指示を実行しない場合があるので、割り込みを発生させた指示自体ではなく、近辺の指示からサンプルを記録する可能性があります。
- OProfile はプロセスが複数回にわたって開始、停止することを想定しています。このため、複数の実行からのサンプルの累積が可能です。前回の実行から得たサンプルデータの消去が必要な場合があります。
- アクセスが CPU に限定されているプロセスの問題の特定に特化しています。そのため、他のイベントでロックを待機している間はスリープ状態のプロセスを特定する場合には役に立ちません。
/usr/share/doc/oprofile-version
に格納されているドキュメントをご覧いただくこともできます。
2.13. Valgrind
$ man valgrind
/usr/share/doc/valgrind-version
にインストールされます。
2.14. pqos
- モニタリング
- Cache Monitoring Technology(CMT)を使用した last Level Cache(LLC)の使用および競合監視
- Memory Bandwidth Monitoring(MBM)テクノロジーを使用したスレッドごとのメモリー帯域幅監視
- 割り当て
- Cache Allocation Technology(CAT)を使用して特定のスレッドおよびプロセスで利用可能な LLC 領域の量の制御
- コードおよびデータ優先度 (CDP) テクノロジーを使用した LLC でのコードおよび配置の制御。
#
pqos --show --verbose
関連情報
- pqos の使用方法は、pqos(8) man ページを参照してください。
- CMT、MBM、CAT、および CDP プロセッサー機能の詳細は、Intel の公式ドキュメント「インテル® リソース・ディレクター・テクノロジー (インテル® RDT)」を参照してください。
第3章 Tuned
3.1. Tuned の概要
udev
を使用して接続されたデバイスを監視し、選択されたプロファイルに従ってシステム設定を静的および動的にチューニングするデーモンです。Tuned は、高スループット、低レイテンシー、省電力などの一般的なユースケース向けの複数の定義済みプロファイルとともに配布されます。各プロファイル向けに定義されたルールを変更し、特定のデバイスのチューニング方法をカスタマイズできます。特定のプロファイルで行われたシステム設定のすべての変更を元に戻すには、別のプロファイルに切り替えるか、tuned サービスを非アクティブ化します。
no-daemon mode
で実行できます (常駐メモリーをまったく必要としません)。このモードでは、tuned は設定を適用し、終了します。このモードでは、D-Bus サポート、ホットプラグサポート、または設定のロールバックサポートを含むたくさんの tuned 機能が使用できないため、no-daemon mode
はデフォルで無効になります。no-daemon mode
を有効にするには、/etc/tuned/tuned-main.conf
ファイルで daemon = 0
を設定します。
sysctl
設定および sysfs
設定の適用と ethtool などの複数の設定ツールのワンショットアクティベーションから構成されます。また、Tuned はシステムコンポーネントの使用を監視し、その監視情報に基いてシステム設定を動的にチューニングします。
/etc/tuned/tuned-main.conf
ファイルを編集し、dynamic_tuning
フラグを 1
に変更することによって有効にできます。
3.1.1. プラグイン
disk
- デバイスおよび測定間隔ごとのディスク負荷 (IO 操作の数) を取得します。
net
- ネットワークカードおよび測定間隔ごとのネットワーク負荷 (転送済みパケットの数) を取得します。
load
- CPU および測定間隔ごとの CPU 負荷を取得します。
cpu
- CPU ガバナーを、
governor
パラメーターで指定された値に設定し、CPU 負荷に応じて PM QoS CPU DMA レイテンシーを動的に変更します。CPU 負荷がload_threshold
パラメーターで指定された値よりも小さい場合、レイテンシーはlatency_high
パラメーターで指定された値に設定されます。それ以外の場合は、latency_low
で指定された値に設定されます。レイテンシーを特定の値に強制し、さらに動的に変更しないようにすることもできます。これは、force_latency
パラメーターを必要なレイテンシー値に設定することにより実現できます。 eeepc_she
- CPU 負荷に応じて FSB 速度を動的に設定します。この機能は一部のネットブックで利用でき、Asus Super buf Engine としても知られています。CPU 負荷が
load_threshold_powersave
パラメーターで指定した値と同じかそれ未満の場合、プラグインは、she_powersave
パラメーターで指定した値に FSB の速度を設定します (FSB の頻度および対応する値の詳細は、カーネルのドキュメントを参照してください、提供されるデフォルト値はほとんどのユーザーに対して機能するはずです)。CPU 負荷がload_threshold_normal
パラメーターで指定した値と同じかそれより大きくなれば、FSB 速度がshe_normal
パラメーターによって指定された値に設定されます。静的チューニングはサポートされず、プラグインは透過的に無効になります (この機能のハードウェアサポートが検出されない場合) net
- wake-on-lan を
wake_on_lan
パラメーターで指定された値に設定します (ethtool ユーティリティーと同じ構文を使用します)。また、インターフェースの使用状況に応じてインターフェース速度が動的に変更します。 sysctl
- プラグインパラメーターで指定されたさまざまな
sysctl
設定を指定します。構文はname
=value
となります。ここで、name
は sysctl ツールにより提供されたものと同じ名前になります。このプラグインは、他のプラグインで指定できない設定を変更する必要がある場合に使用します (ただし、設定を特定のプラグインで指定できる場合は、そのプラグインを使用することが推奨されます)。 usb
- USB デバイスの autosuspend タイムアウトを、
autosuspend
パラメーターで指定した値に設定します。値が 0 の場合は、autosuspend が無効になります。 vm
transparent_hugepages
パラメーターのブール値に応じて Transparent Huge Page を有効または無効にします。audio
- 音声コーデックの autosuspend タイムアウトを
timeout
パラメーターで指定された値に設定します。現時点では、snd_hda_intel
とsnd_ac97_codec
がサポートされてます。値が0
の場合は、autosuspend が無効になります。また、ブール値パラメーターreset_controller
をtrue
に設定することにより、コントローラーを強制的にリセットすることもできます。 disk
- エレベーターを
elevator
パラメーターで指定された値に設定します。また、ALPM をalpm
パラメーターで指定された値に設定し、ASPM はaspm
パラメーターで指定された値、スケジューラークォンタムはscheduler_quantum
パラメーターで指定された値、ディスクスピンダウンのタイムアウトをspindown
パラメーターで指定された値に対して設定します。readahead
パラメーターで指定された値までディスク先読み読み出し、readahead_multiply
パラメーターで指定された定数によって現在のディスク読み取り先の値を乗算できます。さらに、このプラグインにより、現在のドライブ使用状況に応じてドライブの高度な電力管理設定と spindown タイムアウト設定が動的に変更されます。動的チューニングは、ブール値パラメーターdynamic
により制御でき、デフォルトで有効になります。注記異なるディスクの readahead 値を指定する tuned プロファイルを適用すると、ディスク先読みの値の設定がudev
ルールを使用して設定されている場合は、ディスク先読み値の設定が上書きされます。Red Hat では、tuned ツールを使用してディスク先読み値を調整することを推奨します。 mounts
disable_barriers
パラメーターのブール値に応じてマウントのバリアを有効または無効にします。script
- このプラグインは、プロファイルがロードまたはアンロードされたときに実行する外部スクリプトの実行に使用されます。スクリプトは、
start
またはstop
のいずれかの引数 (スクリプトがプロファイルのロード時またはアンロード時に呼び出されるかによって決まります) によって呼び出されます。スクリプトファイル名は、script
パラメーターによって指定できます。スクリプトで停止アクションを正しく実装し、変更したすべての設定を起動アクション中に元に戻す必要がああることに注意してください。ユーザーの利便性のために、functions
Bash ヘルパースクリプトがデフォルトでインストールされ、スクリプトで定義されたさまざまな機能をインポートして使用できます。この機能は、主に後方互換性を維持するために提供されます。この機能は最終手段として使用し、必要な設定を指定できる他のプラグインが存在する場合は、そのプラグインを使用することが推奨されます。 sysfs
- プラグインパラメーターで指定されたさまざまな
sysfs
設定を指定します。構文はname
=value
となります。ここで、name
は、使用する sysfs
パスです。このプラグインは、他のプラグインで指定できない設定を変更する必要がある場合に使用します (設定を特定のプラグインで指定できる場合は、そのプラグインを使用することが推奨されます)。 video
- ビデオカードのさまざまな省電力レベルを設定します (現時点では、Radeon カードのみがサポートされます)。省電力レベルは
radeon_powersave
パラメーターを使用して指定できます。サポートされる値はdefault
、auto
、low
、mid
、high
、およびdynpm
です。詳細については、http://www.x.org/wiki/RadeonFeature#KMS_Power_Management_Options を参照してください。このプラグインは試験目的で提供され、今後のリリースで変更されることがあることに注意してください。 bootloader
- カーネルブートコマンドラインにパラメーターを追加します。このプラグインは、レガシー GRUB 1 および GRUB 2 をサポートし、さらに Extensible Firmware Interface (EFI) を使用する GRUB をサポートします。
grub2_cfg_file
オプションを使用すると、grub2 設定ファイルのカスタマイズされた標準的でない場所を指定できます。これらのパラメーターは、現在の grub 設定とそのテンプレートに追加されます。カーネルパラメーターを有効にするには、マシンを再起動する必要があります。パラメーターは次の構文で指定できます。cmdline
=arg1 arg2 ... argn.
3.1.2. インストールと使用方法
yum install tuned
throughput-performance
- これは、コンピューターノードとして動作する Red Hat Enterprise Linux 7 オペレーティングシステムで事前に選択されます。このようなシステムの目的は、スループットパフォーマンスの最大化です。
virtual-guest
- これは、仮想マシンで事前に選択されます。この目的はパフォーマンスの最大化です。パフォーマンスの最大化に興味がない場合は、
balanced
またはpowersave
プロファイルに変更できます (下記参照)。 balanced
- これは、他のすべてのケースで事前に選択されます。この目的は、パフォーマンスと電力消費の調和です。
systemctl start tuned
systemctl enable tuned
tuned-adm
tuned-adm list
tuned-adm active
tuned-adm profile profile
tuned-adm profile powersave
throughput-performance
プロファイルでディスクに対して high
スループットを設定し、同時に spindown-disk
プロファイルでディスクスピンダウンを low
値に設定することが挙げられます。以下の例では、仮想マシンでの実行でパフォーマンスを最大化するようシステムが最適化され、同時に、低消費電力を実現するようシステムがチューニングされます (低消費電力が最優先である場合)。
tuned-adm profile virtual-guest powersave
tuned-adm recommend
tuned --help
3.1.3. カスタムプロファイル
/usr/lib/tuned/
ディレクトリーに格納されます。各プロファイルには独自のディレクトリーがあります。プロファイルは tuned.conf
という名前の主要設定ファイルとオプションのヘルパースクリプトなどの他のファイルから構成されます。
/etc/tuned/
ディレクトリーにプロファイルディレクトリーをコピーします。同じ名前のプロファイルが 2 つある場合は、/etc/tuned/
に含まれるプロファイルが使用されます。
/etc/tuned/
ディレクトリーで独自のプロファイルを作成して、特定のパラメーターのみが調整、または上書きされた /usr/lib/tuned/
に含まれるプロファイルを使用することもできます。
tuned.conf
ファイルには、複数のセクションが含まれます。[main]
セクションは 1 つだけ存在します。他のセクションはプラグインインスタンス向けの設定です。[main]
セクションを含むすべてのセクションはオプションです。ハッシュ記号 (#) で始まる行はコメントです。
[main]
セクションには、以下のオプションがあります。
include=profile
- 指定されたプロファイルがインクルードされます。たとえば、
include=powersave
の場合は、powersave
プロファイルがインクルードされます。
[NAME] type=TYPE devices=DEVICES
devices
行には、リスト、ワイルドカード (*)、および否定 (!) を含めることができます。また、ルールを組み合わせることもできますdevices
行がない場合は、TYPE
のシステムに存在する、または後で接続されたすべてのデバイスがプラグインインスタンスによって処理されます。これは、devices=*
を使用したときと同様です。プラグインのインスタンスが指定されない場合、プラグインは有効になりませんプラグインがさらに多くのオプションをサポートする場合は、プラグインセクションでそれらのプラグインを指定することもできます。オプションが指定されないと、デフォルト値が使用されます (インクルードされたプラグインで以前に指定されていない場合)。プラグインオプションの一覧は、「プラグイン」を参照してください。
例3.1 プラグインインスタンスの記述
sda
や sdb
などの sd
で始まるすべての候補に一致し、それらの候補に対するバリアは無効になりません。
[data_disk] type=disk devices=sd* disable_barriers=false
sda1
と sda2
を除くすべての候補に一致します。
[data_disk] type=disk devices=!sda1, !sda2 disable_barriers=false
[TYPE] devices=DEVICES
type
の行を省略することができます。タイプと同様に、インスタンスは名前で参照されます。上記の例は、以下のように書き換えることができます。
[disk] devices=sdb* disable_barriers=false
include
オプションを使用して同じセクションが複数回指定された場合は、設定がマージされます。競合のため、設定をマージできない場合は、競合がある以前の設定よりも競合がある最後の定義が優先されます。場合によっては、以前に定義された内容がわからないことがあります。このような場合は、replace
ブール値オプションを使用して true
に設定できます。これにより、同じ名前の以前の定義がすべて上書きされ、マージは行われません。
enabled=false
オプションを指定してプラグインを無効にすることもできます。これは、インスタンスが定義されない場合と同じ効果になります。include
オプションから以前の定義を再定義し、カスタムプロファイルでプラグインをアクティブにしない場合は、プラグインを無効にすると便利です。
balanced
プロファイルに基づき、すべてのデバイスの ALPM が最大の省電力に設定されるように拡張されたカスタムプロファイルの例を示します。
[main] include=balanced [disk] alpm=min_power
isolcpus=2
をカーネルブートコマンドラインに追加するカスタムプロファイルの例を示します。
[bootloader] cmdline=isolcpus=2
3.1.4. Tuned-adm
tuned-adm list
tuned-adm active
tuned-adm profile profile_name
tuned-adm profile latency-performance
tuned-adm off
tuned-adm list
yum search tuned-profiles
yum install tuned-profiles-profile-name
balanced
- デフォルトの省電力プロファイル。パフォーマンスと電力消費のバランスを取ることが目的です。可能な限り、自動スケーリングと自動チューニングを使用しようとします。ほとんどの負荷で良い結果をもたらします。唯一の欠点はレイテンシーが増加することです。現在の tuned リリースでは、CPU、ディスク、音声、および動画のプラグインが有効になり、conservative ガバナーがアクティブ化されます。
radeon_powersave
はauto
に設定されます。 powersave
- 省電力パフォーマンスを最大化するプロファイル。実際の電力消費を最小化するためにパフォーマンスを調整できます。現在の tuned リリースでは、SATA ホストアダプターの USB 自動サスペンド、WiFi 省電力、および ALPM の省電力を有効にします。また、ウェイクアップ率が低いシステムのマルチコア省電力がスケジュールされ、ondemand ガバナーがアクティブ化されます。さらに、AC97 音声省電力と、システムに応じて HDA-Intel 省電力 (10 秒のタイムアウト) が有効になります。KMS が有効なサポート対象 Radeon グラフィックカードがシステムに搭載されている場合は、自動省電力に設定されます。Asus Eee PC では、動的な Super Hybrid Engine が有効になります。備考
powersave
プロファイルは、必ずしも最も効率的ではありません。定義された量の作業を行う場合 (たとえば、動画ファイルをトランスコードする必要がある場合) を考えてください。トランスコードがフルパワーで実行される場合に、マシンが少ない電力を消費することがあります。これは、タスクがすぐに完了し、マシンがアイドル状態になり、非常に効率的な省電力モードに自動的に切り替わることがあるためです。その一方で、調整されたマシンでファイルをトランスコードすると、マシンはトランスコード中に少ない電力を消費しますが、処理に時間がかかり、全体的な消費電力は高くなることがあります。このため、一般的にbalanced
プロファイルが優れたオプションになる場合があります。 throughput-performance
- 高スループットに最適化されたサーバープロファイル。省電力メカニズムが無効になり、ディスクとネットワーク IO のスループットパフォーマンスを向上させる sysctl 設定が有効になり、
deadline
スケジューラーに切り替わります。CPU ガバナーはperformance
に設定されます。 latency-performance
- 低レイテンシーに最適化されたサーバープロファイル。省電力メカニズムが無効になり、レイテンシーを向上させる sysctl 設定が有効になります。CPU ガバナーは
performance
に設定され、CPU は低い C 状態にロックされます (PM QoS を使用)。 network-latency
- 低レイテンシーネットワークチューニング向けプロファイル。
latency-performance
プロファイルに基づきます。また、透過的な巨大ページと NUMA 調整が無効になり、複数の他のネットワーク関連の sysctl パラメーターがチューニングされます。 network-throughput
- スループットネットワークチューニング向けプロファイル。
throughput-performance
プロファイルに基づきます。また、カーネルネットワークバッファーが増加されます。 virtual-guest
- エンタープライズストレージプロファイルに基づいた、Red Hat Enterprise Linux 7 仮想マシンおよび VMware ゲスト向けに設計されたプロファイルで、他のタスクの中で、仮想メモリーのスワップを減らしディスクの readahead 値を増やします。ディスクバリアは無効になりません。
virtual-host
enterprise-storage
プロファイルに基づく仮想ホスト向けプロファイル。仮想メモリーの swappiness の減少、ディスクの readahead 値の増加、ダーティーページのよりアグレッシブな値の有効化などが行われます。oracle
- Oracle データベース向けに最適化されたプロファイルは、
throughput-performance
プロファイルに基づいて読み込まれます。これにより Transparent Huge Page が無効になり、一部の他のパフォーマンス関連カーネルパラメーターが変更されます。このプロファイルは、tuned-profiles-oracle パッケージで提供されます。これは、Red Hat Enterprise Linux 6.8 以降で利用可能です。 desktop
balanced
プロファイルに基づく、デスクトップに最適化されたプロファイル。対話型アプリケーションの応答を向上させるスケジューラーオートグループが有効になります。cpu-partitioning
cpu-partitioning
プロファイルは、システムの CPU を、分離されたハウスキーピングの CPU に分割します。分離された CPU のジッターと割り込みを減らすために、プロファイルは分離された CPU を、ユーザー空間プロセス、可動カーネルスレッド、割り込みハンドラー、およびカーネルタイマーから削除します。ハウスキーピング CPU は、すべてのサービス、シェルプロセス、およびカーネルスレッドを実行できます。/etc/tuned/cpu-partitioning-variables.conf
ファイルにcpu-partitioning
プロファイルを設定できます。設定オプションは以下のようになります。isolated_cores=cpu-list
- 分離する CPU を一覧表示します。分離された CPU の一覧はコンマで区切るか、ユーザーが範囲を指定できます。
3-5
のようにハイフンを使用して範囲を指定できます。このオプションは必須です。この一覧にない CPU は、自動的にハウスキーピング CPU と見なされます。 no_balance_cores=cpu-list
- システム全体のプロセスの負荷分散時に、カーネルに考慮されない CPU の一覧を表示します。このオプションは任意です。通常、これは
isolated_cores
と同じリストです。
cpu-partitioning
の詳細は、tuned-profiles-cpu-partitioning(7) の man ページを参照してください。
Optional
チャンネルで利用可能な tuned-profiles-compat パッケージで、定義済みプロファイルを追加でインストールできます。これらのプロファイルは、後方互換性を維持するために提供され、開発は行われていません。基本パッケージの一般的なプロファイルを使用すると、ほとんどの場合、同等のことやそれ以外のことも行えます。特別な理由がない限り、基本パッケージのプロファイルを使用することが推奨されます。互換プロファイルは以下のとおりです。
default
- これは利用可能なプロファイルの中で省電力への影響度が最も低く、tuned の CPU プラグインとディスクプラグインのみが有効になります。
desktop-powersave
- デスクトップシステム向けの節電プロファイル。tuned の CPU、Ethernet、および disk プラグインである SATA ホストアダプターの ALPM 省電力を有効にします。
laptop-ac-powersave
- AC 電源で稼働するノートパソコン向け省電力プロファイル (影響度は中)。SATA ホストアダプター用の ALPM 省電力、WiFi 省電力、および tuned の CPU、イーサネット、ディスクのプラグインが有効になります。
laptop-battery-powersave
- バッテリーで稼働するラップトップ向け省電力プロファイル (影響度は大)。現在の tuned 実装では、
powersave
プロファイルのエイリアスになります。 spindown-disk
- スピンダウン時間を最大化する、従来の HDD が搭載されたマシン向け省電力プロファイル。tuned 省電力メカニズム、USB 自動サスペンド、および Bluetooth が無効になり、Wi-Fi 省電力が有効になり、ログ同期が無効になり、ディスクライトバック時間が増加し、ディスクの swappiness が減少します。すべてのパーティションは、
noatime
オプションで再マウントされます。 enterprise-storage
- I/O スループットを最大化する、エンタープライズ級のストレージ向けサーバープロファイル。
throughput-performance
プロファイルと同じ設定がアクティブ化され、readahead 設定値が乗算され、ルートパーティションと起動パーティション以外のパーティションでバリアが無効になります。
atomic-host
プロファイル、仮想マシンで atomic-guest
プロファイルを使用します。
yum install tuned-profiles-atomic
atomic-host
- Red Hat Enterprise Linux Atomic Host 向けに最適化されたプロファイル。ベアメタルサーバーでホストシステムとして使用する場合は、throughput-performance プロファイルを使用します。さらに、SELinux AVC キャッシュと PID 制限が増加し、netfilter 接続追跡がチューニングされます。
atomic-guest
- Red Hat Enterprise Linux Atomic Host 向けに最適化されたプロファイル (virtual-guest プロファイルに基づいてゲストシステムとして使用される場合)。さらに、SELinux AVC キャッシュと PID 制限が増加し、netfilter 接続追跡がチューニングされます。
realtime
、realtime-virtual-host
、および realtime-virtual-guest
) が利用可能です。
realtime
プロファイルを有効にするには、tuned-profiles-realtime パッケージをインストールします。root で次のコマンドを実行します。
yum install tuned-profiles-realtime
realtime-virtual-host
プロファイルと realtime-virtual-guest
プロファイルを有効にするには、tuned-profiles-nfv パッケージをインストールします。root で次のコマンドを実行します。
yum install tuned-profiles-nfv
3.1.5. powertop2tuned
yum install tuned-utils
powertop2tuned new_profile_name
/etc/tuned
ディレクトリー内にプロファイルが作成されます。安全上の理由から、すべての PowerTOP チューニングは最初に新しいプロファイルで無効になっています。これらのチューニングを有効にするには、/etc/tuned/profile/tuned.conf
で興味があるチューニングをコメント解除します。--enable
または -e
オプションを使用して、有効な PowerTOP により提示されたほとんどのチューニングで新しいプロファイルを生成できます。USB 自動サスペンドなどの一部の危険なチューニングは引き続き無効になります。これらのチューニングが必要な場合は、手動でコメント解除する必要があります。デフォルトでは、新しいプロファイルはアクティブ化されていません。有効にするには、以下のコマンドを実行します。
tuned-adm profile new_profile_name
powertop2tuned --help
3.2. tuned と tuned-adm によるパフォーマンスチューニング
tuned プロファイルの概要
throughput-performance
です。
- ストレージおよびネットワークに対して少ない待ち時間
- ストレージおよびネットワークの高いスループット
- 仮想マシンのパフォーマンス
- 仮想化ホストのパフォーマンス
tuned ブートローダープラグイン
tuned Bootloader plug-in
を使用すると、パラメーターをカーネル (ブートまたは dracut) コマンドラインに追加できます。GRUB 2 ブートローダーのみがサポートされ、プロファイルの変更を適用するには再起動が必要なことに注意してください。たとえば、quiet
パラメーターを tuned プロファイルに追加するには、tuned.conf
ファイルに次の行を含めます。
[bootloader] cmdline=quiet別のプロファイルに切り替えたり、tuned を手動で停止すると、追加パラメーターが削除されます。システムをシャットダウンまたは再起動すると、パラメーターは
grub.cfg
ファイルで永続化されます。
環境変数と展開 tuned 組み込み関数
nfsroot=/root
に展開されます。
[bootloader] cmdline="nfsroot=$HOME"
tuned
変数を使用できます。次の例では、${isolated_cores}
は 1,2
に展開され、カーネルは isolcpus=1,2
パラメーターで起動します。
[variables] isolated_cores=1,2 [bootloader] cmdline=isolcpus=${isolated_cores}
${non_isolated_cores}
は 0,3-5
に展開され、cpulist_invert
の組み込み関数は 0,3-5
引数で呼び出されます。
[variables] non_isolated_cores=0,3-5 [bootloader] cmdline=isolcpus=${f:cpulist_invert:${non_isolated_cores}}
cpulist_invert
関数は、CPU の一覧を反転します。6 CPU のマシンでは、反転が 1,2
になり、カーネルは isolcpus=1,2
コマンドラインパラメーターで起動されます。
tuned.conf
に追加できます。
[variables] include=/etc/tuned/my-variables.conf [bootloader] cmdline=isolcpus=${isolated_cores}
isolated_cores=1,2
を /etc/tuned/my-variables.conf
ファイルに追加する場合、カーネルは isolcpus=1,2
パラメーターで起動されます。
デフォルトのシステム tuned プロファイルの変更
手順3.1 新しい tuned プロファイルディレクトリーの作成
/etc/tuned/
で、作成するプロファイルと同じ名前の新しいディレクトリーを作成します (/etc/tuned/my_profile_name/
)。- 新しいディレクトリーで、
tuned.conf
という名前のファイルを作成し、次の行を先頭に含めます。[main] include=profile_name
- プロファイルの変更を含めます。たとえば、
vm.swappiness
の値がデフォルトの 10 ではなく 5 に設定された状態で、throughput-performance
プロファイルから設定を使用するには、次の行を含めます。[main] include=throughput-performance [sysctl] vm.swappiness=5
- プロファイルをアクティベートするには、次のコマンドを実行します。
# tuned-adm profile my_profile_name
tuned.conf
ファイルとともにディレクトリーを作成すると、システム tuned プロファイルの更新後にすべてのプロファイルの変更を保持できます。
/user/lib/tuned/
から /etc/tuned/
にコピーします。以下に例を示します。
# cp -r /usr/lib/tuned/throughput-performance /etc/tuned
/etc/tuned
でプロファイルを編集します。同じ名前のプロファイルが 2 つある場合は、/etc/tuned/
にあるプロファイルがロードされることに注意してください。この方法の欠点は、tuned
のアップグレード後にシステムプロファイルが更新される場合に、古くなった変更済みバージョンに変更が反映されなくなることです。
リソース
第4章 Tuna

4.1. Tuna を使用したシステムの確認
#
tuna --show_threads
thread
pid SCHED_ rtpri affinity cmd
1 OTHER 0 0,1 init
2 FIFO 99 0 migration/0
3 OTHER 0 0 ksoftirqd/0
4 FIFO 99 0 watchdog/0
--show_threads
の前に --threads
オプションを追加します
#
tuna --threads=pid_or_cmd_list --show_threads
#
tuna --show_irqs
# users affinity 0 timer 0 1 i8042 0 7 parport0 0
--show_irqs
の前に --irqs
オプションを追加します。
#
tuna --irqs=number_or_user_list --show_irqs
4.2. Tuna を使用した CPU のチューニング
/proc/cpuinfo
ファイルの詳細情報を確認します。
#
tuna --cpus=cpu_list --run=COMMAND
#
tuna --cpus=cpu_list --isolate
#
tuna --cpus=cpu_list --include
4.3. Tuna を使用した IRQ のチューニング
/proc/interrpupts
ファイルを確認します。tuna --show_irqs コマンドを使用することもできます。
--irqs
パラメーターを使用します。
#
tuna --irqs=irq_list --run=COMMAND
--move
パラメーターを使用します。
#
tuna --irqs=irq_list --cpus=cpu_list --move
sfc1
で始まるすべての割り込みを対象とし、2 つの CPU に分散するには、以下を行います。
#
tuna --irqs=sfc1\* --cpus=7,8 --move --spread
--move
パラメーターで IRQ を変更する前および後に --show_irqs
パラメーターを使用します。
#
tuna --irqs=128 --show_irqs # users affinity 128 iwlwifi 0,1,2,3#
tuna --irqs=128 --cpus=3 --move#
tuna --irqs=128 --show_irqs # users affinity 128 iwlwifi 3
4.4. Tuna を使用したタスクのチューニング
--priority
パラメーターを使用します。
#
tuna --threads=pid_or_cmd_list[] --priority=policy:rt_priority
- pid_or_cmd_list 引数は、PID またはコマンド名パターンのコンマ区切りリストです。
- ラウンドロビン形式の場合は、policy を
RR
に設定します。先入れ先出しの場合はFIFO
、デフォルトのポリシーの場合はOTHER
に設定します。スケジューリングポリシーの概要は、「スケジューリングポリシーの調整」 を参照してください。 - rt_priority を 1 から 99 までの範囲で設定します。1 の優先度が最も低くなり、99 の優先度が最も高くなります。
#
tuna --threads=7861 --priority=RR:40
--priority
パラメーターの変更前と後に --show_threads
パラメーターを使用します。
#
tuna --threads=sshd --show_threads --priority=RR:40 --show_threads
thread ctxt_switches
pid SCHED_ rtpri affinity voluntary nonvoluntary cmd
1034 OTHER 0 0,1,2,3 12 17 sshd
thread ctxt_switches
pid SCHED_ rtpri affinity voluntary nonvoluntary cmd
1034 RR 40 0,1,2,3 12 17 sshd
4.5. Tuna の使用例
例4.1 特定 CPU へのタスク割り当て
ssh
スレッドを CPU 0 および 1 で実行し、すべての http
スレッドを CPU 2 および 3 で実行する方法を示しています。
#
tuna --cpus=0,1 --threads=ssh\* --move --cpus=2,3 --threads=http\* --move
- CPU 0 および 1 を選択します。
ssh
で始まるすべてのスレッドを選択します。- 選択したスレッドを選択した CPU に移動します。tuna は、
ssh
で始まるスレッドのアフィニティーマスクを適切な CPU に設定します。CPU は、数字 (0 と 1)、16 進法マスク (0x3
)、またはバイナリー (11
) で表すことができます。 - CPU リストを 2 および 3 にリセットします。
http
で始まるすべてのスレッドを選択します。- 選択したスレッドを選択した CPU に移動します。Tuna は
http
で始まるスレッドのアフィニティーマスクを適切な CPU に設定します。CPU は、数字 (2 と 3)、16 進法マスク (0xC
)、またはバイナリー (1100
) で表すことができます。
例4.2 現行設定の表示
--show_threads
(-P
) パラメーターを使用して現行の設定を表示し、要求した変更が想定どおりに行われたことをテストします。
#
tuna--threads=gnome-sc\*
\--show_threads
\--cpus=0
\--move
\--show_threads
\--cpus=1
\--move
\--show_threads
\--cpus=+0
\--move
\--show_threads
thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 3861 OTHER 0 0,1 33997 58 gnome-screensav thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 3861 OTHER 0 0 33997 58 gnome-screensav thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 3861 OTHER 0 1 33997 58 gnome-screensav thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 3861 OTHER 0 0,1 33997 58 gnome-screensav
gnome-sc
で始まるすべてのスレッドを選択します。- 選択したスレッドを表示し、ユーザーがアフィニティーマスクと RT の優先度を確認できるようにします。
- CPU 0 を選択します。
gnome-sc
スレッドを選択した CPU (CPU 0) に移動します。- 移動の結果を表示します。
- CPU リストを 1 にリセットします。
gnome-sc
スレッドを選択した CPU (CPU 1) に移動します。- 移動の結果を表示します。
- CPU 0 を CPU リストに追加します。
gnome-sc
スレッドを選択した CPU (CPU 0 および 1) に移動します。- 移動の結果を表示します。
第5章 Performance Co-Pilot (PCP)
5.1. PCP の概要およびリソース
- リアルタイムデータの監視および管理
- 履歴データのロギングおよび取得
pmcd
) は、ホストシステムでパフォーマンスデータを収集します。pminfo または pmstat などのクライアントツールを使用すると、同じホストまたはネットワークを介してこのデータを取得、表示、アーカイブ、および処理できます。pcp パッケージは、コマンドラインツールと、基本的な機能を提供します。グラフィカルツールには pcp-gui パッケージが必要です。
リソース
- PCPIntro という名前の man ページでは、Performance Co-Pilot について紹介しています。利用可能なツールの一覧、利用可能な設定オプションの説明、および関連する man ページの一覧が提供されます。デフォルトでは、包括的なドキュメンテーションは
/usr/share/doc/pcp-doc/
ディレクトリーにインストールされます (『Performance Co-Pilot User's and Administrator's Guide』や『Performance Co-Pilot Programmer's Guide』など)。 - PCP については、Red Hat カスタマーポータルの「Index of Performance Co-Pilot (PCP) articles, solutions, tutorials and white papers」を参照してください。
- すでに精通している古いツールの機能がある PCP ツールを調べる必要がある場合は、Red Hat ナレッジベースの記事「Side-by-side comparison of PCP tools with legacy tools」を参照してください。
- Performance Co-Pilot の詳細な説明と使用方法については、「DOCUMENTATION」から公式な PCP ドキュメントを参照してください。Red Hat Enterprise Linux ですぐに PCP を使用する場合は、「PCP Quick Reference Guide」を参照してください。公式な PCP Web サイトには、「FAQ」 (よくある質問の一覧) も含まれます。
5.2. Performance Co-Pilot による XFS ファイルパフォーマンスの分析
5.2.1. XFS PMDA をインストールして PCP で XFS データを収集
#
yum install pcp
#
systemctl enable pmcd.service
#
systemctl start pmcd.service
#
pcp
Performance Co-Pilot configuration on workstation:
platform: Linux workstation 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan
29 18:05:33 UTC 2015 x86_64
hardware: 2 cpus, 2 disks, 1 node, 2048MB RAM
timezone: BST-1
services pmcd
pmcd: Version 3.10.6-1, 7 agents
pmda: root pmcd proc xfs linux mmv jbd2
XFS PMDA の手動インストール
collector
ロールを指定すると、現在のシステムでパフォーマンスメトリックを収集できます。
monitor
ロールを指定すると、システムでローカルシステムまたはリモートシステム、あるいはローカルおよびリモートシステムの両方を監視できます。
both
で、XFS PMDA はほとんどの場合で適切に操作することができます。
#
cd /var/lib/pcp/pmdas/xfs/
xfs
ディレクトリーで以下を実行します。
xfs]#
./Install
You will need to choose an appropriate configuration for install of
the “xfs” Performance Metrics Domain Agent (PMDA).
collector collect performance statistics on this system
monitor allow this system to monitor local and/or remote systems
both collector and monitor configuration for this system
Please enter c(ollector) or m(onitor) or (both) [b]
Updating the Performance Metrics Name Space (PMNS) ...
Terminate PMDA if already installed ...
Updating the PMCD control file, and notifying PMCD ...
Waiting for pmcd to terminate ...
Starting pmcd ...
Check xfs metrics have appeared ... 149 metrics and 149 values
5.2.2. XFS パフォーマンスメトリックの設定および検証
pminfo でのメトリックの検証
、
利用可能なパフォーマンスメトリックに関する情報が表示されます。「XFS PMDA をインストールして PCP で XFS データを収集」コマンドは、XFS PMDA によって提供される利用可能なメトリックをすべて表示します。
#
pminfo xfs
-t metric
- 選択したメトリックを説明するヘルプ情報を 1 行で表示します。
-T metric
- 選択したメトリックを説明するより詳細なヘルプテキストを表示します。
-f metric
- メトリックスに対応するパフォーマンスの現在の読み取り値を表示します。
-t
、-T
、および -f
オプションを使用できます。ほとんどのメトリックデータは、プロービング時にシステム上のマウントされた各 XFS ファイルシステムに提供されます。
.
) を区切り文字として使用し、各グループがルート XFS メトリックからの新しいリーフノードとなるようにする他の XFS メトリックのグループ があります。リーフノードセマンティック (ドット) はすべての PCP メトリックに適用されます。各グループで利用可能なメトリクスの種類の概要は、表A.3「XFS の PCP メトリックグループ」 を参照してください。
例5.1 pminfo ツールを使用した XFS 読み書きメトリックの検証
xfs.write_bytes
メトリックを説明するヘルプ情報を 1 行で表示するには、以下を実行します。
#
pminfo -t xfs.write_bytes
xfs.write_bytes [number of bytes written in XFS file system write operations]
xfs.write_bytes
メトリックを説明するより詳細なヘルプテキストを表示するには、以下を実行します。
#
pminfo -T xfs.read_bytes
xfs.read_bytes
Help:
This is the number of bytes read via read(2) system calls to files in
XFS file systems. It can be used in conjunction with the read_calls
count to calculate the average size of the read operations to file in
XFS file systems.
xfs.read_bytes
メトリックスに対応するパフォーマンスの現在の読み取り値を取得します。
#
pminfo -f xfs.read_bytes
xfs.read_bytes
value 4891346238
pmstore でのメトリックの設定
xfs.control.reset
メトリック) に特定のメトリックの値を編集できます。メトリックの値を編集するには、pmstore
ツールを使用します。
例5.2 pmstore を使用した xfs.control.reset メトリックのリセット
xfs.control.reset
メトリックで pmstore
を使用して、XFS PMDA の記録されたカウンター値をゼロにリセットする方法を示しています。
$
pminfo -f xfs.write
xfs.write
value 325262
#
pmstore xfs.control.reset 1
xfs.control.reset old value=0 new value=1
$
pminfo -f xfs.write
xfs.write
value 0
5.2.3. ファイルシステムごとに利用できる XFS メトリックの検証
例5.3 pminfo でのデバイスごとの XFS メトリックの取得
#
pminfo -f -t xfs.perdev.read xfs.perdev.write
xfs.perdev.read [number of XFS file system read operations]
inst [0 or "loop1"] value 0
inst [0 or "loop2"] value 0
xfs.perdev.write [number of XFS file system write operations]
inst [0 or "loop1"] value 86
inst [0 or "loop2"] value 0
5.2.4. pmlogger でのパフォーマンスデータのロギング
pmlogger
ツールを使用してシステム上で選択したメトリックのアーカイブされたログを作成します。
/var/lib/pcp/config/pmlogger/config.default
です。設定ファイルでは、プライマリーのロギングインスタンスによって記録されるメトリックを指定します。
pmlogger
でローカルマシンのメトリック値をログに記録するには、プライマリーロギングインスタンスを開始します。
#
systemctl start pmlogger.service
#
systemctl enable pmlogger.service
pmlogger
が有効でデフォルトの設定ファイルが設定されている場合、pmlogger の行が PCP 設定に含まれます。
#
pcp
Performance Co-Pilot configuration on workstation:
platform: Linux workstation 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan
[...]
pmlogger: primary logger:/var/log/pcp/pmlogger/workstation/20160820.10.15
pmlogconf での pmlogger 設定ファイルの編集
pmlogger
サービスが実行されているとき、PCP はホスト上でメトリックのデフォルトセットをログに記録します。pmlogconf
ユーティリティーを使用してデフォルト設定をチェックし、必要の応じて XFS ロギンググループを有効にすることができます。有効にする重要な XFS グループには、XFS information、XFS data、および log I/O traffic グループが含まれます。
pmlogconf
のプロンプトの従って、関連するパフォーマンスメトリックのグループを有効または無効にし、有効な各グループのログ間隔を制御します。グループを選択するには、プロンプトの応答として y
(yes) または n
(no) を押します。pmlogconf で汎用 PCP アーカイブのロガー設定を作成または編集するには、以下を入力します。
#
pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
pmlogger 設定ファイルの手動編集
pmlogger
設定ファイルを手動編集し、一定の間隔の特定のメトリックを追加すると、必要に合ったロギング設定を作成することができます。
例5.4 pmlogger 設定ファイルと XFS メトリック
pmlogger
config.default
ファイルの抜粋を示しています。
# It is safe to make additions from here on ... # log mandatory on every 5 seconds { xfs.write xfs.write_bytes xfs.read xfs.read_bytes } log mandatory on every 10 seconds { xfs.allocs xfs.block_map xfs.transactions xfs.log } [access] disallow * : all; allow localhost : enquire;
PCP ログアーカイブの再生
pmdumptext
、pmrep
、またはpmlogsummary
などの PCP ユーティリティーを使用して、ログをテキストファイルにエクスポートし、スプレッドシートにインポートします。- PCP Charts アプリケーションのデータを再生し、システムの現在のデータとともに、グラフを使って回顧的なデータを可視化します。「PCP Charts での視覚追跡」 を参照してください。
pmdumptext
ツールを使用してログファイルを表示できます。pmdumptext を使うと、選択した PCP ログアーカイブを解析し、値を ASCII テーブルにエクスポートできます。pmdumptext ツールを使用すると、アーカイブログ全体をダンプすることができ、コマンドラインでメトリックを指定してログから選択したメトリックの値のみをダンプすることもできます。
例5.5 特定の XFS メトリックログ情報の表示
xfs.perdev.log
メトリックのデータを 5 秒間隔で表示し、すべてのヘッダーを表示する場合は以下を実行します。
$
pmdumptext -t 5seconds -H -a 20170605 xfs.perdev.log.writes
Time local::xfs.perdev.log.writes["/dev/mapper/fedora-home"] local::xfs.perdev.log.writes["/dev/mapper/fedora-root"]
? 0.000 0.000
none count / second count / second
Mon Jun 5 12:28:45 ? ?
Mon Jun 5 12:28:50 0.000 0.000
Mon Jun 5 12:28:55 0.200 0.200
Mon Jun 5 12:29:00 6.800 1.000
5.2.5. PCP Charts での視覚追跡
#
yum install pcp-gui

pmtime
サーバー設定は下部にあります。start および pause ボタンを使用すると以下を制御できます。
- PCP がメトリックデータをポーリングする間隔
- 履歴データのメトリックの日付および時間
- File → Export をクリックして、現在のビューのイメージを保存します。
- Record → Start をクリックして記録を開始します。Record → Stop をクリックして記録を停止します。録画の停止後、記録されたメトリックは後で表示できるようにアーカイブが作成されます。
- 折れ線グラフ
- 棒グラフ
- 使用状況グラフ
view
と呼ばれるメイン設定ファイルにより、1 つ以上のチャートに関連付けられたメタデータを保存することができます。このメタデータでは、使用されるメトリックや、チャート列など、チャート側面をすべて記述します。カスタム view
設定を作成し、File → Save View をクリックして保存して、view
設定を後でロードすることができます。設定ファイルとその 構文
の詳細は、pmchart(1) の man ページを参照してください。
例5.6 PCP Charts の view 設定での積み上げチャートグラフ
loop1
に対して読み書きされた合計バイト数を表す積み上げチャートグラフを示します。
#kmchart version 1 chart title "Filesystem Throughput /loop1" style stacking antialiasing off plot legend "Read rate" metric xfs.read_bytes instance "loop1" plot legend "Write rate" metric xfs.write_bytes instance "loop1"
5.3. ファイルシステムデータを収集するための最小限の PCP 設定
pmlogger
出力の tar.gz
アーカイブは、PCP Charts などの PCP ツールを使用して分析でき、他のソースのパフォーマンス情報と比較できます。
- pcp パッケージをインストールします。
#
yum install pcp pmlogconf
ユーティリティーを実行してpmlogger
設定を更新し、XFS 情報、XFS データ、およびログ I/O トラフィックグループを有効にします。#
pmlogconf -r/var/lib/pcp/config/pmlogger/config.default
pmlogger
サービスを開始します。#
systemctl start pmcd.service#
systemctl start pmlogger.service- XFS ファイルシステム上で操作を実行します。
pmlogger
サービスを停止します。#
systemctl stop pmcd.service#
systemctl stop pmlogger.service- 出力を収集し、ホスト名と現在の日時が名前に使用される
tar.gz
ファイルに保存します。#
cd /var/log/pcp/pmlogger/#
tar -czf $(hostname).$(date +%F-%Hh%M).pcp.tar.gz $(hostname)
第6章 CPU
6.1. 留意事項
- プロセッサーが相互に接続する方法と、メモリーなどの関連リソース
- プロセッサーによる実行用スレッドのスケジュール方式
- Red Hat Enterprise Linux 7 でのプロセッサーによる割り込み処理の方法
6.1.1. システムのトポロジー
- SMP (Symmetric Multi-Processor) トポロジー
- SMP トポロジーにより、すべてのプロセッサーが同時にメモリーにアクセスできるようになります。ただし、共有および同等のメモリーアクセスは、本質的にすべての CPU からのメモリーアクセスをシリアライズするため、SMP システムのスケーリング制約が一般的に許容できないものとして表示されます。このため、最近のサーバーシステムはすべて NUMA マシンです。
- NUMA (Non-Uniform Memory Access) の固定 (ピニング)
- NUMA トポロジーは、SMP トポロジーよりも最近開発されました。NUMA システムでは、複数のプロセッサーが 1 つのソケット上で物理的にグループ化されます。各ソケットにはメモリー専用の領域があり、メモリーへのローカルアクセスがある複数のプロセッサーをまとめてひとつのノードと呼んでいます。同じノードのプロセッサーはそのノードのメモリーバンクへは高速でアクセスでき、別のノードのメモリーバンクへのアクセスは低速になります。したがってローカルメモリー以外へアクセスする場合にはパフォーマンスが低下します。この点を考慮するとパフォーマンス重視のアプリケーションは NUMA トポロジーの場合アプリケーションを実行しているプロセッサーと同じノードにあるメモリーにアクセスさせるようにして、できるだけリモートのメモリーへのアクセスは避けるようにします。NUMA トポロジーのシステムでアプリケーションのパフォーマンスを調整する場合、アプリケーションが実行される場所そして実行ポイントに最も近いメモリーバンクはどれになるのかを考慮しておくことが重要となります。NUMA トポロジーのシステムの場合、プロセッサー、メモリー、周辺デバイスの接続形態に関する情報は
/sys
ファイルシステムに格納されています。/sys/devices/system/cpu
ディレクトリーにはプロセッサー同士の接続形態に関する詳細が格納されています。/sys/devices/system/node
ディレクトリーには NUMA ノードおよびノード間の相対距離に関する情報が格納されています。
6.1.1.1. システムのトポロジーの判断
$ numactl --hardware available: 4 nodes (0-3) node 0 cpus: 0 4 8 12 16 20 24 28 32 36 node 0 size: 65415 MB node 0 free: 43971 MB node 1 cpus: 2 6 10 14 18 22 26 30 34 38 node 1 size: 65536 MB node 1 free: 44321 MB node 2 cpus: 1 5 9 13 17 21 25 29 33 37 node 2 size: 65536 MB node 2 free: 44304 MB node 3 cpus: 3 7 11 15 19 23 27 31 35 39 node 3 size: 65536 MB node 3 free: 44329 MB node distances: node 0 1 2 3 0: 10 21 21 21 1: 21 10 21 21 2: 21 21 10 21 3: 21 21 21 10
$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 40 On-line CPU(s) list: 0-39 Thread(s) per core: 1 Core(s) per socket: 10 Socket(s): 4 NUMA node(s): 4 Vendor ID: GenuineIntel CPU family: 6 Model: 47 Model name: Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz Stepping: 2 CPU MHz: 2394.204 BogoMIPS: 4787.85 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 30720K NUMA node0 CPU(s): 0,4,8,12,16,20,24,28,32,36 NUMA node1 CPU(s): 2,6,10,14,18,22,26,30,34,38 NUMA node2 CPU(s): 1,5,9,13,17,21,25,29,33,37 NUMA node3 CPU(s): 3,7,11,15,19,23,27,31,35,39

6.1.2. スケジューリング
6.1.2.1. カーネルティック
nohz_full
) が用意されユーザー領域タスクによるカーネルの干渉を低減することで決定論がさらに向上されています。このオプションは nohz_full
カーネルパラメーターを使用すると指定したコアで有効にすることができます。コアでオプションを有効にすると時間管理に関するアクティビティーはすべて待ち時間に制約のないコアに移動されます。ユーザー領域のタスクがカーネルタイマーティック関連の待ち時間にマイクロ秒単位で制約がある高性能な計算やリアルタイムの計算を必要とする作業に便利です。
6.1.3. IRQ (Interrupt Request ー 割り込み要求) の処理
6.2. パフォーマンスの問題の監視と診断
6.2.1. turbostat
$ man turbostat
6.2.2. numastat
$ man numastat
6.2.3. /proc/interrupts
/proc/interrupts
ファイルには特定の I/O デバイスから各プロセッサーに送信された割り込み数が記載されています。内容は割り込み要求 (IRQ) 数、各プロセッサーで処理されたタイプ別割り込み要求数、送信された割り込みタイプ、記載割り込み要求に応答したデバイスをコンマで区切った一覧などになります。
6.2.4. pqos でのキャッシュおよびメモリー帯域の監視
- サイクルごとの命令 (IPC)。
- 最終レベルのキャッシュ MISSES の数。
- LLC で特定の CPU で実行されるプログラムのサイズ (キロバイト単位)。
- ローカルメモリーへの帯域幅 (MBL)。
- リモートメモリー (MBR) への帯域幅。
#
pqos --mon-top
関連情報
- pqos ユーティリティーおよび関連プロセッサー機能の概要は、「pqos」 を参照してください。
- CAT を使用して、DPDK (Data Plane Development Kit) のネットワークパフォーマンスでノイジーネイバー仮想マシンの影響を最小限にする方法については、Intel ホワイトペーパー「Increasing Platform Determinism with Platform Quality of Service for the Data Plane Development Kit」を参照してください。
6.3. 推奨設定
6.3.1. カーネルティックタイムの設定
nohz_full
パラメーターを使用して、カーネルコマンドラインでこれらのコアを指定します。16 コアシステムなら nohz_full=1-15
と指定すると動的ティックレス動作が 1 から 15 までのコアで有効になり時間管理はすべて未指定のコアに移動されます (コア 0)。この動作は起動時に一時的に有効にすることも /etc/default/grub
ファイルの GRUB_CMDLINE_LINUX
オプションで永続的に有効にすることもできます。永続的に有効にする場合は grub2-mkconfig -o /boot/grub2/grub.cfg コマンドを実行して設定を保存します。
- システムが起動したら手作業で rcu スレッドを待ち時間に制約のないコアに移動します。この場合コア 0 に移動しています。
# for i in `pgrep rcu[^c]` ; do taskset -pc 0 $i ; done
- カーネルコマンドラインで
isolcpus
パラメーターを使用して、特定のコアをユーザー空間タスクから分離します。 - オプションでカーネルの write-back bdi-flush スレッドの CPU 親和性を housekeeping コアに設定することができます。
echo 1 > /sys/bus/workqueue/devices/writeback/cpumask
# perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
while :; do d=1; done
等を実行するスクリプトが考えられます。
# perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1 1000 irq_vectors:local_timer_entry
# perf stat -C 1 -e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1 1 irq_vectors:local_timer_entry
6.3.2. ハードウェアパフォーマンスポリシーの設定 (x86_energy_perf_policy)
performance
モードで動作します。プロセッサーのサポートを必要とします。CPUID.06H.ECX.bit3
の表示があればサポートされています。実行する場合は root 権限で行ってください。
$ man x86_energy_perf_policy
6.3.3. taskset でプロセスの親和性を設定
$ man taskset
6.3.4. numactl で NUMA 親和性を管理
$ man numactl
libnuma
ライブラリーが収納されます。このライブラリーは、カーネル対応の NUMA ポリシーに対するシンプルなプログラミングインターフェースを提供し、numactl アプリケーションに比べより高度な調整を行うことができます。詳細は man ページをご覧ください。
$ man numa
6.3.5. numad を使用した NUMA 親和性の自動管理
numad
は自動で NUMA の親和性を管理するデーモンです。NUMA リソースの割り当てと管理を動的に改善するために、システム内の NUMA トポロジーとリソースの使用状況を監視します。
$ man numad
6.3.6. スケジューリングポリシーの調整
6.3.6.1. スケジューリングポリシー
6.3.6.1.1. SCHED_FIFO を使った静的優先度のスケジューリング
SCHED_FIFO
(静的優先度スケジューリングとも呼ばれる) はリアルタイムポリシーで各スレッドに固定の優先度を指定します。このポリシーを使用するとイベントの応答時間を改善し待ち時間を低減させることができるため、長期間は実行しない時間的制約のあるタスク対しての使用が推奨されます。
SCHED_FIFO
を使用すると、スケジューラーは SCHED_FIFO
全スレッドの一覧を優先度順にスキャンし実行準備ができているスレッドで最も順位が高いスレッドをスケジュールに入れます。SCHED_FIFO
スレッドの優先レベルは 1 から 99 で指定することができ、99 が最も高い優先度になります。Red Hat では最初は低い順位で使用を開始し、待ち時間に関する問題が見つかった場合にのみ徐々に優先度を上げていく方法を推奨しています。
SCHED_FIFO
の帯域幅を制限してリアルタイムのアプリケーションプログラマーがプロセッサーを独占するリアルタイムのタスクを開始しないよう阻止することができます。
- /proc/sys/kernel/sched_rt_period_us
- 上記のパラメーターはプロセッサー帯域幅の 100% とみなされるべき時間をマイクロ秒で定義します。デフォルト値は
1000000
μs もしくは 1 秒です。 - /proc/sys/kernel/sched_rt_runtime_us
- 上記のパラメーターはリアルタイムスレッドの実行に当てられる時間をマイクロ秒で定義します。デフォルト値は
950000
μs もしくは 0.95 秒です。
6.3.6.1.2. SCHED_RR を使ったラウンドロビン方式の優先度スケジューリング
SCHED_RR
は SCHED_FIFO
のラウンドロビン版になります。このポリシーは、複数のスレッドを同じ優先レベルで実行する必要がある場合に役に立ちます。
SCHED_FIFO
と同様、SCHED_RR
は各スレッドに固定の優先度を指定するリアルタイムポリシーになります。スケジューラーは SCHED_RR
全スレッドの一覧を優先度順にスキャンし実行準備ができているスレッドで最も優先順位が高いスレッドをスケジュールに入れます。ただし、SCHED_FIFO
とは異なり複数のスレッドが同じ優先度を持つ場合は特定の時間内でラウンドロビン方式にスケジュールが行われます。
sched_rr_timeslice_ms
カーネルパラメーターを使って秒単位で設定することができます (/proc/sys/kernel/sched_rr_timeslice_ms
)。最も小さい値は 1 ミリ秒になります。
6.3.6.1.3. SCHED_OTHER を使った通常のスケジュール
SCHED_OTHER
がデフォルトのスケジューリングポリシーになります。このポリシーは Completely Fair Scheduler (CFS) を使用して、このポリシーでスケジュールされているすべてのスレッドへの公平プロセッサーアクセスを許可します。多量のスレッドやデータの処理が重要な場合にはこのポリシーの方が長い期間で見ると効率的なスケジュールになります。
6.3.6.2. CPU の分離
isolcpus
起動パラメーターを使用するとスケジューラーから CPU を切り離すことができます。これによりスケジューラーがその CPU 上にあるユーザー領域のスレッドをスケジュールしないよう保護します。
isolcpus=2,5-7
isolcpus
パラメーターを使用する場合とは若干異なり、isolcpus
で得られるようなパフォーマンスの改善は現時点では期待できません。このツールの詳細は、「Tuna を使った CPU、スレッド、割り込みの親和性の設定」 を参照してください。
6.3.7. AMD64 および Intel 64 での割り込み親和性の設定
smp_affinity
があり、割り込み要求を処理するプロセッサーはこのプロパティーによって指定されます。アプリケーションのパフォーマンスを向上させるには、割り込みの親和性とプロセスの親和性を同じプロセッサーまたは同じコアにあるプロセッサーに割り当てます。これにより、指定された割り込みとアプリケーションスレッドがキャッシュラインを共有できるようになります。
手順6.1 割り込みの自動分散
- BIOS が NUMA トポロジーをエクスポートする場合、
irqbalance
サービスは、サービスを要求するハードウェアに対してローカルとなるノードの割り込み要求を自動的に処理できます。irqbalance
の設定に関する詳細は、「irqbalance」 を参照してください。
手順6.2 割り込みの手動分散
- 設定する割り込み要求に対応するデバイスを確認します。Red Hat Enterprise Linux 7.5 より、システムが最適な割り込み親和性を特定のデバイスおよびそれらのドライバーに自動的に設定するようになりました。親和性を手動で設定する必要はありません。これは以下のデバイスを対象とします。
be2iscsi
ドライバーを使用したデバイス。- NVMe PCI デバイス。
- プラットフォームのハードウェア仕様を見つけます。システムのチップセットが割り込みの分散に対応しているかどうかを確認します。
- その場合には、以下の手順に従って割り込み配信を設定できます。また、チップセットが割り込みの分散に使用するアルゴリズムを確認してください。BIOS によっては割り込み配信を設定するオプションがあります。
- そうでない場合、チップセットは常にすべての割り込みを 1 つの静的な CPU にルーティングします。使用される CPU を設定することはできません。
- システムで、どの APIC (Advanced thumbnailer Interrupt Controller) モードが使用されているかを確認します。物理以外のフラットモード (
flat
) のみが、複数の CPU への割り込みの分散をサポートします。このモードは、CPU が最大 8 のシステムでのみ利用できます。$
journalctl --dmesg | grep APICコマンド出力で、以下を行います。- システムが
flat
以外のモードを使用している場合は、「APIC ルーティングの物理フラットへの設定
」と同様の行が表示されます。 - このようなメッセージが表示されない場合は、システムが
フラット
モードを使用します。
システムがx2apic
モードを使用する場合は、ブートローダー設定のカーネルコマンドラインにnox2apic
オプションを追加してこれを無効にできます。 smp_affinity
マスクを計算します。smp_affinity
の値は、システム内のすべてのプロセッサーを表す 16 進数のビットマスクとして保存されます。各ビットは異なる CPU を設定します。最も大きなビットは CPU 0 です。マスクのデフォルト値はf
で、割り込み要求がシステムのどのプロセッサーでも処理可能であることを意味します。この値を1
に設定すると割り込み要求を処理できるのはプロセッサー 0 のみになります。手順6.3 マスクの計算
- バイナリーでは、割り込みを処理する CPU に
1
の値を使用します。たとえば、CPU 0 および CPU 7 で割り込みを処理するには、0000000010000001
をバイナリーコードとして使用します。表6.1 CPU のバイナリービット
CPU 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 バイナリー 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 - バイナリーコードを 16 進数に変換します。たとえば、Python を使用してバイナリーコードを変換するには、次のコマンドを実行します。
>>>
hex(int('0000000010000001', 2)) '0x81'
プロセッサーが 32 個以上搭載されているシステムでは 32 ビットグループそれぞれにsmp_affinity
値を区切って設定する必要があります。たとえば、64 プロセッサーシステムの最初の 32 プロセッサーのみが割り込み要求を処理できるようにするには、0xffffffff,00000000
を使用します。smp_affinity
マスクを設定します。特定の割り込み要求の割り込み親和性の値は該当の/proc/irq/irq_number/smp_affinity
ファイルに格納されます。計算されたマスクを関連ファイルに書き込みます。# echo mask > /proc/irq/irq_number/smp_affinity
関連情報
- 割り込みステアリングに対応するシステムでは、割り込み要求の
smp_affinity
プロパティーを変更するとハードウェアが設定され、カーネルを介入することなくハードウェアレベルで特定のプロセッサーに割り込みを処理させる決定が行われるようになります。割り込みステーリングの詳細は、9章ネットワーク を参照してください。
6.3.8. Tuna を使った CPU、スレッド、割り込みの親和性の設定
第7章 メモリー
7.1. 留意事項
7.1.1. 大きなページサイズ
HugeTLB
機能 (本書では static huge pages
とも呼ばれます) と Transparent Huge Page
機能の 2 つの異なる Huge Page 機能を使用できます。
7.1.2. TLB (Translation Lookaside Buffer) サイズ
7.2. パフォーマンスの問題の監視と診断
7.2.1. vmstat を使ったメモリー使用量の監視
$ vmstat -s
$ man vmstat
7.2.2. Valgrind を使ったアプリケーションのメモリー使用量のプロファイリング
# yum install valgrind
7.2.2.1. Memcheck を使ったメモリー使用量のプロファイリング
- 発生すべきでないメモリーアクセス
- 未定義または初期化されていない値の使用
- 誤って解放されたヒープメモリー
- ポインターの重複
- メモリーリーク
# valgrind --tool=memcheck application
- --leak-check
- アプリケーションの実行が完了すると memcheck によりメモリーリークの検索が行われます。デフォルト値は検出したメモリーリーク数を出力する --leak-check=summary になります。--leak-check=yes や --leak-check=full を指定するとリークそれぞれの詳細を出力させることができます。無効にする場合は --leak-check=no を指定します。
- --undef-value-errors
- デフォルト値は未定義の値が使用された場合にエラーを報告する --undef-value-errors=yes です。--undef-value-errors=no を指定するとこの報告を無効にしてメモリーチェックの速度を若干早めることができます。
- --ignore-ranges
--ignore-ranges=0xPP-0xQQ,0xRR-0xSS
などのようにメモリーアクセスを確認する際 memcheck に無視させる範囲を指定します。
/usr/share/doc/valgrind-version/valgrind_manual.pdf
に収納されているドキュメントをご覧ください。
7.2.2.2. Cachegrind を使ったキャッシュ使用量のプロファイリング
# valgrind --tool=cachegrind application
- --I1
- --I1=size,associativity,line_size などのように第 1 レベルの命令キャッシュのサイズ、結合性、行サイズを指定します。
- --D1
- --D1=size,associativity,line_size などのように第 1 レベルのデータキャッシュのサイズ、結合性、行サイズを指定します。
- --LL
- --LL=size,associativity,line_size などのように最後のレベルのキャッシュのサイズ、結合性、行サイズを指定します。
- --cache-sim
- キャッシュアクセスおよびミスの数の収集を有効化または無効化します。デフォルトでは有効になっています (--cache-sim=yes)。このオプションと --branch-sim の両方を無効にすると cachegrind には収集する情報がなくなります。
- --branch-sim
- ブランチ命令と誤った予測数の収集を有効化または無効化します。デフォルトでは有効になっています (--branch-sim=yes)。このオプションと --cache-sim の両方を無効にすると cachegrind には収集する情報がなくなります。Cachegrind はプロファイリングの詳細情報をプロセスごとの
cachegrind.out.pid
ファイルに書き込みます。pid はプロセスの識別子になります。この詳細情報は付随する cg_annotate ツールでさらに以下のように処理することができます。# cg_annotate cachegrind.out.pid
# cg_diff first second
/usr/share/doc/valgrind-version/valgrind_manual.pdf
に収納されているドキュメントを参照してください。
7.2.2.3. Massif を使ったヒープとスタックの領域プロファイリング
# valgrind --tool=massif application
- --heap
- massif にヒープのプロファイリングを行わせるかどうかを指定します。デフォルト値は --heap=yes です。--heap=no に設定するとヒープのプロファイリングが無効になります。
- --heap-admin
- ヒープのプロファイリングを有効にした場合の管理に使用するブロックごとのバイト数を指定します。デフォルト値は
8
バイトです。 - --stacks
- massif にスタックのプロファイリングを行わせるかどうかを指定します。スタックのプロファイリングにより massif の動作がかなり遅くなる可能性があるため、デフォルト値は --stack=no です。スタックのプロファイリングを有効にする場合は --stack=yes に設定します。プロファイリングするアプリケーションに関連するスタックサイズの変更をよりわかりやすく示すため massif はメインスタックの開始時のサイズはゼロであると仮定している点に注意してください。
- --time-unit
- massif でプロファイリングデータを収集する間隔を指定します。デフォルト値は
i
(命令を実行) です。ms
(ミリ秒数またはリアルタイム) やB
(ヒープおよびスタックで割り当てられたバイト数または割り当て解除されたバイト数) を指定することもできます。ハードウェアが異なる場合でもほぼ再現が可能なため短時間実行のアプリケーションやテスト目的の場合には割り当てられたバイト数を確認すると役に立ちます。
massif.out.pid
ファイルに出力します。pid は指定アプリケーションのプロセス識別子になります。ms_print ツールはこのプロファイリングデータを図式化しアプリケーション実行中のメモリー消費量を表示すると共にメモリー割り当てのピーク時に割り当てを行うサイトに関する詳細情報を表示します。massif.out.pid
ファイルのデータを図式化するには次のコマンドを実行します。
# ms_print massif.out.pid
/usr/share/doc/valgrind-version/valgrind_manual.pdf
に収納されているドキュメントを参照してください。
7.3. HugeTLB Huge Page の設定
起動時
と実行時
の 2 つの方法があります。起動時に予約すると、メモリーの断片化がそれほど行われていないため、成功の可能性が高くなります。ただし、NUMA マシンでは、複数のページが NUMA ノード間で自動的に分割されます。実行時の方法では、NUMA ノードごとに Huge Page を予約できます。ランタイム予約がブートプロセスの早い段階で行われると、メモリーの断片化はより低くなります。
7.3.1. 起動時の Huge Page の設定
- hugepages
- ブート時にカーネルに設定される永続ヒュージページの数を定義します。デフォルト値は 0 です。物理的に近接な空きページが十分にある場合にしか Huge Page を割り当てることはできません。このパラメーターで予約されるページは他の目的には使用できません。この値は起動後、
/proc/sys/vm/nr_hugepages
ファイルの値を変更することで調整可能です。NUMA システムの場合、このパラメーターで割り当てた Huge Page はノード間で平等に分割されます。実行中、Huge Page を特定ノードに割り当てる場合はそのノードの/sys/devices/system/node/node_id/hugepages/hugepages-1048576kB/nr_hugepages
ファイルの値を変更します。詳細についてはデフォルトで/usr/share/doc/kernel-doc-kernel_version/Documentation/vm/hugetlbpage.txt
にインストールされるカーネル関連ドキュメントをお読みください。 - hugepagesz
- 起動時にカーネルに設定される永続ヒュージページのサイズを定義します。使用できる値は 2 MB と 1 GB です。デフォルト値は 2 MB です。
- default_hugepagesz
- 起動時にカーネルに設定される永続 Huge Page のデフォルトのサイズを定義します。使用できる値は 2 MB と 1 GB です。デフォルト値は 2 MB です。
手順7.1 起動初期時に 1 GB ページを予約
/etc/default/grub
ファイルのカーネルコマンドラインオプションに次の行を root として追加して、1 GB ページ向けの HugeTLB プールを作成します。default_hugepagesz=1G hugepagesz=1G
- 編集したデフォルトファイルを使用して GRUB2 設定を再生成します。BIOS ファームウェアを使用しているシステムの場合は次のコマンドを実行します。
# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI ファームウェアを使用しているシステムの場合は次のコマンドを実行します。# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
/usr/lib/systemd/system/hugetlb-gigantic-pages.service
という名前のファイルを次の内容で作成します。[Unit] Description=HugeTLB Gigantic Pages Reservation DefaultDependencies=no Before=dev-hugepages.mount ConditionPathExists=/sys/devices/system/node ConditionKernelCommandLine=hugepagesz=1G [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/lib/systemd/hugetlb-reserve-pages.sh [Install] WantedBy=sysinit.target
/usr/lib/systemd/hugetlb-reserve-pages.sh
という名前のファイルを次の内容で作成します。#!/bin/sh nodes_path=/sys/devices/system/node/ if [ ! -d $nodes_path ]; then echo "ERROR: $nodes_path does not exist" exit 1 fi reserve_pages() { echo $1 > $nodes_path/$2/hugepages/hugepages-1048576kB/nr_hugepages } reserve_pages number_of_pages node
最後の行で、number_of_pages を予約する 1GB ページの数に置き換え、node をこれらのページを予約するノードの名前に置き換えます。例7.1
node0
およびnode1
でのページの予約たとえば、node0
上に 2 つの 1GB ページを予約し、node1
上に 1 つの 1GB ページを予約するには、最後の行を以下に置き換えます。reserve_pages 2 node0 reserve_pages 1 node1
必要に応じて変更したり、行を追加してメモリーを他のノードに予約することができます。- スクリプトを実行可能にします。
# chmod +x /usr/lib/systemd/hugetlb-reserve-pages.sh
- 初期のブート予約を有効にします。
# systemctl enable hugetlb-gigantic-pages
nr_hugepages
に書き込みを行うことにより、1GB を超えるページを実行時に予約できます。ただし、メモリーの断片化により、このような予約が失敗する可能性があります。起動初期時に実行されるこのスクリプトを使用するのが最も信頼できる 1GB ページの予約方法になります。
7.3.2. 実行時の Huge Page の設定
- /sys/devices/system/node/node_id/hugepages/hugepages-size/nr_hugepages
- 指定 NUMA ノードに割り当てる指定サイズの Huge Page 数を定義します。これは Red Hat Enterprise Linux 7.1 からの対応になります。次の例では 2048 kB の Huge Page を 20 ページ
node2
に割り当てています。# numastat -cm | egrep 'Node|Huge' Node 0 Node 1 Node 2 Node 3 Total add AnonHugePages 0 2 0 8 10 HugePages_Total 0 0 0 0 0 HugePages_Free 0 0 0 0 0 HugePages_Surp 0 0 0 0 0 # echo 20 > /sys/devices/system/node/node2/hugepages/hugepages-2048kB/nr_hugepages # numastat -cm | egrep 'Node|Huge' Node 0 Node 1 Node 2 Node 3 Total AnonHugePages 0 2 0 8 10 HugePages_Total 0 0 40 0 40 HugePages_Free 0 0 40 0 40 HugePages_Surp 0 0 0 0 0
- /proc/sys/vm/nr_overcommit_hugepages
- オーバーコミットメモリーを介してシステムで作成され、使用できる追加の Huge Page の最大数を定義します。このファイルにゼロ以外の値を書き込むと、永続 Huge Page のプールを使い切ってしまった場合にカーネルの通常ページのプールから指定した Huge Page 数が取得されます。この余剰 Huge Page については未使用になると解放されカーネルの通常プールに戻されます。
7.4. Transparent Huge Page の設定
madvise()
システムコールで指定された個別プロセスのメモリー領域のみに Huge Page を割り当てます。
# cat /sys/kernel/mm/transparent_hugepage/enabled
# echo always > /sys/kernel/mm/transparent_hugepage/enabled
# echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
# echo never > /sys/kernel/mm/transparent_hugepage/enabled
direct compaction
を disabled にします。
# echo madvise > /sys/kernel/mm/transparent_hugepage/defrag
/usr/share/doc/kernel-doc-kernel_version/Documentation/vm/transhuge.txt
ファイルを参照してください。
7.5. システムメモリー容量の設定
/proc
ファイルシステム内の該当ファイルの値を変更し、テストとして一時的に設定することができます。そのパラメーターで使用環境に適したパフォーマンスが得られることを確認したら sysctl コマンドを使って今度は永続的にパラメーターを設定します。
# echo 1 > /proc/sys/vm/overcommit_memory
/etc/sysctl.conf
で sysctl vm.overcommit_memory=1
を追加し、次のコマンドを実行します。
# sysctl -p
7.5.1. 仮想メモリーのパラメーター
/proc/sys/vm
にあります。
- dirty_ratio
- パーセンテージの値。指定したパーセント値の合計メモリーが変更されるとシステムはその変更を
pdflush
演算でディスクに記述し始めます。デフォルト値は20
% です。 - dirty_background_ratio
- パーセンテージの値。指定したパーセント値の合計メモリーが変更されるとシステムはその変更をバックグラウンドでディスクに記述し始めます。デフォルト値は
10
% です。 - overcommit_memory
- 大量メモリーの要求を許可するか拒否するか決定する条件を定義します。デフォルト値は
0
です。デフォルトでは、カーネルは、利用可能なメモリー量と大きすぎる要求の失敗を予測することで、ヒューリスティックなメモリーのオーバーコミット処理を実行します。ただし、メモリーは正確なアルゴリズムではなくヒューリスティックで割り当てられるため、この設定ではメモリーをオーバーロードすることができます。このパラメーターを1
に設定するとカーネルはメモリーのオーバーコミット処理を行いません。これにより、メモリーがオーバーロードする可能性が向上しますが、メモリー集中型タスクのパフォーマンスが向上します。このパラメーターを2
に設定するとカーネルは利用可能な swap 領域とovercommit_ratio
で指定されている物理 RAM の割合との合計と同等もしくはそれ以上のメモリー要求は拒否します。これにより、メモリーのオーバーコミットのリスクが軽減されますが、物理メモリーよりも大きいスワップ領域があるシステムのみに推奨されます。 - overcommit_ratio
overcommit_memory
が2
に設定されている場合に考慮される物理 RAM の割合を指定します。デフォルト値は50
です。- max_map_count
- プロセスが使用可能なメモリーマップ領域の最大数を定義します。ほとんどの場合デフォルト値の
65530
が適した値になります。アプリケーション側でこのファイル数以上の数をマッピングする必要がある場合はこの値を増やします。 - min_free_kbytes
- システム全体で維持する空領域の最小値をキロバイト単位で指定します。これを使って各低メモリゾーンに適切な値が確定され、そのサイズに比例した空き予約ページ数が割り当てられます。警告設定値が低すぎるとシステムを破損する恐れがあります。
min_free_kbytes
の設定が低すぎると、システムによるメモリの回収が妨げられます。これによりシステムがハングし、メモリ不足によってプロセスが強制終了される可能性があります。ただし、min_free_kbytes
の設定が高すぎると (システムメモリー合計の 5 – 10% など) システムがすぐにメモリー不足に陥ってしまうためメモリーの回収に非常に時間がかかることになります。 - oom_adj
panic_on_oom
パラメーターが0
に設定されている状態でメモリーを使い切ってしまうと、oom_killer
関数はシステムが復元できるようになるまでプロセスを強制終了し、プロセスを最も高いoom_score
で起動します。oom_adj
パラメーターはプロセスのoom_score
を確定する際に役立ちます。このパラメーターはプロセス ID ごとに設定されます。-17
の値を設定するとそのプロセスのoom_killer
は無効になります。これ以外にも-16
から15
までの値を使用することができます。注記調整されたプロセスによって生成されたプロセスは、プロセスのoom_score
を継承します。- スワップ
- swappiness 値 (
0
〜100
) は、システムが匿名メモリーやページキャッシュを優先する度合いを制御します。値が大きい場合は、ファイルシステムのパフォーマンスが改善され、あまり活発ではないプロセスが RAM から積極的にスワップされます。値が小さい場合は、メモリーからのプロセスのスワップが回避されます。通常この場合は、レイテンシーが低下しますが I/O パフォーマンスが犠牲になります。デフォルト値は60
です。警告swappiness==0
に設定すると非常に強力にスワップを避けるため、メモリーおよび I/O に圧力がかかりメモリー不足によるプロセスの強制終了のリスクが高まります。
7.5.2. ファイルシステムのパラメーター
/proc/sys/fs
にあります。
- aio-max-nr
- すべてのアクティブな非同期入出力コンテキストで許可されるイベントの最大数を定義します。デフォルト値は
65536
です。この値を変更しても、カーネルデータ構造の事前割り当てやサイズ変更は行われません。 - file-max
- システム全体でのファイルハンドルの最大数を決定します。Red Hat Enterprise Linux 7 のデフォルト値は最大値である
8192
、またはカーネルの起動時に利用可能な空きメモリーページの 1/10 です。この値を設定すると、利用可能なファイルハンドルがないためにエラーを解決できます。
7.5.3. カーネルパラメーター
/proc/sys/kernel/
ディレクトリーにある以下のパラメーターのデフォルト値は、利用可能なシステムリソースに応じて起動時にカーネルによって計算されます。
- msgmax
- メッセージキュー内の 1 メッセージの最大許容サイズをバイト単位で定義します。この値は、キューのサイズ (
msgmnb
) を超えることはできません。システムの現在のmsgmax
値を確認するには、以下のコマンドを使用します。# sysctl kernel.msgmax
- msgmnb
- 単一のメッセージキューの最大サイズをバイト単位で定義します。システムの現在の
msgmnb
値を確認するには、以下のコマンドを使用します。# sysctl kernel.msgmnb
- msgmni
- メッセージキュー識別子の最大数 (つまりキューの最大数) を定義します。システムの現在の
msgmni
値を確認するには、以下のコマンドを使用します。# sysctl kernel.msgmni
- shmall
- 一度にシステムで使用できる共有メモリーページの合計量を定義します。ちなみに、AMD64 および Intel 64 アーキテクチャーでは 1 ページは 4096 バイトに相当します。システムの現在の
shmall
値を確認するには、以下のコマンドを使用します。# sysctl kernel.shmall
- shmmax
- カーネルで許容される 1 共有メモリーセグメントの最大サイズをバイト単位で定義します。システムの現在の
shmmax
値を確認するには、以下のコマンドを使用します。# sysctl kernel.shmmax
- shmmni
- システム全体の共有メモリーセグメントの最大数を定義します。いずれのシステムでもデフォルト値は
4096
です。 - threads-max
- システム全体でカーネルが一度に使用できるスレッドの最大数を定義します。システムの現在の
threads-max
値を確認するには、以下のコマンドを使用します。# sysctl kernel.threads-max
デフォルト値は、以下の式で算出されます。mempages / (8 * THREAD_SIZE / PAGE SIZE )
最小値は20
です。
第8章 ストレージとファイルシステム
8.1. 留意事項
- データの書き込みと読み取りのパターン
- 基礎となるジオメトリーとのデータ調整
- ブロックサイズ
- ファイルシステムのサイズ
- ジャーナルサイズおよび場所
- アクセス時間の記録
- データの信頼性確保
- 事前にフェッチするデータ
- ディスク領域の事前割り当て
- ファイルの断片化
- リソースの競合
8.1.1. I/O スケジューラー
- deadline
- SATA ディスク以外のすべてのブロックデバイス向けのデフォルト I/O スケジューラーです。
Deadline
により、要求が I/O スケジューラーに到達した時点からの要求のレイテンシーが保証されます。このスケジューラーはほとんどのユースケースに適していますが、必要に応じて特に書き込み動作より読み取り動作の方が頻繁に起こるユースケースに適しています。キュー待ち I/O 要求は、読み取りまたは書き込みのバッチに分けられてから、増大している論理ブロックアドレス順に実行スケジュールに入れられます。アプリケーションは読み取り I/O でブロックする可能性の方が高いため、デフォルトでは読み取りバッチの方が書き込みバッチより優先されます。1 バッチが処理されるとdeadline
は書き込み動作が待機している長さを確認して次の読み取りバッチまたは書き込みバッチを適宜スケジュールします。バッチごとに処理するリクエスト数、書き込みバッチごとに問題修正のバッチ数、リクエストの有効期限までの期間はすべて設定可能です。詳細は、「deadline スケジューラーのチューニング」 を参照してください。 - cfq
- SATA ディスクとして識別されるデバイスに限りデフォルトとなるスケジューラーです。
cfq
(Completely Fair Queueing) スケジューラーはプロセスをリアルタイム、ベストエフォート、アイドルの 3 種類のクラスに分割します。リアルタイムクラスのプロセスは常にベストエフォートのプロセスより先に処理され、ベストエフォートのプロセスはアイドルクラスのプロセスより先に処理されます。つまり、リアルタイムクラスのプロセスは、ベストエフォートおよびアイドルのクラスプロセス時間を奪うことになります。デフォルトでは、プロセスはベストエフォートクラスに割り当てられます。cfq
は過去データを使ってアプリケーションで発行される今後の I/O 要求数の増減を予測します。I/O の増加を予測した場合は、他のプロセスの I/O が処理を待機している場合であっても、cfq
はアイドリングを行い新しい I/O を待ちます。cfq スケジューラーはアイドリング状態になりやすいため、意図的な調整を行わない限り、シーク時間を多く要さないハードウェアとは併用しないようにしてください。また、ホストベースのハードウェア RAID コントローラーなど、負荷節約型ではない他のスケジューラーとの併用も避けてください。こうしたスケジューラーを重ねると待ち時間が長くなる傾向があります。cfq
の動作は高度な設定が可能です。詳細は、「CFQ スケジューラーのチューニング」 を参照してください。 - noop
noop
I/O スケジューラーはシンプルな FIFO (first-in first-out) のスケジューリングアルゴリズムを実装しています。要求は 単純な last-hit キャッシュを介して汎用のブロック層でマージされます。これは、高速なストレージを使用した CPU バインドシステムに最適な I/O スケジューラーとなります。
8.1.2. ファイルシステム
8.1.2.1. XFS
8.1.2.2. Ext4
8.1.2.3. Btrfs (テクノロジープレビュー)
- ファイルシステム全体ではなく特定のファイル、ボリューム、またはサブボリュームのスナップショットを取得する機能。
- RAID(Inexpensive Disks)の複数のバージョンの冗長アレイをサポートします。
- I/O エラーをファイルシステムオブジェクトにマッピングし直します。
- 透過的な圧縮(パーティションのすべてのファイルは自動的に圧縮される)
- データおよびメタデータのチェックサム。
8.1.2.4. GFS2
8.1.3. ファイルシステムの一般的なチューニングで考慮すべき点
8.1.3.1. 時刻のフォーマットに関する注意点
- Size (サイズ)
- ワークロードに適したサイズのファイルシステムを作成します。ファイルシステムのサイズが小さければ比例してバックアップに要する時間も短くなり、ファイルシステムのチェックにかかる時間やメモリーも少なくてすみます。ただし、ファイルシステムが小さ過ぎると深刻な断片化によるパフォーマンスの低下が発生します。
- ブロックサイズ
- ブロックは、ファイルシステムの作業単位です。ブロックサイズで、単一のブロックに保存可能なデータ量が決まるので、1 度に書き込みまたは読み取りされる最小データ量を指します。デフォルトのブロックサイズは、ほとんどのユースケースに適しています。ただし、ブロックサイズ (または複数ブロックのサイズ) は一度に読み取られるまたは書き込まれる一般的なデータ量と同じか若干大きい方がファイルシステムのパフォーマンスが向上しデータをより効率的に格納するようになります。ファイルサイズは小さくても 1 ブロック全体が使用されます。ファイルは複数のブロックに分散できますが、ランタイム時のオーバーヘッドが増える可能性があります。また、ファイルシステムによっては、特定のブロック数が上限となっており、ファイルシステムの最大数が制限されます。デバイスを mkfs コマンドでフォーマット化する際にファイルシステムのオプションとしてブロックサイズを指定します。ブロックサイズを指定するパラメーターはファイルシステムにより異なります。詳細は mkfs の man ページをご覧ください。たとえば、XFS ファイルシステムをフォーマット化する場合に利用できるオプションを表示させるには次のコマンドを実行します。
$ man mkfs.xfs
- 配置
- ファイルシステムジオメトリーは、ファイルシステム全体でのデータの分散に関係があります。システムで RAID などのストライプ化ストレージを使用する場合は、デバイスのフォーマット時にデータおよびメタデータを下層にあるストレージジオメトリーに合わせて調整することで、パフォーマンスを向上させることができます。多くのデバイスは推奨のジオメトリーをエクスポートし、デバイスが特定のファイルシステムでフォーマットされるとそのジオメトリーが自動的に設定されます。使用するデバイスが推奨配列をエクスポートしない、または推奨されている設定を変更したい場合などは mkfs でデバイスのフォーマットを行う際に手作業で配列を指定する必要があります。ファイルシステムの配列を指定するパラメーターはファイルシステムによって異なります。詳細は使用するファイルシステムの mkfs man ページをご覧ください。たとえば、ext4 ファイルシステムのフォーマット時に使用できるオプションを表示させる場合は次のコマンドを実行します。
$ man mkfs.ext4
- 外部ジャーナル
- ジャーナリングファイルシステムは、操作を実行する前に、ジャーナルファイルに書き込み操作中に加えられる変更を文書化します。これにより、システムクラッシュや電源異常の発生時にストレージデバイスが破損する可能性が低下し、復旧プロセスが高速化されます。メタデータ集約型のワークロードでは、ジャーナルへの更新頻度が非常に多くなります。ジャーナルが大きいと、より多くのメモリーを使用しますが、書き込み操作の頻度は低減します。さらに、プライマリーストレージと同じか、それ以上の速度の専用ストレージにジャーナルを配置することで、メタデータ集約型のワークロードでデバイスのシーク時間を短縮できます。警告外部ジャーナルが信頼できることを確認します。外部のジャーナルデバイスが失われるとファイルシステムが破損します。外部ジャーナルは、フォーマット時に作成し、マウント時にジャーナルデバイスを指定する必要があります。ジャーナルデバイスはマウント時に指定されたものを使用します。詳細については mkfs の man ページおよび mount の man ページを参照してください。
$ man mkfs
$ man mount
8.1.3.2. マウント時の注意点
- バリア
- ファイルシステムバリアによりメタデータが正しく順番通りに永続ストレージに書き込まれ、停電時には
fsync
で送信したデータが必ず維持されるようになります。Red Hat Enterprise Linux の旧バージョンではファイルシステムバリアを有効にするとfsync
に大きく依存するアプリケーションや小さなファイルを多数作成したり削除したりするアプリケーションなどの速度が著しく低下することがありました。Red Hat Enterprise Linux 7 ではファイルシステムバリアのパフォーマンスが改善され、ファイルシステムバリアを無効にしても、パフォーマンスに対する影響はごくわずかになります (3 % 未満)。詳細は『Red Hat Enterprise Linux 7 ストレージ管理ガイド』を参照してください。 - Access Time
- ファイルが読み込まれる度、アクセスが起きた時間 (
atime
) でそのメタデータが更新されます。この際、追加の書き込み I/O が行われます。デフォルトでは Red Hat Enterprise Linux 7 は前回のアクセス時間が最後の変更 (mtime
) または状態変更 (ctime
) の時間より古い場合にのみatime
フィールドを更新するため、ほとんどの場合、このオーバーヘッドが最小になります。ただし、このメタデータの更新に時間がかかる場合で正確なアクセス時間データが必要ない場合には、noatime
マウントオプションを指定してファイルシステムをマウントしてください。この設定で、ファイルの読み取り時にメタデータへの更新が無効になります。また、nodiratime
動作も有効にし、ディレクトリーの読み取り時にメタデータへの更新を無効にします。 - 先読み (read-ahead)
- 先読みは、すぐに必要になる可能性が高いデータを先に取得してページキャッシュにロードすることでディスクからより早くデータを読み出すことが可能になるため、ファイルアクセスの速度が速くなります。read-ahead 値が大きいほど、さらに事前にシステムのデータがフェッチされます。Red Hat Enterprise Linux は、ファイルシステムについて検出した内容に基づいて、適切な read-ahead 値の設定を試みます。ただし、正確な検出が常に可能であるとは限りません。たとえば、ストレージアレイが単一の LUN としてシステムに表示した場合に、システムはその単一の LUN を検出するので、アレイに適した read-ahead 値は設定されません。連続 I/O を大量にストリーミングするワークロードは、read-ahead 値を高くすると効果がある場合が多いです。Red Hat Enterprise Linux 7 で用意されているストレージ関連の調整済みプロファイルでは LVM ストライプを使用するため先読み値が高く設定されています。しかし、この調整が必ずしもあらゆる作業負荷に十分なわけではありません。先読み動作を定義するパラメーターはファイルシステムにより異なります。詳細は mount の man ページをご覧ください。
$ man mount
8.1.3.3. メンテナンス
- バッチ破棄
- このタイプの破棄は fstrim コマンドの一部になります。ファイルシステム内にある未使用のブロックで、管理者が指定した基準に一致するものをすべて破棄します。Red Hat Enterprise Linux 7 では、物理的な破棄動作に対応している XFS と ext4 フォーマットのデバイスでバッチ破棄がサポートされます (つまり、
/sys/block/devname/queue/discard_max_bytes
の値がゼロ以外の HDD デバイスおよび/sys/block/devname/queue/discard_granularity
の値が0
以外の SSD デバイス)。 - オンライン破棄
- このタイプの破棄動作はマウント時に
discard
オプションを使って設定します。ユーザーの介入を必要とせずリアルタイムで実行されます。ただし、オンライン破棄は使用中から空きの状態に移行しているブロックしか破棄しません。Red Hat Enterprise Linux 7 では XFS および ext4 フォーマットのデバイスでオンライン破棄をサポートしています。パフォーマンス維持にオンライン破棄が必要な状況やシステムの作業負荷上バッチ破棄が実行できないような状況を除き、バッチ破棄の使用を推奨しています。 - 事前割り当て
- 事前割り当てでは、領域にデータを書き込むことなく、ファイルに割り当て済みとしてディスク領域をマークします。これは、データの断片化や、読み取りのパフォーマンスの低下を抑える場合に役立ちます。Red Hat Enterprise Linux 7 では XFS、ext4、GFS2 のデバイスでのマウント時の領域事前割り当てに対応しています。ファイルシステムに適したパラメーターについては mount man ページをご覧ください。アプリケーションは、
fallocate(2)
glibc
呼び出しを使用して、事前割り当てした領域の利点を活用することも可能です。
8.2. パフォーマンスの問題の監視と診断
8.2.1. vmstat を使ったシステムパフォーマンスの監視
- Si
- スワップ(または swap 領域から読み取り)を KB 単位で読み取ります。
- so
- スワップ領域(KB 単位)をスワップアウトまたは書き込みします。
- bi
- ブロック内の書き込み操作(KB 単位)
- bo
- KB 単位の読み取り操作をブロックしたり、ブロックします。
- Wa
- I/O 操作が完了するまで待機するキューの一部。
$ man vmstat
8.2.2. iostat を使った I/O パフォーマンスの監視
$ man iostat
8.2.2.1. blktrace を使った詳細な I/O 分析
$ man blktrace
$ man blkparse
8.2.2.2. btt を使った blktrace 出力の分析
blktrace
メカニズムによって追跡され、btt によって分析される重要なイベントの一部は次のとおりです。
- I/O イベント (
Q
) のキュー - ドライバーイベント (
D
) への I/O のディスパッチ - I/O イベントの完了 (
C
)
blktrace
イベント間のタイミングを確認します。たとえば、以下のコマンドは、スケジューラー、ドライバー、およびハードウェアレイヤーが含まれるカーネル I/O スタックの下部で費やされた合計時間 (Q2C
) を待機期間の平均として報告します。
$
iostat -x
[...]
Device: await r_await w_await
vda 16.75 0.97 162.05
dm-0 30.18 1.13 223.45
dm-1 0.14 0.14 0.00
[...]
D2C
)、デバイスが過負荷の状態であったり、デバイスの送られたワークロードが最適ではないことがあります。ストレージデバイスがディスパッチされる前 (Q2G
) に、ブロック I/O が長時間キューに置かれた場合、使用中のストレージは I/O の負荷に対応できないことを示す場合があります。たとえば、LUN のキューが満杯の状態になり、I/O をストレージデバイスにディスパッチできないことがあります。
Q2Q
) がリクエストがブロックレイヤーで費やす時間の合計 (Q2C
) よりも大きいと btt が示す場合、I/O リクエストの間にアイドル時間があり、I/O サブシステムがパフォーマンスの問題に関係しない可能性があることを意味します。
Q2C
値を比較すると、ストレージサービス時間の変動量を示すことができます。値は以下のいずれかになります。
- 小さい範囲ではほぼ一貫している。
- 分布範囲では変動が大きく、ストレージデバイス側での輻輳問題の可能性がある。
$
man btt
8.2.2.3. iowatcher を使用した blktrace 出力の分析
8.2.3. SystemTap を使ったストレージの監視
/usr/share/doc/systemtap-client/examples/io
ディレクトリーにインストールされます。
disktop.stp
- ディスクの読み取りや書き込みの状態を 5 秒ごとにチェックして上位 10 位のエントリーを出力します。
iotime.stp
- 読み取りおよび書き込みの動作に費やした時間、読み取りと書き込みのバイト数を出力します。
traceio.stp
- 監視した累積 I/O トラフィックに応じた上位 10 位の実行可能ファイルを毎秒出力します。
traceio2.stp
- 指定デバイスに対して読み取りおよび書き込みが発生するとその実行可能ファイル名とプロセス ID を出力します。
inodewatch.stp
- 指定のメジャーまたはマイナーデバイス上の指定 inode に対して読み取りや書き込みが発生するたびにその実行可能ファイル名とプロセス ID を出力します。
inodewatch2.stp
- 指定のメジャーまたはマイナーデバイス上の指定 inode で属性が変更されるたびにその実行可能ファイル名、プロセス ID、属性を出力します。
8.3. ソリッドステートディスク
SSD のチューニング時に考慮すべき点
/usr/share/doc/kernel-version/Documentation/block/switching-sched.txt
ファイルを参照してください。
vm_dirty_background_ratio
と vm_dirty_ratio
設定の値を下げ、書き出しのアクティビティーが増えても通常は、ディスクの他の操作のレイテンシーに悪影響はありません。ただし、このチューニングで 総 I/O 処理が増加する 場合があるため、ワークロードに固有のテストを実施しない限りこのチューニングはお勧めできません。
8.4. 設定ツール
8.4.1. ストレージパフォーマンス向けチューニングプロファイルの設定
- latency-performance
- throughput-performance (デフォルト)
$ tuned-adm profile name
8.4.2. デフォルト I/O スケジューラーの設定
cfq
スケジューラーが使用され、その他すべてのドライブでは deadline
スケジューラーが使用されます。このセクションで説明する手順に従ってデフォルトのスケジューラーを指定した場合には、そのデフォルトスケジューラーがすべてのデバイスに適用されます。
/etc/default/grub
ファイルを変更して設定することができます。
elevator
パラメーターを設定するには、disk
プラグインを有効にします。ディスク
プラグインの詳細は、『Tuned』 の章の 「プラグイン」 を参照してください。
elevator
パラメーターを追加します。手順8.1「GRUB 2 を使用したデフォルト I/O スケジューラーの設定」 で説明されているように、Tuned ツールを使用するか、/etc/default/grub
ファイルを手動で変更できます。
手順8.1 GRUB 2 を使用したデフォルト I/O スケジューラーの設定
/etc/default/grub
ファイルのGRUB_CMDLINE_LINUX
行に、elevator
パラメーターを追加します。#
cat /etc/default/grub ... GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=vg00/lvroot rd.lvm.lv=vg00/lvswap elevator=noop" ...Red Hat Enterprise Linux 7 で使用可能なスケジューラーは、deadline
、noop
、およびcfq
です。詳細については、お使いのカーネルのドキュメントに含まれているcfq-iosched.txt
およびdeadline-iosched.txt
ファイルを参照してください。これらは kernel-doc パッケージのインストールにより利用することができます。- 追加した
elevator
パラメーターを含む新しい設定ファイルを作成します。BIOS ファームウェアを使用しているシステムと UEFI ファームウェアを使用しているシステムとでは、GRUB 2 設定ファイルの場所が異なります。以下のコマンドのいずれかを使用して、GRUB 2 設定ファイルを再作成します。- BIOS ファームウェアを使用している場合は、以下のコマンドを使用します。
#
grub2-mkconfig -o /etc/grub2.cfg - UEFI ファームウェアを使用している場合は、以下のコマンドを使用します。
#
grub2-mkconfig -o /etc/grub2-efi.cfg
- システムを再起動して、変更を有効にします。GNU GRand Unified Bootloader バージョン 2 (GRUB 2) の詳細な情報については、『Red Hat Enterprise Linux 7 システム管理者のガイド』の「GRUB 2 について」セクションを参照してください。
8.4.3. 汎用のブロックデバイスチューニングパラメーター
/sys/block/sdX/queue/
ディレクトリーないで利用できます。リストされたチューニングパラメーターは I/O スケジューラーのチューニングと区別され、すべての I/O スケジューラーに適用できます。
- add_random
- いくつかの I/O イベントが
/dev/random
のエントロピープールに貢献しています。これらの貢献のオーバーヘッドが計測可能になる場合、このパラメーターを0
に設定することができます。 - iostats
- デフォルト値は
1
(enabled
) です。iostats
を0
に設定すると、デバイスに対する I/O 統計の収集が無効化され、I/O パスのオーバーヘッドが若干削減されます。また、iostats
を0
に設定すると、特定の NVMe ソリッドステートストレージデバイスなど、非常に高性能なデバイスのパフォーマンスが若干向上します。特定のストレージモデルで無効にするようにベンダーからの指示がない限り、iostats
は有効のままにしておくことを推奨します。iostats
を無効にすると、デバイスの I/O 統計が/proc/diskstats
ファイルからなくなります。/sys/diskstats
の内容は、sar
またはiostats
などの I/O ツールを監視するための I/O 情報のソースです。したがって、デバイスのiostats
パラメーターを無効にすると、デバイスは I/O 監視ツールの出力に表示されなくなります。 - max_sectors_kb
- I/O 要求の最大サイズを KB 単位で指定します。デフォルト値は
512
KB です。このパラメーターの最小値は、ストレージデバイスの論理ブロックサイズで決まります。パラメーターの最大値はmax_hw_sectors_kb
の値で確定されます。一部のソリッドステートディスクは、I/O リクエストが内部消去ブロックサイズよりも大きいとパフォーマンスが悪化します。システムにアタッチするソリッドステートディスクモデルがこれに該当するかを判断するには、ハードウェアのベンダーに確認し、ベンダーの推奨事項に従います。Red Hat では、max_sectors_kb
を最適な I/O サイズと内部消去ブロックサイズの倍数にするように推奨しています0 が指定されているか、ストレージデバイスによる指定がない場合には、どちらかのパラメーターのlogical_block_size
の値を使用します。 - nomerges
- 要求をマージは、ほとんどのワークロードで有用です。ただし、デバッグの目的では、マージを無効にすると便利です。デフォルトでは、
nomerges
パラメーターは0
に設定されており、マージが有効です。単純な 1 回だけのマージを無効にするにはnomerges
を1
に設定します。すべてのタイプのマージを無効にするには、nomerges
を2
に設定します。 - nr_requests
- 一度にキュー待ちさせることができる読み取りと書き込み要求の最大数を指定します。デフォルト値は
128
です。つまり、読み取りまたは書き込みの要求に対する次の処理をスリープ状態にするまでそれぞれ 128 個の読み取り要求と 128 個の書き込み要求をキュー待ちにすることができます。遅延の影響を受けやすいアプリケーションの場合、ライトバック I/O が書き込み要求でデバイスキューを満杯にできないようにするため、このパラメーターの値を低くしてストレージのコマンドキューの深さを制限します。デバイスのキューが満杯になると I/O 動作を実行しようとしている他のプロセスはキューが使用できるようになるまでスリープ状態になります。要求はラウンドロビン方式で割り当てられ、1 つのプロセスが継続してキューのすべての領域を使用しないようにします。I/O スケジューラー内の I/O 操作の最大数はnr_requests*2
です。nr_requests
は読み取りと書き込みで別々に適用されます。nr_requests
は I/O スケジューラー内の I/O 操作のみに適用され、基盤のデバイスにすでにディスパッチされた I/O 操作には適用されません。そのため、1 つのデバイスに対する未処理の I/O 操作の最大数は(nr_requests*2)+(queue_depth)
(queue_depth
は/sys/block/sdN/device/queue_depth
で LUN キューの深さと呼ばれることもあります)。たとえば、未処理の I/O 操作の合計数はavgqu-sz
列のiostat
の出力に表示されます。 - optimal_io_size
- このパラメーターで最適な I/O サイズを報告するストレージデバイスもあります。この値が報告される場合は、できるだけ報告された最適な I/O サイズに合わせその倍数の I/O をアプリケーションで発行させることを推奨しています。
- read_ahead_kb
- 連続読み込み操作中にオペレーティングシステムが読み取ることができる最大キロバイト数を定義します。その結果、次のシーケンシャル読み取りに対し、必要となりそうな情報はカーネルページキャッシュ内にすでに存在するため、読み取りの I/O 操作が向上します。
read_ahead_kb
の値を大きくすると、デバイスマッパーは効果を得られます。開始点として、各デバイスに対して 128 KB の値にするとよいでしょう。read_ahead_kb
の値を 4–8 MB に上げると、大型のファイルのシーケンシャル読み取りが行われるアプリケーション環境でのパフォーマンスが向上する可能性があります。 - rotational
- 一部のソリッドステートディスクは、ソリッドステートのステータスを正しく公開せず、従来の回転ディスクとしてマウントされます。ご使用の SSD デバイスで、この値が自動的に
0
に設定されない場合は、この値を手作業で設定し、スケジューラーで不要なシーク時間短縮ロジックを無効にします。 - rq_affinity
- デフォルトでは I/O 要求を発行したプロセッサーとは異なるプロセッサーで I/O の完了を処理することができます。
rq_affinity
を1
に設定するとこの機能を無効にして I/O の完了はその I/O 要求を発行したプロセッサーでしか行わないようにします。これによりプロセッサーのデータキャッシングの効率性が改善されます。 - scheduler
- スケジューラーや特定ストレージデバイスのスケジューラー優先順位を設定するには、
/sys/block/devname/queue/scheduler
ファイルを編集します (devname は設定するデバイスの名前に置き換えます)。# echo cfq > /sys/block/hda/queue/scheduler
8.4.4. deadline スケジューラーのチューニング
deadline
を使用するとキュー待ちの I/O 要求は読み取りまたは書き込みのバッチに分けられてから増大している論理ブロックアドレス順に実行スケジュールに入れられます。アプリケーションは読み取り I/O でブロックする可能性の方が高いため、デフォルトでは読み取りバッチの方が書き込みバッチより優先されます。1 バッチが処理されると deadline
は書き込み動作が待機している長さを確認して次の読み取りバッチまたは書き込みバッチを適宜スケジュールします。
deadline
スケジューラーの動作に影響を与えるパラメーターです。
- fifo_batch
- ひとつのバッチで発行する読み取りまたは書き込みの動作数です。デフォルトは
16
です。値を高くするほど処理能力も高まりますが待ち時間も増加します。 - front_merges
- 前方マージを一切生成しない作業負荷の場合、
0
に設定することは可能です。ただし、このチェックのオーバーヘッドを測定していない限り Red Hat ではデフォルト値の1
の使用を推奨しています。 - read_expire
- ミリ秒単位で指定します。この時間内に読み取り要求がスケジュールされます。デフォルト値は
500
(0.5 秒) です。 - write_expire
- ミリ秒単位で指定します。この時間内に書き込み要求がスケジュールされます。デフォルト値は
5000
(5 秒) です。 - writes_starved
- 読み取りバッチ数を指定します。指定バッチ数を先に処理してから書き込みバッチをひとつ処理します。高い値を設定するほど読み取りバッチの方が多く優先して処理されます。
8.4.5. CFQ スケジューラーのチューニング
/sys/block/devname/queue/iosched
ディレクトリー配下にある指定ファイルでデバイスごとに設定を変更します。
- back_seek_max
- CFQ に後方シークを行わせる最長距離をキロバイトで指定します。デフォルト値は
16
KB です。後方シークは特にパフォーマンスを低下さるため、大きな値の使用は推奨していません。 - back_seek_penalty
- ディスクヘッドで前方または後方への移動を決定する際に後方シークに対して適用する乗数を指定します。デフォルト値は
2
です。ディスクヘッドの位置が 1024 KB でシステムに等距離の要求がある場合 (1008 KB と 1040 KB など)、back_seek_penalty
が後方シークの距離に対して適用されディスクは前方に移動します。 - fifo_expire_async
- ミリ秒単位の長さで指定します。非同期 (バッファされた書き込み) の要求を処理せず放置する長さです。この時間を過ぎると非同期の処理待ち要求が処理リストに移動されます。デフォルト値は
250
ミリ秒です。 - fifo_expire_sync
- ミリ業単位の長さで指定します。同期 (読み取りまたは
O_DIRECT
書き込み) の要求を処理せず放置する長さです。この時間を過ぎると非同期の処理待ち要求が処理リストに移動されます。デフォルト値は125
ミリ秒です。 - group_idle
- このパラメーターはデフォルトでは
0
(無効) に設定されます。1
(有効) に設定するとcfq
スケジューラーは制御グループ内で I/O を発行している最後のプロセスでアイドリングします。比例加重 I/O 制御グループを使用し、slice_idle
を0
に設定している (高速ストレージで) 場合に便利です。 - group_isolation
- このパラメーターはデフォルトでは
0
(無効) に設定されます。1
(有効) に設定するとグループ間をより強力に分離しますが、ランダムな作業負荷および連続した作業負荷の両方に対して公平性が適用されるため処理能力は低減されます。group_isolation
を無効にすると (0
の設定) 公平性は連続した作業負荷にのみ適用されます。詳細は/usr/share/doc/kernel-doc-version/Documentation/cgroups/blkio-controller.txt
にインストールされているドキュメントをご覧ください。 - low_latency
- このパラメーターはデフォルトでは
1
(有効) に設定されます。有効の場合、cfq
はデバイスで I/O を発行している各プロセスごと最大300
ミリ秒の待ち時間を与え処理能力より公平性を優先させます。0
(無効) に設定するとターゲットの待ち時間は無視され、各プロセスは完全なタイムスライスを受け取ります。 - quantum
cfq
がひとつのデバイスに一度に送信できる I/O 要求数を指定します。基本的にはキューの深さを制限します。デフォルト値は8
です。使用するデバイス側はより深いキューに対応している可能性はありますが、quantum の値を上げると待ち時間も増えます。特に大量の連続する書き込み作業負荷がある場合は顕著です。- slice_async
- 非同期の I/O 要求を発行している各プロセスに割り当てるタイムスライスの長さを指定します (ミリ秒単位)。デフォルト値は
40
ミリ秒です。 - slice_idle
- 次の要求を待つあいだ cfq にアイドリングを行わせる長さをミリ秒単位で指定します。デフォルト値は
0
(キューまたはサービスツリーレベルではアイドリングを行わない) です。デフォルト値を使用すると外付け RAID ストレージでの処理能力が最適となりますが、シーク動作の総数が増加するため RAID ではない内蔵ストレージの場合には処理能力が低下します。 - slice_sync
- 同期 I/O 要求を発行している各プロセスに割り当てるタイムスライスの長さをしていします (ミリ秒単位)。デフォルト値は
100
ミリ秒です。
8.4.5.1. 高速ストレージの CFQ のチューニング
cfq
スケジューラーの使用は推奨しません。こうしたストレージで cfq
を使用しなければならない場合は、次の設定ファイルを編集する必要があります。
/sys/block/devname/queue/iosched/slice_idle
を0
に設定します。/sys/block/devname/queue/iosched/quantum
を64
に設定します。/sys/block/devname/queue/iosched/group_idle
を1
に設定します。
8.4.6. noop スケジューラーのチューニング
noop
I/O スケジューラーは、主に高速のストレージを使用する CPU バウンドシステムで使用すると便利です。一般的に、noop
I/O スケジューラーは仮想マシンが仮想ディスクに I/O 操作を実行するときに仮想マシンで使用されますが、この使用に限定されません。
noop
I/O スケジューラーに固有するチューニング可能なパラメーターはありません。
8.4.7. パフォーマンス改善を目的としたファイルシステムの設定
8.4.7.1. XFS チューニング
8.4.7.1.1. フォーマットオプション
$ man mkfs.xfs
- ディレクトリーのブロックサイズ
- ディレクトリーのブロックサイズは I/O 動作ごとに読み出したり修正したりするディレクトリー情報の量に影響を与えます。ディレクトリーブロックサイズの最小値はファイルシステムのブロックサイズになります (デフォルト 4 KB)。また最大値は
64
KB になります。所定のブロックサイズの場合、サイズが大きいディレクトリーの方が小さいディレクトリーより多くの I/O を必要とします。またディレクトリーのブロックサイズが大きいシステムの方が小さいサイズより I/O 動作ごとの処理能力の消費量が高くなります。したがってディレクトリーのサイズ、ディレクトリーブロックサイズ共にできるだけ小さいサイズにすることを推奨しています。Red Hat は、write-heavy および read-heavy 負荷に対して、一覧表示されたエントリー数のないファイルシステムの場合は、表8.1「ディレクトリーブロックサイズに対して推奨しているディレクトリーエントリーの最大数」 に記載されているディレクトリーブロックサイズを推奨します。表8.1 ディレクトリーブロックサイズに対して推奨しているディレクトリーエントリーの最大数
ディレクトリーのブロックサイズ 最大エントリー数 (読み取りが多い作業負荷) 最大エントリー数 (書き込みが多い作業負荷) 4 KB 100,000–200,000 1,000,000–2,000,000 16 KB 100,000–1,000,000 1,000,000–10,000,000 64 KB >1,000,000 >10,000,000 ディレクトリーのブロックサイズによって異なる読み取りや書き込みの作業に与える影響については XFS 提供のドキュメントを参照してください。ディレクトリーのブロックサイズを設定するには mkfs.xfs -l オプションを使用します。詳細は mkfs.xfs man ページをご覧ください。 - 割り当てグループ
- 割り当てグループは独立した構造でファイルシステムのセクション全体に割り当てられている inode や空領域でインデックスを作成します。各割り当てグループは個別に修正できるため XFS による割り当て動作および割り当て解除の動作は影響するグループが異なる限り同時に行わせることが可能です。したがってファイルシステム内で実行可能な並列動作数は割り当てグループ数と同数になります。ただし、並列動作の実行は動作を行えるプロセッサー数によっても制限されるため割り当てグループ数はシステム内のプロセッサー数と同数またはそれ以上にすることを推奨しています。ひとつのディレクトリーを複数の割り当てグループで同時に変更することはできません。したがって多数のファイルを作成したり削除するアプリケーションには一つのディレクトリーに全てのファイルを保存させないようにすることを推奨しています。割り当てグループを設定するには mkfs.xfs -d オプションを使用します。詳細は mkfs.xfs man ページをご覧ください。
- 増大に関する制約
- フォーマットを行った後にファイルシステムのサイズを大きくする必要が生じた場合 (ハードウェアの追加やシンプロビジョニング)、一旦フォーマットを完了した割り当てグループのサイズは変更できないため初期のファイルレイアウトに十分注意してください。割り当てグループのサイズ決定は初期のファイルシステム容量ではなく最終的な容量に応じて行ってください。完全に増大し切った状態のファイルシステムの割り当てグループ数はその最大サイズ (1 TB) に達しない限り 200 から 300 以内に収まるようにします。したがって、ほとんどのファイルシステムで増大可能な推奨最大サイズは初期サイズの 10 倍になります。RAID アレイでファイルシステムを増大させる場合、新しい割り当てグループのヘッダーが追加したストレージに正しく合うようデバイスのサイズを割り当てグループサイズの倍数にする必要があるため更に注意が必要です。また、新しいストレージには既存ストレージと同じ配列を持たせる必要があります。フォーマット後は配列を変更することができないため、同じブロックデバイスに異なる配列のストレージがある場合は最適化が行えません。
- inode とインライン属性
- inode に十分な領域がある場合は inode への属性名と値の書き込みを XFS で直接行うことができます。こうしたインライン属性の読み出しや変更は余分な I/O が必要ないため別々の属性ブロックの読み出しに比べ 10 倍速くなります。デフォルトの inode サイズは 256 バイトです。属性の格納に使用できるのはこのうちの約 100 バイトのみ、inode に格納されるデータエクステントポインター数により異なります。ファイルシステムをフォーマットする際に inode サイズを増やすと属性の格納に使用できる領域サイズが増加します。属性名および属性値はいずれも最大サイズ 254 バイトに制限されています。属性名か属性値のいずれかの長さが 254 バイトを超えるとその属性は別の属性ブロックにプッシュされインラインには格納されなくなります。inode パラメーターを設定するには mkfs.xfs -i オプションを使用します。詳細は mkfs.xfs man ページをご覧ください。
- RAID
- ソフトウェア RAID を使用している場合は mkfs.xfs で自動的にベースとなるハードウェアが適切なストライプ単位とストライプ幅に設定されます。しかし、ハードウェア RAID を使用している場合はハードウェア RAID が必ずしもすべてこの情報をエクスポートするとは限らないため手作業によるストライプ単位とストライプ幅の設定が必要な場合があります。設定を行う場合は mkfs.xfs -d オプションを使用します。詳細は mkfs.xfs man ページをご覧ください。
- ログサイズ
- 保留中の変更はログに書き込みが行われる同期イベントの発生までメモリー内に集められます。ログのサイズにより同時に処理できる並列の変更数が決定します。また、メモリー内に集めることができる変更の最大サイズも決定するため、ログ記録したデータがディスクに書き込まれる頻度も決定されます。ログが小さいほどデータのディスクへの書き込み頻度は多くなります。ただし、大きいログはそれだけ保留中の変更を記録するため大きくのメモリーを使用するため、メモリーに制限があるシステムの場合はログを大きくしても意味がありません。ログはベースとなるストライブの単位と合わせるとパフォーマンスが良くなります。つまり、ログがストライプ単位の境界線で開始や終了を行うためです。ログをストライプ単位に合わせるには mkfs.xfs -d オプションを使用します。詳細は mkfs.xfs man ページをご覧ください。ログサイズを設定するには以下の mkfs.xfs オプションを使用します。logsize にはログのサイズを入力します。
# mkfs.xfs -l size=logsize
詳細については mkfs.xfs の man ページをご覧ください。$ man mkfs.xfs
- ログのストライプ単位
- RAID5 や RAID6 レイアウトを使用するストレージデバイスに書き込みを行うログの場合、ストライプ単位の境界線で書き込みの開始や終了を行わせるとパフォーマンスが良くなります (ベースとなるストライプ単位にあわせる)。mkfs.xfs を使用すると自動的に適切なログのストライブ単位への設定が試行されます。ただし、この情報をエクスポートしている RAID デバイスによります。同期イベントが非常に頻繁に発生するような作業の場合、ログのストライプ単位を大きく設定するとパフォーマンスが低下する場合があります。書き込みが小さい場合、1 ログストライプのサイズを埋める必要があるため待ち時間が増えることがあるためです。ログ書き込みの待ち時間で制約を受ける作業の場合は、Red Hat では、ログのストライプ単位を 1 ブロックに設定して、アラインされていないログの書き込み開始を可能とすることを推奨しています。対応しているログのストライプ単位の最大サイズはログのバッファサイズの最大値です (256 KB)。これによりベースとなるストレージにログに設定できるストライプ単位より大きいストライプ単位を持たせることができます。この場合、mkfs.xfs により警告が発せられログのストライプ単位には 32 KB が設定されます。ログのストライプ単位を設定するには以下のいずれかのオプションを使用します。N にはストライプ単位として使用するブロック数を入力します。size にはストライプ単位のサイズを KB で入力します。
mkfs.xfs -l sunit=Nb mkfs.xfs -l su=size
詳細については mkfs.xfs の man ページをご覧ください。$ man mkfs.xfs
8.4.7.1.2. マウントオプション
- Inode 割り当て
- 1 TB を超えるサイズのファイルシステムの場合、inode 割り当ての使用を強く推奨します。
inode64
パラメーターを使用すると XFS が inode とデータをファイルシステム全体に割り当てるよう設定されます。これにより inode の多くがファイルシステムの先頭に割り当てられるのを防ぎ、データの多くがファイルシステムの後方に割り当てられるようになり、大きなファイルシステムのパフォーマンスが向上します。 - ログのバッファサイズと数
- ログバッファが大きいほどログにすべての変更を書き込む際に要する I/O 動作数が少なくなります。大きなログバッファは I/O 使用が多い作業で非揮発性の書き込みキャッシュがないシステムのパフォーマンスを改善します。ログのバッファサイズは
logbsize
マウントオプションで設定、ログバッファに格納できる情報量の最大値を定義します。ログのストライプ単位を設定していない場合はバッファの書き込みは最大値より短くなるため、同期の多い作業に対してはログのバッファサイズを小さくする必要はありません。ログバッファのデフォルトサイズは 32 KB です。最大サイズは 256 KB です。これ以外に対応しているサイズは 64 KB、128 KB、または 32 KB から 256 KB のあいだのログストライプ単位の 2 の累乗の倍数です。ログバッファ数はlogbufs
マウントオプションで指定します。デフォルト値は 8 ログバッファ (最大) ですが最小では 2 ログバッファを指定することができます。余分なログバッファにメモリーを割り当てる余裕のないメモリー制約のあるシステム以外、通常はログバッファ数を減らす必要はありません。ログバッファ数を減らすとログのパフォーマンスが低下する傾向があります。特にログの I/O 待ち時間に制約のある作業に顕著に見られます。 - 変更のログ記録の遅延
- XFS にはログに変更を書き込む前にメモリーにその変更を集めておくことができるオプションがあります。
delaylog
パラメーターを使うと頻繁に変更されるメタデータは変更の度にログに書き込むのではなく、定期的なログへの書き込みを行わせることができるようになります。このオプションを使用するとクラッシュで失う可能性のある動作数が増え、またメタデータの追跡に使用するメモリー量も増加します。ただし、メタデータの変更速度やスケーラビリティーが 10 倍向上されるため、fsync
、fdatasync
、またはsync
などを使ってデータとメタデータのディスクへの書き込みを確実に行わせる場合にデータやメタデータの整合性を損うことがありません。
8.4.7.2. ext4 のチューニング
8.4.7.2.1. フォーマットオプション
- Inode テーブルの初期化
- ファイルシステム内のすべての inode を初期化するときに、非常に大きいファイルシステムではかなりの時間がかかる場合があります。デフォルトでは、初期化のプロセスは保留になります (レイジー inode テーブルの初期化が有効)。ただし、システムに ext4 ドライバーがない場合は、レイジー inode テーブルの初期化がデフォルトでは無効になります。lazy_itable_init を 1 に設定すると有効になります。このような場合、カーネルのプロセスはファイルシステムがマウントされるとその初期化を続行します。
$ man mkfs.ext4
8.4.7.2.2. マウントオプション
- Inode テーブル初期化の割合
- レイジー inode テーブルの初期化が有効になっている場合は
init_itable
パラメーターの値を指定することで初期化が起こる割合を制御することができます。バックグラウンドでの初期化にかかる時間はほぼ 1 をこのパラメーターの値で割った数値になります。デフォルト値は10
です。 - ファイルの自動同期
- 既存ファイル名の変更を行ったり、ファイルの短縮や書き直しをすると
fsync
が正しく動作しないアプリケーションがあります。ext4 の場合、デフォルトではこうした動作の後には必ず自動的にファイルの同期が行われます。ただしこのファイルの自動同期は時間がかかる場合があります。ここまでの同期を必要としない場合はマウント時にnoauto_da_alloc
オプションを指定するとこの動作を無効にすることができますnoauto_da_alloc
を設定する場合、データの整合性を確保するにはアプリケーション側で明示的に fsync を使用する必要があります。 - ジャーナル I/O の優先度
- ジャーナル I/O の優先度はデフォルトでは通常の I/O より若干高い
3
です。マウント時にjournal_ioprio
パラメーターを使ってジャーナル I/O の優先度を制御することができます。journal_ioprio
に指定できる値は0
から7
の範囲です。0
が最も優先度の高い I/O になります。
$ man mount
8.4.7.3. Btrfs のチューニング
データ圧縮
compress=zlib
: 圧縮率が高く、古いカーネルに安全なデフォルトオプション。compress=lzo
: 圧縮は高速ですが、zlib よりも低速です。compress=no
: 圧縮を無効にします。compress-force=method
: 動画やディスクイメージなどの圧縮率が高くないファイルにも圧縮を有効にします。利用可能な方法はzlib
とlzo
です。
zlib
または lzo
に置き換えたあとでこのコマンドを実行します。
$ btrfs filesystem defragment -cmethod
lzo
を使用してファイルを再圧縮するには、次のコマンドを実行します。
$ btrfs filesystem defragment -r -v -clzo /
8.4.7.4. GFS2 のチューニング
- ディレクトリーの間隔
- GFS2 マウントポイントの最上位レベルのディレクトリー内に作成されるディレクトリーはすべて自動的に間隔が置かれ、断片化を低減すると共にディレクトリー内での書き込み速度を速めています。最上位レベルのディレクトリー同様別のディレクトリーノ間隔も空ける場合は以下に示すように
T
属性でそのディレクトリーに印を付けます。dirname には間隔を空けるディレクトリーのパスを入力します。# chattr +T dirname
chattr は e2fsprogs パッケージの一部として提供されます。 - 競合を減らす
- GFS2 はクラスター内のノード間で通信を必要とする可能性があるグローバルロックのメカニズムを使用します。複数のノード間でファイルやディレクトリーの競合が起きるとパフォーマンスの低下を招きます。複数のノード間で共有するファイルシステムの領域をできるだけ小さくすることでキャッシュ間の無効化を招く危険性を最小限に抑えることができます。
第9章 ネットワーク
9.1. 留意事項
/proc/sys/net/core/dev_weight
で指定) が転送されるまで続けられます。
tuned
、チューニングデーモン、numad
NUMA デーモン、CPU の電源状態、割り込みの分散、一時停止フレーム、割り込みの統合、アダプターキュー (netdev
バックログ)、アダプター RX および TX バッファー、アダプター TX キュー、モジュールパラメーター、アダプターオフロード、ジャンボフレーム、TCP および UDP プロトコルチューニング、ならびに NUMA ローカリティー。
9.1.1. チューニングを行う前に
9.1.2. パケット受信におけるボトルネック
- NIC ハードウェアバッファまたはリングバッファ
- 大量のパケットがドロップされるとハードウェアバッファがボトルネックとなる場合があります。破棄されたパケットについてシステムの監視に関する情報は、「ethtool」 を参照してください。
- ハードウェアまたはソフトウェアの割り込みキュー
- 割り込みにより、レイテンシーやプロセッサーの競合が増大する可能性があります。プロセッサーが割り込みを処理する方法は、「IRQ (Interrupt Request ー 割り込み要求) の処理」 を参照してください。システムで割り込み処理を監視する方法は、「/proc/interrupts」 を参照してください。割り込み処理に影響する設定オプションは、「AMD64 および Intel 64 での割り込み親和性の設定」 を参照してください。
- アプリケーションのソケット受信キュー
- 要求しているアプリケーションに対して多数のパケットがコピーされない場合、
/proc/net/snmp
の UDP 入力エラー (InErrors
) が増加する場合などはアプリケーションの受信キューでのボトルネックを示しています。このエラーに関するシステムの監視に関する詳細は、「ss」 および 「/proc/net/snmp」 を参照してください。
9.2. パフォーマンスの問題の監視と診断
9.2.1. ss
$ man ss
9.2.2. ip
$ man ip
9.2.3. dropwatch
$ man dropwatch
9.2.4. ethtool
$ ethtool -S devname
$ man ethtool
9.2.5. /proc/net/snmp
/proc/net/snmp
には IP、ICMP、TCP、UDP などの監視と管理のため snmp エージェントで使用されるデータが表示されます。このファイルを定期的にチェックして普段とは異なる値がないかを確認、パフォーマンス関連の問題となる可能性が潜んでいないか確認することができます。たとえば、/proc/net/snmp
の UDP 入力エラー (InErrors
) が増えている場合はソケット受信キューでの障害を示している可能性があります。
9.2.6. SystemTap を使ったネットワークの監視
/usr/share/doc/systemtap-client/examples/network
ディレクトリーにインストールされます。
nettop.stp
- 5 秒ごとにプロセス一覧 (プロセス ID とコマンド)、送受信したパケット数、その間にプロセスによって送受信されたデータ量を出力します。
socket-trace.stp
- Linux カーネルの
net/socket.c
ファイル内の各関数をインストルメント化して、追跡データを出力します。 dropwatch.stp
- 5 秒ごとにカーネル内の場所で解放されたソケットバッファ数を出力します。
--all-modules
オプションを使用してシンボリック名を表示します。
latencytap.stp
スクリプトは異なるタイプの待ち時間が 1 つ以上のプロセスに与える影響を記録します。レイテンシータイプの一覧を 30 秒ごとに出力し、待機しているプロセスまたはプロセスの合計時間で降順でソートします。これは、ストレージとネットワークレイテンシーの両方の原因を特定するのに役立ちます。Red Hat は、このスクリプトに --all-modules
オプションを使用して、レイテンシーイベントのマッピングをより有効化することを推奨します。デフォルトではこのスクリプトは /usr/share/doc/systemtap-client-version/examples/profiling
ディレクトリーにインストールされます。
9.3. 設定ツール
9.3.1. ネットワークパフォーマンス向けの Tuned プロファイル
- latency-performance
- network-latency
- network-throughput
9.3.2. ハードウェアバッファーの設定
- 入力トラフィックの速度が遅い
- キューを満たす速度を下げるには、受信トラフィックのフィルター、参加するマルチキャストグループ数の削減、またはブロードキャストトラフィック量の削減を行います。受信トラフィックのフィルター方法に関する詳細は『Red Hat Enterprise Linux 7 セキュリティーガイド』を参照してください。マルチキャストグループの詳細は Red Hat Enterprise Linux 7 のクラスタリング関連のドキュメントを参照してください。ブロードキャストのトラフィックの詳細は『Red Hat Enterprise Linux 7 システム管理者のガイド』または設定するデバイスに関するドキュメントを参照してください。
- ハードウェアバッファーキューのサイズ
- キューのサイズを大きくすることでドロップされてしまうパケット数を減らしオーバーフローを防ぎます。ethtool コマンドでネットワークデバイスの rx/tx パラメーターを修正します。
# ethtool --set-ring devname value
- キューのドレイン (解放) レートの変更
- デバイス加重はデバイスで一度 (スケジュールされているプロセッサーのアクセス 1 回) に受信できるパケット数を参照します。
dev_weight
パラメーターで管理されているデバイス加重を増やすことでキューが排出される割合を増加させることができます。一時的に変更する場合は/proc/sys/net/core/dev_weight
ファイルの内容を編集します。永続的に変更する場合は procps-ng パッケージで提供される sysctl を使って変更します。
9.3.3. 割り込みキューの設定
9.3.3.1. ビジーポーリングの設定
sysctl.net.core.busy_poll
を0
以外の値に設定します。このパラメーターはソケットのポーリングと選択用デバイスキューでパケットを待機する時間を管理します (マイクロ秒単位)。Red Hat は、50
の値を推奨します。SO_BUSY_POLL
ソケットオプションをソケットに追加します。
sysctl.net.core.busy_read
のパラメーターも 0
以外の値に設定する必要があります。このパラメーターはソケットの読み取り用デバイスキューでパケットを待機する時間を管理します (マイクロ秒単位)。また、SO_BUSY_POLL
オプションのデフォルト値も設定します。Red Hat ではソケット数が少ない場合は 50
、ソケット数が多い場合は 100
の設定を推奨しています。ソケット数が非常に多くなる場合は (数百以上) 代わりに epoll
を使用します。
- bnx2x
- be2net
- ixgbe
- mlx4
- myri10ge
# ethtool -k device | grep "busy-poll"
busy-poll: on [fixed]
が返された場合はそのデバイスでビジーポーリングを使用することができます。
9.3.4. ソケット受信キューの設定
- 受信トラフィックの速度を下げる
- キューに到達する前にパケットをフィルターまたは破棄したり、デバイスのウェイトを下げたりすることで、キューがいっぱいになる速度を低減します。
- アプリケーションのソケットキューの深さを増やす。
- バーストで制限されたトラフィック量を受信するソケットキューが、ソケットキューの深さを、トラフィックのバーストサイズに一致するように増やすと、パケットがドロップされるのを防ぐことができます。
9.3.4.1. 受信トラフィックの速度を下げる
dev_weight
パラメーターで管理します。一時的に変更する場合は /proc/sys/net/core/dev_weight
ファイルの内容を編集します。永続的に変更する場合は procps-ng パッケージで提供される sysctl を使って変更します。
9.3.4.2. キューの深さを増やす
- /proc/sys/net/core/rmem_default の値を増やす
- このパラメーターは、ソケットが使用する受信バッファーのデフォルトサイズを制御します。この値は
/proc/sys/net/core/rmem_max
の値以下にする必要があります。 - setsockopt を使って SO_RCVBUF に大きな値を設定する
- このパラメーターにより、ソケットの受信バッファーの最大サイズを制御します (バイト単位)。
getsockopt
システムコールを使用して、バッファーの現在の値を判断します。詳細は socket(7) の man ページを参照してください。
9.3.5. RSS (Receive-Side Scaling) の設定
/proc/interrupts
内でそのインターフェースに関連付けられているかどうかチェックします。たとえば、p1p1
インターフェイスを確認する場合は以下を実行します。
# egrep 'CPU|p1p1' /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 89: 40187 0 0 0 0 0 IR-PCI-MSI-edge p1p1-0 90: 0 790 0 0 0 0 IR-PCI-MSI-edge p1p1-1 91: 0 0 959 0 0 0 IR-PCI-MSI-edge p1p1-2 92: 0 0 0 3310 0 0 IR-PCI-MSI-edge p1p1-3 93: 0 0 0 0 622 0 IR-PCI-MSI-edge p1p1-4 94: 0 0 0 0 0 2475 IR-PCI-MSI-edge p1p1-5
p1p1
インターフェースに 6 つの受信キューが作成されたことを示しています (p1p1-0
から p1p1-5
)。また、各キューで処理された割り込みの数と、割り込みをした CPU の数も表示されます。この場合、デフォルトではこの特定の NIC ドライバーは CPU ごとに 1 つのキューを作成するため 6 つのクエリーがあります。また、このシステムには CPU が 6 つあります。これは、NIC ドライバー間で非常に一般的なパターンです。
0000:01:00.0
のデバイスをチェックするには、以下のコマンドを実行するとそのデバイスの割り込み要求キューを一覧表示できます。
# ls -1 /sys/devices/*/*/0000:01:00.0/msi_irqs 101 102 103 104 105 106 107 108 109
bnx2x
ドライバーは num_queues
で設定されます。sfc
ドライバーの場合は、rss_cpus
パラメーターで設定されます。通常、/sys/class/net/device/queues/rx-queue/
で設定されます。この device はネットワークデバイスの名前 (eth1
) で、rx-queue は適切な受信キューの名前です。
--show-rxfh-indir
および --set-rxfh-indir
パラメーターを使ってネットワークアクティビティーの配分方法を修正したり、特定タイプのネットワークアクティビティーを他より重要なアクティビティーとして加重することもできます。
irqbalance
デーモンを RSS と併用するとノード間メモリー転送やキャッシュラインバウンスの可能性が低減されます。これにより、ネットワークパケット処理のレイテンシーが短縮されます。
9.3.6. 受信パケットステアリング (RPS) の設定
- RPS は、どのネットワークインターフェースカードでも使用できます。
- 新しいプロトコルに対応するために、ソフトウェアフィルターを RPS に簡単に追加できます。
- RPS は、ネットワークデバイスのハードウェア割り込みレートを増やしません。ただし、プロセッサー間割り込みは導入されます。
/sys/class/net/device/queues/rx-queue/rps_cpus
ファイル内でネットワークデバイスおよび受信キューごとに設定されます。device はネットワークデバイスの名前 (eth0
など)、rx-queue は該当する受信キューの名前です (rx-0
など)。
rps_cpus
ファイルのデフォルト値は 0
です。この値の場合は RPS は無効です。したがってネットワーク割り込みを処理する CPU がパケットも処理します。
rps_cpus
を設定します。
rps_cpus
ファイルはコンマで区切った CPU ビットマップを使用します。したがって、CPU がインターフェースの受信キューの割り込みを処理できるようにするには、プレースホルダー内のその位置の値を 1 に設定します。たとえば、CPU 0、1、2、および 3 で割り込みを処理する場合は rps_cpus
の値を f
(15 の 16 進数表記) に設定します。2 進数表記では、15 は 00001111
(1+2+4+8) で表されます。
9.3.7. RFS (Receive Flow Steering) の設定
/proc/sys/net/core/rps_sock_flow_entries
- このファイルの値を同時にアクティブになるであろう接続の予測最大数に設定します。適度なサーバー負荷の場合は
32768
の設定値を推奨しています。入力した値はすべて直近の 2 の累乗で切り上げられます。 /sys/class/net/device/queues/rx-queue/rps_flow_cnt
- device は設定するネットワークデバイス名 (
eth0
など)、rx-queue は設定する受信キューになります (rx-0
など)。rps_sock_flow_entries
をN
で割った値をこのファイルの値に設定します。ここで、N
は、デバイスの受信キューの数です。たとえば、rps_flow_entries
が32768
に設定され、16 の設定済み受信キューがある場合、rps_flow_cnt
を2048
に設定する必要があります。単一キューデバイスの場合は、rps_flow_cnt
の値は、rps_sock_flow_entries
の値と同じです。
9.3.8. アクセラレート RFS の設定
- アクセラレート RFS がネットワークインターフェースカード対応になっていること。アクセラレート RFS は
ndo_rx_flow_steer()
netdevice
関数をエクスポートするカードでサポートされています。 ntuple
フィルタリングを有効にする必要があります。
付録A ツールについて
A.1. irqbalance
--oneshot
オプションで 1 回きりの実行も可能です。
- --powerthresh
- CPU が省電力モードになる前にアイドル状態になることが可能な CPU 数を設定します。しきい値を超える CPU 数が平均
softirq
ワークロードを 1 標準偏差以上下回り、平均値から 1 標準偏差を超える CPU がなく、複数のirq
がこれらに割り当てられている場合、CPU は省電力モードに入ります。このモードでは、CPU はirq
バランシングの一部ではないので、不必要に再開されることがありません。 - --hintpolicy
irq
カーネル親和性ヒントの処理方法を決定します。exact
(irq
親和性ヒントを常に適用)、subset
(irq
は均等に分散されるが割り当てオブジェクトは親和性ヒントのサブセット)、またはignore
(irq
親和性ヒントを完全に無視) の値を使用できます。- --policyscript
- 各割り込みリクエストを実行するスクリプトの場所を定義します。デバイスパスおよび
irq
番号が引数として渡され、irqbalance はゼロ終了コードを予想します。定義されたスクリプトでは、渡されたirq
の管理で irqbalance をガイドするために、ゼロもしくはそれ以上の鍵の値のペアを指定することができます。有効な鍵の値のペアとして認識されるのは、以下のものです。- ban
- 有効な値は、
true
(渡されたirq
をバランシングから除外) もしくはfalse
(このirq
でバランシングを実施) です。 - balance_level
- 渡された
irq
のバランスレベルをユーザーが上書きできるようにします。デフォルトでは、バランスレベルはirq
を所有するデバイスの PCI デバイスクラスに基づきます。有効な値はnone
、package
、cache
、またはcore
になります。 - numa_node
- 渡された
irq
にはローカルとみなされる NUMA ノードを、ユーザーが上書きできるようにします。ローカルノードについての情報が ACPI で指定されていない場合は、デバイスはすべてのノードから等距離とみなされます。有効な値は、特定の NUMA ノードを識別する整数 (0 から)、およびirq
が全ノードから等距離であるとみなすことを指定する-1
になります。
- --banirq
- 指定割り込み要求番号を持つ割り込みが禁止割り込み一覧に追加されます。
IRQBALANCE_BANNED_CPUS
環境変数を使って irqbalance に無視される CPU のマスクを指定することもできます。
$ man irqbalance
A.2. ethtool
$ man ethtool
A.3. ss
t
)、内部 TCP 情報 (i
)、ソケットのメモリー使用量 (m
)、ソケットを使用しているプロセス (p
)、ソケット情報の詳細 (i
) などを表示します。
$ man ss
A.4. tuned
/etc/tuned/tuned-main.conf
ファイルの dynamic_tuning
パラメーターを編集します。その後、Tuned がシステム統計を周期的に分析し、その統計を使用してシステムのチューニング設定を更新します。update_interval
パラメーターを使用すると更新の間隔を秒単位で設定できます。
$ man tuned
A.5. tuned-adm
include
パラメーターが用意されるため、既存のプロファイルで独自の Tuned プロファイルをベースにすることができます。
- throughput-performance
- 処理能力の改善に焦点をあてたサーバープロファイルになります。デフォルトのプロファイルでほとんどのシステムに推奨となります。このプロファイルは、
intel_pstate
とmin_perf_pct=100
を設定して節電によりパフォーマンスを重視します。透過的な HugePage を有効にし、cpupower を使ってperformance
cpufreq ガバナーを設定します。kernel.sched_min_granularity_ns
を10
μs に、kernel.sched_wakeup_granularity_ns
を15
μs に、vm.dirty_ratio
を40
% にそれぞれ設定します。 - latency-performance
- 待ち時間の短縮に焦点をあてたサーバープロファイルです。c-state チューニングや Transparent Huge Page の TLB 効率性の改善を目的とする待ち時間に制約のある作業負荷に推奨のプロファイルです。このプロファイルは、
intel_pstate
とmax_perf_pct=100
を設定して節電によりパフォーマンスを重視します。透過的な Huge Page ページを有効にし、cpupower を使ってperformance
cpufreq ガバナーを設定、cpu_dma_latency
値に1
を要求します。 - network-latency
- ネットワークの待ち時間短縮に焦点をあてたサーバープロファイルです。このプロファイルは、
intel_pstate
とmin_perf_pct=100
を設定して節電によりパフォーマンスを重視します。透過的な巨大ページと NUMA 自動負荷分散が無効になります。また、cpupower を使用してperformance
cpufreq ガバナーが設定され、1
のcpu_dma_latency
値が要求されます。また、busy_read
およびbusy_poll
の時間を50
μs に設定し、tcp_fastopen
を3
に設定します。 - network-throughput
- ネットワーク処理能力の改善に焦点をあてたサーバープロファイルです。
intel_pstate
とmax_perf_pct=100
を設定しカーネルのネットワークバッファサイズを大きくして節電よりパフォーマンスを重視します。Transparent Huge Page を有効にし、cpupower を使ってperformance
cpufreq ガバナーを設定します。また、kernel.sched_min_granularity_ns
を10
μs にkernel.sched_wakeup_granularity_ns
を 15 μs に、vm.dirty_ratio
を40
% にそれぞれ設定します。 - virtual-guest
- Red Hat Enterprise Linux 7 仮想マシンと VMware ゲストでのパフォーマンスの最適化に焦点をあてたプロファイルです。このプロファイルは、
intel_pstate
とmax_perf_pct=100
を設定して節電によりパフォーマンスを重視します。また仮想マシンの swap を低減します。Transparent Huge Page を有効にし、cpupower を使ってperformance
cpufreq ガバナーを設定します。また、kernel.sched_min_granularity_ns
を10
μs にkernel.sched_wakeup_granularity_ns
を 15 μs に、vm.dirty_ratio
を40
% にそれぞれ設定します。 - virtual-host
- Red Hat Enterprise Linux 7 仮想ホストでのパフォーマンスの最適化に焦点をあてたプロファイルです。このプロファイルは、
intel_pstate
とmax_perf_pct=100
を設定して節電によりパフォーマンスを重視します。また仮想マシンの swap を低減します。Transparent Huge Page を有効にしダーティーなページをより頻繁にディスクに書き戻します。cpupower を使ってperformance
cpufreq ガバナーを設定しますまた、kernel.sched_min_granularity_ns
を10
μs に、kernel.sched_wakeup_granularity_ns
を 15 μs に、kernel.sched_migration_cost
を5
μs に、vm.dirty_ratio
を40
% に、それぞれ設定します。 cpu-partitioning
cpu-partitioning
プロファイルは、システムの CPU を、分離されたハウスキーピングの CPU に分割します。分離された CPU のジッターと割り込みを減らすために、プロファイルは分離された CPU を、ユーザー空間プロセス、可動カーネルスレッド、割り込みハンドラー、およびカーネルタイマーから削除します。ハウスキーピング CPU は、すべてのサービス、シェルプロセス、およびカーネルスレッドを実行できます。/etc/tuned/cpu-partitioning-variables.conf
ファイルにcpu-partitioning
プロファイルを設定できます。設定オプションは以下のようになります。isolated_cores=cpu-list
- 分離する CPU を一覧表示します。分離された CPU の一覧はコンマで区切るか、ユーザーが範囲を指定できます。
3-5
のようにハイフンを使用して範囲を指定できます。このオプションは必須です。この一覧にない CPU は、自動的にハウスキーピング CPU と見なされます。 no_balance_cores=cpu-list
- システム全体のプロセスの負荷分散時に、カーネルに考慮されない CPU の一覧を表示します。このオプションは任意です。通常、これは
isolated_cores
と同じリストです。
cpu-partitioning
の詳細は、tuned-profiles-cpu-partitioning(7) の man ページを参照してください。
tuned-adm
で提供される節電プロファイルの詳細は『Red Hat Enterprise Linux 7 電力管理ガイド』を参照してください。
tuned-adm
の使用に関する詳細は man ページをご覧ください。
$ man tuned-adm
A.6. perf
- perf stat
- このコマンドは、実行された命令や消費したクロックサイクルなど、一般的なパフォーマンスイベントに関する全体的な統計を提供します。デフォルトの測定イベント以外のイベントに関する統計を収集する場合はオプションフラグを使用することができます。Red Hat Enterprise Linux 6.4 からは perf stat を使って 1 コントロールグループ (cgroups) または複数のコントロールグループに応じてモニタリングにフィルターをかけることができるようになります。詳細については man ページをご覧ください。
$ man perf-stat
- perf record
- このコマンドでパフォーマンスデータをファイルに記録し、後で perf report を使って分析を行うことができます。詳細については man ページをご覧ください。
$ man perf-record
- perf report
- ファイルからパフォーマンスデータを読み取り、記録されたデータの分析を行います。詳細については man ページをご覧ください。
$ man perf-report
- perf list
- このコマンドは、特定のマシンで利用可能なイベントを一覧表示します。これらのイベントは、システムのソフトウェア設定とパフォーマンス監視ハードウェアによって異なります。詳細については man ページをご覧ください。
$ man perf-list
- perf top
- top ツールとよく似た機能を実行します。リアルタイムでパフォーマンスカウンタープロファイルを生成および表示します。詳細については man ページをご覧ください。
$ man perf-top
- perf trace
- strace ツールとよく似た機能を実行します。指定されたスレッドまたはプロセスによって使用されるシステムコールとそのアプリケーションが受信するすべてのシグナルを監視します。追跡するターゲットを増やすこともできます。全一覧は man ページをご覧ください。
$ man perf-trace
A.7. Performance Co-Pilot (PCP)
表A.1 Red Hat Enterprise Linux 7 で Performance Co-Pilot により配布されるシステムサービス
表A.2 Red Hat Enterprise Linux 7 で Performance Co-Pilot により配布されるツール
表A.3 XFS の PCP メトリックグループ
メトリックグループ | 提供されたメトリック |
---|---|
xfs.* | 読み書き操作の数、読み書きバイト数を含む一般的な XFS メトリック。inode がフラッシュされた回数、クラッシュした回数、クラスター化に失敗した数に関するカウンターを併用。 |
xfs.allocs.*
xfs.alloc_btree.*
| ファイルシステムのオブジェクトの割り当てに関するメトリックの範囲。これには、エクステントおよびブロックの作成/解放の数が含まれます。割り当てツリーの検索と、拡張レコードの作成と btree からの削除との比較。 |
xfs.block_map.*
xfs.bmap_tree.*
| メトリックには、ブロックマップの読み取り/書き込みとブロックの削除の数、挿入、削除、および検索のためのエクステントリスト操作が含まれます。また、ブロックマップからの比較、検索、挿入、および削除に関する操作カウンター。 |
xfs.dir_ops.* | 作成、エントリー削除、getdent の操作の数に対する XFS ファイルシステムのディレクトリー操作のカウンター。 |
xfs.transactions.* | メタデータトランザクション数のカウンター。同期および非同期トランザクション数、および空のトランザクション数が含まれます。 |
xfs.inode_ops.* | オペレーティングシステムが、複数の結果で inode キャッシュの XFS inode を検索する回数のカウンター。このカウントキャッシュのヒット数、キャッシュミスなど。 |
xfs.log.*
xfs.log_tail.*
| XFS ファイルシステムを介したログバッファーの書き込み数のカウンターには、ディスクに書き込まれたブロックの数が含まれます。また、ログフラッシュおよびピニングの数のメトリックです。 |
xfs.xstrat.* | XFS フラッシュデーモンによってフラッシュされたファイルデータのバイト数と、ディスクの連続したスペースおよび連続していないスペースにフラッシュされたバッファー数のカウンター。 |
xfs.attr.* | すべての XFS ファイルシステム上での属性 get、set、remove、list 操作の数。 |
xfs.quota.* | XFS ファイルシステム上の quota 操作のメトリック。クオータの再要求数、クオータキャッシュのミス数、キャッシュのヒット数、およびクオータデータの再要求数のカウンターが含まれます。 |
xfs.buffer.* | XFS バッファーオブジェクトに関するメトリックの範囲。カウンターには、ページ検索時に要求されたバッファコールの数、成功したバッファロック、待機バッファロック、失敗したときのロック、失敗したときの再試行、バッファーヒットが含まれます。 |
xfs.btree.* | XFS btree の操作に関するメトリック。 |
xfs.control.reset | XFS 統計のメトリックカウンターをリセットするのに使用される設定メトリック。コントロールメトリックは、pmstore ツールを使用して切り替えられます。 |
表A.4 デバイスごとの XFS の PCP メトリックグループ
メトリックグループ | 提供されたメトリック |
---|---|
xfs.perdev.* | 読み書き操作の数、読み書きバイト数を含む一般的な XFS メトリック。inode がフラッシュされた回数、クラッシュした回数、クラスター化に失敗した数に関するカウンターを併用。 |
xfs.perdev.allocs.*
xfs.perdev.alloc_btree.*
| ファイルシステムのオブジェクトの割り当てに関するメトリックの範囲。これには、エクステントおよびブロックの作成/解放の数が含まれます。割り当てツリーの検索と、拡張レコードの作成と btree からの削除との比較。 |
xfs.perdev.block_map.*
xfs.perdev.bmap_tree.*
| メトリックには、ブロックマップの読み取り/書き込みとブロックの削除の数、挿入、削除、および検索のためのエクステントリスト操作が含まれます。また、ブロックマップからの比較、検索、挿入、および削除に関する操作カウンター。 |
xfs.perdev.dir_ops.* | 作成、エントリー削除、getdent の操作の数に対する XFS ファイルシステムのディレクトリー操作のカウンター。 |
xfs.perdev.transactions.* | メタデータトランザクションの数のカウンター。これには、空のトランザクションの数と、同期および非同期のトランザクションの数のカウントが含まれます。 |
xfs.perdev.inode_ops.* | オペレーティングシステムが、複数の結果で inode キャッシュの XFS inode を検索する回数のカウンター。このカウントキャッシュのヒット数、キャッシュミスなど。 |
xfs.perdev.log.*
xfs.perdev.log_tail.*
| XFS ファイルシステムを介したログバッファーの書き込み数のカウンターには、ディスクに書き込まれたブロックの数が含まれます。また、ログフラッシュおよびピニングの数のメトリックです。 |
xfs.perdev.xstrat.* | XFS フラッシュデーモンによりフラッシュされたファイルデータのバイト数と、ディスク上の連続および非連続の領域にフラッシュされたバッファーの数のカウンター。 |
xfs.perdev.attr.* | すべての XFS ファイルシステムでの属性の取得、設定、削除、および一覧表示の操作数のカウント。 |
xfs.perdev.quota.* | XFS ファイルシステムでのクォータ操作のメトリック。これには、クォータ回収、クォータキャッシュミス、キャッシュヒット、およびクォータデータの回収の数に関するカウンターが含まれます。 |
xfs.perdev.buffer.* | XFS バッファーオブジェクトに関するメトリックの範囲。カウンターには、ページ検索時に要求されたバッファコールの数、成功したバッファロック、待機バッファロック、失敗したときのロック、失敗したときの再試行、バッファーヒットが含まれます。 |
xfs.perdev.btree.* | XFS btree の操作に関するメトリック。 |
A.8. vmstat
- -a
- アクティブおよび非アクティブなメモリーを表示します。
- -f
- 起動時からのフォーク数を表示します。これには
fork
、vfork
、clone
のシステムコールが含まれ、作成されたタスク数の合計と同じになります。各プロセスはスレッドの使用により 1 タスクまたは複数のタスクで表されます。表示は繰り返されません。 - -m
- スラブ情報を表示します。
- -n
- ヘッダーが定期的に表示されるように指定します。
- -s
- 各種イベントのカウンターとメモリー統計の表を表示します。表示は繰り返されません。
- delay
- リポート間の遅延を秒単位で指定します。遅延を指定しない場合はマシンを最後に起動した時点からの平均値のレポートが一つのみ出力されます。
- count
- システムに関するレポートの回数を指定します。count を指定せず delay を指定すると vmstat は無期限で報告を行います。
- -d
- ディスクの統計を表示します。
- -p
- パーティション名を値として取得し、そのパーティションの詳細な統計を報告します。
- -S
- レポートで出力される単位を指定します。
k
(1000 バイト)、K
(1024 バイト)、m
(1,000,000 バイト)、M
(1,048,576 バイト) の値が使用できます。 - -D
- ディスクアクティビティーに関するサマリー統計を報告します。
$ man vmstat
A.9. x86_energy_perf_policy
# x86_energy_perf_policy -r
# x86_energy_perf_policy profile_name
- performance
- プロセッサーは省エネのためパフォーマンスを犠牲にはしません。これはデフォルト値です。
- normal
- 大幅な省エネとなる可能性がある場合はマイナーなパフォーマンス低下を許容します。ほとんどのサーバーおよびデスクトップで妥当な設定になります。
- powersave
- 最大限の省エネを目的とし大幅なパフォーマンス低下の可能性を受け入れます。
$ man x86_energy_perf_policy
A.10. turbostat
- pkg
- プロセッサーパッケージ番号。
- core
- プロセッサーのコア数。
- CPU
- Linux CPU(論理プロセッサー)番号。
- %c0
- CPU が終了した命令の間隔(パーセント)。
- GHz
- この数字が TSC の値よりも大きい場合、CPU は turbo モードになります。
- TSC
- 間隔全体の平均クロック速度。
- %c1、%c3 および %c6
- プロセッサーが c1、c3、または c6 の状態にある間隔のパーセンテージ。
- %pc3 または %pc6
- プロセッサーが pc3 または pc6 の各状態だったあいだの間隔の割合
-i
オプションでカウンター結果出力の間隔を指定します。結果を 10 秒ごとに出力させる場合は turbostat -i 10 を実行します。
A.11. numastat
- numa_hit
- このノードに正常に割り当てられていたページ数。
- numa_miss
- 対象のノードのメモリーが少ないために、このノードに割り当てたページ数。それぞれの
numa_miss
イベントには、別のノードで対応するnuma_foreign
イベントがあります。 - numa_foreign
- 代わりに別のノードに割り当てられたこのノードについて最初に意図されたページ数です。それぞれの
numa_foreign
イベントには、対応するnuma_miss
イベントが別のノードにあります。 - interleave_hit
- このノードに正常に割り当てられるインターリーブポリシーページの数。
- local_node
- このノードのプロセスで、このノードで正常に割り当てられるページ数。
- other_node
- 別のノード上でのプロセスによって当該ノードへの割り当てに成功したページ数
- -c
- 表示情報の表を横方向に縮小します。これは、NUMA ノード数が多いシステムでは有用ですが、コラムの幅とコラム間の間隔はあまり予測可能ではありません。このオプションが使用されると、メモリー量は一番近いメガバイトに切り上げ/下げられます。
- -m
- ノードあたりでのシステム全体のメモリー使用量を表示します。
/proc/meminfo
にある情報に類似したものです。 - -n
- オリジナルの numastat コマンド (
numa_hit
、numa_miss
、numa_foreign
、interleave_hit
、local_node
、およびother_node
)と同じ情報が表示されますが、測定単位にメガバイトを使用した更新フォーマットが使われます。 - -p pattern
- 指定されたパターンのノードごとのメモリー情報を表示します。pattern の値が数字の場合は、numastat は数値プロセス識別子と仮定します。それ以外の場合は、numastat は指定されたパターンをプロセスコマンドラインで検索します。
-p
オプションの値の後に入力されるコマンドライン引数は、フィルターにかける追加のパターンとみなされます。追加のパターンは、フィルターを絞り込むのではなく拡張します。 - -s
- 表示データを降順に並び替え、(total コラムの) メモリー消費量の多いものが最初に表示されます。オプションでは、node を指定すると、表はその node のコラムにしたがって並び替えられます。このオプション使用時には、以下のように node の値は
-s
オプションの直後に続けます。numastat -s2
このオプションと値の間に空白スペースを入れないでください。 - -v
- 詳細情報を表示します。つまり、複数プロセスのプロセス情報が各プロセスの詳細情報を表示します。
- -V
- numastat バージョン情報を表示します。
- -z
- 情報情報から値が 0 の行と列のみを省略します。表示目的で 0 に切り下げられている 0 に近い値は、表示出力から省略されません。
A.12. numactl
- --hardware
- ノード間の相対的な距離など、システムで利用可能なノードのインベントリーを表示します。
- --membind
- メモリーが特定のノードからのみ割り当てられるようにします。指定された場所に利用可能なメモリーが十分にない場合は、割り当ては失敗します。
- --cpunodebind
- 指定したコマンドとその子プロセスが、指定したノードでのみ実行されるようにします。
- --phycpubind
- 指定したコマンドとその子プロセスが、指定されたプロセッサーでのみ実行されるようにします。
- --localalloc
- メモリーは常にローカルノードから割り当てられるように指定します。
- --preferred
- メモリーを割り当てる元となるノードを指定します。この指定ノードからメモリーが割り当てられない場合は、別のノードがフォールバックとして使用されます。
$ man numactl
A.13. numad
A.13.1. コマンドラインからの numad の使用
# numad
/var/log/numad.log
にログ記録されます。アクティビティーは、以下のコマンドで停止されるまで継続されます。
# numad -i 0
# numad -S 0 -p pid
- -p pid
- 指定 pid を明示的な対象一覧に加えます。指定されたプロセスは numad プロセスの重要度しきい値に達するまで管理されません。
- -S 0
- プロセススキャンのタイプを
0
に設定し、numad 管理を明示的に対象プロセスに限定します。
$ man numad
A.13.2. numad のサービスとしての使用
/var/log/numad.log
にログ記録されます。
# systemctl start numad.service
# chkconfig numad on
$ man numad
A.13.3. プレプレースメントアドバイス
A.13.4. KSM をともなう numad の使用
/sys/kernel/mm/ksm/merge_nodes
パラメーターの値を 0
に変更して NUMA ノードにまたがるページのマージを回避します。これを実行しないと、KSM はノードにまたがってページをマージするので、リモートメモリーアクセスが増大します。また、カーネルメモリーが計算した統計情報は、ノード間での大量のマージ後にはそれぞれの間で相反する場合があります。そのため、KSM デーモンが大量のメモリーページをマージすると、numad
は利用可能なメモリーの正確な分量と場所について混乱する可能性があります。KSM は、システムにメモリーをオーバーコミットしている場合にのみ、有用なものです。システムに未使用のメモリーが大量にあると、KSM デーモンをオフにして無効にすることでパフォーマンスが高まる場合があります。
A.14. OProfile
- ophelp
- システムプロセッサーで使用可能なイベントとその簡単な説明を表示します。
- opimport
- サンプルデータベースファイルをシステム用に外部のバイナリー形式からネイティブの形式に変換します。異なるアーキテクチャーからのサンプルデータベースを解析する場合にのみこのオプションを使用してください。
- opannotate
- アプリケーションがデバッグシンボルでコンパイルされている場合は、実行可能ファイル用のアノテーション付きソースを作成します。
- opcontrol
- プロファイリング実行で収集されるデータを設定します。
- operf
- opcontrol の代わりとなる予定です。operf ツールは Linux Performance Events Subsystem を使用するので、単一プロセスとしてもシステムワイドとしてもより正確なプロファイリングのターゲットが可能になります。また、システム上でパフォーマンス監視ハードウェアを使用する他のツールと OProfile がよりうまく共存することが可能になります。opcontrol とは異なり、初期設定が不要で、
--system-wide
オプションを使用していなければ、root 権限なしで使用できます。 - opreport
- プロファイリングデータを取得します。
- oprofiled
- デーモンとして実行して定期的にサンプルデータをディスクに書き込みます。
$ man oprofile
A.15. taskset
# taskset -c processors pid
1,3,5-7
のようにプロセッサーの範囲で置き換えます。pid を再構成するプロセスのプロセス識別子で置き換えます。
# taskset -c processors -- application
$ man taskset
A.16. SystemTap
付録B 改訂履歴
改訂履歴 | |||
---|---|---|---|
改訂 10.13-59 | Mon May 21 2018 | Marek Suchánek | |
| |||
改訂 10.14-00 | Fri Apr 6 2018 | Marek Suchánek | |
| |||
改訂 10.13-58 | Fri Mar 23 2018 | Marek Suchánek | |
| |||
改訂 10.13-57 | Wed Feb 28 2018 | Marek Suchánek | |
| |||
改訂 10.13-50 | Thu Jul 27 2017 | Milan Navrátil | |
| |||
改訂 10.13-44 | Tue Dec 13 2016 | Milan Navrátil | |
| |||
改訂 10.08-38 | Wed Nov 11 2015 | Jana Heves | |
| |||
改訂 0.3-23 | Tue Feb 17 2015 | Laura Bailey | |
| |||
改訂 0.3-3 | Mon Apr 07 2014 | Laura Bailey | |
|