Điểm:1

Tại sao các thông số vòng NIC không được đặt trước ở khả năng tối đa của Phần cứng?

lá cờ us

Kiểm tra bộ đệm vòng NIC:

# ethtool -g eth0
Tham số vòng cho eth0:
Cài đặt trước tối đa:
RX: 4096
RX Mini: 0
RX khổng lồ: 0
TX: 4096
Cài đặt phần cứng hiện tại:
RX: 256
RX Mini: 0
RX khổng lồ: 0
TX: 256

Người ta có thể đặt "RX/TX" lên đến giới hạn được hiển thị trong "Mức tối đa được đặt trước" như:

# ethtool -G eth0 rx 4096 rx 4096

Câu hỏi là: theo mặc định;, tại sao những thứ này được đặt quá thấp (trong mọi máy chủ tôi có, tất cả chúng đều ở mức 256) thay vì giá trị cao hơn hoặc khả năng tối đa của Phần cứng của chúng? Có bất kỳ hạn chế nào (nếu có, sẽ không?) làm tăng các giá trị này?

ewwhite avatar
lá cờ ng
Câu hỏi hay!!
Điểm:1
lá cờ cn

Đầu tiên, các số bạn đặt không có trong byte như nhiều người nghĩ, họ đang ở trong mô tả (và kích thước bộ mô tả phụ thuộc vào phần cứng). Vì vậy, khi bạn tăng độ dài vòng, bạn yêu cầu cấp phát nhiều bộ nhớ hơn trong kernel cho các bộ mô tả này. Nói chung, bạn muốn bộ nhớ kernel này nằm trong bộ đệm L1 để quá trình xử lý ngắt diễn ra nhanh nhất có thể. Tăng kích thước vòng làm cho điều này ít xảy ra hơn và trong một số trường hợp là hoàn toàn không thể.

Điều tiếp theo là kết hợp ngắt - nói chung, khi bạn tăng kích thước bộ đệm vòng, NIC sẽ điều chỉnh điểm thấp/cao của nó một cách thích hợp và sẽ kích hoạt ngắt khi có nhiều dữ liệu hơn được lưu vào bộ đệm (điều này ít xảy ra hơn). Thời gian mà hạt nhân cần để xử lý lượng dữ liệu lớn hơn này trong quá trình xử lý ngắt cũng sẽ tăng lên.

Tất cả các kết quả trên dẫn đến hiệu ứng thùng đơn giản - với xác suất rơi gói vòng lớn hơn sẽ giảm và độ trễ mạng tăng. Điều này có thể hoàn toàn ổn nếu bạn đang phát trực tuyến các tệp lớn qua TCP và có thể hoàn toàn không mong muốn nếu bạn là một ứng dụng gói nhỏ có độ trễ thấp (tức là chơi game, v.v.).

Các số mặc định mà bạn thấy là sự đánh đổi hợp lý giữa hai số này.

CrazyRabbit avatar
lá cờ us
Cảm ơn vì lời giải thích này. Tôi đang sử dụng một ứng dụng để phân phối các tệp qua TCP và đã gặp lỗi fifo, vì vậy dựa trên https://serverfault.com/questions/650596/ meaning-of-rx-queue-csum-err-and-rx-fifo- lỗi tôi đã tăng nó. Có cách nào, ngoài thử và sai, để tăng giá trị này thành "giá trị tốt" giữa giá trị mặc định 256 và giá trị được chấp nhận tối đa 4096 không?
Peter Zhabin avatar
lá cờ cn
@ user1773988, đối với một khối lượng công việc cụ thể mà kích thước gói đã biết, chúng tôi sử dụng `iperf` với các tham số phù hợp để mô phỏng tải và xem hiệu suất cũng như tải CPU hệ thống (cũng bị ảnh hưởng bởi cài đặt này) để tìm điểm phù hợp. Chúng tôi đã từng phải đặt những thứ này trên một loạt tường lửa Linux với vai trò là BRAS của người nghèo trong môi trường ISP và đó là nơi thử và sai là phương pháp duy nhất..
CrazyRabbit avatar
lá cờ us
Cảm ơn bạn đã nhập. câu hỏi phụ; những thứ này có thể được giảm xuống dưới 256 không? Giả sử một máy chủ Redis, các gói nhỏ, NIC chuyên dụng, havig rx và tx được đặt thành 128?
Peter Zhabin avatar
lá cờ cn
@ user1773988, điều này có thể được hạ xuống tới 48 AFAIR, nhưng xác suất rớt gói sẽ tăng lên đặc biệt trong trường hợp bùng nổ pps bất ngờ. Redis là một ứng dụng TCP và việc giảm sẽ không có tác dụng gì. Tôi không có kinh nghiệm trực tiếp với nội dung có độ trễ thấp, chỉ từ quan điểm của ISP, vì vậy chúng tôi hầu như luôn tăng các giá trị này nhưng đến một điểm nhất định dựa trên số liệu thống kê theo dõi 24h.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.