내 서버가 새로운 들어오는 TCP 연결을 수락 할 수있는 속도는 Xen에서 실제로 나쁩니다. 베어 메탈 하드웨어에 대한 동일한 테스트는 3-5 배의 속도 향상을 보여줍니다.

1. Xen에서 어떻게 그렇게 나쁘게됩니까?
2. 새로운 TCP 연결 성능을 향상시키기 위해 Xen을 조정할 수 있습니까?
3. 이런 종류의 사용 사례에 더 적합한 다른 가상화 플랫폼이 있습니까?

배경

최근에 Xen에서 실행되는 사내 개발 Java 서버의 성능 병목 현상을 연구하고 있습니다. 서버는 HTTP를 말하고 간단한 TCP 연결 / 요청 / 응답 / 연결 끊기 호출에 응답합니다.

그러나 서버에 트래픽로드를 전송하는 동안에도 초당 최대 7,000 개 이상의 TCP 연결 (8 코어 EC2 인스턴스, Xen을 실행하는 c1.xlarge)을 수락 할 수 없습니다. 테스트 중에 서버는 하나의 코어 (필수 CPU 0은 아님)가 80 %를 초과하여로드되는 반면 다른 코어는 거의 유휴 상태로 유지되는 이상한 동작을 나타냅니다. 이것은 문제가 커널 / 기본 가상화와 관련이 있다고 생각하게합니다.

베어 메탈 비 가상화 플랫폼에서 동일한 시나리오를 테스트 할 때 35,000 / 초를 초과하는 TCP accept () 속도를 보여주는 테스트 결과를 얻습니다. 이것은 모든 코어가 거의 포화 상태 인 Ubuntu를 실행하는 Core i5 4 코어 시스템에서 발생합니다. 나에게 그런 종류의 그림은 옳은 것 같습니다.

Xen 인스턴스에서 다시 sysctl.conf에있는 거의 모든 설정을 활성화 / 조정하려고했습니다. 수신 패킷 조정 활성화 및 수신 흐름 조정 및 스레드 / 프로세스를 CPU에 고정하지만 명백한 이득은 없습니다.

가상화를 실행할 때 성능 저하가 예상된다는 것을 알고 있습니다. 그러나이 정도로? 속도가 느리고 베어 메탈 서버보다 성능이 우수합니다. 5 배 8 코어?

1. 이것이 Xen의 예상되는 동작입니까?
2. 새로운 TCP 연결 성능을 향상시키기 위해 Xen을 조정할 수 있습니까?
3. 이런 종류의 사용 사례에 더 적합한 다른 가상화 플랫폼이 있습니까?

이 동작을 재현

이것을 더 조사하고 문제를 지적했을 때 netperf 성능 테스트 도구가 내가 겪고있는 유사한 시나리오를 시뮬레이션 할 수 있음을 알았습니다. netperf의 TCP_CRR 테스트를 사용하여 다른 서버 (가상 및 비가 상 서버)에서 다양한 보고서를 수집했습니다. 일부 조사 결과에 기여하거나 현재 보고서를 찾으려면 https://gist.github.com/985475 를 참조 하십시오.

이 문제가 잘못 작성된 소프트웨어로 인한 것이 아니라는 것을 어떻게 알 수 있습니까?

1. 이 서버는 베어 메탈 하드웨어에서 테스트되었으며 사용 가능한 모든 코어를 거의 포화시킵니다.
2. 연결 유지 TCP 연결을 사용하면 문제가 해결됩니다.

이것이 왜 중요한가?

에서 ESN (고용주) 난의 프로젝트 리더입니다 Beaconpush , 자바로 작성된 혜성 / 웹 소켓 서버입니다. 성능이 뛰어나고 최적의 조건에서 대역폭을 거의 포화시킬 수는 있지만 여전히 새로운 TCP 연결 속도에 제한이 있습니다. 즉, 사용자가 매우 자주 출입하는 큰 사용자 이탈이 발생하면 많은 TCP 연결을 설정 / 해제해야합니다. 우리는 가능한 한 오랫동안 연결을 유지하기 위해 노력합니다. 그러나 결국 accept () 성능은 코어가 회전하는 것을 막아 주므로 우리는 그것을 좋아하지 않습니다.

업데이트 1

누군가이 질문을 Hacker News에 게시했지만 거기에 몇 가지 질문 / 답변도 있습니다. 그러나 나는 내가 따라갈 때 찾은 정보 로이 질문을 최신 상태로 유지하려고 노력할 것입니다.

내가 테스트 한 하드웨어 / 플랫폼 :

• 인스턴스 유형이 c1.xlarge (8 코어, 7GB RAM) 및 cc1.4xlarge (2x Intel Xeon X5570, 23GB RAM)가있는 EC2. 사용 된 AMI는 각각 ami-08f40561 및 ami-1cad5275입니다. 누군가는 "보안 그룹"(즉, EC2 방화벽)도 영향을 미칠 수 있다고 지적했습니다. 그러나이 테스트 시나리오에서는 이와 같은 외부 요인을 제거하기 위해 localhost에서만 시도했습니다. 내가 들었던 또 다른 소문은 EC2 인스턴스가 100k PPS 이상을 푸시 할 수 없다는 것입니다.
• Xen을 실행하는 두 개의 개인 가상화 서버. 하나는 테스트 전에 무부하 였지만 차이는 없었습니다.
• Rackspace의 전용 Xen 서버. 같은 결과에 대해.

이 테스트를 다시 실행하고 https://gist.github.com/985475 에서 보고서를 작성하는 과정에 있습니다. 도움을 받으려면 숫자를 기부하십시오. 그것은 간단합니다!

