메시지 큐 적체 Mailbox / job queue backlog

원인 ID sp-queue · 주 담당 게임개발팀·서버 개발

요청이 처리 속도보다 빨리 들어와 대기열에 쌓이면, 뒤쪽 요청은 몇 초 뒤에야 처리되거나 버려집니다.

왜 요청이 처리 속도보다 빨리 도착 → 그러면 대기열이 길어지고 한도를 넘으면 버림 → 화면에서는 스킬·거래 반응이 늦거나 씹힘

증상: 입력 지연, 씹힘·롤백
요인: 지연, 손실
누가 겪나: 특정 장소·채널, 특정 기능만
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 대기열 길이 모니터링, 오래된 요청 우선 폐기 정책, 처리 병렬화.
그래프에서는: 한도에 닿아 평평해짐 · 큐 길이·가장 오래된 메시지 나이, 초당 처리 수
확인할 곳: 서버가 남기는 큐별 길이, 가장 오래된 메시지의 나이, 초당 들어온 수·처리한 수·버린 수. 코드 지표가 없으면 ss(또는 netstat)로 게임 소켓의 Recv-Q(커널이 받아 두었지만 프로세스가 아직 읽지 않은 양)
이러면 맞음: 들어오는 수가 처리 수를 넘는 동안 처리 수는 한 값에서 더 오르지 못하고, 큐 길이·나이와 버린 수가 계속 늘어남
이러면 아님: 큐가 짧고 나이도 작은데 반응이 늦으면 회선 지연이나 틱 자체의 지연 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
실제 사례: CCP Games 2014: EVE Online HED-GP 대규모 함대전의 서버 과부하

출처

Avoiding insurmountable queue backlogs AWS
Amazon Builders' Library. 적체는 대기 중인 메시지의 나이로 감시, 실시간 시스템은 새 데이터부터 처리(LIFO에 가깝게), 오래된 메시지는 버리기도 함
Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
처리 속도보다 요청이 빠르면 큐가 차서 지연이 늘고 FIFO 대신 LIFO나 CoDel로 이미 쓸모없어진 오래된 요청을 덜어 냄
ss(8) — Linux manual page iproute2
소켓 통계를 보여 주는 도구(netstat과 비슷한 정보), -p로 소켓을 쓰는 프로세스 표시
netstat(8) — Linux manual page net-tools
Recv-Q: 연결된 소켓에서 사용자 프로그램이 아직 가져가지 않은 바이트 수