Làm thế nào để bạn chẩn đoán mất gói?

Tôi nhận ra điều này rất chủ quan và phụ thuộc vào một số biến, nhưng tôi tự hỏi những bước mà hầu hết mọi người trải qua khi họ cần chẩn đoán mất gói trên một hệ thống nhất định?

Tôi là một kỹ sư mạng, vì vậy tôi sẽ mô tả điều này từ quan điểm của tôi.

Đối với tôi, chẩn đoán mất gói thường bắt đầu bằng "nó không hoạt động tốt". Từ đó, tôi thường cố gắng tìm bộ càng gần hai đầu của giao tiếp (thông thường, một máy trạm trong văn phòng và máy chủ ở đâu đó) và ping càng gần đầu kia càng tốt (lý tưởng là "điểm cuối từ xa", nhưng đôi khi có những tường lửa tôi không thể gửi ping qua, vì vậy sẽ phải giải quyết giao diện LAN trên bộ định tuyến) và xem liệu tôi có thể thấy bất kỳ mất mát nào không.

Nếu tôi có thể thấy mất, đó thường là trường hợp "không đủ băng thông" hoặc "liên kết với các vấn đề" ở giữa, vì vậy hãy tìm tuyến qua mạng và bắt đầu từ giữa, thường cung cấp cho bạn đầu này hoặc đầu kia.

Nếu tôi không thể thấy mất, hai bước tiếp theo có xu hướng là "gửi thêm ping" hoặc "gửi ping lớn hơn". Nếu điều đó không sắp xếp cho biết vấn đề là gì, đã đến lúc bắt đầu xem xét các chính sách QoS và thống kê giao diện thông qua toàn bộ đường dẫn giữa các điểm cuối.

Nếu điều đó không tìm thấy gì, đã đến lúc bắt đầu đặt câu hỏi về các giả định của bạn, bạn có thực sự đang bị mất gói. Cách duy nhất chắc chắn để tìm thấy đó là chụp đồng thời ở cả hai đầu, bằng cách sử dụng WireShark (hoặc tương đương) trên máy chủ hoặc bằng cách kết nối các máy sniffer (có thể sử dụng WireShark hoặc tương tự) thông qua vòi mạng. Sau đó là niềm vui của việc so sánh hai gói chụp ...

Đôi khi, cái được cho là "mất gói" chỉ đơn giản là thứ gì đó ở phía máy chủ chậm hơn đáng kể (như, nói, chuyển cơ sở dữ liệu từ "trên cùng một mạng LAN" sang "20 ms" và sử dụng các truy vấn đòi hỏi rất nhiều qua lại giữa front-end và cơ sở dữ liệu).

Từ quan điểm của một hệ thống Linux, trước tiên tôi sẽ tìm kiếm mất gói trên giao diện mạng ethtool -S ethX.

Hầu hết thời gian, tăng bộ đệm vòng với ethtool -G ethX rx VALUEgiải quyết điều này.

Đôi khi các ngắt không cân bằng vì hệ thống thiếu dịch vụ mất cân bằng, vì vậy hãy tìm trong chkconfig(EL) hoặc update-rc(Debfox) để xem dịch vụ này có chạy không. Bạn có thể biết nếu các ngắt không cân bằng vì /proc/interruptssẽ chỉ hiển thị Core 0 phục vụ tất cả các kênh IRQ.

Không thực hiện được điều này, bạn có thể cần phải tăng net.core.netdev_max_backlognếu hệ thống vượt qua hơn một vài gigabit lưu lượng và có thể net.core.netdev_budget.

Nếu điều đó không hiệu quả, bạn có thể điều chỉnh các giá trị kết hợp ngắt với ethtool -C.

Nếu không có giọt gói nào trên giao diện mạng, hãy nhìn vào netstat -svà xem liệu có giọt nào trong bộ đệm ổ cắm không, chúng sẽ được báo cáo với các số liệu thống kê như " pruned from receive queue" và " dropped from out-of-order queue".

