Tràn hàng đợi kết nối (backlog) Listen backlog / SYN queue overflow
ID nguyên nhân so-backlog · 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), Phát triển client (Đội phát triển game)
Ngay sau bảo trì, khi hàng chục nghìn người chơi kết nối cùng lúc, hàng đợi kết nối (backlog) của kernel bị tràn và các yêu cầu kết nối bị bỏ.
Vì sao Vừa hết bảo trì, kết nối đổ về nhanh hơn tốc độ server game xử lý bằng accept → Dẫn đến Hàng đợi kết nối của kernel (backlog, lấy giá trị nhỏ hơn giữa giá trị code server truyền cho listen và giới hạn của kernel) bị đầy → Trên màn hình Yêu cầu kết nối bị bỏ, client thử lại hết lần này đến lần khác, dẫn đến không vào được·kẹt loading
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), Phát triển client (Đội phát triển game)
Việc cần làm (Đội phát triển game)
Server: tăng giá trị listen truyền trong code, không để thread nhận kết nối bị dừng vì việc khác, thêm hệ thống hàng chờ đăng nhập. Client: tăng khoảng cách thử lại (rải ngẫu nhiên).
Việc cần làm (Đội hạ tầng)
Tăng somaxconn của kernel (phải tăng cả giá trị listen trong code server mới có tác dụng), luôn bật SYN cookie, giám sát số lần tràn (TcpExtListenOverflows trong nstat).
Con số tham khảo
Giới hạn của kernel Linux (somaxconn) mặc định là 4.096 từ bản 5.4 (trước đó là 128), nhưng nếu code server truyền cho listen một giá trị nhỏ hơn thì giá trị đó là giới hạn. Khi hàng đợi đầy, Linux lặng lẽ bỏ yêu cầu kết nối mà không báo lỗi. OS phía client gửi lại vài lần, bắt đầu sau 1 giây, nên người chơi chỉ thấy loading kéo dài, không thấy báo “Kết nối thất bại”. Server Windows thì gửi lại phản hồi từ chối, nên client thấy “Kết nối thất bại” ngay.
Trên đồ thị
Tăng vọt ngay sau đăng nhập hoặc bảo trì · Số lần tràn hàng đợi kết nối (ListenOverflows), số lần thử kết nối
Chỗ cần xem
Mức tăng của TcpExtListenOverflows và TcpExtListenDrops trong nstat -az; dùng ss -ltn so sánh Recv-Q (số kết nối đang chờ accept) với Send-Q (giới hạn backlog) của socket đang listen
Đúng nếu
ListenOverflows tăng vào lúc kết nối dồn về, và Recv-Q của socket đang listen dính sát giá trị Send-Q
Loại trừ nếu
ListenOverflows không đổi. Kết nối đã thiết lập nhưng loading không xong → “Đăng nhập ồ ạt và query N+1”; bị chặn đúng ở một mức số người cố định → “Giới hạn file descriptor”
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Nguồn
listen(2) — Linux manual pageLinux man-pages Backlog của listen vượt somaxconn thì bị cắt bớt mà không báo; somaxconn mặc định 4.096 (từ 5.4, trước đó là 128); khi hàng đợi đầy, yêu cầu có thể bị bỏ qua để client tự thử lại
IP SysctlLinux kernel tcp_syn_retries: yêu cầu kết nối (SYN) được gửi lại nhiều lần, lần truyền lại đầu tiên chờ 1 giây; tcp_abort_on_overflow mặc định tắt (tràn cũng không gửi phản hồi từ chối); tcp_syncookies mặc định bật
SNMP counterLinux kernel TcpExtListenOverflows: số lần bỏ yêu cầu kết nối (SYN) vì hàng đợi accept đầy; khi đó TcpExtListenDrops cũng tăng theo
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Giá trị Recv-Q và Send-Q trong ss: với socket đang listen là số kết nối chờ accept và giới hạn backlog; với socket đã kết nối là số byte ứng dụng chưa đọc và số byte đã gửi nhưng chưa nhận được ACK