Tốc độ mà máy chủ của tôi có thể chấp nhận () các kết nối TCP mới đến thực sự rất tệ trong Xen. Thử nghiệm tương tự trên phần cứng kim loại trần cho thấy tốc độ tăng gấp 3-5 lần.

1. Làm thế nào điều này là rất xấu theo Xen?
2. Bạn có thể điều chỉnh Xen để cải thiện hiệu suất cho các kết nối TCP mới không?
3. Có nền tảng ảo hóa nào khác phù hợp hơn cho loại trường hợp sử dụng này không?

Lý lịch

Gần đây tôi đã nghiên cứu một số điểm nghẽn về hiệu năng của một máy chủ Java được phát triển nội bộ chạy dưới Xen. Máy chủ nói HTTP và trả lời các cuộc gọi kết nối / yêu cầu / phản hồi / ngắt kết nối TCP đơn giản.

Nhưng ngay cả khi gửi lưu lượng thuyền đến máy chủ, nó không thể chấp nhận hơn ~ 7000 kết nối TCP mỗi giây (trên phiên bản EC2 8 lõi, c1.xlarge chạy Xen). Trong quá trình thử nghiệm, máy chủ cũng thể hiện một hành vi kỳ lạ trong đó một lõi (không nhất thiết là cpu 0) được tải rất nhiều> 80%, trong khi các lõi khác gần như không hoạt động. Điều này dẫn đến tôi nghĩ rằng vấn đề có liên quan đến kernel / ảo hóa cơ bản.

Khi thử nghiệm kịch bản tương tự trên nền tảng kim loại trần, không ảo hóa, tôi nhận được kết quả thử nghiệm cho thấy tốc độ chấp nhận TCP () vượt quá 35 000 / giây. Điều này trên máy Core i5 4 lõi chạy Ubuntu với tất cả các lõi gần như đã bão hòa hoàn toàn. Đối với tôi loại hình đó có vẻ đúng.

Trên phiên bản Xen một lần nữa, tôi đã thử bật / chỉnh gần như mọi cài đặt có trong sysctl.conf. Bao gồm cho phép nhận Chỉ đạo gói và Nhận chỉ đạo luồng và ghim các luồng / quy trình vào CPU nhưng không có mức tăng rõ ràng.

Tôi biết hiệu suất xuống cấp sẽ được dự kiến ​​khi chạy ảo hóa. Nhưng đến mức độ này? Một máy chủ chậm, kim loại trần vượt trội hơn đức. 8 lõi theo hệ số 5?

1. Đây có phải là hành vi thực sự mong đợi của Xen?
2. Bạn có thể điều chỉnh Xen để cải thiện hiệu suất cho các kết nối TCP mới không?
3. Có nền tảng ảo hóa nào khác phù hợp hơn cho loại trường hợp sử dụng này không?

Tái tạo hành vi này

Khi tiếp tục điều tra vấn đề này và xác định chính xác vấn đề, tôi phát hiện ra rằng công cụ kiểm tra hiệu năng netperf có thể mô phỏng kịch bản tương tự mà tôi đang gặp phải. Sử dụng thử nghiệm TCP_CRR của netperf, tôi đã thu thập các báo cáo khác nhau từ các máy chủ khác nhau (cả ảo hóa và không đạo đức.). Nếu bạn muốn đóng góp với một số phát hiện hoặc tra cứu các báo cáo hiện tại của tôi, vui lòng xem https://gist.github.com/985475

Làm thế nào để tôi biết vấn đề này không phải do phần mềm được viết kém?

1. Máy chủ đã được thử nghiệm trên phần cứng kim loại trần và nó gần như bão hòa tất cả các lõi có sẵn cho nó.
2. Khi sử dụng các kết nối TCP duy trì, vấn đề sẽ biến mất.

Tại sao nó lại quan trọng?

