CPU 사용률 100%의 배신: 메모리 지연이 성능을 갉아먹는다
It's the Memory Latency, Stupid
데이터베이스 CPU가 100%인데도 실제로는 절반 이상이 메모리 지연으로 멈춰 있다. Pivot 엔진의 GROUP BY를 순진한 해시맵으로 구현하면 99m 행 처리에 3.9초, perf 측정 결과 50.1%가 메모리 대기였다. 이를 4096개 파티션으로 나눠 캐시에 맞추는 radix partitioning으로 바꾸자 2.7초로 줄고, 메모리 대기 비율은 23.5%로, DRAM 로드는 4.5GB에서 1.5GB로 감소했다.
이것은 CPU가 메모리에서 멈춰 아무것도 못한 시간이 50.1%였고, 실제로 연산을 완료한 시간은 16.1%에 불과하다는 것을 말해준다.
HN 토론
46- boricj
회사에서 메시지 패싱을 엄청 많이 쓰고, 깊게 중첩된 클래스 계층 구조에서 C++ 가상 메서드를 쓰고, 큰 DOM에 기성 C++ STL 컨테이너까지 쓰는 다른 팀과 일하는데... 그게 STM32MP1 위에서 돌아갑니다. 인오더(in-order) Cortex-A7에 캐시는 쥐꼬리만 한 녀석이죠.
반대로 우리 팀에서 저는 인라인으로 할당하는 커스텀 C++ STL 컨테이너와 SAX 스타일 처리 라이브러리, 그리고 2000년대 비디오 게임처럼 인덱스+세대(generation)를 쓰는 링크 기반 객체 풀을 직접 작성했는데... 그건 RAM이 1메가바이트도 안 되는 STM32H5 위에서 돌아갑니다.
제가 시연해 보여주는 사람들에게 기계적 공감(mechanical sympathy)은 잃어버린 기술처럼 느껴지더군요... 그리고 저는 첫 번째 팀에게 우리 사이에서 내가 병목이 되지 않을 거라는 걸 벤치마크 수치로, 그것도 몇 자릿수 단위로 보여줘야 했습니다.
- happyPersonR
글쓴이에게 박수를 보냅니다, 일관성 있어 보이네요.
저는 flamegraph를 좋아합니다.
사람들이 flamegraph를 만드는 데 perf를 쓴다는 걸 압니다.
하지만 앞으로는, 이제 LLM이 있으니 에이전트를 시켜서 어셈블리와 PMU를 확인하고 어셈블리에서 뭘 하고 있는지도 보게 하세요.
제 2센트였고, 모두 즐거운 코딩 되시길 :)
- drivebyhooting
제시된 해법은 그냥 클러스터드 해시맵, 좋게 말하면 '지역성 민감(locality sensitive)' 방식인 것 같네요.
그래도 여전히 몇 자릿수만큼 더 나은 건 아닙니다.
- brcmthrowaway
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
이걸 2026년 버전으로 다시 쓴 사람 있나요?