コミュニティソリューション

大容量ファイル転送後にZimaOSのsearchdがCPUを100%使用:1.3.2での修正と、現在の検索におけるインデックス作成スケジュールの仕組み

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.

元の高CPU使用率の挙動は、単に「通常のインデックス作成が永遠に続く」というものではありませんでした。大容量ファイルの転送後、 searchd CPU使用率が100%のまま数時間、ときには数日間続いたとの報告もあり、システム温度が上昇し、検索を停止するかCPUを使い続けるかの選択を迫られました。

IceWhaleは後に、ページネーションロジックの特殊なケースによって長時間にわたるCPU使用率の問題が発生することがあると正確に説明しました。この問題はZimaOS 1.3.2-beta2で修正・最適化されました。同じアップデートで、アイドル時間経過後の検索エンジンの折りたたみ機能が追加され、ファイル名のインデックスは正確かつリアルタイムに維持され、ファイルコンテンツのインデックス作成はリソース使用率を抑えて深夜に実行されるようになりました。現在のZimaOS検索ドキュメントでは、さらに明確なスロットリングと、アイドル時のメモリ使用量およびサービス数の大幅な削減が行われています。

大容量ファイルの転送後、searchdがCPUを100%使用しているZimaOSのシステムモニター
ソースモニターには、次のように表示されています。 searchd 転送がすでに完了した後もCPU使用率を支配していました。

検索にはインデックスが必要

Zima-Giorgioは当初、Filesの検索機能にはファイルのインデックス作成が必要だと説明しました。この点は正しかったものの、なぜCPU使用率が異常に長時間高止まりするのかは説明できていませんでした。

IceWhaleは後に、ページネーションロジックの特殊なケースを特定

2025年2月11日、orca-zhangは、長時間にわたるCPU使用率の問題はページネーションロジックのエラーが原因で断続的に発生することがあり、1.3.2-beta2で修正および最適化されたと述べました。

これは最も確度の高い情報源に基づく結論であり、以前の曖昧な「インデックスを作成中」という説明に置き換えるべきです。

1.3.2で検索サービスのアイドル時折りたたみ機能を追加

IceWhaleは、検索が必要ない場合について、 searchd アイドル状態が約3分間続くと解放され、軽量な zimaos-search メモリ使用量は100 MB未満、CPU使用率はおよそ0~1%です。

コンテンツのインデックス作成は深夜に移行

同じ回答では、2つの処理が分けて説明されています。

  • ファイル名のインデックス — 可能な限り正確かつリアルタイムに維持されます。
  • ファイルコンテンツのインデックス — 深夜まで延期され、低リソース使用率で実行されます。

この区別は、現在の検索アーキテクチャにも存在します。

現在のIceWhaleのドキュメントには、次のように記載されています。

  • ファイル変更のリアルタイム監視とファイル名のインデックス作成。
  • コンテンツのインデックス作成は深夜に実行されます。
  • 1回の処理タイプ/セッションあたり、最大100,000件のドキュメントです。
  • 1種類あたりの処理時間は最大5分です。
  • CPUスパイクに対する書き込みバリア保護。
  • 非アクティブ後のサービスとメモリの折りたたみ。

現在のZimaOS検索アーキテクチャを使用してください。

検索はZimaOS 1.3.2から無効にできる

orca-zhangは、次の項目に追加された永続化について述べました。 /etc 1.3.2では、検索を必要としないユーザーが次のコマンドを実行できるようになりました。

systemctl disable zimaos-search

検索を停止または無効にすると、Filesの検索でサービスが利用できないと表示されます。現在のユーザーは、過去のバグだけを理由にコアサービスを無効にする前に、まず現在の検索動作を確認してください。

/dev/rootの「100% Full」スクリーンショットは別の問題でした

別の参加者が気づいたこと /dev/root 使用率が100%と表示されたため、サイズを拡張しようとしました。IceWhaleは、この読み取り専用のSquashFSルート表現はシステムの整合性を保つために意図されたものであり、空き容量が必要な従来の書き込み可能なルートパーティションのように扱うべきではないと説明しました。

SquashFSイメージがいっぱいと表示されるため、ZimaOSのシステムパーティションのサイズ変更や削除を行わないでください。

searchdのCPU使用率が高かった期間のZimaOSダッシュボード。システムCPU負荷、ストレージ、インストール済みアプリが表示されています
基盤となる読み取り専用のシステムルートレイアウトは設計どおりに動作していたにもかかわらず、検索による高いCPU使用率はシステムレベルで確認されました。

現在のZimaOSで検索が高いCPU使用率を使用する場合

  1. システムが最新の安定版ZimaOSを使用していることを確認する。
  2. 大容量ファイルのインポートが直前に行われていないか確認する。
  3. ドキュメントに記載されたインデックス作成時間が終了するまで待つ。
  4. サービスのアイドル時間後にCPU使用率が低下するか監視する。
  5. 現在の状態を収集 zimaos-search CPU使用率が想定時間を大幅に超えて高いままの場合のログ。

searchdのCPU使用率が高い場合のよくある質問

CPU使用率が複数日間100%になるのは正常と見なされていましたか?

いいえ。IceWhaleは後にページネーションロジックの特殊なケースを特定し、1.3.2-beta2で修正しました。

現在のZimaOSでは、コンテンツのインデックス作成はいつ行われますか?

現在のドキュメントでは、コンテンツのインデックス作成は深夜のオフピーク時間帯に行われ、ファイル名の変更はリアルタイムでインデックス化されるとされています。

/dev/rootが100%ということは、システムディスクの空き容量がないという意味ですか?

ソースのケースではありません。IceWhaleは、SquashFSのシステムルート表現は意図的に読み取り専用で、容量がいっぱいに見えるのは想定内だと説明しました。