Tại ESN (chủ nhân của tôi), tôi là trưởng dự án của Beaconpush , một máy chủ Comet / Web Socket được viết bằng Java. Mặc dù nó rất hiệu quả và có thể bão hòa hầu hết mọi băng thông được cung cấp cho nó trong điều kiện tối ưu, nó vẫn bị giới hạn về tốc độ kết nối TCP mới có thể được thực hiện. Đó là, nếu bạn có một người dùng lớn, nơi người dùng đến và đi rất thường xuyên, nhiều kết nối TCP sẽ phải được thiết lập / phá bỏ. Chúng tôi cố gắng giảm thiểu việc giữ cho các kết nối này tồn tại càng lâu càng tốt. Nhưng cuối cùng, hiệu năng accept () là thứ giữ cho lõi của chúng ta không bị quay và chúng ta không thích điều đó.

Cập nhật 1

Ai đó đã đăng câu hỏi này lên Hacker News , cũng có một số câu hỏi / câu trả lời. Nhưng tôi sẽ cố gắng cập nhật câu hỏi này với thông tin tôi tìm thấy khi đi cùng.

Phần cứng / nền tảng tôi đã thử nghiệm điều này trên:

• EC2 với các thể hiện c1.xlarge (8 lõi, RAM 7 GB) và cc1.4xlarge (gấp 2 lần Intel Xeon X5570, RAM 23 GB). Các AMI được sử dụng lần lượt là ami-08f40561 và ami-1cad5275. Ai đó cũng chỉ ra rằng "Nhóm bảo mật" (tức là tường lửa EC2) cũng có thể ảnh hưởng. Nhưng đối với kịch bản thử nghiệm này, tôi chỉ thử trên localhost để loại bỏ các yếu tố bên ngoài như thế này. Một tin đồn khác mà tôi đã nghe là các phiên bản EC2 không thể đẩy hơn 100 nghìn PPS.
• Hai máy chủ ảo hóa chạy Xen. Một người có tải trọng bằng 0 trước khi thử nghiệm nhưng không tạo ra sự khác biệt.
• Riêng máy chủ, Xen-server tại Rackspace. Về kết quả tương tự đấy.

Tôi đang trong quá trình chạy lại các thử nghiệm này và điền vào các báo cáo tại https://gist.github.com/985475 Nếu bạn muốn giúp đỡ, hãy đóng góp số của bạn. Dễ thôi!

(Kế hoạch hành động đã được chuyển sang một câu trả lời tổng hợp, riêng biệt)

Ngay bây giờ: Hiệu suất gói nhỏ hút theo Xen

(chuyển từ câu hỏi sang câu trả lời riêng thay thế)

Theo một người dùng trên HN (một nhà phát triển KVM?) Điều này là do hiệu suất gói nhỏ trong Xen và cả KVM. Đó là một vấn đề được biết đến với ảo hóa và theo ông, ESX của VMWare xử lý việc này tốt hơn nhiều. Ông cũng lưu ý rằng KVM đang mang lại một số tính năng mới được thiết kế để giảm bớt điều này ( bài gốc ).

Thông tin này là một chút nản lòng nếu nó chính xác. Dù bằng cách nào, tôi sẽ thử các bước dưới đây cho đến khi một số bậc thầy Xen đi kèm với câu trả lời dứt khoát :)

Iain Kay từ danh sách gửi thư của người dùng xen kẽ đã biên soạn biểu đồ này: Lưu ý các thanh TCP_CRR, so sánh "2.6.18-239.9.1.el5" so với "2.6.39 (với Xen 4.1.0)".

Kế hoạch hành động hiện tại dựa trên câu trả lời / câu trả lời tại đây và từ HN :

1. Gửi vấn đề này đến danh sách gửi thư dành riêng cho Xen và bugzilla của xensource theo đề xuất của syirecton-dj Một tin nhắn đã được đăng lên danh sách người dùng xen kẽ , đang chờ trả lời.

2. Tạo một trường hợp kiểm tra bệnh lý cấp ứng dụng đơn giản và xuất bản nó.
   Một máy chủ thử nghiệm với các hướng dẫn đã được tạo và xuất bản lên GitHub . Với điều này, bạn sẽ có thể thấy trường hợp sử dụng trong thế giới thực hơn so với netperf.

