ZimaOS 1.6.2에서 대규모 파일 작업 후 재부팅 루프가 발생하고 icewhale-files 또는 icewhale-files-backup이 수 기가바이트의 RAM을 사용한다면, 영구적인 서비스 마스크를 적용하기 전에 ZimaOS 1.7.1 이상으로 업데이트하세요. ZimaOS 1.7.1은 특정 파일 작업 시나리오에서 발생하는 비정상적인 메모리 사용량을 공식적으로 수정했습니다.
원본 제보는 장애 발생 과정을 명확히 기록하고 있어 여전히 유용합니다. 약 749,000개의 파일이 복사되었고, 7.5GB RAM 시스템에서 파일 서비스의 메모리 사용량이 합쳐서 약 6GB까지 증가했으며, 스왑이 거의 100%에 도달한 후 서버가 9~10분마다 재부팅되었습니다. 서비스를 마스킹하면 반복 재부팅은 중단되지만 Files 웹 앱과 Backup 서비스도 비활성화됩니다.
메모리 고갈 패턴 파악
일반적인 징후는 다음과 같습니다.
- RAM이 거의 소진됨
- 스왑이 거의 가득 참
-
icewhale-files메모리 사용량 상위 프로세스에 포함됨 - 매우 높은 I/O 대기 또는 명백한 시스템 멈춤
- 대량의 파일 수 작업 후 워치독과 유사한 재부팅이 반복됩니다.
1단계: ZimaOS 1.7.1 이상으로 업데이트
공식 ZimaOS 1.7.1 릴리스 노트에는 파일 작업 시나리오에서 발생하는 비정상적인 메모리 사용량에 대한 수정 사항이 명시되어 있습니다.
이것이 현재의 주요 해결 방법입니다. 1.6.2 우회 방법을 2026년의 일반적인 구성으로 사용해서는 안 됩니다.
2단계: RAM 및 스왑 측정
free -h
ps aux --sort=-%mem | head
swapon --show무언가를 비활성화하기 전에 실제로 파일 서비스가 원인인지 확인하세요.
3단계: 최근 재부팅 확인
journalctl --list-boots반복되는 간격은 워치독 또는 재설정 동작과 무작위 정전 현상을 구분하는 데 도움이 될 수 있습니다.
구버전 1.6.2 시스템에서의 긴급 중지
업데이트를 완료할 만큼 서버가 오랫동안 실행 상태를 유지하지 못한다면, 제보자는 다음 방법으로 서버를 안정화했습니다.
sudo systemctl stop icewhale-files.service icewhale-files-backup.service
sudo systemctl mask icewhale-files.service icewhale-files-backup.service이는 긴급 복구 방법입니다. 중요한 기본 기능이 비활성화됩니다. 업데이트 후 마스크를 제거하고 현재 서비스를 정상적으로 테스트하세요.
복구 후 마스크 해제
sudo systemctl unmask icewhale-files.service icewhale-files-backup.service
sudo systemctl start icewhale-files.service icewhale-files-backup.service시스템이 수정된 최신 릴리스로 업데이트되고 메모리 동작을 관찰할 수 있을 만큼 안정성이 확보된 후에만 이 작업을 수행하세요.
파일 수가 많은 것과 파일 크기가 큰 것은 다릅니다
67GB짜리 동영상 하나보다 작은 파일 749,000개가 메타데이터와 인덱싱에 훨씬 더 큰 부담을 줄 수 있습니다. 문제를 재현하거나 보고할 때는 전체 바이트 수와 파일 수를 모두 포함하세요.
NTFS/FUSE 및 다수의 컨테이너도 부하를 증가시킵니다
해당 소스 시스템에서는 약 38개의 컨테이너와 여러 NTFS 볼륨도 실행 중이었습니다. ntfs-3g. 이러한 조건은 맥락일 뿐 입증된 원인은 아닙니다. 관찰된 메모리 증가가 IceWhale 파일 서비스에서 발생한 경우, 이를 근본 원인으로 단정하지 마세요.
현재 첫 번째 해결책으로 무작위 MemoryMax를 추가하지 마세요
소스 작성자는 systemd를 제안했습니다. MemoryMax= 제품 개선 사항으로서 적용된 것입니다. 최신 버전에서는 서비스 용량을 인위적으로 제한하면 작업에 실제로 메모리가 필요한 경우 새로운 인덱싱 또는 백업 오류가 발생할 수 있습니다.
먼저 업데이트한 다음 측정하세요. 절충점을 이해한 경우에만 서비스 제한을 적용하세요.
작은 시스템 드라이브에 AppData를 저장하지 마세요
메모리 스래싱은 일시적인 I/O를 크게 증가시킬 수 있습니다. 최신 ZimaOS 앱 저장소 가이드에서는 AppData를 주 저장소로 옮길 것을 권장합니다.
성능 문제 해결 가이드에서 더 폭넓은 리소스 점검 목록을 제공합니다.
자주 묻는 질문
ZimaOS 1.7.1에서 이 메모리 버그가 해결되었나요?
특정 파일 작업 시나리오에서 발생하는 비정상적인 메모리 사용을 공식적으로 해결했으며, 이는 원래 문제의 패턴과 직접적으로 일치합니다.
icewhale-files를 영구적으로 마스킹해야 하나요?
아니요. 마스킹은 Files 및 Backup 기능을 비활성화하는 긴급 우회 방법입니다.
스왑을 사용하니 서버 상태가 왜 더 나빠졌나요?
RAM이 고갈되면 공격적인 페이징으로 인해 디스크 I/O가 급증하고 오랜 시간 멈출 수 있습니다. 특히 파일 서비스가 이미 매우 많은 파일을 검사하거나 복사하는 중이라면 더욱 그렇습니다.
그래도 문제가 계속 발생한다면 어떤 증거를 수집해야 하나요?
ZimaOS 버전, 파일 수, 전송 크기, RAM/스왑 상태, 메모리를 가장 많이 사용하는 프로세스, 마운트/파일 시스템 유형, 부팅/재부팅 시각입니다.