(행동 계획은 별도의 통합 된 답변으로 이동되었습니다)

지금 : Xen에서 작은 패킷 성능 저하

(질문 자체에서 별도의 답변으로 이동)

HN (KVM 개발자?) 사용자에 따르면 이는 Xen 및 KVM의 작은 패킷 성능 때문입니다. 가상화에있어 알려진 문제이며 VMWare의 ESX는이를 훨씬 잘 처리합니다. 또한 KVM은이를 완화하기 위해 설계된 몇 가지 새로운 기능을 제공한다고 언급했습니다 ( 원래 게시물 ).

이 정보는 정확하다면 약간 실망합니다. 어느 쪽이든, 나는 Xen 전문가가 확실한 대답을 얻을 때까지 아래 단계를 시도 할 것입니다 :)

xen-users 메일 링리스트의 Iain Kay가이 그래프를 컴파일했습니다. TCP_CRR 막대를 확인하고 "2.6.18-239.9.1.el5"와 "2.6.39 (Xen 4.1.0)"을 비교하십시오.

여기 답변 / 답변과에서를 기반으로 현재 행동 계획 HN :

1. syneticon-DJ에 의해 제안 젠 고유의 메일 링리스트와 젠소스의 버그질라에이 문제를 제출 메시지가 젠 사용자 목록에 게시 된 회신을 기다리고.

2. 간단한 병리학적인 응용 프로그램 수준 테스트 사례를 만들어 게시합니다.
   지침이있는 테스트 서버가 생성 되어 GitHub에 게시되었습니다 . 이를 통해 netperf와 비교하여보다 실제적인 사용 사례를 볼 수 있어야합니다.

3. 64 비트로 인해 Xen에서 오버 헤드가 더 많이 발생할 수 있으므로 32 비트 PV Xen 게스트 인스턴스를 사용해보십시오. 누군가가 HN에서 이것을 언급했습니다. 차이를 만들지 않았습니다.

4. HN에서 abofh가 제안한대로 sysctl.conf에서 net.ipv4.tcp_syncookies를 활성화하십시오. 이 분명히 있습니다 핸드 쉐이크가 커널에서 발생하는 것이기 때문에 성능을 향상시킬 수 있습니다. 나는 이것으로 운이 없었다.

5. HN에서 abofh가 제안한 백 로그를 1024에서 훨씬 더 높은 값으로 늘리십시오. 게스트가 dom0 (호스트)이 제공하는 실행 슬라이스 중에 더 많은 연결을 수락 할 수 있기 때문에 도움이 될 수 있습니다.

6. 수락 률을 절반으로 줄일 수 있으므로 모든 시스템에서 conntrack이 비활성화되어 있는지 다시 확인하십시오 (deubeulyou가 제안 함). 예, 모든 테스트에서 비활성화되었습니다.

7. "netstat -s에서 대기열 오버 플로우 및 동기화 버킷 오버 플로우 청취"(HN의 mike_esspe에서 제안)를 확인하십시오.

8. 여러 코어로 인터럽트 처리를 분할하십시오 (이전에 활성화하려고 시도한 RPS / RFS는이 작업을 수행해야하지만 다시 시도해 볼 가치가 있습니다). HN의 adamt가 제안합니다.

9. Matt Bailey가 제안한대로 TCP 세그먼트 화 오프로드 및 분산 / 수집 가속 기능을 해제합니다. (EC2 또는 유사한 VPS 호스트에서는 불가능)

일화 적으로 NIC 하드웨어 가속을 끄면 Xen 컨트롤러의 네트워크 성능이 크게 향상됩니다 (LXC의 경우도 마찬가지).

스 캐터 수집 가속 :

/usr/sbin/ethtool -K br0 sg off

TCP 세분화 오프로드 :

/usr/sbin/ethtool -K br0 tso off

여기서 br0은 하이퍼 바이저 호스트의 브리지 또는 네트워크 장치입니다. 매번 부팅 할 때마다 끄도록 설정해야합니다. YMMV.

Xen에서 자체 서버 또는 EC2 인스턴스에서만 테스트를 수행 했습니까?

Accept는 또 다른 syscall이며 처음 몇 개의 패킷에는 특정 플래그가 있다는 점에서 새로운 연결 만 다릅니다. Xen과 같은 하이퍼 바이저는 분명히 차이가 없어야합니다. 설정의 다른 부분은 다음과 같습니다. 예를 들어 EC2의 경우 보안 그룹과 관련이 있다고해도 놀라지 않을 것입니다. conntrack은 또한 새로운 연결 수락 률을 절반으로 줄인 것으로보고되었습니다 (PDF) .

마지막으로 최근 Librato가 블로그에 게시 한 것처럼 EC2 (및 아마도 일반적으로 Xen)에서 이상한 CPU 사용 / 중단을 일으키는 CPU / 커널 조합이있는 것 같습니다 .

dom0의 브리징 코드에서 iptables 및 기타 후크를 비활성화했는지 확인하십시오. 브리지 네트워킹 Xen 설정에만 적용됩니다.

echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge.bridge-nf-call-arptables

서버 크기에 따라 다르지만 작은 코어 (4 코어 프로세서)에 따라 하나의 CPU 코어를 Xen dom0에 전용으로 고정합니다. 하이퍼 바이저 부팅 옵션 :

dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=<at least 512M>

실제 이더넷 PCI 장치를 domU로 전달하려고 했습니까? 좋은 성능 향상이 있어야합니다.