El comportamiento original de uso elevado de la CPU no era simplemente que «la indexación normal puede ejecutarse indefinidamente». Después de una transferencia grande, searchd se mantuvo al 100 % de CPU durante horas —y algunos usuarios informaron de varios días—, lo que elevó la temperatura del sistema y les obligó a elegir entre detener la búsqueda o dejar la CPU ocupada.
Más tarde, IceWhale ofreció una explicación precisa: un caso límite ocasional en la lógica de paginación podía causar el problema de uso prolongado de la CPU. Se corrigió y optimizó en ZimaOS 1.3.2-beta2. La misma actualización añadió el plegado del motor de búsqueda tras un período de inactividad, mantuvo la indexación de nombres de archivo precisa y en tiempo real, y trasladó la indexación del contenido de los archivos a medianoche con un uso reducido de recursos. La documentación actual de Búsqueda de ZimaOS ha evolucionado aún más, con una limitación explícita y cifras de memoria y servicios en reposo mucho menores.
searchd dominando la CPU después de que la transferencia ya se hubiera completado.La búsqueda requiere un índice
Zima-Giorgio explicó inicialmente que la función de búsqueda de Archivos necesita indexar los archivos. Esa parte era correcta, pero no explicaba por qué la CPU permanecía al máximo durante períodos inusualmente largos.
Más tarde, IceWhale identificó un caso límite en la lógica de paginación
El 11 de febrero de 2025, orca-zhang dijo que el problema de CPU prolongado podía deberse ocasionalmente a un error de lógica de paginación y que el problema se había corregido y optimizado en la versión 1.3.2-beta2.
Esta es la conclusión más sólida de la fuente y debería reemplazar la explicación vaga anterior de «está indexando».
Se añadió el plegado del servicio de búsqueda inactivo en la versión 1.3.2
IceWhale dijo que, cuando no se necesitaba la búsqueda, searchd se liberaría después de aproximadamente tres minutos de inactividad, dejando solo el servicio ligero zimaos-search servicio por debajo de 100 MB de memoria y alrededor del 0–1 % de CPU.
La indexación del contenido se trasladó a medianoche
La misma respuesta separó dos tareas:
- índice de nombres de archivo — se mantiene lo más preciso y actualizado posible en tiempo real;
- índice del contenido de los archivos — retrasado hasta medianoche y ejecutado con un uso reducido de recursos.
Esa distinción sigue existiendo en la arquitectura de búsqueda actual.
La búsqueda actual de ZimaOS añade límites de recursos explícitos
La documentación actual de IceWhale describe:
- monitorización en tiempo real de los cambios de archivos e indexación de nombres de archivo;
- indexación del contenido a medianoche;
- máximo de 100.000 documentos por tipo de procesamiento/sesión;
- máximo de cinco minutos de procesamiento por tipo;
- protección mediante barrera de escritura contra picos de CPU;
- plegado del servicio y la memoria tras un periodo de inactividad.
Usa la arquitectura actual de búsqueda de ZimaOS.
La búsqueda se podía desactivar desde ZimaOS 1.3.2
orca-zhang dijo que la persistencia añadida a /etc en la versión 1.3.2 permitía a los usuarios que no necesitaban la búsqueda ejecutar:
systemctl disable zimaos-searchDetener o desactivar la búsqueda hará que la búsqueda de Archivos indique que el servicio no está disponible. Los usuarios actuales deberían comprobar primero el funcionamiento actual de la búsqueda antes de desactivar un servicio esencial únicamente debido a un error histórico.
La captura de pantalla de «/dev/root al 100 %: lleno» correspondía a un problema diferente
Otro participante se dio cuenta /dev/root mostraba un uso del 100 % e intentó ampliarla. IceWhale explicó que esta representación de la raíz SquashFS de solo lectura es intencionada para garantizar la integridad del sistema y no debe tratarse como una partición raíz convencional con permisos de escritura que necesite espacio libre.
No cambie el tamaño ni elimine las particiones del sistema de ZimaOS porque la imagen SquashFS aparece llena.
Si la búsqueda utiliza mucha CPU en la versión actual de ZimaOS
- confirmar que el sistema utiliza la versión estable actual de ZimaOS;
- comprobar si se acaba de importar un archivo grande;
- permitir que finalice la ventana de indexación documentada;
- supervisar si el uso de la CPU disminuye después del periodo de inactividad del servicio;
- recopilar los datos actuales
zimaos-searchregistros si la CPU permanece alta mucho más allá del intervalo esperado.
Preguntas frecuentes sobre el uso elevado de CPU de searchd
¿Se consideraba normal que la CPU estuviera al 100 % durante varios días?
No. Posteriormente, IceWhale identificó un caso límite en la lógica de paginación y lo solucionó en la versión 1.3.2-beta2.
¿Cuándo realiza la indexación del contenido la versión actual de ZimaOS?
La documentación actual indica que la indexación del contenido se procesa durante las horas de menor actividad, a medianoche, mientras que los cambios en los nombres de archivo se indexan en tiempo real.
¿Que /dev/root esté al 100 % significa que el disco del sistema se ha quedado sin espacio libre?
No en el caso de origen. IceWhale explicó que la representación de la raíz del sistema SquashFS es intencionadamente de solo lectura y está diseñada para aparecer llena.
