ループバックのレイテンシがコイインターフェイスよりも少ないのはなぜですか?


8

Stack Overflow Careersは次のように提供されます。

user -> internet -> our fw -> nginx -> haproxy -> web farm
  • FreeBSDは使用中のオペレーティングシステムです。
  • このボックスにはファイアウォールやQoSが設定されていません
  • nginxはSSL終了を処理します
  • haproxyは負荷分散を処理します
  • nginx / haproxyは片道約15 Mbpsを推進しています

通常の操作中、nginxはHTTPリクエストを受信して​​処理を行い、同じボックスのループバックアドレス(127.0.0.1)にバインドされているhaproxyインスタンスにリクエストを渡します。

先日いくつかのトラブルシューティングを行うために、nginxが実行されていたのと同じインターフェイスにhaproxyインスタンスを移動しました。これにより、すべてのリクエストに100ミリ秒のレイテンシが追加されました。このインターフェースは、真の物理インターフェースではなく、鯉のインターフェースです。

なぜこれが事実だったのか誰かに説明してくれる?パケットキューとの競合ですか?または、ループバックは「ソフト」であるため、常に高速ですか?ここで欠けている基本的なことがあり、誰かが親切に教えてくれることを願っています。


1
オンボックスアドレスに送信されたパケットは、loまたはe {th、n}ポートのどちらを経由しても、Linuxのハードウェアにヒットすることはありません。BSDに関しては、権威をもって話すことはできません。
BMDan 2010

同じインターフェースに切り替えましたか?haproxyをループバックに戻したときに100msは消えましたか?
tomjedrz 2010

@tomjedrz-はい。切り替えた途端、待ち時間はなくなりました。
Michael Gorsuch

回答:


2

100msの一定の遅延は奇妙に見えます。パケットはバッファリングされ、すぐには配信されないようです。または、それらの一部がドロップされて再送信される場合もあります。このインターフェイスでtcpdumpを実行して問題を表示できますか?FreeBSDでのIPスタックの動作やCARPの実装方法はわかりませんが、たとえば、スレーブがMACアドレスを無償のARPで定期的にアドバタイズし、マスターがパケットを両側に送信することは可能ですか?

実際のインターフェイスでtcpdumpを実行して、何も出力されないようにすることもできますか?

システムがCARPデバイスのARPエントリをキャッシュしないことで、CARPデーモンが応答する必要のあるセッションのパケットごとにARP要求が発行される可能性はありますか?

それらのほとんどはいくつかの愚かなアイデアですが、それはあなたが正しい方向に検索するのを助けるためです。


アイデアをありがとう、ウィリー。構成を時間外のインターフェイスに戻し、パケットトレースの結果を確認します。
Michael Gorsuch

1

わかりやすくするために、アクセス方法を127アドレスからローカルIPに変更しただけです。正しい?

それが事実であり、違いがあった場合、何かが正しくありません。でルーティングテーブルをチェックしてnetstat -rn、ローカルIPのルーティング先を確認します。これは、lo0インターフェイス(127と同様)にルーティングする必要があります。

あなたのnetstat -rn出力は漠然とこれに似ているはずです:

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            1.2.3.1            UGS       131  2655014   nge1
1.2.3.0/23         link#2             U           0       88   nge1
1.2.3.4            link#2             UHS         0    34848    lo0
127.0.0.1          link#5             UH          0    64678    lo0
192.168.0.0/26     link#1             U           2 41703537   nge0
192.168.0.1        link#1             UHS         0    70088    lo0

私はこれを投稿に含めるべきでした:これらのインターフェースは鯉のインターフェースです。netstatを実行するまでは、完全に頭がおかしくなりました。違いはありますか?
Michael Gorsuch

ええ、それだけです。使用しているアドレスがそのIPを使用する鯉のインターフェイスに割り当てられている場合、ループバックデバイスに到達する前に鯉のスタックを強制的に通過します。それでも100msは過剰です。問題のホストはそのIPのマスターですか、それとも負荷分散を使用していますか?トラフィックを他の鯉のホストに送信している可能性があります。
Chris S

ホストはそのIPのマスターです。
Michael Gorsuch

私は同様の環境を整え、それをテストし終えたところです。コイインターフェースIP、127 IP、および物理IPの応答時間に大きな違いはありませんでした。ここにはテストするサーバーが1つしかないため、コイのスレーブはありませんが、環境内の他の場所(ファイアウォールまたはトラフィックシェーピング?)で問題が発生してレイテンシが発生していると思われます。これはi386-8.1-STABLEです。
クリスS

ありがとう、クリス。トラフィックが減少したときに、さらに情報を収集できるかどうかを確認します。現在のシステムはファイアウォールパッケージを使用していないか、トラフィックシェーピングを行っていません。また、SOファミリーサイトに表示している求人広告が原因で大量のトラフィックが発生していることにも注意してください(元の質問が更新されます)。通常の時間帯は、片道約15 Mbpsです。
マイケル・ゴラスチ

0

ループバックが割り込みレベルのソフトウェアI / Fとして実装され、トラフィックがボックスの外に出ないようにしたことがあります。ループバックを実行しているときに、これが原因でしたか?免責事項:単なる一般的な質問です。FreeBSDについて何も知りません。

-ピート


これは、FreeBSDで機能する方法ではありません。
Chris S
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.