콘텐츠로 이동

디스크 가득 참 / 데이터베이스 무한 증가

박스의 디스크가 부족해지고, 관측성 데이터베이스 파일이 보유해야 할 데이터량에 비해 거대해 집니다 — 예를 들어 실제 보존된 예측값은 약 1 GB뿐인데 디스크에서는 수십 GB를 차지합니다. 오래된 행을 삭제(또는 보존 기간 단축)해도 파일이 줄어들지 않습니다.

원인: 오래된 행은 일정에 따라 삭제되지만, 증분 auto-vacuum 없이 생성된 데이터베이스에서는 해제된 페이지가 내부 free-list에 보관되어 운영체제로 결코 반환되지 않습니다. 파일은 영원히 최고 수위에 머뭅니다.

백엔드 컨테이너 내부에서 데이터베이스 파일 크기를 예상 실제 크기와 비교해 확인하세요:

Terminal window
docker compose -f docker-compose.release.yml exec backend \
sh -c 'ls -lh /data/aiboard.db'

보존 윈도우가 보유해야 할 데이터량보다 파일이 몇 배나 크다면(며칠치 예측값에 대해 수 GB 파일), free-list 비대화 상태입니다. 한 번의 고속 쓰기 버스트가 파일을 정상 상태 크기보다 훨씬 부풀릴 수 있습니다.

현재 릴리스는 각 보존 스윕 후 공간을 자동으로 회수하므로, 정상 박스는 스스로 교정됩니다. 해당 동작이 적용되기 전에 비대해진 데이터베이스는 일회성 회수가 필요합니다.

  1. 회수 중 데이터베이스에 쓰기가 발생하지 않도록 백엔드를 중지합니다:

    Terminal window
    docker compose -f docker-compose.release.yml stop backend
  2. 데이터베이스 파일에 대해 일회성 회수를 실행합니다. 이는 파일을 증분 auto-vacuum으로 변환하고 압축하여 free-list 페이지를 OS로 반환합니다:

    Terminal window
    docker compose -f docker-compose.release.yml run --rm --entrypoint sh backend -c \
    'sqlite3 /data/aiboard.db "PRAGMA auto_vacuum=INCREMENTAL; VACUUM;"'
  3. 파일이 줄었고 데이터가 온전한지 검증합니다:

    Terminal window
    docker compose -f docker-compose.release.yml run --rm --entrypoint sh backend -c \
    'ls -lh /data/aiboard.db; sqlite3 /data/aiboard.db "PRAGMA integrity_check;"'
    # 훨씬 작은 파일과 다음을 예상: ok
  4. 백엔드를 다시 시작합니다:

    Terminal window
    docker compose -f docker-compose.release.yml start backend
  • 보존 기간을 제한하세요. 보존 윈도우(InferenceObservability:RetentionDays, 기본 3일)는 일정에 따라 오래된 예측 행을 삭제하고, 삭제 후 회수가 해제된 페이지를 디스크로 반환하여 파일을 가볍게 유지합니다.
  • 버스트 가드로 행 개수를 제한하세요. InferenceObservability:MaxRows(기본 5,000,000)는 시간 윈도우 안에서도 최신 N개 행으로 잘라내므로, 갑작스러운 고속 급증이 시간 기반 스윕이 실행되기 전에 디스크를 채우지 못하게 합니다. 박스의 디스크가 제한적이라면 이 값을 낮추세요.
  • 처리량/스텁 테스트에 주의하세요. 고속 쓰기 버스트(예: 센서 파이프라인 처리량 테스트)가 애초에 파일을 부풀리는 원인입니다. 프로덕션 박스의 영구 저장소에 대해 고속 테스트를 켜둔 채로 두지 마세요.