性能ボトルネックについて

UltraMonkey L7(v3.0.2) を RHEL6.0 で動かし,最大性能を計測すると,RHEL5.5 で動かした UltraMonkey L7(v2.3.0) よりも性能が上がらない

  • 原因
    • その 1: 1 CPU コアに処理が偏っていたため
    • その 2: 不要なカーネルモジュール(nf_conntrack)が CPU を消費していたため
    • その 3: RHEL6 のプロセススケジューラ(CFS)が UltraMonkey L7 v3 と相性の悪いスケジュールポリシーだったため
  • 対策
    • その 1: NIC の割り込みが CPU 0 に偏っていたため,効率的に処理するために RHEL6 のスケジューラがスレッドを CPU 0 に偏らせていた
      • NIC の割り込みを各 CPU コアに分散(multqueue)させて,スレッドを各 CPU コアに分散させた
        • スレッドは各 CPU コアに分散したものの,UltraMonkey の性能は向上せず
    • その 2: nf_conntrack モジュールをカーネルからアンロード
      • UltraMonkey の性能が 6% ほどアップ
    • その 3: CFS は sleep していたスレッドが起床すると,それまで動いていたスレッドをとめて sleep から起床したスレッドに動作を切り替える
      • 大量のスレッドが短い間隔で sleep と起床を繰り返す UltraMonkey v3 では,オーバーヘッド負荷が大きすぎる
        • スレッドが起床してもすぐには動作が切り替わらないようにスケジューラのパラメータを調整
          • UltraMoneky の性能がさらに 24% アップし,対策 2 とあわせて 30% ほどアップ.RHEL5.5 上の v2 の性能を越え,限界性能クライアント数が 67,000 に達する