2009-04-17 54 views
22

Tôi có một chương trình rất đơn giản được viết trong 5 phút để mở một ổ cắm và vòng lặp thông qua yêu cầu và in ra màn hình các byte được gửi tới nó.Có giới hạn về số lượng kết nối tcp/ip giữa các máy trên linux không?

Sau đó tôi đã thử điểm chuẩn số lượng kết nối mà tôi có thể kết hợp với để tìm hiểu xem có bao nhiêu người dùng đồng thời tôi có thể hỗ trợ với chương trình này.

Trên máy khác (nơi mạng giữa chúng không bão hòa) Tôi đã tạo một chương trình đơn giản đi vào vòng lặp và kết nối với máy chủ và gửi byte "hello world".

Khi vòng lặp 1000-3000 khách hàng hoàn tất với tất cả các yêu cầu được gửi. Khi vòng lặp vượt quá 5000, nó bắt đầu có thời gian chờ sau khi hoàn tất số yêu cầu X đầu tiên. Tại sao điều này? Tôi đã chắc chắn để đóng ổ cắm của tôi trong vòng lặp.

Bạn chỉ có thể tạo quá nhiều kết nối trong một khoảng thời gian nhất định không?

Giới hạn này chỉ áp dụng được giữa cùng một máy và tôi không cần phải lo lắng về điều này khi sản xuất có 5000 yêu cầu đến từ các máy khác nhau?

+0

bạn có thể giám sát ổ cắm của bạn sử dụng lệnh ss -s. Và làm theo các bước để tăng giới hạn socket nếu cần – Antarus

+0

bạn có thể sử dụng lại các ổ cắm TIMED_WAIT như: 's = socket.socket (socket.AF_INET, socket.SOCK_STREAM, 0)' 's.setsockopt (socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) ' – knutole

Trả lời

24

Có giới hạn, có. Xem ulimit.

Ngoài ra, bạn cần xem xét trạng thái TIMED_WAIT. Khi cổng TCP được đóng (theo mặc định), cổng vẫn giữ nguyên trạng thái chiếm trong trạng thái TIMED_WAIT trong 2 phút. Giá trị này có thể điều chỉnh được. Điều này cũng sẽ "chạy bạn ra khỏi ổ cắm" ngay cả khi chúng được đóng lại.

Chạy netstat để xem nội dung hoạt động TIMED_WAIT.

P.S. Lý do cho TIMED_WAIT là xử lý trường hợp các gói đến sau khi đóng socket. Điều này có thể xảy ra vì các gói bị trễ hoặc phía bên kia không biết rằng socket đã được đóng chưa. Điều này cho phép hệ điều hành tự động thả các gói đó mà không có khả năng "lây nhiễm" một kết nối socket khác, không liên quan.

+0

Tôi vừa kiểm tra với netstat trên cả hai máy, và thực sự có một tấn TIMED_WAIT ở phía máy khách nhưng không có TIMED_WAIT ở phía máy chủ. Đây là bahaviour bạn đang mô tả? Giả sử có: 1) Điều này có nghĩa đây không phải là vấn đề trong sản xuất vì giới hạn dường như đến từ phía máy khách (hết ổ cắm) chứ không phải phía máy chủ (nơi không có ổ cắm) 2) Có cách nào để có được xung quanh này vì vậy tôi có thể kiểm tra máy chủ của tôi với tải tương tự như sản xuất? – erotsppa

+0

Hành vi của TIMED_WAIT là hệ điều hành cụ thể. Có, bạn có thể vượt qua nó - có thể thay đổi thời gian chờ TIMED_WAIT, ví dụ: từ 120 giây đến 30 hoặc thậm chí ít hơn. –

+0

ulimit cho tôi thấy "không giới hạn" ... nhưng tôi thực sự không nghĩ rằng nó không giới hạn ... – trillions

1

Bạn có thể muốn kiểm tra /etc/security/limits.conf

8

Khi tìm kiếm hiệu suất tối đa bạn gặp phải nhiều vấn đề và tắc nghẽn tiềm năng. Chạy một bài kiểm tra hello world đơn giản không nhất thiết phải tìm tất cả chúng.

