tcpdump tăng hiệu suất udp

Tôi đang chạy một bộ kiểm tra tải để xác định hiệu suất của thiết lập sau:

Node.js test suite (client) --> StatsD (server) --> Graphite (server)

Nói tóm lại, bộ kiểm tra node.js sẽ gửi một lượng số liệu đã đặt mỗi x giây cho một cá thể StatsD được đặt trên một máy chủ khác. StatsD sau đó lần lượt xóa các số liệu mỗi giây cho một cá thể Graphite nằm trên cùng một máy chủ. Sau đó, tôi xem xét có bao nhiêu số liệu thực sự được gửi bởi bộ thử nghiệm và bao nhiêu đã được Graphite nhận được để xác định mất gói giữa bộ thử nghiệm và Graphite.

Tuy nhiên tôi nhận thấy rằng đôi khi tôi có tốc độ giảm gói rất lớn (lưu ý rằng nó được gửi với giao thức UDP), dao động từ 20-50%. Vì vậy, đó là khi tôi bắt đầu xem xét nơi các gói tin này bị rơi, vì nó có thể là một số vấn đề về hiệu năng với StatsD. Vì vậy, tôi bắt đầu đăng nhập các số liệu trong mỗi phần của hệ thống để theo dõi nơi xảy ra sự sụt giảm này. Và đây là nơi mọi thứ trở nên kỳ lạ.

Tôi đang sử dụng tcpdump để tạo tệp chụp mà tôi kiểm tra sau khi chạy thử. Nhưng bất cứ khi nào tôi chạy thử nghiệm với tcpdump đang chạy, việc mất gói gần như không có! Có vẻ như tcpdump bằng cách nào đó làm tăng hiệu suất của các bài kiểm tra của tôi và tôi không thể hiểu tại sao và làm thế nào để thực hiện việc này. Tôi đang chạy lệnh sau để ghi nhật ký tin nhắn tcpdump trên cả máy chủ và máy khách:

tcpdump -i any -n port 8125 -w test.cap

Trong một trường hợp thử nghiệm cụ thể, tôi đang gửi 40000 số liệu / s. Kiểm tra trong khi chạy tcpdump có mất gói khoảng 4% trong khi kiểm tra không bị mất gói khoảng 20%

Cả hai hệ thống đang chạy dưới dạng Xen VM với thiết lập sau:

• Intel Xeon E5-2630 v2 @ 2.60GHz
• RAM 2GB
• Ubuntu 14.04 x86_64

Những điều tôi đã kiểm tra nguyên nhân tiềm ẩn:

• Tăng kích thước nhận / gửi bộ đệm UDP.
• Tải CPU ảnh hưởng đến bài kiểm tra. (tải tối đa 40-50%, cả phía máy khách và máy chủ)
• Chạy tcpdump trên các giao diện cụ thể thay vì 'bất kỳ'.
• Chạy tcpdump với '-p' để tắt chế độ lăng nhăng.
• Chỉ chạy tcpdump trên máy chủ. Điều này dẫn đến việc mất gói 20% xảy ra và dường như không ảnh hưởng đến các bài kiểm tra.
• Chỉ chạy tcpdump trên máy khách. Điều này dẫn đến hiệu suất tăng.
• Tăng netdev_max_backlog và netdev_bocate lên 2 ^ 32-1. Điều này làm cho không có sự khác biệt.
• Đã thử mọi cài đặt có thể của chế độ lăng nhăng trên mọi nic (tắt máy chủ và tắt máy khách, tắt máy chủ và bật máy khách, cả bật, tắt cả hai). Điều này làm cho không có sự khác biệt.

Khi tcpdump đang chạy, nó sẽ khá nhanh chóng trong việc đọc trong các khung đến. Giả thuyết của tôi là các cài đặt bộ đệm vòng gói của NIC có thể là một chút trên kích thước nhỏ; Khi tcpdump đang chạy, nó sẽ được dọn sạch một cách kịp thời hơn.

