Amazon EC2 で数日間HAProxyと格闘してきました。これまでの経験は素晴らしいものでしたが、ソフトウェア ロード バランサーからより多くのパフォーマンスを引き出すことに行き詰まっています。私たちは正確には Linux ネットワーキングの達人ではありません (通常、私たちは .NET ショップです) が、適切な ulimit の設定を試み、カーネル メッセージと tcpdumps に不規則性がないかどうかを調べて、これまでのところ独自のものを保持してきました。ただし、これまでのところ、約 1,700 リクエスト/秒の横ばい状態に達しており、その時点でクライアントのタイムアウトが大量に発生しています ( httperfを使用して微調整してきました)。この目的のために）。同僚と私は最新の Stack Overflow ポッドキャストを聞いていました。Reddit の創設者は、サイト全体が 1 つの HAProxy ノードで実行されており、これまでのところボトルネックにはなっていないと述べています。あっ！どういうわけか、多くの同時リクエストが表示されないか、何かひどく間違っているか、または EC2 の共有の性質が Ec2 インスタンスのネットワーク スタックを制限している (私たちは大きなインスタンス タイプを使用しています)。Joel と Reddit の創設者の両方が、ネットワークが制限要因になる可能性が高いことに同意しているという事実を考慮すると、それが私たちが目にしている制限である可能性はありますか?
どんな考えでも大歓迎です！
編集実際の問題は、実際にはロードバランサーノードではなかったようです! この例では、実際には httperf を実行しているノードが原因でした。httperf はリクエストごとにソケットを構築および破棄するため、カーネルでかなりの量の CPU 時間を消費します。リクエスト レートを高くすると、TCP FIN TTL (デフォルトでは 60 秒) がソケットを長く保持しすぎ、ip_local_port_range のデフォルトがこの使用シナリオに対して低すぎました。基本的に、クライアント (httperf) ノードが絶えず新しいソケットを作成および破棄してから数分後、未使用のポートの数が不足し、この段階で後続の「リクエスト」がエラーになり、1 秒あたりのリクエスト数が少なくなり、大量のポートが生成されました。エラーの。
nginx も検討しましたが、RighScale と連携しており、HAProxy 用のドロップイン スクリプトがあります。ああ、それが絶対に必要であることが証明されない限り、[もちろん]コンポーネントを切り替えるには締め切りがきつすぎます。幸いなことに、AWS にいることで、nginx を並行して (保証されている場合) 使用して別のセットアップをテストし、後で夜通し切り替えることができます。
このページでは、各 sysctl 変数についてかなり詳しく説明しています (この場合、ip_local_port_range と tcp_fin_timeout は調整されています)。