서버의 컨텍스트 스위치 횟수가 늘었습니다. 정상적인 I/O 대기인지 과도한 스레드 경쟁인지 구분하려면 어떤 지표를 함께 봐야 하나요?

컨텍스트 스위치가 많다는 사실만으로 서버가 비효율적이라고 결론 내리면 안 됩니다. I/O가 끝나기를 기다리던 작업을 재우고 다른 작업을 실행하는 전환은 CPU를 놀리지 않기 위한 정상 동작일 수 있습니다. 반대로 실행 가능한 스레드가 코어 수보다 지나치게 많거나, 짧은 작업이 여러 실행기와 락 사이를 오가면 실제 계산보다 스케줄링·캐시 손실 비용이 커질 수 있습니다. 저는 전환 횟수가 아니라 같은 요청량에서 CPU 시간, 응답 지연, 유용한 처리량이 어떻게 변했는지를 먼저 비교하겠습니다. 이러한 원인과 비용을 분리해 측정하는 것이 컨텍스트 스위치 분석입니다.

전환의 이유를 나눠 봅니다

자발적 전환은 I/O, 조건 변수, 락 대기처럼 실행 흐름이 스스로 양보한 경우이고, 비자발적 전환은 time slice 만료나 더 높은 우선순위 작업의 선점처럼 커널이 실행을 빼앗은 경우입니다. 전자는 I/O 병렬성을 높일 수 있지만, 후자가 급증하면서 run queue와 runnable thread가 함께 늘면 CPU 경쟁을 의심합니다. 다만 전환 유형만으로 원인을 확정할 수는 없습니다. 같은 락을 반복해서 잡는 작업은 자발적·비자발적 전환을 모두 만들 수 있으므로 스레드 상태, 락 대기 시간, CPU별 사용률과 함께 봐야 합니다.

예를 들어 DB 응답을 기다리는 요청이 많으면 CPU 사용률은 낮고 자발적 전환은 늘 수 있습니다. 이 경우 스레드를 더 만들기보다 연결 풀 대기와 DB 지연을 줄이는 편이 맞습니다. 반대로 CPU를 쓰는 짧은 작업이 수십 개 실행 큐에서 번갈아 깨어나고 캐시 적중률이 떨어진다면 작업자 수나 실행기 경계를 줄이고 작은 작업을 묶겠습니다. 배치를 키우면 전환은 줄지만 먼저 도착한 작업의 대기 시간이 늘 수 있으므로 p50만 보지 않고 p95·p99를 확인합니다.

측정과 개선의 순서

먼저 요청량과 작업 종류를 고정하고 자발적·비자발적 전환, run queue, 코어별 CPU, 락·I/O·풀 대기, p99를 같은 시간축으로 수집합니다. 스레드 덤프와 스케줄링 trace에서 실제로 무엇이 깨우고 재웠는지도 확인합니다. 전환 수를 줄이는 패치 전후에는 처리량뿐 아니라 캐시 미스, 메모리 대역폭, 작업 회복 시간을 비교합니다. 바쁜 대기로 바꾸는 것은 전환을 줄여 보일 수 있지만 CPU와 전력, 다른 작업의 실행 기회를 소모하므로 대기 원인이 짧고 확실한 경우에만 제한적으로 사용하겠습니다.

컨텍스트 스위치 수와 지연이 함께 올라도 인과관계는 실험으로 확인해야 합니다. 요청률이 초당 1,000건에서 2,000건으로 오른 결과 I/O 완료와 깨우기가 두 배가 된 것일 수도 있고, 메모리 압력이나 락 경합이 먼저 생겨 전환을 늘렸을 수도 있습니다. 전환 이벤트 주변의 wait reason과 on-CPU 시간을 추적하고, 요청률을 고정한 채 작업자 수와 배치 크기를 하나씩 바꾸겠습니다. 실행기 큐를 합치면 전환은 줄어도 CPU 작업이 I/O 작업을 막는 head-of-line blocking이 생길 수 있으므로 작업 종류별 큐도 비교하겠습니다.

예를 들어 작업자 32개에서 16개로 줄여 context switch가 40% 감소했는데 p99가 20% 나빠졌다면 최적화 성공으로 보지 않습니다. 반대로 전환이 그대로여도 연결 풀 대기가 700ms에서 50ms로 줄면 사용자 지연의 핵심 원인을 해결한 것입니다. 최종 기준은 전환 횟수 하나가 아니라 같은 SLO를 지키는 데 필요한 CPU·메모리·하위 자원이 줄었는지입니다.

추가로 전환은 프로세스·스레드·코루틴을 같은 단위로 세면 안 됩니다. 사용자 공간 실행기에서의 양보가 커널 스케줄러 전환을 만들지 않을 수 있고, 프로세스 전환은 주소 공간과 TLB 처리 비용을 더할 수 있습니다. 측정 도구가 세는 이벤트의 정의를 확인한 뒤 전환당 비용을 비교하겠습니다.