"CPU 점유율 100%의 진실" 사실 절반은 멍때리고 있는 중?

요약 서버 모니터링 창에서 CPU 점유율이 100%를 찍고 있으면 흔히 프로세서가 최대 성능으로 쉴 새 없이 연산하고 있다고 착각하기 쉽습니다. 하지만 하드웨어 관점에서 CPU 점유율 100%는 단지 리눅스 태스크가 CPU를 점유하고 있다는 뜻일 뿐, 실제로 CPU 내부 파이프라인이 꽉 차서 일하고 있다는 의미는 아닙니다. 이러한 괴리가 발생하는 주된 원인은 바로 '메모리 지연 시간(Memory Latency)'에 있습니다. 최신 고성능 CPU 코어는 나노초(ns)당 약 4~8개의 명령어를 처리할 수 있을 정도로 극도로 빠릅니다. 반면 메인 메모리(DRAM) 접근에는 약 50~100ns가 걸립니다. 즉, RAM에서 데이터 하나를 읽어오는 시간 동안 CPU는 무려 400~800개의 연산 명령어를 실행할 수 있을 만큼의 시간을 그냥 허비하게 되는 셈입니다. 이 격차를 줄이기 위해 CPU 내부에 L1, L2, L3 캐시를 두고 작은 용량의 데이터를 초고속(L1 기준 약 1ns)으로 처리하도록 유도합니다. 데이터베이스 엔지니어링에서 캐시 활용률이 핵심 과제로 꼽히는 이유도 여기에 있습니다. 예를 들어 9,900만 건의 데이터셋에서 약 1,700만 개의 고유 유저 ID를 기준으로 'GROUP BY' 집계 쿼리를 순진하게 해시맵 형태로 돌릴 경우, 해시 테이블 크기가 너무 커져 고속 CPU 캐시 범위를 완전히 벗어나게 됩니다. 결국 거의 모든 접근이 RAM으로 향하는 '콜드 히트' 상태가 발생합니다. 실제 AMD EPYC 9124(16코어, 128GB DDR5) 베어메탈 서버에서 perf 도구로 단일 코어의 내부 하드웨어 카운터를 측정한 결과, 전체 실행 시간의 50.1% 동안 CPU가 메모리 응답을 기다리느라 멈춰 있는(stalling) 상태였으며, 실제로 명령어를 처리해 완료(retiring)한 비율은 16.1%에 불과한 것으로 나타났습니다. 겉보기엔 CPU가 100% 풀가동되는 것처럼 보여도, 실제로는 절반 이상의 시간을 멍하니 메모리를 기다리는 데 낭비하고 있었던 셈입니다.