대용량 CLOB 데이터 처리와 Swap Memory: 서버 중단

대용량 텍스트 데이터를 다루는 CLOB(Character Large Object) 타입은 설계와 운영 단계에서 세심한 주의를 요구한다. 최근 실무에서 CLOB 데이터를 대량으로 삽입하던 중 서버가 응답 불능 상태에 빠진 사례를 바탕으로, DB와 OS 레벨에서 발생하는 병목 현상을 분석해 본다.

1. CLOB 처리가 유발하는 DB 내부의 부하

일반적인 데이터 타입과 달리 CLOB은 데이터의 크기 자체가 커서 DB가 처리하는 방식부터 다르다. 테이블의 행(Row) 안에 저장되지 않고 별도의 LOB 세그먼트에 기록되는데, 이 과정에서 두 가지 큰 부하가 발생한다.

• I/O 폭발: 데이터가 저장될 때마다 테이블과 LOB 저장소라는 두 군데에 쓰기 작업이 일어난다.
• 로깅(Logging)의 늪: 데이터 크기에 비례해 Redo/Undo 로그가 기하급수적으로 쌓이면서 디스크 쓰기 속도가 처리를 따라가지 못하는 병목이 생긴다.

2. 결정적 원인: 메모리 설정 부재와 스왑(Swap)의 습격

이번 장애의 가장 핵심적인 원인은 물리 메모리 고갈에 따른 스왑 메모리(Swap Memory) 전이였다.

보통 DB에서 LOB 전용 캐시 영역을 별도로 설정하지 않으면, 대용량 데이터는 일반 데이터들이 상주해야 할 Buffer Cache 영역을 침범한다. 이른바 '캐시 오염(Cache Pollution)'이 발생하면서 정작 서비스에 필요한 데이터들이 메모리에서 쫓겨나고, 시스템은 부족한 메모리를 메꾸기 위해 디스크의 일부인 스왑 영역을 끌어다 쓰기 시작한다.

문제는 여기서 터진다. RAM보다 수천 배 느린 디스크(Swap)에 메모리 연산을 맡기는 순간, CPU는 데이터를 기다리는 iowait 상태에 빠지며 모든 프로세스가 멈춘 듯한 '프리징' 현상이 나타나는 것이다.

3. 데이터 아키텍트(DA)의 최적화 제언

이러한 리스크를 방지하기 위해 대용량 처리를 앞두고 있다면 다음과 같은 전략적 접근이 필요하다.

• Direct Path Write 유도: 버퍼 캐시를 거치지 않고 디스크에 직접 쓰는 APPEND 방식 등을 활용해 메모리 간섭을 원천 차단해야 한다.
• LOB 세그먼트 최적화: NOCACHE 옵션을 통해 불필요한 메모리 점유를 막고, 데이터 유실 리스크를 감당할 수 있는 범위 내에서 NOLOGGING을 검토하여 쓰기 속도를 확보한다.
• OS 레벨의 방어선: 리눅스 환경이라면 HugePages 설정을 통해 주요 DB 메모리 영역이 스왑으로 빠지지 않도록 고정하는 물리적 조치가 병행되어야 한다.