私のQuTS hero h6.0ベータテストのまとめ - システム停止の根本原因を特定 — Qsirch

QuTS hero h6.0 Betaのテスト中、ZFSの重大な障害のような深刻なシステムスタックに遭遇しました。

  • ロードアベレージが数百まで急上昇
  • SSHコマンドがフリーズ(psfindgetcfg
  • プロセスがDステートで停止
  • システムが部分的に応答しなくなる
  • ZFSプールが断続的にハングする
  • カーネルログに[DISK SLOW]警告やZFSアサーションが表示

最初はディスクの故障やZFSのバグのように見えましたが、徹底的に調査した結果、根本原因はもっと単純でした。

Qsirchを削除したら即座に問題が解消しました。

発生したこと

Qsirchは再起動後にフルインデックスサイクルを開始しました。QuTS hero(ZFS)上では、Qsirchのインデックスエンジンが非常に重いメタデータI/Oを発生させます。

  • ディープディレクトリウォーク
  • 小さなランダムリード
  • SQLite/MariaDBへの書き込み
  • サムネイル抽出
  • コンテンツスキャン

この負荷が私のプールの一つを圧倒し、以下のような問題を引き起こしました。

  • 数秒単位のディスクレイテンシ
  • ZFSトランザクションの遅延
  • カーネルI/O待ちの蓄積
  • Dステートで停止するプロセス
  • システム全体のスタック

Qsirchを削除した途端、システムは即座に安定しました。

  • ZFSプールのレイテンシが正常に戻る
  • [DISK SLOW]警告が消える
  • カーネルスタックが発生しない
  • コマンドがフリーズしない
  • ロードアベレージが正常値に戻る

他の変更は一切不要でした。

重要なポイント

QuTS hero h6.0 Betaでは、QsirchがZFSプールを圧倒する可能性があります。特に大規模または多忙なプールで顕著です。もし以下のような症状が出た場合は、

  • 原因不明のシステムスタック
  • プロセスのフリーズ
  • CPU使用率が低いのに高負荷
  • ZFSレイテンシ警告

まずQsirchを無効化または削除してみてください。

私の環境では、Qsirchを削除することで完全に問題が解決しました

「いいね!」 1

先ほど言い忘れましたが、2.5インチSSDのうち1台が事故直後に故障しました。根本的な問題と関連している可能性がありますが、まだ検証中です。念のため、これも追記しておきます。

QSirchは、NAS上のすべてのファイルをインデックス化するため、最初は非常にCPU負荷が高くなります。これは問題ではなく、仕様上の特性です。NASの初期設定時には、QSirchを有効にする前に、すべての設定や動作が落ち着くまで待つのが最適です。また、QSirchのインデックス対象から除外するフォルダーを設定することもできます。例えば、Container Stationのデータや仮想マシンのドライブはQSirchに含める必要はないでしょう。

QSirchのインデックス作業が完了すれば、CPUやリソースの消費は最小限になります。しかし、NAS内のデータ検索において非常に強力な機能を発揮します。

「いいね!」 1

この問題はバージョン6.0にアップグレードした後から発生し始めましたか?以前のバージョンではすべて正常に動作していましたか?ありがとうございます!

以前はQTS(キュー・ティー・エス)を使っていて問題はありませんでした。

ご説明いただきありがとうございます。QSirchが初回インデックス作成時にどのように動作するか、詳細を共有していただき本当に感謝しています。正直、もっと早く知っていればよかったです。

私の場合、NASが約5日間アクセス不能な状態で稼働し続け、最終的にはSSDが不良セクタのため故障してしまいました。その前にも、システムが3日間アクセス不能になり、リセットしてすべて再設定し直したことがありました。

Qsirchを再度有効にしたところ、NASがすぐにアクセス不能になりました。これは以前にも見られたのと同じ挙動で、長時間応答しなくなり、前回は数日間ノンストップで負荷がかかった結果、SSDが不良セクタで故障する原因にもなりました。

前述の通り、このような大規模なOSアップデートの直後は、たとえ自分では気づかなくても、内部で多くの処理が行われている可能性が高いです。Qsirchもこれに加わるため、NASが落ち着くまで負荷がかかります。

実際の使用状況や何が原因で遅くなっているかを確認したい場合は、SSHセッションを開いて「top」コマンドを実行してください。これにより、CPU負荷や各プロセスのCPU使用率が表示されます。CPU負荷が重要な数値です。これはCPUのコア数やスレッド数以下であるべきです。もしそれを超えている場合、システムの動作が遅くなり始めます。

こんにちは、社内でこの問題の再現を試みましたが、同じ結果を確認することができませんでした。

念のためご案内しますと、QuTS hero 6.0.0 beta 上の Qsirch はパフォーマンス向上のため最適化されており、以前のバージョンよりもCPU使用率がやや高くなる場合があります。しかしながら、ご指摘のような特定の状況には遭遇しておりません。

さらなる調査のために、いくつかデータの詳細を教えていただけますか?

  • ファイル全体のサイズはどれくらいですか?

  • 動画と写真はそれぞれ何点ありますか?

  • 現在使用中の総容量はどれくらいですか?

よろしくお願いいたします。

こんにちは、

フォローアップありがとうございます。QuTS hero 6.0.0 betaにおけるQsirch最適化についてご説明いただき感謝いたします。

調査のご参考までに、以下のご要望の詳細情報をお送りします。

  • Multimedia Console経由でQsirchがインデックスしたファイルの合計サイズ:およそ23.13 TB(2つのストレージプールにまたがっています)

  • 写真:893,365枚

  • 動画:11,917本

  • 音楽:0(現時点でインデックス済み)

ご注意:これはMultimedia Consoleに追加されたファイルのサブセットのみを反映しています。私の全データセットはこのほぼ2倍の規模で、まだインデックスされていない大規模な音楽ライブラリも含まれています。

  • 現在使用中の総容量

    • ストレージプール1:21.81 TB中12.52 TB使用

    • ストレージプール2:14.13 TB中10.61 TB使用

システム仕様、CPU使用率グラフ、またはログなど、負荷プロファイルの再現に役立つ情報が必要であればご連絡ください。引き続きご協力いたします。

よろしくお願いいたします。
Victor Lam

さらに、私のQNAP AI Coreは複数の認識ワークロードを積極的に実行しています。AI Coreは有効化されており、QAI‑U100アクセラレータを使用中で、検出されてReady状態です。ご存知の通り、これらのバックグラウンド認識プロセスはシステム全体のパフォーマンスに影響を与える可能性があるため、現在の進捗状況を以下に共有します。

  • 顔認識:作業中 — 52%(470,880 / 893,637)最終更新:2025/12/31 09:59:20

  • オブジェクト認識:作業中 — 55%(496,770 / 893,637)最終更新:2025/12/31 09:59:45

  • 類似写真認識:作業中 — 54%(483,804 / 893,637)最終更新:2025/12/31 09:58:42

本システムでサポートされているAIアクセラレートデバイスの種類には、Coral Edge TPU、Hailo‑8、Hailo‑8L、QAI‑M100、QAI‑U100、内蔵GPU、NPUが含まれます。

インデックス作成や認識中にログ、パフォーマンストレース、追加のメトリクスが必要な場合は、提供可能です。

問題に関するもう一つのアップデートです:

Qsirchをインストールしていないにもかかわらず、NASが再び応答しなくなりました。障害発生時、唯一動作していたプロセスはMultimedia Consoleによる写真と動画のインデックス作成でした。最終的にシステムは完全に応答しなくなり、NASをリセットし、すべてのハードドライブを物理的に取り外してシステムを復旧する必要がありました。

再構築後、現在は写真のみをインデックス作成するようにしています。この軽減された負荷のもとで、NASは約2日間安定して稼働しています。

こんにちは、情報を提供していただきありがとうございます!こちらでも問題を再現してみたいと思います。

お使いの写真や動画のファイル形式(例:.jpg、.heic、.mp4)を教えていただけますか?また、各写真のおおよそのサイズもご教示ください。

AI Coreについて言及されていましたが、現在有効になっているAI機能はありますか?よろしくお願いします。