커뮤니티 솔루션

대용량 파일 전송 후 ZimaOS searchd의 CPU 사용률이 100%까지 치솟는 문제: 1.3.2 수정 사항과 현재 검색 기능의 색인 일정 관리 방식

A January-February 2025 ZimaOS thread where searchd stayed at 100% CPU for hours or days after a large file transfer. IceWhale first explained that Files search required indexing, then identified an occasional pagination-logic corner case, fixed it in 1.3.2-beta2, added idle service folding, moved content indexing to midnight at low resource use, and documented how to disable search.

최초의 높은 CPU 사용량 문제는 단순히 “일반적인 인덱싱이 무한정 실행될 수 있다”는 문제가 아니었습니다. 대용량 파일을 전송한 뒤에도 searchd가 몇 시간 동안 CPU를 100% 사용했고, 일부 사용자는 며칠간 지속됐다고 보고했습니다. 이로 인해 시스템 온도가 상승했고, 사용자는 검색을 중단할지 아니면 CPU가 계속 바쁘게 돌아가도록 둘지 선택해야 했습니다.

IceWhale는 나중에 정확한 원인을 설명했습니다. 페이지 매김 로직에서 간혹 발생하는 특정 예외 상황 때문에 CPU 사용량이 장시간 높게 유지될 수 있다는 것이었습니다. 이 문제는 ZimaOS 1.3.2-beta2에서 수정 및 최적화되었습니다. 같은 업데이트에서 일정 시간 유휴 상태가 지속되면 검색 엔진을 통합하는 기능이 추가되었고, 파일 이름 인덱싱은 정확하고 실시간으로 유지되었으며, 파일 콘텐츠 인덱싱은 자정에 리소스 사용량을 낮춰 실행하도록 변경되었습니다. 최신 ZimaOS 검색 문서는 명시적인 부하 제한을 도입하고 유휴 시 메모리 사용량과 서비스 수를 훨씬 낮추는 등 더욱 발전했습니다.

대용량 파일 전송 후 searchd가 CPU를 100% 사용하는 ZimaOS 시스템 모니터
소스 모니터에는 파일 전송이 이미 완료된 후에도 searchd가 CPU를 계속 점유하는 모습이 표시됩니다.

검색에는 인덱스가 필요합니다

Zima-Giorgio는 처음에 파일 검색 기능이 파일을 인덱싱해야 한다고 설명했습니다. 이 부분은 맞았지만, CPU 사용량이 이례적으로 오랫동안 최고 수준을 유지한 이유는 설명하지 못했습니다.

IceWhale, 페이지 매김 로직의 특정 예외 상황을 나중에 확인

2025년 2월 11일, orca-zhang은 CPU 사용량이 장시간 높은 문제는 간혹 페이지 매김 로직 오류로 인해 발생할 수 있으며, 1.3.2-beta2에서 이 문제가 수정 및 최적화되었다고 밝혔습니다.

이는 가장 확실한 결론이며, 이전의 모호한 “인덱싱 중”이라는 설명을 대체해야 합니다.

1.3.2에서 유휴 검색 서비스 통합 기능 추가

IceWhale는 검색이 필요하지 않을 때 약 3분간 유휴 상태가 지속되면 searchd를 종료해, 메모리 사용량이 100MB 미만이고 CPU 사용량이 약 0~1%인 경량 zimaos-search 서비스만 남긴다고 밝혔습니다.

콘텐츠 인덱싱을 자정으로 이동

같은 답변에서는 두 가지 작업을 구분했습니다.

  • 파일 이름 인덱스 — 가능한 한 정확하고 실시간으로 유지합니다.
  • 파일 콘텐츠 인덱스 — 자정까지 미루고 리소스 사용량이 낮을 때 실행합니다.

현재 검색 아키텍처에도 이 구분은 여전히 존재합니다.

현재 IceWhale 문서에는 다음과 같이 나와 있습니다.

  • 실시간 파일 변경 모니터링 및 파일 이름 인덱싱;
  • 자정에 콘텐츠 인덱싱;
  • 처리 유형/세션당 최대 100,000개 문서;
  • 파일 형식별 처리 시간은 최대 5분입니다.
  • CPU 급증을 방지하는 쓰기 장벽 보호
  • 비활성 상태가 되면 서비스/메모리를 절전 상태로 전환합니다.

현재 ZimaOS Search 아키텍처를 사용하세요.

ZimaOS 1.3.2부터 검색 비활성화 가능

orca-zhang은 1.3.2에서 /etc에 추가된 지속성 설정 덕분에 검색이 필요 없는 사용자는 다음 명령을 실행할 수 있다고 말했습니다.

systemctl disable zimaos-search

search를 중지하거나 비활성화하면 Files 검색에서 서비스를 사용할 수 없다고 표시됩니다. 현재 사용자는 과거 버그를 이유로 핵심 서비스를 비활성화하기 전에 먼저 현재 검색 동작을 확인해야 합니다.

/dev/root가 '100% 꽉 참'으로 표시된 스크린샷은 다른 문제였습니다

다른 사용자는 /dev/root의 사용률이 100%로 표시되는 것을 보고 크기를 늘리려고 했습니다. IceWhale은 이 읽기 전용 SquashFS 루트 표현이 시스템 무결성을 위해 의도된 것이며, 여유 공간이 필요한 기존의 쓰기 가능한 루트 파티션처럼 취급해서는 안 된다고 설명했습니다.

SquashFS 이미지가 꽉 찬 것으로 표시된다는 이유로 ZimaOS 시스템 파티션의 크기를 조정하거나 삭제하지 마세요.

searchd의 CPU 사용률이 높았던 당시 시스템 CPU 부하, 저장 공간 및 설치된 앱을 보여주는 ZimaOS 대시보드
기본 읽기 전용 시스템 루트 구조는 설계대로 작동하고 있었지만, 시스템 수준에서는 검색으로 인한 높은 CPU 사용률이 확인되었습니다.

현재 ZimaOS에서 검색 CPU 사용률이 높은 경우

  1. 시스템이 최신 안정 버전 ZimaOS를 사용 중인지 확인하세요.
  2. 대용량 파일을 방금 가져왔는지 확인하세요.
  3. 문서에 안내된 색인 작업 시간을 마칠 때까지 기다리세요.
  4. 서비스 유휴 시간 이후 CPU 사용률이 떨어지는지 모니터링하세요.
  5. CPU 사용률이 예상 시간을 훨씬 넘어서도 높은 상태라면 현재 zimaos-search 로그를 수집하세요.

searchd CPU 사용률 높음 FAQ

CPU 사용률이 며칠 동안 100%인 것이 정상으로 여겨졌나요?

아닙니다. IceWhale은 이후 페이지네이션 로직의 예외 상황을 찾아내 1.3.2-beta2에서 수정했습니다.

현재 ZimaOS는 콘텐츠를 언제 색인하나요?

현재 문서에 따르면 콘텐츠 색인은 사용량이 적은 자정에 처리되고, 파일 이름 변경은 실시간으로 색인됩니다.

/dev/root가 100%라는 것은 시스템 디스크의 여유 공간이 없다는 뜻인가요?

소스 케이스에는 해당하지 않습니다. IceWhale은 SquashFS 시스템 루트 표현이 의도적으로 읽기 전용이며 꽉 찬 것처럼 보이는 것이 정상이라고 설명했습니다.