.NET은 dotnet-counters monitor의 스레드 풀 스레드 수와 대기열 길이(.NET 9 이후 dotnet.thread_pool.thread.count·dotnet.thread_pool.queue.length, 8 이하 ThreadPool Thread Count·ThreadPool Queue Length)를 보고, dotnet-stack으로 워커 스레드들이 어디서 기다리는지 확인. JVM·네이티브 서버는 스레드 덤프로 같은 것을 확인
이러면 맞음
CPU 사용률은 100%보다 한참 낮은데 스레드 수가 천천히 계속 늘거나 상한에 붙어 있고, 대기열이 쌓이며 워커 대부분이 같은 외부 호출(DB·HTTP) 응답을 기다림
이러면 아님
대기열이 비어 있는데도 느리면 호출 대상 자체가 느린 것이라 연쇄 장애·외부 서비스 의존 쪽
확인 수단
인프라 도구로 확인(게임 코드 불필요)
더 알아보기
패킷 받기와 게임 로직이 같은 워커 스레드 풀을 나눠 쓰는 구조라면, 느린 작업 몇 개가 워커를 모두 점유하는 순간 서버 전체의 패킷 처리가 멈춥니다.
Debug ThreadPool StarvationMicrosoft 풀에 남은 스레드가 없어 새 작업이 대기하면 응답이 느려짐, 스레드를 점유하는 블로킹 코드가 원인. dotnet-counters에서 CPU는 100%보다 한참 낮은데 dotnet.thread_pool.thread.count가 천천히 계속 늘면 고갈 신호(dotnet.thread_pool.queue.length도 큰 경우가 많음), dotnet-stack으로 스레드가 기다리는 곳 확인