TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

オペレーティング システムのパフォーマンスを調整する

このドキュメントでは、CentOS 7 の各サブシステムをチューニングする方法を紹介します。

ノート：

  • CentOS 7 オペレーティング システムのデフォルト構成は、中程度のワークロードで実行されるほとんどのサービスに適しています。特定のサブシステムのパフォーマンスを調整すると、他のサブシステムに悪影響を及ぼす可能性があります。したがって、システムをチューニングする前に、すべてのユーザー データと構成情報をバックアップしてください。
  • すべての変更を実本番環境に適用する前に、テスト環境で完全にテストしてください。

性能分析手法

システムのチューニングは、システムのパフォーマンス分析の結果に基づいて行う必要があります。このセクションでは、パフォーマンス分析の一般的な方法をリストします。

60秒以内に

60,000ミリ秒でのLinuxパフォーマンス分析は、著者のブレンダン・グレッグと Netflix パフォーマンス エンジニアリング チームによって公開されています。使用されるすべてのツールは、Linux の公式リリースから入手できます。次のリスト項目の出力を分析して、最も一般的なパフォーマンスの問題をトラブルシューティングできます。

  • uptime
  • dmesg | tail
  • vmstat 1
  • mpstat -P ALL 1
  • pidstat 1
  • iostat -xz 1
  • free -m
  • sar -n DEV 1
  • sar -n TCP,ETCP 1
  • top

詳細な使用方法については、対応するman説明を参照してください。

パフォーマンス

perf は、Linux カーネルによって提供される重要なパフォーマンス分析ツールであり、ハードウェア レベル (CPU/PMU、パフォーマンス監視ユニット) 機能とソフトウェア機能 (ソフトウェア カウンター、トレース ポイント) をカバーします。詳しい使用方法については、 パフォーマンスの例を参照してください。

BCC/bpftrace

CentOS 7.6 以降、Linux カーネルは Berkeley Packet Filter (BPF) をサポートしています。したがって、適切なツールを選択して、 60秒以内にの結果に基づいて詳細な分析を実行できます。 perf/ftrace と比較して、BPF はプログラム可能であり、パフォーマンスのオーバーヘッドが小さくなります。 kprobe と比較して、BPF はより高いセキュリティを提供し、本番環境により適しています。 BCC ツールキットの詳しい使用方法については、 BPF コンパイラ コレクション (BCC)を参照してください。

性能調整

このセクションでは、分類されたカーネル サブシステムに基づいたパフォーマンス チューニングを紹介します。

CPU—周波数スケーリング

cpufreq は、CPU 周波数を動的に調整するモジュールです。 5つのモードをサポートします。サービスのパフォーマンスを確保するには、パフォーマンス モードを選択し、動的調整を行わずに CPU 周波数をサポートされている最高の動作周波数に固定します。この操作のコマンドはcpupower frequency-set --governor performanceです。

CPU - 割り込みアフィニティ

  • irqbalanceサービスを通じて自動残高を実装できます。
  • 手動バランス:
    • 割り込みのバランスを取る必要があるデバイスを特定します。 CentOS 7.5 以降、システムは、 be2iscsiドライバーと NVMe 設定を使用するデバイスなど、特定のデバイスとそのドライバーに対して最適な割り込みアフィニティを自動的に構成します。このようなデバイスに対して割り込みアフィニティを手動で設定することはできなくなりました。
    • 他のデバイスについては、チップのマニュアルを参照して、これらのデバイスが割り込みの分散をサポートしているかどうかを確認してください。
      • そうでない場合、これらのデバイスのすべての割り込みは同じ CPU にルーティングされ、変更できなくなります。
      • 存在する場合は、 smp_affinityマスクを計算し、対応する構成ファイルを設定します。詳細はカーネルドキュメントを参照してください。

NUMA CPU バインディング

Non-Uniform Memory Access (NUMA) ノード間でのメモリへのアクセスをできるだけ避けるために、スレッドの CPU アフィニティを設定することで、スレッド/プロセスを特定の CPU コアにバインドできます。通常のプログラムでは、CPU バインディングにnumactlコマンドを使用できます。詳しい使用方法については、Linux のマニュアル ページを参照してください。ネットワーク インターフェイス カード (NIC) の割り込みについては、 ネットワークを調整するを参照してください。

