Si ZimaOS 1.6.2 entra en un bucle de reinicios después de una operación con una enorme cantidad de archivos y icewhale-files o icewhale-files-backup consume varios gigabytes de RAM, actualiza a ZimaOS 1.7.1 o una versión posterior antes de aplicar máscaras permanentes a los servicios. ZimaOS 1.7.1 solucionó oficialmente el uso anómalo de memoria en determinados escenarios de operaciones con archivos.
El informe de origen sigue siendo valioso porque documenta claramente la cadena de fallos: se copiaron aproximadamente 749.000 archivos, los servicios de archivos llegaron a consumir unos 6 GB combinados en una máquina con 7,5 GB de RAM, el espacio de intercambio alcanzó casi el 100 % y el servidor se reiniciaba cada 9–10 minutos. Enmascarar los servicios detuvo el bucle, pero también desactivó la aplicación web Files y el servicio de copias de seguridad.
Reconocer el patrón de saturación de memoria
Las señales habituales incluyen:
- la RAM casi agotada;
- el espacio de intercambio casi lleno;
-
icewhale-filesentre los procesos que más memoria consumen; - una espera de E/S muy elevada o bloqueos aparentes del sistema;
- reinicios repetidos similares a los provocados por un watchdog después de operaciones con un gran número de archivos.
Paso 1: Actualizar a ZimaOS 1.7.1 o una versión posterior
Las notas de la versión oficiales de ZimaOS 1.7.1 indican explícitamente una solución para el uso anómalo de memoria en escenarios de operaciones con archivos.
Esa es la solución principal actual. La solución alternativa de la versión 1.6.2 no debería ser tu configuración habitual en 2026.
Paso 2: Medir la RAM y el espacio de intercambio
free -h
ps aux --sort=-%mem | head
swapon --showConfirma si los servicios de archivos son realmente responsables antes de desactivar nada.
Paso 3: Comprobar los reinicios recientes
journalctl --list-bootsUn intervalo repetitivo puede ayudar a distinguir el comportamiento del watchdog o de los reinicios de las pérdidas de alimentación aleatorias.
Detención de emergencia en un sistema antiguo con la versión 1.6.2
Si el servidor no puede permanecer activo el tiempo suficiente para actualizar, el usuario de origen lo estabilizó con:
sudo systemctl detener icewhale-files.service icewhale-files-backup.service
sudo systemctl enmascarar icewhale-files.service icewhale-files-backup.serviceEsta es una medida de recuperación de emergencia. Desactiva funciones nativas importantes. Después de actualizar, elimina las máscaras y prueba los servicios actuales con normalidad.
Desmarcar después de la recuperación
sudo systemctl desmarcar icewhale-files.service icewhale-files-backup.service
sudo systemctl iniciar icewhale-files.service icewhale-files-backup.serviceHazlo únicamente después de que el sistema esté en una versión corregida/actual y tengas suficiente estabilidad para observar el comportamiento de la memoria.
Una gran cantidad de archivos no es lo mismo que un archivo de gran tamaño
749.000 archivos pequeños pueden sobrecargar los metadatos y la indexación mucho más que un solo vídeo de 67 GB. Al reproducir o informar del problema, incluye tanto los bytes totales como la cantidad de archivos.
NTFS/FUSE y muchos contenedores aumentan la presión
La máquina de origen también ejecutaba unos 38 contenedores y varios volúmenes NTFS mediante ntfs-3g. Esas condiciones son contexto, no causas demostradas. Evita convertirlas en la causa raíz cuando el aumento de memoria observado se produjo en los servicios de archivos de IceWhale.
No añadas un MemoryMax arbitrario como primera solución actual
El autor original sugirió systemd MemoryMax= como mejora del producto. En una versión actual, limitar artificialmente el servicio puede crear nuevos fallos de indexación o de copias de seguridad si la carga de trabajo realmente necesita memoria.
Actualiza primero y luego mide. Aplica límites al servicio únicamente cuando comprendas el compromiso.
Mantén AppData fuera de la pequeña unidad del sistema
La saturación de memoria puede generar una gran cantidad de E/S temporal. La guía de almacenamiento de aplicaciones de ZimaOS actual recomienda mover AppData al almacenamiento principal.
La guía de solución de problemas de rendimiento ofrece una lista de comprobación más amplia de recursos.
Preguntas frecuentes
¿ZimaOS 1.7.1 solucionó este error de memoria?
Solucionó oficialmente el uso anómalo de memoria en ciertos escenarios de operaciones con archivos, lo que coincide directamente con el patrón de fallo original.
¿Debería enmascarar icewhale-files permanentemente?
No. El enmascaramiento fue una solución de emergencia que deshabilita las funciones Archivos y Copias de seguridad.
¿Por qué el swap empeoró el servidor?
Cuando se agota la RAM, la paginación agresiva puede generar una gran cantidad de E/S de disco y bloqueos prolongados, especialmente mientras los servicios de archivos ya están escaneando o copiando cantidades enormes de archivos.
¿Qué pruebas debería recopilar si sigue ocurriendo?
Versión de ZimaOS, cantidad de archivos, tamaño transferido, estado de la RAM/swap, procesos que más memoria consumen, tipos de montaje/sistema de archivos y marcas de tiempo de arranque/reinicio.