Nếu bạn là người đăng ký Red Hat, thì bài viết hỗ trợ này rất hữu ích Tổng quan về Tiếp nhận gói . Nó có một số thứ trong đó mà tôi không nghĩ rằng bạn đã xem xét.

Xem xét cách hệ thống của bạn đối phó với IRQs; xem xét việc tăng 'dev_ weight' của giao diện mạng (có nghĩa là nhiều gói được đọc từ NIC đến không gian người dùng); nhìn vào tần suất ứng dụng đọc ổ cắm (nó có thể sử dụng một luồng chuyên dụng không, có vấn đề / cách giải quyết nào liên quan đến khả năng mở rộng không).

Tăng bộ đệm khung NIC (sử dụng ethtoollệnh - nhìn vào các --set-ringđối số vv).

Nhìn vào 'nhận tỷ lệ bên' và sử dụng ít nhất nhiều luồng nhận được để đọc trong lưu lượng.

Tôi tự hỏi nếu tcpdump đang làm một cái gì đó tuyệt vời như sử dụng hỗ trợ kernel cho bộ đệm vòng gói . Điều đó sẽ giúp giải thích hành vi bạn đang thấy.

Thống đốc quyền lực nào bạn đang sử dụng? Tôi đã thấy những hành vi tương tự với thống đốc "ondemand" hoặc "bảo thủ".

Cố gắng sử dụng bộ điều chỉnh "hiệu suất" và vô hiệu hóa mọi tính năng tiết kiệm năng lượng trong BIOS máy chủ.

Nó có thay đổi gì không?

Một cách khác là ip_conntarckmô-đun, Bạn có chắc chắn hộp linux của bạn có thể chấp nhận kết nối mới không? kiểm tra qua:

root@debian:/home/mohsen# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536
root@debian:/home/mohsen# sysctl  net.ipv4.netfilter.ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 29

Bạn phải kiểm tra

net.ipv4.netfilter.ip_conntrack_max >  net.ipv4.netfilter.ip_conntrack_count

nếu max == đếm, kết nối tối đa của bạn đã đầy và hộp linux của bạn không thể chấp nhận kết nối mới.
Nếu bạn không có ip_conntrack, bạn có thể tải dễ dàng quamodprobe ip_conntrack

Tôi nghi ngờ bên nhận đơn giản là không có khả năng xử lý tốc độ gói và đây là lý do:

1. sử dụng tcpdump trên máy khách sẽ làm giảm các gói bị rơi: tcpdump đang làm chậm máy khách và do đó máy chủ đang thấy tốc độ đóng gói thấp hơn nhiều mà nó vẫn có thể xử lý một phần. Bạn sẽ có thể xác nhận giả thuyết này bằng cách kiểm tra bộ đếm gói RX / TX trên cả máy khách và máy chủ

2. bạn đã đề cập rằng bạn đã tăng kích thước nhận / gửi bộ đệm UDP, bạn có thể nói chi tiết bằng cách nào? Điều quan trọng là trên máy chủ, bạn thay đổi cả rmem_max và rmem_default, ví dụ: sysctl -w net.core.rmem_max=524287 sysctl -w net.core.wmem_max=524287 sysctl -w net.core.rmem_default=524287 sysctl -w net.core.wmem_default=524287

Kiểm tra cài đặt của bạn

Dừng statsd và ứng dụng nút, sau đó với hệ thống nhàn rỗi, sử dụng iperf để kiểm tra tốc độ gói mà mạng / kernel có thể xử lý. Nếu bạn có thể truyền phát 40K gói / s bằng iperf nhưng không thể với số liệu thống kê thì bạn nên tập trung nỗ lực vào việc điều chỉnh số liệu thống kê.

Điều chỉnh khác

Cũng nhớ điều chỉnh net.core.netdev_max_backlog : số lượng gói tối đa được phép xếp hàng khi một giao diện cụ thể nhận gói nhanh hơn nhân có thể xử lý chúng.