Bạn có thể thử tăng bộ đệm ổ cắm mặc định và tối đa cho giao thức thích hợp (ví dụ: net.ipv4.tcp_rmemđối với TCP).

Nếu ứng dụng đặt kích thước bộ đệm ổ cắm riêng, thì ứng dụng có thể cần thay đổi cấu hình. Nếu ứng dụng của bạn có kích thước bộ đệm ổ cắm được mã hóa cứng, hãy khiếu nại với nhà cung cấp ứng dụng của bạn.

Cá nhân tôi không thích giảm tải giao thức lên các NIC (kiểm tra, giảm tải phân đoạn, giảm tải lớn) vì nó dường như gây ra nhiều rắc rối hơn giá trị của nó. Chơi xung quanh với các cài đặt này bằng cách sử dụng ethtool -Kcó thể đáng giá một shot.

Nhìn vào các tùy chọn mô-đun cho NIC ( modinfo <drivername>) của bạn vì bạn có thể cần phải thay đổi một số tính năng. Để đưa ra một ví dụ mà tôi đã gặp, sử dụng Flow Director của Intel trên một hệ thống xử lý một luồng TCP lớn có thể sẽ gây hại cho hiệu quả của luồng đó, vì vậy hãy tắt FDir.

Ngoài ra, bạn đang bắt tay vào điều chỉnh hệ thống cụ thể này cho khối lượng công việc cụ thể của nó, mà tôi đoán là vượt quá phạm vi câu hỏi của bạn.

Tôi sẽ bắt đầu bằng cách sử dụng công cụ chụp gói như: wireshark (trên Windows) và tcpdump (trên thiết bị đầu cuối Linux).

Tôi cũng sẽ kiểm tra cấu hình tường lửa (tường lửa máy chủ cũng như tường lửa mạng).

Cô lập, sau đó loại bỏ.

Tìm tập hợp con nhỏ nhất của đường dẫn với bài toán. Thực hiện việc này bằng cách kiểm tra các kết hợp khác nhau và / hoặc chắt lọc báo cáo người dùng. Đừng quên yếu tố thời gian trong cuộc chinh phục. Có thể đó chỉ là gói dữ liệu trên tất cả lưu lượng truy cập vào một mạng cụ thể hoặc có thể chỉ có các máy khách không dây đang chịu đựng. Đưa các loại lưu lượng khác nhau vào tài khoản (giới hạn tỷ lệ trên ping). Tìm cách đáng tin cậy nhất và dễ dàng lặp lại để kiểm tra nó.

Sau đó loại bỏ các nguyên nhân tiềm năng. Giảm lưu lượng trên các liên kết (tạm thời), loại bỏ các nguồn nhiễu khỏi phổ, ngắt kết nối một số máy khách nhất định. Cuối cùng, bạn sẽ tìm thấy nguồn gốc của vấn đề.

Đôi khi bạn có thể thực hiện các phím tắt bằng cách nhìn vào các gói dữ liệu hoặc đoán (nó luôn luôn bittorrent). Ngoài ra, nói với giáo sư serverfault của bạn là tuyệt vời.

Ping có thể không hiển thị mất gói trừ khi bạn gửi ping lớn! Tôi đã bị mất gói trên mạng mà không nhìn thấy được cho đến khi tôi tăng kích thước gói ping của mình.

Cho cửa sổ:

ping -n 30 -l <largevalue> <target>

Đối với largevaluetôi đã sử dụng 40.960 (40k gói)

Vì targettôi đã sử dụng một vài địa chỉ IP đầu tiên từtracert google.com

(đó là bộ định tuyến & modem cáp của tôi). Một trong những thiết bị tiếp theo chuỗi có sự mất gói khủng khiếp (> 60%) cho các gói lớn nhưng 0% cho các gói nhỏ. Tôi đã sửa nó bằng cách khởi động lại nhưng nó cũng có thể là dây cáp hoặc thứ gì đó bên trong cần thay thế.