web-dev-qa-db-ja.com

VM）でのHaproxyスループットパフォーマンス

私はHAProxyを初めて使用しますが、期待するスループットが得られないにもかかわらず、機能させることができました。

私のセットアップには、5ノードのストレージクラスター（Riak CS、S3スタイルのストレージを実行）と別のVM roundrobinでHAProxyを実行）が含まれています。すべてのVMは、それぞれ専用のVirtualBoxを使用しています。 HAProxy VMはWindows7にあり、他はWindows 10です。これはすべて同じギガビットネットワーク上にあり、HAProxyについて1.4と1.5の両方をテストしました。

ディスクに保存せずにダウンロードするスクリプト（python + boto）があり、100 MBのファイルを何度もダウンロードします。それぞれが単純な取得要求に要約されるはずです。そのスクリプトをローカルで3回実行して、負荷を追加します。

それらすべてをHAProxyのIPにポイントすると、約4〜500 Mbpsのダウンロードが得られますが、HAProxyを使用せず、それぞれを個別のIPにポイントすると、最大900 + Mbpsを取得できます。

このテストを実行すると、HAProxyが単一のコアを使い果たしてボトルネックになっているように見えます。単一の接続であると私が信じている単一のスクリプトが実行されている場合、HAProxyのコアCPUの20〜40％を消費していますが、これは疑わしいと思われますか？

HAProxyは高スループットを処理できます のように聞こえるので、UbuntuまたはHAProxy構成ファイルのいずれかで正しく設定されていない可能性がある場所をデバッグしようとしています。構成でnbproc 3を使用すると、最小限の改善が見られます。3つのプロセス間で負荷が確実に分散されていないため、1つはまだ最大になっています。

VMなど、このセットアップについて何かが潜在的な危険信号として飛び出しますか？私のhaproxy設定は原因に聞こえますか？または私の一般的なUbuntu設定？また、質問する価値があります。これはHAProxyの良いユースケースですか、悪いユースケースですか。

[〜＃〜]編集[〜＃〜]

さらに掘り下げる必要がありますが、現在の感覚では、これはVM固有であり、イーサネットドライバ（e1000）にある可能性がありますか？HAProxyセットアップを物理マシンに移動できました（ VMではありません）、シングルコアでは、以前のテストケースでCPU使用率をほとんど登録しませんでした...

完全な構成

global
    #log 127.0.0.1   local0
    #log 127.0.0.1   local1 notice
    maxconn 256000
    spread-checks 5
    daemon 
    nbproc 4 
    cpu-map 1 2
    cpu-map 2 3
    cpu-map 3 4
    cpu-map 4 5

defaults
    option dontlog-normal
    option  redispatch
    option  allbackups
    no option   httpclose
    retries 3
    maxconn 256000
    contimeout  5000
    clitimeout  5000
    srvtimeout  5000

    option forwardfor except 127.0.0.1

frontend riak_cs
    bind          *:8098
    bind          *:8080
    mode          http
    capture       request header Host len 64

    acl d1 dst_port 8098
    acl d2 dst_port 8080

    use_backend   riak_cs_backend_stats if d1
    use_backend   riak_cs_backend if d2



backend riak_cs_backend
    mode http 
    balance roundrobin
    option httpchk GET /riak-cs/ping
    timeout connect 60s
    timeout http-request 60s

    stats enable
    stats uri /haproxy?stats

    server riak1 192.168.80.105:8080 weight 1 maxconn 1024 check inter 5s 
    server riak2 192.168.80.106:8080 weight 1 maxconn 1024 check inter 5s
    server riak3 192.168.80.107:8080 weight 1 maxconn 1024 check inter 5s
    server riak4 192.168.80.108:8080 weight 1 maxconn 1024 check inter 5s
    server riak5 192.168.80.109:8080 weight 1 maxconn 1024 check inter 5s

backend riak_cs_backend_stats 
    mode http
    balance roundrobin
    timeout connect 60s
    timeout http-request 60s

    stats enable 
    stats uri /haproxy?stats

    server riak1 192.168.80.105:8098 weight 1 maxconn 1024 
    server riak2 192.168.80.106:8098 weight 1 maxconn 1024
    server riak3 192.168.80.107:8098 weight 1 maxconn 1024
    server riak4 192.168.80.108:8098 weight 1 maxconn 1024 
    server riak5 192.168.80.109:8098 weight 1 maxconn 1024
networkingload-balancingvirtual-machineshaproxy
2
g3cko

私は自分の質問に答えるのは嫌いですが、私の結論は私のテストがVM制限されているということだと思います。正確にどのように言うことはできませんが、私のvmを介したHAProxyのCPU使用率ははるかに高く、上記のように、同じ構成の物理ハードウェアでテストし、nbproc部分を削除しても、HAProxyにほとんど目立たないCPU負荷が見られます。

VMを介して本番環境を実行することは私の目標ではありませんでしたが、VMはテスト（実際のハードウェアを待機している間）や、これらがどのように機能するかを学ぶのにはるかに便利です。

1
g3cko

設定も使用中のバージョンも表示しなかったので（私のコメントを参照）、これは「暗闇の中での撮影」に少し似ています。とにかく、各HAProxyプロセスを1つの特定のコアに固定し、それらをすべて最大化して、それらの間の負荷を均等にすることを試みることができます。

ドキュメントの引用：

cpu-map <"all"|"odd"|"even"|process_num> <cpu-set>...

Linux 2.6以降では、プロセスを特定のCPUセットにバインドすることができます。これは、プロセスが他のCPUで実行されることは決してないことを意味します。 cpu-mapディレクティブは、プロセスセットのCPUセットを指定します。最初の引数は、バインドするプロセス番号です。このプロセスは、マシンのワードサイズに応じて、1〜32または64の番号である必要があり、nbprocを超えるプロセスIDはすべて無視されます。 bind-processディレクティブと同様に、allを使用してすべてのプロセスを一度に指定したり、oddを使用して奇数のみを指定したり、evenを使用して偶数を指定したりできます。 2番目以降の引数はCPUセットです。各CPUセットは、0〜31または63の一意の番号、またはダッシュ（ '-'）で区切られた2つのそのような番号の範囲のいずれかです。複数のCPU番号または範囲を指定でき、プロセスはそれらすべてにバインドできます。明らかに、複数のcpu-mapディレクティブを指定できます。各cpu-mapディレクティブは、重複すると前のディレクティブを置き換えます。

したがって、3つのプロセスを使用している場合は、以下をテストします。

cpu-map 1 0
cpu-map 2 1
cpu-map 3 2
0
gf_