3. Hãy thử phiên bản khách PV Xen 32 bit, vì 64 bit có thể gây ra nhiều chi phí hơn trong Xen. Có người nhắc đến chuyện này trên HN. Không làm nên sự khác biệt.

4. Hãy thử bật net.ipv4.tcp_syncookies trong sysctl.conf theo đề xuất của abofh trên HN. Điều này rõ ràng có thể cải thiện hiệu suất vì bắt tay sẽ xảy ra trong kernel. Tôi không có may mắn với điều này.

5. Tăng số lượng tồn đọng từ 1024 lên cao hơn nhiều, cũng được đề xuất bởi abofh trên HN. Điều này cũng có thể giúp vì khách có khả năng có thể chấp nhận () nhiều kết nối hơn trong khi lát thực thi được cung cấp bởi dom0 (máy chủ).

6. Kiểm tra kỹ xem conntrack có bị vô hiệu hóa trên tất cả các máy không vì nó có thể giảm một nửa tỷ lệ chấp nhận (được đề xuất bởi deubeulyou). Vâng, nó đã bị vô hiệu hóa trong tất cả các bài kiểm tra.

7. Kiểm tra "tràn hàng đợi nghe và xô đồng bộ tràn trong netstat -s" (được đề xuất bởi mike_esspe trên HN).

8. Phân chia xử lý ngắt giữa nhiều lõi (RPS / RFS tôi đã thử kích hoạt trước đó được cho là để làm điều này, nhưng có thể đáng để thử lại). Đề xuất bởi adamt tại HN.

9. Tắt giảm phân đoạn TCP và phân tán / thu thập gia tốc theo đề xuất của Matt Bailey. (Không thể có trên EC2 hoặc các máy chủ VPS tương tự)

Thông thường, tôi thấy rằng việc tắt tăng tốc phần cứng NIC giúp cải thiện đáng kể hiệu năng mạng trên bộ điều khiển Xen (cũng đúng với LXC):

Phân tán thu thập accell:

/usr/sbin/ethtool -K br0 sg off

Giảm tải phân đoạn TCP:

/usr/sbin/ethtool -K br0 tso off

Trong đó br0 là cầu nối hoặc thiết bị mạng của bạn trên máy chủ hypanneror. Bạn sẽ phải thiết lập tính năng này để tắt nó mỗi khi khởi động. YMMV.

Có lẽ bạn có thể làm rõ một chút - bạn đã chạy thử nghiệm dưới Xen trên máy chủ của riêng bạn hay chỉ trên một ví dụ EC2?

Chấp nhận chỉ là một tòa nhà khác và các kết nối mới chỉ khác ở chỗ một vài gói đầu tiên sẽ có một số cờ cụ thể - một trình ảo hóa như Xen chắc chắn sẽ không thấy bất kỳ sự khác biệt nào. Các phần khác trong thiết lập của bạn có thể: ví dụ trong EC2, tôi sẽ không ngạc nhiên nếu Nhóm bảo mật có liên quan đến nó; conntrack cũng được báo cáo để giảm một nửa tỷ lệ chấp nhận kết nối mới (PDF) .

Cuối cùng, dường như có các kết hợp CPU / Kernel gây ra việc sử dụng / treo CPU kỳ lạ trên EC2 (và có thể là Xen nói chung), như Librato đã viết gần đây .

Hãy chắc chắn rằng bạn đã tắt iptables và các hook khác trong mã cầu nối trong dom0. Rõ ràng nó chỉ áp dụng cho thiết lập Xen mạng cầu.

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

Nó phụ thuộc vào kích thước của máy chủ nhưng trên các máy nhỏ hơn (bộ xử lý 4 lõi) dành một lõi cpu cho Xen dom0 và ghim nó. Tùy chọn khởi động Hypervisor:

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

Bạn đã thử chuyển thiết bị PCI ethernet vật lý sang domU chưa? Nên có hiệu suất tốt đẹp tăng.