hạn chế có thể bao gồm:

  • hạn chế ổ cắm Kernel: tìm trong /proc/sys/net cho rất nhiều điều chỉnh kernel ..
  • quá trình giới hạn: kiểm tra ulimit như những người khác đã tuyên bố đây
  • như ứng dụng của bạn phát triển trong phức tạp, nó có thể không có đủ năng lượng CPU để theo kịp số lượng kết nối đến. Sử dụng top để xem liệu CPU của bạn có tối đa
  • số lượng chủ đề không? Tôi không có kinh nghiệm với luồng, nhưng điều này có thể đi vào chơi kết hợp với các mục trước đó.
2

Máy chủ của bạn có đơn luồng không? Nếu có, bạn đang sử dụng chức năng ghép kênh/ghép kênh nào?

Sử dụng select() không hoạt động vượt quá giới hạn bộ mô tả tệp tối đa được mã hóa cứng tại thời gian biên dịch, điều này là vô vọng (thường là 256 hoặc nhiều hơn).

thăm dò ý kiến ​​() là tốt hơn nhưng bạn sẽ kết thúc với vấn đề khả năng mở rộng với một số lượng lớn FDs repopulating thiết lập mỗi lần xung quanh vòng lặp.

epoll() sẽ hoạt động tốt với một số giới hạn khác mà bạn đạt được.

Kết nối 10k phải đủ dễ dàng để đạt được. Sử dụng hạt nhân 2.6 (ish) 2.6 gần đây.

Bạn đã sử dụng bao nhiêu máy khách? Bạn có chắc chắn bạn không đạt đến giới hạn phía máy khách không?

+0

Trên hệ thống chọn giới hạn cứng của tôi là 1024 và thực sự không thể vượt quá giới hạn này (giới hạn được áp đặt bởi kiểu dữ liệu chứa bản đồ của các bộ mô tả tệp để xem). –

2

Câu trả lời nhanh là 2^16 cổng TCP, 64K.

Các vấn đề với giới hạn áp đặt hệ thống là vấn đề về cấu hình, đã được đề cập trong các nhận xét trước.

Các tác động bên trong đối với TCP không rõ ràng (đối với tôi). Mỗi cổng đòi hỏi bộ nhớ cho nó là instantiation, đi vào một danh sách và cần bộ đệm mạng cho dữ liệu quá cảnh.

Với phiên 64K TCP, chi phí cho các phiên bản của cổng có thể là vấn đề đối với hạt nhân 32 bit, nhưng không phải hạt nhân 64 bit (sửa ở đây sẵn sàng chấp nhận). Quá trình tra cứu với các phiên 64K có thể làm chậm mọi thứ một chút và mọi gói tin đều truy cập hàng đợi hẹn giờ, điều này cũng có thể có vấn đề. Lưu trữ cho dữ liệu quá cảnh về mặt lý thuyết có thể sưng lên với kích thước cửa sổ lần cổng (có thể là 8 GByte).

Vấn đề với tốc độ kết nối (đã đề cập ở trên) có thể là những gì bạn đang thấy. TCP thường mất thời gian để làm việc. Tuy nhiên, nó không phải là bắt buộc. Kết nối TCP, giao dịch và ngắt kết nối có thể được thực hiện rất hiệu quả (kiểm tra xem các phiên TCP được tạo và đóng) như thế nào.

Có các hệ thống vượt qua hàng chục gigabit mỗi giây, do đó việc chia tỷ lệ gói dữ liệu phải ổn định.

Có máy có nhiều bộ nhớ vật lý, vì vậy trông có vẻ ổn.

Hiệu suất của hệ thống, nếu được định cấu hình cẩn thận phải OK.

Phía máy chủ của mọi thứ sẽ mở rộng theo cách tương tự.

Tôi sẽ quan tâm đến những thứ như băng thông bộ nhớ.

Xem xét thử nghiệm nơi bạn đăng nhập vào máy chủ lưu trữ cục bộ 10.000 lần. Sau đó nhập một ký tự. Toàn bộ ngăn xếp thông qua không gian người dùng sẽ được tương tác với từng nhân vật. Dấu chân hoạt động có khả năng sẽ vượt quá kích thước bộ nhớ cache dữ liệu. Chạy qua nhiều bộ nhớ có thể làm căng thẳng hệ thống VM. Chi phí chuyển mạch bối cảnh có thể tiếp cận một giây!

này được thảo luận trong một loạt các chủ đề khác: https://serverfault.com/questions/69524/im-designing-a-system-to-handle-10000-tcp-connections-per-second-what-problems

Các vấn đề liên quan