비싼 계산 줄이기, 틱을 여러 스레드로 나누기, 인원 분산(채널), 틱 처리 시간을 지표로 남기기.
인프라팀 할 일
틱 시간과 코어별 CPU 사용률을 모니터링·경보에 추가, 단일 코어 성능(클럭)이 높은 CPU·인스턴스 검토.
수치 감각
20틱 서버의 예산은 50ms, 30틱은 33ms, 60틱은 16.7ms. 갑자기 몰릴 때를 대비해 평소에는 예산의 절반 정도만 쓰도록 여유를 두는 편이 안전합니다.
그래프에서는
인원·부하를 따라 오름 · 서버 틱 시간, 존·채널별 인원, 게임 스레드 CPU
확인할 곳
서버가 남기는 틱 처리 시간(p99)·틱 초과 횟수를 존·채널별 인원과 같은 그래프에 놓고 봄. 틱 지표가 없으면 pidstat -t 1로 게임 스레드 하나의 CPU 사용률
이러면 맞음
인원이 몰린 시각에 틱 시간이 예산(20틱이면 50ms)을 넘고 그동안 게임 스레드의 CPU 사용률이 100% 가까이 붙어 있음
이러면 아님
틱이 넘치는데 게임 스레드 CPU가 낮으면 기다림 쪽 원인(GC 멈춤, 락, 동기 호출). bcc runqlat의 런큐 지연이 길면 스레드가 CPU를 배정받지 못한 것이라 CPU 부족·스레드 과다 쪽
확인 수단
게임 서버·클라이언트의 로그·지표가 필요
더 알아보기
틱이 늦을 때의 모습은 서버 설계에 따라 다릅니다. 틱마다 게임 상태를 정해진 시간(예: 50ms)만큼 진행하는 서버는 게임 시간 자체가 느려져 슬로우모션이 됩니다. 실제로 흐른 시간만큼 한 번에 움직이는 서버는 게임 진행 속도는 지키지만 패킷이 드물고 한 번에 크게 움직여 뚝뚝 끊김·순간이동으로 보입니다. 어느 쪽이든 입력 반응은 늦어집니다. 게임 스레드 하나가 서버 전체를 맡으면 서버 전체가, 지역마다 스레드를 나눴다면 그 지역이 느려집니다. EVE Online처럼 대규모 전투에서 일부러 게임 시간을 최대 10배까지 늦춰(Time Dilation) 계산을 따라잡게 하는 게임도 있습니다.