Mỗi tick, nếu server dồn bản cập nhật cho hàng nghìn người rồi gửi đi trong một khoảnh khắc, bộ đệm nhỏ của switch hoặc giới hạn tức thời của cloud sẽ tràn trong chưa đầy 1 ms và một phần gói tin bị bỏ.
Vì sao Ngay đầu tick, server gửi dồn một lượt toàn bộ gói tin cho mọi người → Dẫn đến Bộ đệm của cổng switch nơi lưu lượng từ nhiều server dồn về (vài trăm KB đến vài MB mỗi cổng) hoặc giới hạn của instance cloud bị tràn trong khoảnh khắc (mức sử dụng trung bình vẫn thấp) → Trên màn hình Nhiều người cùng lúc bị dịch chuyển tức thời hoặc khựng, nhìn chỉ số trung bình thì không thấy nguyên nhân
Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Hạ tầng server (Đội hạ tầng), Hạ tầng mạng (Đội hạ tầng)
Việc cần làm (Đội phát triển game)
Chia dữ liệu gửi của một tick rải ra trong suốt tick (pacing theo từng kết nối khó gỡ được cảnh hàng nghìn kết nối cùng dồn vào đầu tick), lệch thời điểm bắt đầu tick giữa các server, giới hạn tốc độ bằng SO_MAX_PACING_RATE cho kết nối gửi dữ liệu lớn.
Việc cần làm (Đội hạ tầng)
Thiết bị server·OS: giới hạn tốc độ gửi của toàn server (shaper trong OS của server, tc trên Linux), dùng pacing (hàng đợi fq của Linux, BBR) để dàn đều khi một kết nối gửi dồn. Mạng: dùng switch có bộ đệm lớn, kiểm tra counter bỏ gói ở chiều ra của cổng switch với chu kỳ ngắn (nhìn mức sử dụng trung bình sẽ không thấy).
Con số tham khảo
Lượng dữ liệu một cổng 10 Gbps gửi được trong 1 ms là khoảng 1,25 MB. Khi tick của nhiều server trùng nhau và cùng dồn vào một cổng, bộ đệm đầy ngay tức thì.
Trên đồ thị
Tăng theo số người và tải · Số gói bị bỏ ở chiều ra của cổng switch, tỷ lệ truyền lại
Chỗ cần xem
Số gói bị bỏ ở chiều ra (ifOutDiscards) của cổng switch nối với server và cổng tầng trên của nó, thu thập với chu kỳ vài giây; nếu là cloud thì xem bw_out_allowance_exceeded và pps_allowance_exceeded trong ethtool -S. Gom các lần truyền lại cùng thời điểm bằng bcc tcpretrans để đối chiếu
Đúng nếu
mức sử dụng trung bình theo phút thấp nhưng số gói bị bỏ ở chiều ra hoặc số lần vượt allowance tăng, và tăng theo số người chơi đồng thời hoặc số người tụ tập một chỗ. Truyền lại xảy ra cùng một lúc trên nhiều kết nối của server đó và không dồn vào dải IP người chơi của một nhà mạng hay khu vực cụ thể
Loại trừ nếu
cùng cổng đó lỗi CRC và lỗi chiều vào (input error) cũng tăng → “Lỗi vật lý”. Counter bỏ gói trên NIC hoặc softnet dropped của server nhận tăng → “Host server nhận bỏ gói tin”
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm
Pacing hoạt động riêng cho từng kết nối. Khi hàng nghìn kết nối, mỗi kết nối gửi một hai gói, cùng dồn vào đầu tick thì pacing theo kết nối khó gỡ được, server game phải tự chia thời điểm gửi. Ngược lại, khi một kết nối gửi dữ liệu lớn, NIC cắt vài chục KB dữ liệu thành các gói rồi đẩy ra liên tiếp (TSO), và kiểu dồn này thì pacing dàn đều rất tốt.
Nguồn
High-Resolution Measurement of Data Center MicroburstsMeta Hơn 70% burst ở switch rack trong trung tâm dữ liệu kết thúc trong vài chục µs, và mức sử dụng trung bình theo phút ít liên quan đến số gói bị drop (IMC 2017)
tc-fq(8) — Linux manual pageiproute2 Hàng đợi fq pacing theo từng socket (kết nối), SO_MAX_PACING_RATE đặt tốc độ tối đa cho từng kết nối
net/ipv4/tcp_bbr.cLinux kernel BBR đặt pacing_rate theo băng thông điểm nghẽn ước tính rồi gửi theo tốc độ đó
IP SysctlLinux kernel TCP chọn kích thước frame TSO theo tốc độ của luồng (tối đa 64 KB, tcp_min_tso_segs)
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: số gói tin bị bỏ, không được gửi đi dù không có lỗi, vì các lý do như cần giải phóng chỗ trong bộ đệm