TrotVote
[IT 심층 분석]

고성능 NVMe SSD의 불시의 Timeout 에러와 PCIe 전원 관리 D3 상태 충돌 디버깅

김민준 · IT 시스템 엔지니어|
빅데이터를 실시간으로 인덱싱하는 사내 NoSQL 클러스터 노드들 중 특정 벤더의 최상급 NVMe SSD를 꽂은 랙에서만 간헐적으로 스토리지 연결이 툭툭 끊어지는 괴현상이 발생했습니다. 커널 dmesg 로그엔 오로지 "nvme: controller is down; will reset" 이라는 무미건조하고 폭력적인 텍스트만 한 줄 찍힌 채, 데이터베이스 프로세스가 I/O 행킹(Hanging) 상태에 빠져 전체 클러스터 동기화가 마비되곤 했습니다. 스토리지 제조사는 하드웨어 펌웨어 결함이 아니라고 발뺌했고, 팀의 분위기는 험악해져만 갔습니다. 디스크를 바꾸는 게 임시방편이었지만 저는 끝장 기조로 PCIe 버스의 패킷 로그 스니핑을 감행했습니다. 도무지 원인을 모르겠다는 막막함이 오히려 제 투쟁심을 불태웠습니다. 원인은 황당하게도 속도가 아니라 절전, 즉 전원 관리 충돌에 있었습니다. 최신 NVMe SSD와 리눅스 커널은 안 쓰는 디스크의 전력을 아끼기 위해 서로 ASPM(Active-State Power Management) 협상을 합니다. 디스크가 순간 I/O를 멈추고 아주 깊은 절전 상태인 D3로 진입했는데, 하필 메인보드의 PCIe 루트 콤플렉스와 커널 사이의 웨이크업 타이밍 규약이 안 맞아서 디스크가 제때 깨어나지 못하고 질식사해버린 것이었습니다. 트래픽이 밀려올 때 디스크는 아직 잠에서 덜 깬 상태였고, I/O 스케줄러는 응답 없음에 격분하여 그대로 타임아웃 도끼를 휘두르며 하드 리셋을 걸어버렸던 그 찰나의 부조리가 사건의 전말이었습니다. 저는 GRUB 부트로더 커널 파라미터로 잠입하여 pcie_aspm=off 와 nvme_core.default_ps_max_latency_us=0 값을 강제로 주입했습니다. 이 조치는 NVMe 디스크에게 "1원도 전력을 아끼지 말고 24시간 내내 최고 전투 태세(D0 상태)를 유지하라"는 잔인하지만 가장 확실한 족쇄였습니다. 서버의 전기 요금은 조금 상승했겠지만, 그 대가로 NoSQL 클러스터는 디스크 IOPS의 절대적 극강 성능을 타임아웃 없이 뿜어냈습니다. 하드웨어 스펙 시트에 쓰여있는 그럴싸한 전원 관리 기술들이 사실 커널 레벨의 실제 필드에서는 얼마나 불안정하고 파괴적인 지뢰가 될 수 있는지 배웠고, 엔지니어는 때론 효율성보다 단순 무식할 정도의 확실함을 택할 줄 알아야 한다는 아주 실전적인 교훈을 얻었습니다.