Tại sao máy chủ web của tôi giảm kết nối với thiết lập lại TCP ở mức tải cao?

Tôi có một thiết lập VPS nhỏ với nginx. Tôi muốn đạt được hiệu suất cao nhất có thể từ nó, vì vậy tôi đã thử nghiệm tối ưu hóa và thử nghiệm tải.

Tôi đang sử dụng Blitz.io để thực hiện kiểm tra tải bằng cách NHẬN một tệp văn bản tĩnh nhỏ và gặp phải một vấn đề kỳ lạ khi máy chủ dường như đang gửi lại TCP khi số lượng kết nối đồng thời đạt khoảng 2000. Tôi biết rằng đây là một vấn đề rất số lượng lớn, nhưng từ việc sử dụng htop, máy chủ vẫn còn nhiều thời gian và bộ nhớ CPU, vì vậy tôi muốn tìm ra nguồn gốc của vấn đề này để xem liệu tôi có thể đẩy nó hơn nữa không.

Tôi đang chạy Ubuntu 14.04 LTS (64-bit) trên VPS Linode 2GB.

Tôi không có đủ danh tiếng để đăng trực tiếp biểu đồ này, vì vậy đây là một liên kết đến biểu đồ Blitz.io:

Dưới đây là những điều tôi đã làm để thử và tìm ra nguồn gốc của vấn đề:

• Giá trị cấu hình nginx worker_rlimit_nofileđược đặt thành 8192
• đã nofileđặt thành 64000 cho cả giới hạn cứng và mềm cho rootvà www-datangười dùng (nginx chạy như thế nào) trong/etc/security/limits.conf

• không có dấu hiệu nào cho thấy có lỗi xảy ra /var/log/nginx.d/error.log(thông thường, nếu bạn đang chạy vào giới hạn mô tả tệp, nginx sẽ in các thông báo lỗi nói như vậy)

• Tôi đã thiết lập ufw, nhưng không có quy tắc giới hạn tỷ lệ. Nhật ký ufw cho thấy không có gì bị chặn và tôi đã thử vô hiệu hóa ufw với kết quả tương tự.

• Không có lỗi chỉ định trong /var/log/kern.log
• Không có lỗi chỉ định trong /var/log/syslog

• Tôi đã thêm các giá trị sau vào /etc/sysctl.confvà tải chúng sysctl -pmà không có hiệu lực:

  net.ipv4.tcp_max_syn_backlog = 1024
  net.core.somaxconn = 1024
  net.core.netdev_max_backlog = 2000
  

Có ý kiến ​​gì không?

EDIT: Tôi đã thực hiện một thử nghiệm mới, kết nối tới 3000 kết nối trên một tệp rất nhỏ (chỉ có 3 byte). Đây là biểu đồ Blitz.io:

Một lần nữa, theo Blitz, tất cả các lỗi này là lỗi "Thiết lập lại kết nối TCP".

Đây là biểu đồ băng thông Linode. Hãy nhớ rằng đây là mức trung bình 5 phút để nó vượt qua được lọc một chút (băng thông tức thời có thể cao hơn nhiều), nhưng vẫn không có gì:

CPU:

Tôi / O:

Đây là htopgần cuối của bài kiểm tra:

Tôi cũng đã bắt được một số lưu lượng truy cập bằng cách sử dụng tcpdump trong một thử nghiệm khác (nhưng trông tương tự), bắt đầu chụp khi các lỗi bắt đầu xuất hiện: sudo tcpdump -nSi eth0 -w /tmp/loadtest.pcap -s0 port 80

Đây là tệp nếu bất cứ ai muốn xem nó (~ 20MB): https://drive.google.com/file/d/0B1NXWZBKQN6ETmg2SEFOZUsxV28/view?usp=shared

Đây là biểu đồ băng thông từ Wireshark:

(Dòng là tất cả các gói, thanh màu xanh là lỗi TCP)

Từ cách giải thích của tôi về việc chụp (và tôi không phải là chuyên gia), có vẻ như các cờ TCP RST đang đến từ nguồn kiểm tra tải chứ không phải máy chủ. Vì vậy, giả sử rằng có điều gì đó không ổn ở phía dịch vụ kiểm tra tải, có an toàn không khi cho rằng đây là kết quả của một số loại quản lý mạng hoặc giảm thiểu DDOS giữa dịch vụ kiểm tra tải và máy chủ của tôi?

Cảm ơn!

Có thể có bất kỳ số lượng nguồn của các thiết lập lại kết nối. Trình kiểm tra tải có thể ra khỏi các cổng phù du có sẵn để bắt đầu kết nối, một thiết bị trên đường đi (như tường lửa làm NAT) có thể bị cạn kiệt NAT pool và không thể cung cấp cổng nguồn cho kết nối, có ở đó không một bộ cân bằng tải hoặc tường lửa ở cuối của bạn có thể đã đạt đến giới hạn kết nối? Và nếu thực hiện NAT nguồn trên lưu lượng truy cập vào, điều đó cũng có thể bị cạn kiệt cổng.

Một người sẽ thực sự cần một tập tin pcap từ cả hai đầu. Những gì bạn muốn tìm là nếu một nỗ lực kết nối được gửi nhưng không bao giờ đến máy chủ nhưng vẫn xuất hiện như thể nó được thiết lập lại bởi máy chủ. Nếu đó là trường hợp thì một cái gì đó dọc theo dòng đã phải thiết lập lại kết nối. Kiệt sức hồ bơi NAT là một nguồn phổ biến của các loại vấn đề.

Ngoài ra, netstat -st có thể cung cấp cho bạn một số thông tin bổ sung.

Một số ý tưởng để thử, dựa trên kinh nghiệm điều chỉnh tương tự gần đây của riêng tôi. Với tài liệu tham khảo:

Bạn nói đó là một tệp văn bản tĩnh. Chỉ trong trường hợp có bất kỳ quá trình xử lý ngược dòng nào đang diễn ra, rõ ràng các socket miền cải thiện thông lượng TCP qua kết nối dựa trên cổng TC:

https://rtcamp.com/tutorials/php/fpm-sysctl-tweaking/ https://engineering.gosquared.com/optimising-nginx-node-js-and-networking-for-ematvy-workloads

Bất kể chấm dứt ngược dòng:

Kích hoạt multi_accept và tcp_nodelay: http://tweaked.io/guide/nginx/

Vô hiệu hóa TCP Khởi động chậm: /programming/17015611/disable-tcp-slow-start http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/

Tối ưu hóa cửa sổ tắc nghẽn TCP (initcwnd): http://www.nateware.com/linux-network-tuning-for-2013.html

Để đặt số lượng tệp mở tối đa (nếu điều đó gây ra sự cố của bạn), bạn cần thêm "fs.file-max = 64000" vào /etc/sysctl.conf

Xin vui lòng, xem có bao nhiêu cổng ở TIME_WAITtrạng thái bằng cách sử dụng lệnh netstat -patunl| grep TIME | wc -lvà thay đổi net.ipv4.tcp_tw_reusethành 1.