2

ネットワーク クライアントとサーバー アプリケーションがあります。データフローは、クライアントがサーバーにメッセージを送信し、サーバーが確認応答で応答するようなものです。確認応答を受信した場合にのみ、クライアントは次のメッセージを送信します。

C++ で記述されたクライアント アプリケーションには、ネットワーク スレッド (ソケット経由でメッセージを送信する役割)、メイン スレッド (要求メッセージを作成する役割)、およびタイマー スレッド (毎秒起動する) という 3 つのスレッドがあります。

サーバー アプリケーションには、メイン スレッドとネットワーク スレッドの 2 つのスレッドがあります。

RHEL 6.3、2.6.32-279 カーネルを実行しています。

構成 1

  1. tuned-adm プロファイルのレイテンシー-パフォーマンス
  2. 同じ CPU コア ID 上のすべてのクライアントのスレッド
  3. すべてのサーバーのスレッドは同じ CPU コア ID にありますが、クライアントのスレッドとはコア ID が異なります
  4. 同じマシンで実行されているクライアントとサーバー

スループット: 1 秒あたり 4500 メッセージ

構成 2

  1. tuned-adm プロファイルのスループット-パフォーマンス
  2. 同じ CPU コア ID 上のすべてのクライアントのスレッド
  3. すべてのサーバーのスレッドは同じ CPU コア ID にありますが、クライアントのスレッドとはコア ID が異なります
  4. 同じマシンで実行されているクライアントとサーバー

スループット: 1 秒あたり 9 ～ 15 メッセージ

構成 3

  1. tuned-adm プロファイルのスループット-パフォーマンス
  2. 異なる CPU コア ID 上のすべてのクライアントのスレッド
  3. 異なる CPU コア ID 上のすべてのサーバーのスレッド、およびクライアントのスレッドとは異なるコア ID
  4. 同じマシンで実行されているクライアントとサーバー

スループット: 1 秒あたり 1100 メッセージ

マシンの負荷はごくわずかです。プロファイルがレイテンシーパフォーマンスからスループットパフォーマンスに切り替えられたときに、1 秒あたり 4k から 9 メッセージに低下したことを誰か説明できますか?

4

1 に答える 1

1

RHEL のtuned-adm プロファイル間の相違点の基本的なスケジュールは次のとおりです。

遅延パフォーマンスは、I/O エレベーターをデッドラインにシフトし、CPU ガバナーを「パフォーマンス」設定に変更します。

スループットのパフォーマンスは、ネットワークとディスクのパフォーマンスに合わせて最適化されています。以下の詳細を参照してください...

ワークロードはレイテンシーの影響を受けやすいようです。

ここに画像の説明を入力

throughput-performanceコメント付きの設定は次のとおりです。latency-performanceこれらのいずれも変更しません。

# ktune sysctl settings for rhel6 servers, maximizing i/o throughput
#
# Minimal preemption granularity for CPU-bound tasks:
# (default: 1 msec#  (1 + ilog(ncpus)), units: nanoseconds)
kernel.sched_min_granularity_ns = 10000000

# SCHED_OTHER wake-up granularity.
# (default: 1 msec#  (1 + ilog(ncpus)), units: nanoseconds)
#
# This option delays the preemption effects of decoupled workloads
# and reduces their over-scheduling. Synchronous workloads will still
# have immediate wakeup/sleep latencies.
kernel.sched_wakeup_granularity_ns = 15000000

# If a workload mostly uses anonymous memory and it hits this limit, the entire
# working set is buffered for I/O, and any more write buffering would require
# swapping, so it's time to throttle writes until I/O can catch up.  Workloads
# that mostly use file mappings may be able to use even higher values.
#
vm.dirty_ratio = 40
于 2013-06-01T15:15:18.663 に答える