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

ZimaOSアプリの読み込みが遅い:本当のボトルネックを見つける

A ZimaOS 1.4.1 system became slow as more apps were installed; disabling search indexing improved responsiveness while IceWhale prepared app-loading fixes.

結論:アプリの読み込みが遅い原因は少なくとも4つの層に分かれる—「アプリが多すぎる」と決めつけない

2025年のシステムでは、インストール済みアプリが約10個あるだけで動作が非常に重くなり、検索インデックスを無効にするとホストの応答性が大幅に改善しました。その後、IceWhaleは1.4.2でアプリ読み込みの最適化を実施しました。しかし現在でも、遅い「アプリ」画面の原因は、ホストの負荷、ストレージ、Dockerの起動、App Store/APIの状態、ブラウザーのいずれかである可能性があります。UIが速くなるまでアプリをアンインストールするのではなく、これらの層を個別に診断してください。

インストール済みアプリの表示が遅いZimaOSホストで、高いCPU使用率を示すBTOPシステムモニター
最初の診断スクリーンショットでは、初期報告でCPUとメモリの使用率は低いとされていたにもかかわらず、ホストで多数のプロセスが動作していました。
ZimaOSの検索インデックスを無効にした後、CPU負荷が大幅に低下し応答性が改善したことを示すBTOP
古い1.4.1ビルドで検索インデックスを無効にすると、システム全体の応答性は大幅に改善しました。ただし、「アプリ」画面の表示には依然として数分かかることがありました。

ステップ1:ホストに実際の負荷がかかっているか確認する

free -h
uptime
docker stats --no-stream
df -h

空きメモリ、ロードアベレージ、スワップ、ディスク使用率、各コンテナの使用状況を確認します。ダッシュボードのパーセンテージだけでは、1つのプロセスがCPUコアを丸ごと使用していたり、ストレージサービスがI/O待ちになっていたりする状態を見逃すことがあります。DockerのDockerコンテナ統計を使うと、アプリの負荷とホストサービスの負荷を切り分けられます。

検索インデックスの無効化は、恒久的なルールではなく過去の回避策

ZimaOS 1.4.1では、このケースで検索インデックスを無効にすると負荷が大幅に低下しました。ただし、現在のZimaOSユーザー全員がインデックスを無効にすべきという意味ではありません。その後、ファイルサービスやアプリ管理機能には多くの改良が加えられています。過去の回避策は、A/Bテストによる診断としてのみ使用してください。オプションのインデクサーを無効にした直後に負荷が下がるなら、調査すべき処理を特定できたことになります。

ステップ2:「アプリ」画面を疑う前に、コンテナが実行中か確認する

docker ps -a
docker inspect CONTAINER --format '{.State.Status}'

Plex、Paperless、その他のサービスがすでに実行中で、直接URLはすぐに開くのに「アプリ」画面の読み込みだけが続く場合、問題はコンテナ自体ではなく管理/UI経路にあります。ZimaOSアプリの要件を確認すると、ワークロード自体がホストに対して単純に大きすぎないか判断できます。

ステップ3:ストレージのレイテンシーを確認する

負荷の高いHDD RAID上にアプリのメタデータ、Dockerレイヤー、永続データがあると、CPUやRAMが正常に見えても、起動や一覧表示が遅く感じられることがあります。AppDataが回転式ディスク上にある場合は、ソフトウェアを変更する前に、ローカルディスクでのテスト結果と高速なSSD/NVMe経路を比較してください。

データベース、サムネイル、Dockerの状態情報が同じHDD上の大量メディアと競合している場合は、ZimaOSのデータ移行が役立ちます。

ステップ4:UIだけが遅い場合は、ブラウザーのネットワークツールを使う

ブラウザーの開発者ツールを開き、「アプリ」画面を再読み込みして、保留中のままになっているAPIリクエストやエラーを返しているリクエストを確認します。古いブラウザーキャッシュや、1件の失敗したアプリ管理リクエストによって、Dockerが正常でもグリッドが空白に見えることがあります。Chromeのブラウザーネットワークトレースで、診断の手がかりを得られます。

古い1.4.1の事例以降に変わったこと

ZimaOS 1.4.2では、アプリの読み込み、更新処理、ダウンロード速度が改善されました。その後、ZimaOS 1.7.1では、Dockerコンテナの起動、App Storeの表示、インストール画面も再び改善されています。したがって、以前の挙動を「アプリが6個を超えると発生する本質的な制限」と説明すべきではありません。

古いアプリマネージャーの不具合を調べる前に、現在の安定版を使う

最新のマシンでもアプリの読み込みに数分かかる場合は、まず現在の安定版ZimaOSリリースであることを確認し、そのうえで直接アプリURL、Dockerの状態、ブラウザーのネットワーク情報を使って再現状況を確認してください。同じサブシステムが原因だと証明せずに、1.7.xシステムへ1.4.1のベータ版向け回避策を適用しないでください。

Portainerのコンテナビューを使うと、上級ユーザーは別の管理画面から確認できます。

最初の対処として、すべてのアプリを再インストールしない

再インストールすると、構成が削除されたりボリュームのマッピングが変更されたりする一方で、遅い管理リクエストが解決しないことがあります。AppDataをバックアップし、まずコンテナ自体が失敗しているかを特定してください。その後、基盤となるリソースまたはUIの問題を把握してから、影響を受けたアプリだけを再作成します。

ベータ版エクスペリエンスの切り替えとSSHアクセス設定を表示するZimaOSの開発者モード
IceWhaleは、1.4.2のアプリ読み込み修正を待つ間に、ユーザーがベータ版更新通知を有効にできる場所を示すため、このスクリーンショットを使用しました。

FAQ

ZimaOSのアプリが表示されるまで数分かかるのはなぜですか?

ホストのCPU/I/O負荷、遅いAppDataストレージ、コンテナの起動、App Store APIの遅延、ブラウザー側の状態などが原因として考えられます。各層を個別に確認してください。

検索インデックスを無効にすべきですか?

特定のZimaOS 1.4.1のケースでは効果がありました。現在のリリースでは、インデックス処理が実際にリソースを消費している場合を除き、診断目的の比較としてのみ使用してください。

ZimaOSでは何個のアプリを実行できますか?

意味のある固定数はありません。軽量なアプリ10個でも、負荷の高いAI、メディア、データベースのワークロード1つより少ないリソースしか使用しない場合があります。

アプリのURLは動作するのに、「アプリ」画面が空白なのはなぜですか?

コンテナが正常でも、管理UIやバックエンドのアプリ一覧リクエストが遅い、または失敗している可能性があります。

AppDataはHDDとSSDのどちらに置くべきですか?

頻繁にアクセスするデータベース、メタデータ、コンテナの状態情報は通常SSD/NVMeの恩恵を受けます。一方、大容量のメディアファイルはHDDストレージに置いたままでも問題ありません。