メモリ - 透過的巨大ページ (THP)

データベースには連続的なメモリアクセス パターンではなく、疎なメモリ アクセス パターンが存在することが多いため、データベース アプリケーションに THP を使用することはお勧めできません。高レベルのメモリ断片化が深刻な場合、THP ページが割り当てられるときにレイテンシーが長くなります。 THP に対して直接圧縮が有効になっている場合、CPU 使用率が急増します。したがって、THP を無効にすることをお勧めします。

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

メモリ - 仮想メモリのパラメータ

  • 比率はdirty_ratioパーセント。ダーティ ページ キャッシュの合計量がシステムメモリ全体のこの割合に達すると、システムはpdflush操作を使用してダーティ ページ キャッシュをディスクに書き込み始めます。デフォルト値のdirty_ratio 20% で、通常は調整する必要はありません。 NVMe デバイスなどの高性能 SSD の場合、この値を下げるとメモリ再利用の効率が向上します。
  • 比率はdirty_background_ratioパーセント。ダーティ ページ キャッシュの合計量がシステムメモリ全体のこの割合に達すると、システムはバックグラウンドでディスクへのダーティ ページ キャッシュの書き込みを開始します。デフォルト値のdirty_background_ratio 10% で、通常は調整する必要はありません。 NVMe デバイスなどの高性能 SSD の場合、より低い値を設定すると、メモリ再利用の効率が向上します。

ストレージとファイルシステム

コア I/O スタック リンクは、ファイル システムレイヤー、ブロック デバイスレイヤー、ドライバーレイヤーを含めて長いです。

I/Oスケジューラ

I/O スケジューラは、storageデバイス上で I/O 操作をいつ、どのくらいの時間実行するかを決定します。 I/Oエレベーターとも呼ばれます。 SSD デバイスの場合、I/O スケジューリング ポリシーをnoopに設定することをお勧めします。

echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler

フォーマットパラメータ - ブロックサイズ

ブロックはファイル システムの作業単位です。ブロック サイズによって、1 つのブロックに格納できるデータ量が決まり、したがって、毎回書き込まれるか読み取られるデータの最小量が決まります。

デフォルトのブロック サイズは、ほとんどのシナリオに適しています。ただし、ブロック サイズ (または複数のブロックのサイズ) が、通常毎回読み書きされるデータ量と同じかわずかに大きい場合、ファイル システムのパフォーマンスが向上し、データstorage効率が高くなります。小さなファイルでもブロック全体が使用されます。ファイルは複数のブロックに分散できますが、実行時のオーバーヘッドが増加します。

mkfsコマンドを使用してデバイスをフォーマットする場合、ファイル システム オプションの一部としてブロック サイズを指定します。ブロック サイズを指定するパラメーターは、ファイル システムによって異なります。詳細については、 man mkfs.ext4使用など、対応するmkfsマニュアル ページを参照してください。

mountパラメータ

mountコマンドでnoatimeオプションが有効になっている場合、ファイルの読み取り時のメタデータの更新は無効になります。 nodiratime動作が有効な場合、ディレクトリの読み取り時のメタデータの更新は無効になります。

ネットワークチューニング

ネットワーク サブシステムは、機密性の高い接続を備えたさまざまな部分で構成されています。 CentOS 7 ネットワーク サブシステムは、ほとんどのワークロードに対して最高のパフォーマンスを提供するように設計されており、これらのワークロードのパフォーマンスを自動的に最適化します。したがって、通常はネットワーク パフォーマンスを手動で調整する必要はありません。

ネットワークの問題は通常、ハードウェアまたは関連デバイスの問題によって発生します。したがって、プロトコル スタックを調整する前に、ハードウェアの問題を除外してください。

