Het oorspronkelijke gedrag met hoge CPU-belasting was niet simpelweg “normale indexering die eindeloos kan doorgaan”. Na een grote overdracht, searchd bleef urenlang op 100% CPU draaien — en sommige gebruikers meldden meerdere dagen — waardoor de systeemtemperatuur steeg en ze moesten kiezen tussen het stoppen van de zoekfunctie of de CPU bezet laten.
IceWhale gaf later een precieze verklaring: een incidenteel randgeval in de pagineringslogica kon het langdurige CPU-probleem veroorzaken. Dit werd opgelost/geoptimaliseerd in ZimaOS 1.3.2-beta2. Dezelfde update voegde het inklappen van de zoekengine na een periode van inactiviteit toe, hield de indexering van bestandsnamen nauwkeurig en real-time en verplaatste de indexering van bestandsinhoud naar middernacht, met lager resourcegebruik. De huidige documentatie over ZimaOS Search is verder geëvolueerd, met expliciete throttling en veel lagere aantallen voor inactief geheugen- en servicegebruik.
searchd de CPU bleef domineren nadat de overdracht al was voltooid.Zoeken vereist een index
Zima-Giorgio legde aanvankelijk uit dat de zoekfunctie van Bestanden bestanden moet indexeren. Dat deel klopte, maar het verklaarde niet waarom de CPU ongewoon lang maximaal belast bleef.
IceWhale identificeerde later een randgeval in de pagineringslogica
Op 11 februari 2025 zei orca-zhang dat het langdurige CPU-probleem soms kon worden veroorzaakt door een fout in de pagineringslogica en dat dit in 1.3.2-beta2 was opgelost en geoptimaliseerd.
Dit is de meest overtuigende conclusie uit de bronnen en moet de eerdere vage uitleg “het is aan het indexeren” vervangen.
1.3.2 voegde het inklappen van de inactieve zoekservice toe
IceWhale zei dat wanneer zoeken niet nodig was, searchd zou na ongeveer drie minuten inactiviteit worden vrijgegeven, waardoor alleen de lichtgewicht zimaos-search service met minder dan 100 MB geheugen en ongeveer 0–1% CPU.
Inhoudsindexering werd verplaatst naar middernacht
Hetzelfde antwoord maakte onderscheid tussen twee taken:
- bestandsnamenindex — zo nauwkeurig en real-time mogelijk bijgehouden;
- bestandsinhoudsindex — uitgesteld tot middernacht en uitgevoerd met laag resourcegebruik.
Dat onderscheid bestaat nog steeds in de huidige zoekarchitectuur.
De huidige zoekfunctie van ZimaOS voegt expliciete resource-limieten toe
De huidige documentatie van IceWhale beschrijft:
- real-time monitoring van bestandswijzigingen en indexering van bestandsnamen;
- inhoudsindexering om middernacht;
- maximaal 100.000 documenten per verwerkingstype/sessie;
- maximaal vijf minuten verwerkingstijd per type;
- beveiliging met schrijfbarrières tegen CPU-pieken;
- service-/geheugenfolding na inactiviteit.
Gebruik de huidige ZimaOS Search-architectuur.
Search kon vanaf ZimaOS 1.3.2 worden uitgeschakeld
orca-zhang zei dat de persistentie was toegevoegd aan /etc in 1.3.2 konden gebruikers die Search niet nodig hadden het volgende uitvoeren:
systemctl disable zimaos-searchDoor Search te stoppen/uit te schakelen, meldt Files zoeken dat de service niet beschikbaar is. Huidige gebruikers moeten eerst het huidige zoekgedrag controleren voordat ze een kernservice uitsluitend vanwege een historische bug uitschakelen.
De screenshot met “100% vol” van /dev/root betrof een ander probleem
Een andere deelnemer merkte op /dev/root gaf 100% gebruik aan en probeerde de partitie te vergroten. IceWhale legde uit dat deze alleen-lezen SquashFS-rootweergave bewust zo is ontworpen voor systeemintegriteit en niet moet worden behandeld als een conventionele schrijfbare rootpartitie die vrije ruimte nodig heeft.
Wijzig of verwijder geen ZimaOS-systeempartities omdat de SquashFS-image vol lijkt te zijn.
Als Search veel CPU gebruikt op het huidige ZimaOS
- bevestig dat het systeem de huidige stabiele versie van ZimaOS gebruikt;
- controleer of er zojuist een groot aantal bestanden is geïmporteerd;
- laat het gedocumenteerde indexeringsvenster voltooien;
- controleer of het CPU-gebruik daalt na de inactieve periode van de service;
- verzamel actuele
zimaos-searchlogboeken als de CPU ruim na het verwachte tijdvenster hoog blijft.
Veelgestelde vragen over hoog CPU-gebruik van searchd
Werd 100% CPU-gebruik gedurende meerdere dagen als normaal beschouwd?
Nee. IceWhale ontdekte later een randgeval in de pagineringslogica en verholp dit in 1.3.2-beta2.
Wanneer indexeert het huidige ZimaOS de inhoud?
Volgens de huidige documentatie wordt de inhoudsindexering tijdens daluren om middernacht verwerkt, terwijl wijzigingen in bestandsnamen in realtime worden geïndexeerd.
Betekent /dev/root op 100% dat de systeemschijf geen vrije ruimte meer heeft?
Niet in de broncase. IceWhale legde uit dat de SquashFS-weergave van de systeemroot bewust alleen-lezen is en naar verwachting vol lijkt.
