Il comportamento originale di utilizzo elevato della CPU non era semplicemente “l'indicizzazione normale può durare all'infinito”. Dopo un trasferimento di grandi dimensioni, searchd rimaneva al 100% della CPU per ore — e alcuni utenti hanno segnalato diversi giorni — aumentando la temperatura del sistema e costringendoli a scegliere tra interrompere la ricerca o lasciare la CPU occupata.
In seguito IceWhale ha fornito una spiegazione precisa: un caso limite occasionale nella logica di paginazione poteva causare il problema della CPU elevata protratta. È stato risolto e ottimizzato in ZimaOS 1.3.2-beta2. Lo stesso aggiornamento ha aggiunto la sospensione del motore di ricerca dopo un periodo di inattività, ha mantenuto l'indicizzazione dei nomi dei file accurata e in tempo reale e ha spostato l'indicizzazione dei contenuti dei file a mezzanotte, con un utilizzo ridotto delle risorse. La documentazione attuale della ricerca di ZimaOS si è ulteriormente evoluta, con una limitazione esplicita delle risorse e valori molto più bassi per la memoria in stato di inattività e il numero di servizi.
searchd utilizzando la maggior parte della CPU dopo che il trasferimento era già stato completato.La ricerca richiede un indice
Inizialmente Zima-Giorgio ha spiegato che la funzione di ricerca di Files deve indicizzare i file. Questa parte era corretta, ma non spiegava perché la CPU rimanesse al massimo per periodi insolitamente lunghi.
In seguito IceWhale ha identificato un caso limite nella logica di paginazione
L'11 febbraio 2025, orca-zhang ha dichiarato che il problema della CPU elevata poteva occasionalmente essere causato da un errore nella logica di paginazione e che il problema era stato risolto e ottimizzato nella versione 1.3.2-beta2.
Questa è la conclusione più solida della fonte e dovrebbe sostituire la precedente spiegazione vaga “sta indicizzando”.
La versione 1.3.2 ha aggiunto la sospensione del servizio di ricerca inattivo
IceWhale ha dichiarato che, quando la ricerca non era necessaria, searchd sarebbe stato rilasciato dopo circa tre minuti di inattività, lasciando solo il leggero zimaos-search servizio con meno di 100 MB di memoria e circa 0–1% di CPU.
L'indicizzazione dei contenuti è stata spostata a mezzanotte
La stessa risposta separava due attività:
- indice dei nomi dei file — mantenuto il più accurato e aggiornato possibile in tempo reale;
- indice del contenuto dei file — rimandato a mezzanotte ed eseguito con un basso utilizzo delle risorse.
Questa distinzione esiste ancora nell'architettura di ricerca attuale.
La ricerca attuale di ZimaOS aggiunge limiti espliciti alle risorse
La documentazione attuale di IceWhale descrive:
- monitoraggio in tempo reale delle modifiche ai file e indicizzazione dei nomi dei file;
- indicizzazione dei contenuti a mezzanotte;
- massimo 100.000 documenti per tipo di elaborazione/sessione;
- tempo massimo di elaborazione di cinque minuti per tipo;
- protezione con barriera di scrittura contro i picchi della CPU;
- riduzione del servizio/della memoria dopo l'inattività.
Utilizza l'architettura attuale della ricerca di ZimaOS.
La ricerca poteva essere disabilitata a partire da ZimaOS 1.3.2
orca-zhang ha dichiarato che la persistenza aggiunta a /etc nella versione 1.3.2 consentiva agli utenti che non avevano bisogno della ricerca di eseguire:
systemctl disable zimaos-searchArrestare/disabilitare la ricerca significa che la ricerca in File segnalerà che il servizio non è disponibile. Gli utenti attuali dovrebbero prima verificare il comportamento attuale della ricerca prima di disabilitare un servizio fondamentale soltanto a causa di un bug storico.
Lo screenshot di “/dev/root pieno al 100%” riguardava un problema diverso
Un altro partecipante ha notato /dev/root risultava utilizzata al 100% e ha provato ad ampliarla. IceWhale ha spiegato che questa rappresentazione della radice SquashFS in sola lettura è intenzionale per garantire l'integrità del sistema e non deve essere trattata come una normale partizione radice scrivibile che necessita di spazio libero.
Non ridimensionare né eliminare le partizioni di sistema di ZimaOS perché l'immagine SquashFS risulta piena.
Se la ricerca utilizza molta CPU nell'attuale ZimaOS
- confermare che il sistema utilizzi la versione stabile più recente di ZimaOS;
- verificare se è stata appena importata una grande quantità di file;
- lasciare terminare la finestra di indicizzazione documentata;
- monitorare se l'utilizzo della CPU diminuisce dopo il periodo di inattività del servizio;
- raccogliere i dati attuali
zimaos-searchi log se la CPU rimane elevata ben oltre l'intervallo previsto.
FAQ sulla CPU elevata di searchd
Era considerato normale un utilizzo della CPU al 100% per più giorni?
No. In seguito, IceWhale ha individuato un caso limite nella logica di paginazione e lo ha corretto nella versione 1.3.2-beta2.
Quando esegue l'indicizzazione dei contenuti l'attuale ZimaOS?
La documentazione attuale indica che l'indicizzazione dei contenuti viene eseguita durante le ore di minore attività, a mezzanotte, mentre le modifiche ai nomi dei file vengono indicizzate in tempo reale.
Il fatto che /dev/root sia al 100% significa che il disco di sistema è privo di spazio libero?
Non si trovava nel caso di partenza. IceWhale ha spiegato che la rappresentazione della radice di sistema SquashFS è intenzionalmente di sola lettura e dovrebbe risultare piena.