ネットワーク スタックは主に自己最適化されますが、ネットワーク パケット処理の次の側面がボトルネックとなり、パフォーマンスに影響を与える可能性があります。

  • NIC ハードウェア キャッシュ: ハードウェア レベルでパケット損失を正確に観察するには、 ethtool -S ${NIC_DEV_NAME}コマンドを使用してdropsフィールドを観察します。パケットロスが発生した場合、ハード/ソフト割り込みの処理速度がNICの受信速度に追いつかない可能性があります。受信バッファ サイズが上限より小さい場合は、パケット損失を避けるために RX バッファを増やすこともできます。クエリ コマンドはethtool -g ${NIC_DEV_NAME} 、変更コマンドはethtool -G ${NIC_DEV_NAME}です。

  • ハードウェア割り込み: NIC が Receive-Side Scaling (RSS、マルチ NIC 受信とも呼ばれる) 機能をサポートしている場合は、 /proc/interrupts NIC 割り込みを観察します。割り込みが不均一な場合は、 CPU—周波数スケーリング 、 CPU - 割り込みアフィニティ 、およびNUMA CPU バインディングを参照してください。 NIC が RSS をサポートしていない場合、または RSS の数が物理 CPU コアの数よりもはるかに少ない場合は、受信パケット ステアリング (RPS、RSS のソフトウェア実装と見なすことができます) および RPS 拡張受信フロー ステアリング ( RFS）。詳細な設定については、 カーネルドキュメント参照してください。

  • ソフトウェア割り込み: /proc/net/softnet_statの監視を観察します。 3 番目の列を除く他の列の値が増加している場合は、CPU 時間を増やすためにsoftirqに対してnet.core.netdev_budgetまたはnet.core.dev_weightの値を適切に調整します。さらに、CPU 使用率をチェックして、どのタスクが CPU を頻繁に使用しているのか、またそれらのタスクを最適化できるかどうかを判断する必要もあります。

  • アプリケーションソケットの受信キュー: ss -nmpのResv-q列を監視します。キューがいっぱいの場合は、アプリケーション ソケット キャッシュのサイズを増やすか、自動キャッシュ調整方法を使用することを検討してください。さらに、アプリケーションレイヤーのアーキテクチャを最適化し、ソケットの読み取り間隔を短縮できるかどうかを検討してください。

  • イーサネット フロー制御: NIC とスイッチがフロー制御機能をサポートしている場合は、この機能を使用して、カーネルが NIC キュー内のデータを処理する時間を残し、NIC バッファ オーバーフローの問題を回避できます。

  • 割り込みの結合: ハードウェア割り込みが頻繁すぎるとシステムのパフォーマンスが低下し、ハードウェア割り込みが遅すぎるとパケット損失が発生します。新しい NIC は割り込み結合機能をサポートしており、ドライバーがハードウェア割り込みの数を自動的に調整できるようになります。 ethtool -c ${NIC_DEV_NAME}を実行して確認し、 ethtool -C ${NIC_DEV_NAME}を実行してこの機能を有効にすることができます。アダプティブ モードにより、NIC は割り込み結合を自動的に調整できます。このモードでは、ドライバーはトラフィック モードとカーネル受信モードをチェックし、パケット損失を防ぐためにリアルタイムで結合設定を評価します。 NIC のブランドが異なれば、機能やデフォルト構成も異なります。詳細については、NICのマニュアルを参照してください。

  • アダプタ キュー: プロトコル スタックを処理する前に、カーネルはこのキューを使用して NIC が受信したデータをバッファリングします。各 CPU には独自のバックログ キューがあります。このキューにキャッシュできるパケットの最大数はnetdev_max_backlogです。 /proc/net/softnet_statの 2 番目の列に注目してください。行の 2 番目の列が増加し続ける場合、CPU [行-1] キューがいっぱいでデータ パケットが失われたことを意味します。この問題を解決するには、引き続きnet.core.netdev_max_backlog値を 2 倍にします。

  • 送信キュー: 送信キューの長さの値によって、送信前にキューに入れることができるパケットの数が決まります。デフォルト値は1000で、10 Gbps には十分です。ただし、 ip -s linkの出力から TX エラーの値を確認した場合は、それを 2 倍にしてip link set dev ${NIC_DEV_NAME} txqueuelen 2000にすることができます。

  • Driver: 通常、NIC ドライバーはチューニング パラメーターを提供します。デバイスのハードウェア マニュアルとドライバーのドキュメントを参照してください。

このページは役に立ちましたか？