Community-Lösung

ZimaOS searchd bei 100 % CPU nach einer großen Dateiübertragung: Die Lösung in 1.3.2 und wie die aktuelle Suche die Indizierung plant

A January-February 2025 ZimaOS thread where searchd stayed at 100% CPU for hours or days after a large file transfer. IceWhale first explained that Files search required indexing, then identified an occasional pagination-logic corner case, fixed it in 1.3.2-beta2, added idle service folding, moved content indexing to midnight at low resource use, and documented how to disable search.

Das ursprüngliche Verhalten mit hoher CPU-Auslastung war nicht einfach darauf zurückzuführen, dass die normale Indizierung unbegrenzt laufen kann. Nach einer großen Übertragung searchd blieb stundenlang bei 100 % CPU – manche Nutzer berichteten sogar von mehreren Tagen –, wodurch die Systemtemperatur stieg und sie entweder die Suche stoppen oder die CPU weiter auslasten lassen mussten.

IceWhale lieferte später eine genaue Erklärung: Ein gelegentlicher Sonderfall in der Paginierungslogik konnte das lang anhaltende CPU-Problem verursachen. Er wurde in ZimaOS 1.3.2-beta2 behoben und optimiert. Dasselbe Update fügte das Zusammenlegen der Such-Engine nach einer Leerlaufzeit hinzu, hielt die Dateinamenindizierung aktuell und echtzeitnah und verlegte die Inhaltsindizierung von Dateien auf Mitternacht, mit geringerer Ressourcennutzung. Die aktuelle Dokumentation zur ZimaOS-Suche wurde inzwischen weiterentwickelt und enthält explizite Drosselungen sowie deutlich niedrigere Angaben zum Speicherverbrauch und zur Anzahl der Dienste im Leerlauf.

ZimaOS-Systemmonitor, der nach der Übertragung einer großen Datei eine CPU-Auslastung von 100 % durch searchd anzeigt
Der Quellmonitor zeigt searchd die CPU dominierte, nachdem die Übertragung bereits abgeschlossen war.

Die Suche benötigt einen Index

Zima-Giorgio erklärte zunächst, dass die Dateisuche Dateien indizieren müsse. Dieser Teil war korrekt, erklärte jedoch nicht, warum die CPU ungewöhnlich lange vollständig ausgelastet blieb.

IceWhale identifizierte später einen Sonderfall in der Paginierungslogik

Am 11. Februar 2025 erklärte orca-zhang, dass das lang anhaltende CPU-Problem gelegentlich durch einen Fehler in der Paginierungslogik verursacht werden konnte und in 1.3.2-beta2 behoben und optimiert wurde.

Dies ist die wichtigste Schlussfolgerung aus den Quellen und sollte die frühere vage Erklärung „es wird indiziert“ ersetzen.

1.3.2 fügte das Zusammenlegen des Suchdienstes im Leerlauf hinzu

IceWhale erklärte, dass der Dienst bei nicht benötigter Suche searchd sollte nach etwa drei Minuten Leerlaufzeit freigegeben werden, sodass nur der schlanke zimaos-search Dienst mit weniger als 100 MB Arbeitsspeicher und etwa 0–1 % CPU.

Die Inhaltsindizierung wurde auf Mitternacht verlegt

Dieselbe Antwort unterschied zwischen zwei Aufgaben:

  • Dateinamenindex – so aktuell und echtzeitnah wie möglich gehalten;
  • Dateiinhaltsindex – verzögert bis Mitternacht und mit geringer Ressourcennutzung ausgeführt.

Diese Unterscheidung besteht auch in der aktuellen Sucharchitektur weiterhin.

Die aktuelle Dokumentation von IceWhale beschreibt:

  • Echtzeitüberwachung von Dateiänderungen und Dateinamenindizierung;
  • Inhaltsindizierung um Mitternacht;
  • maximal 100.000 Dokumente pro Verarbeitungstyp/Sitzung;
  • maximal fünf Minuten Verarbeitungszeit pro Typ;
  • Schutz durch Schreibbarrieren gegen CPU-Spitzen;
  • Zusammenfassen von Dienst und Speicher nach Inaktivität.

Verwenden Sie die aktuelle ZimaOS-Sucharchitektur.

Die Suche konnte ab ZimaOS 1.3.2 deaktiviert werden

orca-zhang erklärte, dass die Persistenz ergänzt wurde, um /etc ermöglichte es Nutzern, die keine Suche benötigten, in Version 1.3.2 Folgendes auszuführen:

systemctl disable zimaos-search

Durch das Beenden oder Deaktivieren der Suche wird bei der Dateisuche angezeigt, dass der Dienst nicht verfügbar ist. Aktuelle Nutzer sollten zunächst das aktuelle Suchverhalten überprüfen, bevor sie einen zentralen Dienst allein aufgrund eines historischen Fehlers deaktivieren.

Der Screenshot „/dev/root – 100 % voll“ zeigte ein anderes Problem

Ein anderer Teilnehmer bemerkte /dev/root zeigte eine Auslastung von 100 % an und versuchte, es zu vergrößern. IceWhale erklärte, dass diese schreibgeschützte SquashFS-Root-Darstellung für die Systemintegrität absichtlich so gestaltet ist und nicht wie eine herkömmliche beschreibbare Root-Partition behandelt werden sollte, die freien Speicherplatz benötigt.

Ändern Sie die Größe der ZimaOS-Systempartitionen nicht und löschen Sie sie nicht, nur weil das SquashFS-Image als voll angezeigt wird.

ZimaOS-Dashboard während des Zeitraums mit hoher searchd-CPU-Auslastung, mit Anzeige der System-CPU-Last, des Speichers und der installierten Apps
Die hohe CPU-Auslastung durch die Suche war auf Systemebene sichtbar, obwohl das zugrunde liegende schreibgeschützte System-Root-Layout wie vorgesehen funktionierte.

Wenn die Suche im aktuellen ZimaOS eine hohe CPU-Auslastung verursacht

  1. bestätigen, dass das System die aktuelle stabile Version von ZimaOS verwendet;
  2. prüfen, ob gerade ein großer Dateiimport stattgefunden hat;
  3. abwarten, bis das dokumentierte Indizierungsfenster abgeschlossen ist;
  4. überwachen, ob die CPU-Auslastung nach der Leerlaufphase des Dienstes sinkt;
  5. aktuelle Werte erfassen zimaos-search Protokolle, wenn die CPU deutlich über den erwarteten Zeitraum hinaus hoch bleibt.

FAQ zu hoher CPU-Auslastung durch searchd

Galt eine CPU-Auslastung von 100 % über mehrere Tage als normal?

Nein. IceWhale identifizierte später einen Sonderfall in der Paginierungslogik und behob ihn in 1.3.2-beta2.

Wann führt das aktuelle ZimaOS eine Inhaltsindizierung durch?

Laut der aktuellen Dokumentation wird die Inhaltsindizierung um Mitternacht außerhalb der Spitzenzeiten durchgeführt, während Änderungen an Dateinamen in Echtzeit indiziert werden.

Bedeutet eine Auslastung von 100 % bei /dev/root, dass auf der Systemfestplatte kein freier Speicherplatz mehr vorhanden ist?

Das war nicht der Fall in der ursprünglichen Quelle. IceWhale erklärte, dass die SquashFS-Darstellung des System-Roots absichtlich schreibgeschützt ist und erwartungsgemäß als voll angezeigt wird.