출력된 결과를 보니 시스템 마비의 진짜 주범인 병목 구간 이 완벽하게 식별되었습니다. 출력에 등장하는 무수한 hello 명령어들은 드라이버나 에이전트가 연결 상태를 유지하기 위해 최대 10초까지 대기(maxAwaitTimeMS: 10000)하는 지극히 정상적인 커넥션 핑(Ping) 작업입니다. 진짜 문제는 OpID 229번 작업 입니다. 이 단 하나의 작업이 전체 MongoDB의 락(Lock)을 쥐고 시스템을 마비시키고 있습니다. 1. 핵심 문제 분석 (OpID: 229) JavaScript OpID : 229 명령어 타입 : remove 대상 네임스페이스 (DB.Collection) : miho.ingest_data 실행 시간 (ms) : 61458.924 <-- 무려 61 초째 실행 중 실행 중인 쿼리 내용 : { q : { kind : 'profile' , ts : { '$lt' : 1783877400 } }, limit : 0 } 왜 시스템이 마비되고 있는가? 오래된 데이터 대량 삭제 (remove + limit: 0): miho.ingest_data 컬렉션에서 kind: 'profile'이면서 타임스탬프(ts)가 특정 시점 이전인 데이터를 한 번에 전부(limit: 0) 지우고 있습니다. 인덱스 누락 또는 스캔 과부하: 데이터 삭제(Delete)를 하려면 먼저 삭제할 대상을 찾아야 합니다. 현재 kind 필드와 ts 필드가 결합된 인덱스가 없거나 부실하여, 수천만 건에 달할 수 있는 전체 데이터를 풀 스캔하며 지우고 있습니다. ZFS I/O 및 스레드 병목 유발: 대량 삭제 연산은 디스크에 엄청난 쓰기/수정 부하를 주며 WiredTiger 캐시를 점유합니다. 앞서 top에서 본 mongod 스레드 수십 개가 일제히 RUN 상태로 치솟고 ZFS I/O 대기(zio->i)가 발생한 직접적인 원인이 바로 이 61초 넘게 붙잡혀 있는 삭제 작업 때문입니다. 2. 부하를 즉시 해결하기 위한 단계별 조치 방안 [1단계] 즉시 부하를 끄기 위한 응급 처치 (Kill Op) 현재 61초 이상 슬롯을 독점하고 있는 삭제 작업을 강제로 종료시켜 CPU와 ZFS의 숨통을 틔워야 합니다. 관리자 쉘 상태 그대로 아래 명령어를 누락 없이 입력해 주세요. JavaScript db.killOp( 229 ); 명령을 실행하면 해당 쓰기 락이 해제되면서 치솟았던 top의 CPU 로드와 대기 큐가 급격히 떨어지기 시작할 것입니다. [2단계] 근본적인 해결책: 복합 인덱스(Compound Index) 생성 해당 오래된 데이터 정리 작업(데이터 로테이션/클린업 데몬)은 앞으로도 주기적으로 실행될 것입니다. 이 작업이 실행될 때 풀 스캔을 하지 않고 즉시 대상만 낚아채서 지울 수 있도록 kind와 ts 필드에 대한 복합 인덱스 를 반드시 생성해 주어야 합니다. 우선 miho 데이터베이스로 이동한 뒤 인덱스를 생성합니다. JavaScript // 1. 해당 DB로 이동 use miho; // 2. 부하를 막기 위해 백그라운드로 인덱스 생성 (MongoDB 4.2 이상은 기본이 non-blocking입니다) db.ingest_data.createIndex({ kind : 1 , ts : 1 }); [3단계] 소스 코드 및 수집 정책 보완 (★중요) 인덱스를 걸어두더라도 limit: 0으로 수백만 건을 한 번에 지우면 순간적인 쓰기 부하와 트랜잭션 락은 피할 수 없습니다. 데이터를 지우는 주기적인 클린업 데몬 로직 소스 코드가 있다면, 한 번에 다 지우지 말고 쪼개서 지우도록(Chuncking) 변경하는 것이 안전합니다. 예를 들어 limit를 1,000~5,000건 정도로 주어 루프를 돌리며 지우거나, 지우는 주기 자체를 더 자주 실행되도록 좁혀서 한 번에 삭제되는 데이터 총량을 최소화해야 시스템이 항상 부드럽게 작동합니다.