REHLサーバー上のアプリケーション転送とtcpdumpログの間の遅延は次のとおりです。いつもこれは大きなメッセージの場合は約200ミリ秒（下697572-488690 = 208882マイクロ秒を参照）で非常に大きいのに対し、小さなメッセージの場合は遅延は数マイクロ秒と非常に小さいです。
私の考えには一つもないようです。TCPタイマーこれは200msの遅延を説明できます。この遅延は通常、小さなメッセージをターゲットとするNagleのアルゴリズムによって引き起こされますが、待ち時間が大きい場合は大きなメッセージにのみ適用されるため、ここではそうではありません。
そして、次のような大きなメッセージを添付しました。
IBM MQトレースログ抜粋：
12:13:12.488685 4172.1 RSESS:000001 ----{ ccxSend
12:13:12.488688 4172.1 RSESS:000001 -----{ cciTcpSend
12:13:12.488690 4172.1 RSESS:000001 ------{ send
12:13:12.488697 4172.1 RSESS:000001 ------} send rc=OK
12:13:12.488711 4172.1 RSESS:000001 Sending 1138 bytes
[large message]
12:13:12.488714 4172.1 RSESS:000001 RetCode (OK)
12:13:12.488716 4172.1 RSESS:000001 -----} cciTcpSend rc=OK
tcpdump抽出：
12:13:05.884715 IP (tos 0x0, ttl 49, id 60415, offset 0, flags [DF], proto: TCP (6), length: 68) otherHost.otherPort > ourHost.ourPort: P, cksum 0x7673 (correct), 2893948259:2893948287(28) ack 1576932354 win 1024 ....
12:13:05.884718 IP (tos 0x0, ttl 64, id 60352, offset 0, flags [DF], proto: TCP (6), length: 40) ourHost.ourPort > otherHost.otherPort: ., cksum 0xcd9c (correct), ack 2893948287 win 5768
12:13:12.697572 IP (tos 0x0, ttl 64, id 60353, offset 0, flags [DF], proto: TCP (6), length: 1064) ourHost.ourPort > otherHost.otherPort: P, cksum 0x0059 (incorrect (-> 0x6a5a), 1576932354:1576933378(1024) ack 2893948287 win 5768
[first packet of large message]
12:13:12.708367 IP (tos 0x0, ttl 49, id 61060, offset 0, flags [DF], proto: TCP (6), length: 40) otherHost.otherPort > ourHost.ourPort: ., cksum 0xe024 (correct), ack 1576933378 win 0
12:13:12.708865 IP (tos 0x0, ttl 49, id 61061, offset 0, flags [DF], proto: TCP (6), length: 40) otherHost.otherPort > ourHost.ourPort: ., cksum 0xdc24 (correct), ack 1576933378 win 1024
12:13:12.708869 IP (tos 0x0, ttl 64, id 60354, offset 0, flags [DF], proto: TCP (6), length: 154) ourHost.ourPort > otherHost.otherPort: P, cksum 0xfcca (incorrect (-> 0xa1fb), 1576933378:1576933492(114) ack 2893948287 win 5768
[second packet of large message]
12:13:12.716154 IP (tos 0x0, ttl 49, id 61062, offset 0, flags [DF], proto: TCP (6), length: 40) otherHost.otherPort > ourHost.ourPort: ., cksum 0xdc24 (correct), ack 1576933492 win 910
12:13:12.717202 IP (tos 0x0, ttl 49, id 61063, offset 0, flags [DF], proto: TCP (6), length: 68) otherHost.otherPort > ourHost.ourPort: P, cksum 0x71e5 (correct), 2893948287:2893948315(28) ack 1576933492 win 1024
12:13:12.717209 IP (tos 0x0, ttl 64, id 60355, offset 0, flags [DF], proto: TCP (6), length: 40) ourHost.ourPort > otherHost.otherPort: ., cksum 0xc90e (correct), ack 2893948315 win 5768
小さなメッセージで（抜粋の文脈が少ない）：
15:15:33.133940 4215.1 RSESS:000001 ------{ send
15:15:33.133954 4215.1 RSESS:000001 ------} send rc=OK
...
15:15:33.133966 4215.1 RSESS:000001 Sending 512 bytes
[small message]
15:15:33.133969 4215.1 RSESS:000001 RetCode (OK)
TCPダンプ：
15:15:33.133949 IP (tos 0x0, ttl 64, id 37357, offset 0, flags [DF], proto: TCP (6), length: 552) ourHost.ourPort > otherHost.otherPort: P, cksum 0xfe58 (incorrect (-> 0x2dd8), 1566021015:1566021527(512) ack 2491002247 win 5768
[small message]
システムとドライバのバージョン：
Linux 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linuxサーバーバージョン5.3（Tikanga）
# /usr/sbin/ethtool -i bond0
driver: bonding
version: 3.2.4
firmware-version: 2
$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.2.4 (January 28, 2008)
Bonding Mode: fault-tolerance (active-backup)
Currently Active Slave: eth2
# /usr/sbin/ethtool -i eth2
driver: e1000e
version: 1.2.10-NAPI
firmware-version: 5.12-2
次のステップ？
この問題の根本原因が見つからず、次のように考えています。
- ただアップグレードしたいボンディングまたはe1000eドライバー。しかし、バインディングエラーがあるかどうかを確認するために、バインディングドライバのバージョンとリリースノートがどこにあるかを知っている人はいますか？
- メッセージごとに1つのパケットのみを送信する必要がある場合は問題が発生しませんので、相手に大きなTCPウィンドウを設定するように依頼してください。これはまた、大きなメッセージの最初のパケットと2番目のパケットの間の10ミリ秒の待機時間を短縮します。
誰にも異なるアイデアがありますか？ボンドまたはe1000eドライバのトレースログを取得する方法はありますか？
ベストアンサー1
sendまたは、各呼び出しで少なすぎるバイトを渡していますwrite。呼び出しごとに少なくとも2 KBまたは呼び出しごとに4 KBを渡す必要があります。可能であれば、論理メッセージ全体を集めてすぐに送信してください。これにより、システムコールが節約され、パケットがより効率的に圧縮され、遅延ACKによってレイテンシが破損するのを防ぎます。