Det ursprungliga beteendet med hög CPU-användning var inte bara att ”normal indexering kan pågå för evigt”. Efter en stor överföring, searchd låg kvar på 100 % CPU i timmar – och vissa användare rapporterade flera dagar – vilket höjde systemtemperaturen och tvingade dem att välja mellan att stoppa sökningen eller låta CPU:n fortsätta arbeta.
IceWhale gav senare en exakt förklaring: ett specialfall i pagineringslogiken kunde ibland orsaka det långvariga CPU-problemet. Det åtgärdades och optimerades i ZimaOS 1.3.2-beta2. Samma uppdatering lade till att sökmotorn stängs ned efter inaktivitet, behöll korrekt indexering av filnamn i realtid och flyttade indexeringen av filinnehåll till midnatt med lägre resursanvändning. Den aktuella dokumentationen för ZimaOS Search har utvecklats ytterligare, med uttrycklig strypning och betydligt lägre minnesanvändning och färre aktiva tjänster vid inaktivitet.
searchd som belastade CPU:n mest efter att överföringen redan hade slutförts.Sökning kräver ett index
Zima-Giorgio förklarade först att filsökningsfunktionen behöver indexera filer. Den delen stämde, men förklarade inte varför CPU-användningen låg kvar på max ovanligt länge.
IceWhale identifierade senare ett specialfall i pagineringslogiken
Den 11 februari 2025 sade orca-zhang att det långvariga CPU-problemet ibland kunde orsakas av ett fel i pagineringslogiken och att problemet hade åtgärdats och optimerats i 1.3.2-beta2.
Detta är den starkaste slutsatsen från källorna och bör ersätta den tidigare vaga förklaringen ”den indexerar”.
1.3.2 lade till nedstängning av söktjänsten vid inaktivitet
IceWhale sade att när sökning inte behövdes, searchd skulle frigöras efter ungefär tre minuters inaktivitet, så att endast den lättviktiga zimaos-search tjänst under 100 MB minne och omkring 0–1 % CPU.
Innehållsindexeringen flyttades till midnatt
Samma svar skilde mellan två uppgifter:
- filnamnsindex – hålls så korrekt och uppdaterat i realtid som möjligt;
- filinnehållsindex – fördröjs till midnatt och körs med låg resursanvändning.
Den skillnaden finns fortfarande i den aktuella sökarkitekturen.
Aktuell ZimaOS-sökning lägger till uttryckliga resursbegränsningar
I aktuell dokumentation från IceWhale beskrivs:
- övervakning av filändringar i realtid och indexering av filnamn;
- innehållsindexering vid midnatt;
- högst 100 000 dokument per bearbetningstyp/session;
- högst fem minuters bearbetningstid per typ;
- skrivbarriärskydd mot CPU-toppar;
- tjänstens/minnets komprimering efter inaktivitet.
Använd den aktuella ZimaOS-sökarkitekturen.
Sökning kunde inaktiveras från och med ZimaOS 1.3.2
orca-zhang sade att den beständighet som lades till /etc i 1.3.2 kunde användare som inte behövde sökning köra:
systemctl disable zimaos-searchOm sökning stoppas/inaktiveras kommer filsökningen att rapportera att tjänsten inte är tillgänglig. Aktuella användare bör först kontrollera det aktuella sökbeteendet innan de inaktiverar en kärntjänst enbart på grund av ett historiskt fel.
Skärmbilden med ”100 % full” för /dev/root gällde ett annat problem
En annan deltagare lade märke till /dev/root visade 100 % användning och försökte utöka den. IceWhale förklarade att denna skrivskyddade SquashFS-rotrepresentation är avsiktlig för systemintegriteten och inte ska behandlas som en konventionell skrivbar rotpartition som behöver ledigt utrymme.
Ändra inte storlek på eller radera ZimaOS-systempartitioner eftersom SquashFS-avbildningen rapporteras som full.
Om sökningen använder mycket CPU i den aktuella versionen av ZimaOS
- bekräfta att systemet kör den aktuella stabila versionen av ZimaOS;
- kontrollera om en stor filimport nyligen har genomförts;
- låt det dokumenterade indexeringsintervallet slutföras;
- övervaka om CPU-användningen sjunker efter tjänstens inaktiva period;
- samla in aktuell
zimaos-searchloggar om CPU-användningen förblir hög långt efter det förväntade tidsintervallet.
FAQ om hög CPU-användning för searchd
Betraktades 100 % CPU-användning under flera dagar som normalt?
Nej. IceWhale identifierade senare ett specialfall i sidindelningslogiken och åtgärdade det i 1.3.2-beta2.
När utför nuvarande ZimaOS innehållsindexering?
Den aktuella dokumentationen anger att innehållsindexering utförs under lågtrafik kl. 00.00, medan ändringar av filnamn indexeras i realtid.
Betyder /dev/root på 100 % att systemdisken saknar ledigt utrymme?
Inte i källfallet. IceWhale förklarade att SquashFS-representationen av systemroten är skrivskyddad och förväntas visas som full.
