우리는 약 200 마일 떨어진 위치 사이에 다양하게 라우팅 된 새로운 1Gbps 이더넷 링크 쌍을 가지고 있습니다. ‘클라이언트’는 합리적으로 강력한 새로운 머신 (HP DL380 G6, 듀얼 E56xx 제온, 48GB DDR3, 300GB 10krpm SAS 디스크의 R1 쌍, W2K8R2-x64)이며 ‘서버’는 충분한 머신입니다 (HP BL460c G6 , 듀얼 E55xx 제온, 72GB, R1 쌍의 146GB 10krpm SAS 디스크, 듀얼 포트 Emulex 4Gbps FC HBA, 듀얼 Cisco MDS9509에 연결된 다음 128 x 450GB 15krpm FC 디스크가있는 전용 HP EVA 8400 (RHEL 5.3-x64).
클라이언트에서 SFTP를 사용하면 대용량 (> 2GB) 파일을 사용하는 처리량은 약 40Kbps입니다. 우리는 ‘기타 로컬 서버’테스트에 대한 서버를 수행했으며 로컬 스위치 (Cat 6509)를 통해 약 500Mbps를 보았습니다.
링크 공급자에게 문제가 자신의 것임을 증명하기 위해 어떤 다른 테스트 방법을 사용 하시겠습니까?
답변
코끼리 튜닝 :
pQd가 말한 것처럼 여기에는 문제가 아닌 튜닝이 필요할 수 있습니다. 이러한 종류의 링크는 “긴 파이프, 지방 파이프”또는 코끼리로 알려져 있습니다 ( RFC 1072 참조 ). 이것은 거리를 지나가는 기가비트 파이프이므로 (이 경우 거리는 실제로 시간 / 대기 시간) tcp 수신 창이 커야합니다 (그림은 TCP / IP 그림 볼륨 1, TCP 확장 섹션 참조).
수신 창을 확인하려면 대역폭 지연 제품을 계산하십시오.
Bandwidth * Delay = Product
대기 시간이 10MS 인 경우이 계산기 는 약 1.2MB의 수신 창을 원하는 것으로 추정합니다. 위의 공식으로 계산할 수 있습니다.
echo $(( (1000000.00/.01)/8 ))
12500000
따라서 큰 문제가 무엇인지 알아 낸 후에 tcp 창 크기 조정 (더 큰 창을 허용하는 TCP 확장)이 제대로 조정 되고 있는지 확인하기 위해 패킷 덤프를 실행할 수 있습니다.
창 경계 :
이것이 문제인 경우, 스케일링이없는 창 크기에 제한이있는 경우, 창 스케일링이없고 파이프 크기에 관계없이 대기 시간이 약 200ms 인 경우 다음 결과가 예상됩니다.
Throughput = Recieve Window/Round Trip Time
그래서:
echo $(( 65536/.2 ))
327680 #Bytes/second
당신이보고있는 결과를 얻으려면 대기 시간을 해결하기 만하면됩니다.
RTT = RWIN/Throughput
따라서 (40 kBytes / s의 경우) :
echo $(( 65536.0/40000.0 ))
1.63 #Seconds of Latency
(내 수학을 확인하십시오. 물론 프로토콜 / 헤더 오버 헤드가 모두 포함되어 있지는 않습니다)
답변
40kbps는 매우 낮습니다 ([미디어 변환기 / 이중 불일치 결함이 의심되는 시점까지] (그러나 기가비트이므로 반이중을위한 공간이 없습니다!) 등). 패킷 손실 또는 지터가 매우 높아야합니다.
iperf는 사용 가능한 처리량을 측정하기 위해 가장 먼저 떠오르는 도구입니다. 한쪽에서 뛰다
iperf -s
그리고 다른쪽에 :
iperf -t 60 -c 10.11.12.13
그런 다음 테스트를 시작하기 전에 두 시스템간에 클라이언트 / 서버 역할을 교환하고 이중화에 -d를 사용하여 mtr을 실행하고 mtr을 실행하고 사용하지 않은 링크에서 어떤 대기 시간 / 패킷 손실이 있는지, 그리고 데이터 전송 중에 어떻게 변경되는지 확인할 수 있습니다.
링크가 용량의 90 % 정도 포화 될 때까지 지터가 매우 작고 패킷 손실이 없습니다.
답변
tracepath는 두 사이트 간의 라우팅 문제를 보여줍니다.
iperf, ttcp 및 bwping은 유용한 정보를 제공 할 수 있습니다.
이 1GB 링크가 어떻게 프로비저닝되는지 알고 있습니까? 이 링크를 브리징하거나 라우팅하고 있습니까? 링크에 대한 SLA는 무엇입니까? 링크 제공 업체에 의해 형성 될 수 있습니까?
40kbs 만 얻는다면 심각한 문제가 발생합니다 .1GB / s 링크가 아닌 1MB 링크가 아닌지 확인하십시오. 당신은 아마 링크의 속도가 당신이 생각하는 것과는 다르다는 것을 알게 될 것입니다 🙂
답변
RFC 2544 또는 Y.156sam
이는 운송 업체가 SLA를 입증하기 위해 수행되는 네트워크 테스트입니다. IPERF 등은 검증 가능한 네트워크 테스트 방법이 아닙니다.