☰

그리고 다음과 같은 큰 메시지를 첨부했습니다.

tag-icon • tag-icon rhel drivers tcp
그리고 다음과 같은 큰 메시지를 첨부했습니다.

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운전사. 그런데 바인딩 오류가 있는지 확인하기 위해 바인딩 드라이버 버전과 릴리스 노트가 어디에 있는지 아는 사람이 있습니까?
  • 메시지당 하나의 패킷만 전송해야 하는 경우에는 문제가 발생하지 않으므로 상대방에게 더 큰 TCP 창을 설정하도록 요청하세요. 또한 이는 큰 메시지의 첫 번째 패킷과 두 번째 패킷 사이의 시간인 10밀리초만큼 대기 시간을 줄여줍니다.

누구든지 다른 아이디어가 있나요? 본드나 e1000e 드라이버의 추적 로그를 얻을 수 있는 방법이 있나요?

답변1

send또는 에 대한 각 호출에서 너무 적은 바이트를 전달하고 있습니다 write. 호출당 최소 2KB 또는 호출당 4KB를 전달해야 합니다. 가능하다면 전체 논리 메시지를 모아서 즉시 보내십시오. 이렇게 하면 시스템 호출이 절약되고, 패킷이 더 효율적으로 압축되며, 지연된 ACK로 인해 대기 시간이 손상되는 것을 방지할 수 있습니다.

답변2

~에 따르면Linux 튜닝: 전문가 가이드ESnet 네트워크 성능 기술 자료에서:

참고: Redhat Enterprise Linux 5.3 - 5.5 및 해당 변형(Centos, Scientific Linux 등)에서 사용되는 2.6.18 커널의 여러 버전에서는 bic과 Cuban 모두 버그가 있는 것으로 보입니다. 2.6.18.x 커널에서는 htcp를 사용하는 것이 안전합니다.

bic 또는 큐빅 버그에 대한 세부정보를 찾을 수 없습니다.Red Hat 오류 데이터베이스또는 다른 곳에서는 이것이 실제 답변이라는 증거가 없습니다.

관련 정보