クライアントブラウザでのJitsi MeetにおけるCPU使用率の高さを修正する
Jitsi MeetブラウザのCPUスパイクを診断し、ビデオタイル、カメラエフェクト、ブラウザグラフィック、ホスト設定をチェックすることで、クライアントの負荷を軽減します。
簡潔に言うと、プレビュージェネレーターアプリをインストールして有効化し、慎重に範囲を絞った最初の生成を1回実行した後、occ preview:pre-generate比較的負荷の少ない時間帯にスケジュール設定してください。また、プレビューのサイズとNextcloudが一度に生成する新しいプレビューの数を制限してください。このアプリは、ユーザーがファイルを開いた瞬間から処理を中断するため、CPU使用率の上限を厳密に設定するわけではなく、ディスク使用量が増加する可能性があります。
この設定は、特に写真やドキュメントのライブラリが既に構築されている小規模サーバーで、閲覧中にサムネイル表示によってCPU使用率が急上昇する自己ホスト型のNextcloudサーバーに適しています。ただし、インスタンスでサーバー側暗号化を使用している場合は、この設定はあまり役に立ちません。プレビュージェネレータープロジェクトでは、暗号化は既知の非互換性として挙げられています。マネージドホスティング、Nextcloud AIO、Docker、パッケージインストールではコマンドパスが異なるため、展開環境に合わせてコマンドを調整してください。推測したディレクトリからコマンドを実行しないでください。
現在のアプリの手順では、アプリをインストールして有効化し、preview:generate-all一度実行した後、preview:pre-generate後日ファイル変更をスケジュールすることを推奨しています。最初のコマンドは、大規模なライブラリでは負荷が高くなる場合があります。まずは、ユーザーまたはフォルダを1つ、ワーカーを1つ用意してください。プレビュージェネレータープロジェクトのREADMEとコマンドオプションを確認し、 Nextcloud App StoreでNextcloudのバージョンと互換性のあるリリースを選択してください。
まず、CPU使用率が上昇するタイミングを特定します。写真が大量に含まれるフォルダやプレビューが必要なドキュメントを開いたときにCPU使用率が上昇する場合は、事前生成機能によってその処理の大部分をスケジュールされたタスクに移行できる可能性があります。誰も閲覧していないときにCPU使用率が高いままだったり、別のサービスと同時にCPU使用率が急上昇したりする場合は、プレビュージェネレーターでは原因を特定できない可能性があります。設定を変更する前に、プロセスモニターとNextcloudのログを確認してください。
プレビュージェネレーターは、追加または変更されたファイルを記録し、バックグラウンドジョブで処理します。既存のプレビューがあると、後続のリクエストのコストが下がりますが、不足しているプレビューは、スケジュールされたジョブが処理する前にオンデマンドで生成できます。つまり、キューがいっぱいになると、アプリはユーザーに表示される負荷の急増を抑えますが、CPUスパイクがゼロになることを保証することはできません。また、プレビューの配信速度を上げるためにストレージ容量を犠牲にしています。閲覧頻度の低い小規模なライブラリであれば、Nextcloudのオンデマンド動作で問題ないかもしれません。

Nextcloud管理者としてサインインし、アプリエリアを開いて「プレビュージェネレーター」を探し、インストールして有効化してください。先に進む前に、App Storeでインストール済みのNextcloudメジャーバージョンの安定版が提供されていることを確認してください。App Storeで互換性がないと表示されているバージョンに、最新のアプリフォルダを手動でコピーすることは避けてください。
シェルアクセス権を持つ管理者は、以下のコマンドでアプリを確認または有効化できますocc。一般的なパッケージインストールコマンドを以下に示します。PHPバイナリとNextcloudパスは、ご使用のホストに合わせて変更してください。DockerまたはAIOの場合は、そのデプロイメントでサポートされているコンテナコマンドまたはスケジューラの手順を使用してください。
sudo -u www-data php /var/www/nextcloud/occ app:enable previewgenerator
Nextcloudの管理設定で、バックグラウンドジョブモードとしてCronを選択し、通常のNextcloudシステムcronが実際に実行されていることを確認してください。アプリのREADMEには、組み込みのプレビューバックグラウンドジョブにはCronモードが必要であり、WebcronモードとAJAXモードはこの長時間実行ジョブではサポートされていないと記載されています。通常のcronが正常に動作していない場合、このアプリをインストールするだけではキューは進行しません。
Nextcloudの通常のcron.phpスケジュールと、アプリのオプションの専用preview:pre-generateスケジュールを混同しないでください。これらは別々の仕組みです。アプリに組み込まれているバックグラウンドジョブ、または専用のシステムcronコマンドを使用できます。専用コマンドを選択する場合は、同じキューに対して両方のパスが実行されないように、組み込みのプレビューバックグラウンドジョブを無効にすることをプロジェクトは推奨します。


CPU負荷の高いプレビュー作成の場合、同時に実行される新しいプレビューの数を減らしてください。Nextcloud 35の設定リファレンスでは、preview_concurrency_new同時実行される新しいプレビュー生成を制御します。ドキュメントに記載されているデフォルト値は4で、マニュアルではCPUコア数を超えないようにすることを推奨しています。小規模なホストでは、2などの値をテストするか、サーバーが応答しなくなる場合は1に設定してください。これにより同時処理は制限されますが、大きな画像や動画1つだけでもかなりのCPUリソースを消費する可能性があります。
プレビューのサイズも重要です。Nextcloud 35 のドキュメントでは、デフォルトの最大幅と高さは 4096 ピクセルです。幅と高さを小さくするとpreview_max_x、プレビューが小さくなる代わりに、処理とメモリの必要量を削減できます。設定ファイルをバックアップし、設定を既存の PHP 配列にマージしてください。ファイルをスニペットで置き換えないでください。たとえば、管理者は両方の値を 2048 に設定し、ファイルビューと写真ビューで品質をテストすることができます。preview_max_yconfig/config.php
アプリでは、複数のサイズバリエーションを生成することもできます。README には、一般的なファイル、写真、アクティビティでの使用に適した縮小サイズのプロファイル (正方形サイズ64 256、幅と高さが一直線になるサイズ256 4096、空) が記載されておりwidthSizes、heightSizesこれらのバリエーション グループをスキップすることもできます。これらの設定は、ユーザーが使用するアプリに適合する場合にのみ使用してください。Memories タイムラインやその他のアプリでは、追加のサイズが必要になる場合があります。プロジェクトでは、プレビュー サイズは許容されるサイズ ルールを満たす必要があり、設定された最大値を超えてはならないと注意しています。Nextcloudのプレビュー サイズと品質の設定、およびリリース固有の設定リファレンスを確認してください。
アプリを有効にして制限を設定したら、インスタンス全体ではなく、テストフォルダまたは1人のユーザーに対して最初のジェネレーターを実行してください。アプリはユーザーIDまたはパスによるフィルタリングをサポートしており、コマンドはワーカー数を受け付けます。最初の実行では、保守的な方法としてワーカーを1つ使用してください。
sudo -u www-data php /var/www/nextcloud/occ preview:generate-all --workers=1 --path="/alice/files/Photos"
alice、パス、および Nextcloud のインストール パスを、サーバーの実際の値に置き換えてください。パス オプションは の形式を使用します/[username]/files/[folder path]。パスとユーザー フィルターを省略すると、コマンドがライブラリ全体を走査する可能性があります。ユーザーの活動が少ないときにバッチを実行し、CPU、メモリ、ディスク容量を監視し、サーバーが不安定になった場合は停止して再評価してください。効果を測定するまでは、処理を早く終わらせるためだけにワーカー 数を増やさないでください。
テストバッチが正常に動作したら、preview:pre-generateシステムのcronスケジュールに追加します。アプリのREADMEには10分ごとという例が挙げられていますが、これは必須ではありません。アップロード量と利用可能なアイドル時間に合わせて間隔を選択してください。たとえば、Webサーバーアカウントが所有するcrontabには、インストールに合わせてパスを調整した以下の行を含めることができます。
*/10 * * * * cd /var/www/nextcloud && /usr/bin/php -f occ preview:pre-generate
この専用システムcronを使用する場合は、プロジェクトの推奨に従って、アプリに組み込まれているプレビューのバックグラウンドジョブを無効にしてください。ドキュメントに記載されているアプリ設定は次のとおりです。
sudo -u www-data php /var/www/nextcloud/occ config:app:set --value=true --type=boolean previewgenerator job_disabled
Nextcloudの通常のcron.phpジョブは有効のままにしておいてください。コンテナやホスト型プラットフォームの場合は、コンテナのcronエントリにホストパスを指定するのではなく、プラットフォームでサポートされているスケジューラを使用してください。アプリが暗号化を有効にした状態でインストールされている場合は、ここで作業を中断し、管理者またはホスティングプロバイダにご相談ください。このプロジェクトでは現在、その構成はサポート対象外となっています。

実行してocc preview:queue-stats、生成前のキューと古いプレビューを確認してください。スケジュールされた実行の間にキューが縮小する場合は、ワーカーが追いついていることを示しています。キューが着実に増加する場合は、ユーザーが設定されたジョブの処理速度よりも速くファイルを追加していることを意味します。追加のCPU負荷が許容範囲内であることを確認した後、実行頻度または許可されるジョブの制限を慎重に増やしてください。このアプリは、ジョブの実行時間と実行ごとのプレビューの制限を公開しています。READMEには、ゼロは無制限を意味すると記載されているため、リソースが限られたホストでは、安易にゼロを選択しないでください。
展開前後の同時刻におけるCPU使用率のピークを比較し、次に通常のユーザーとして代表的な写真フォルダとドキュメントのプレビューを開きます。サムネイルが表示され、ページが正常に動作し、スケジュールされたバッチ処理後にCPU使用率が安定することを確認してください。日中のCPU使用率が安定し、キューの処理が適切に進んでいる状態であれば良好です。処理待ちのバックログが常に増加したり、ユーザーセッションが遅くなったりする場合は、スケジュール、サイズプロファイル、または基盤となるプレビュープロバイダを再検討する必要があります。

プレビューの種類によっては、サーバー側のプログラムに依存するものがあります。Nextcloudのマニュアルでは、動画プレビューにはFFmpeg、オフィス文書プレビューにはLibreOfficeが挙げられています。これらの形式は通常の画像サムネイルとは動作が異なる場合があり、サポート状況はプロバイダの設定によって異なります。プロバイダを変更したりサービスを追加したりする前に、まず同時実行数を減らし、対象ファイル数を絞ってテストすることをお勧めします。
プロジェクトのREADMEによると、プレビューのサイズやサポートされるファイルの種類を変更し、キャッシュされたプレビューを破棄する必要がある場合、Nextcloud 31以降ではocc preview:cleanupそのための機能が用意されています。この機能は、生成されたすべてのプレビューファイルを削除し、その後、ユーザーがファイルにアクセスすると、Nextcloudがオンデマンドでプレビューを作成します。これにより、一時的に、削減しようとしているCPUスパイクが再発する可能性があります。適切な場合はバックアップを取り、クリーンアップを意図的にスケジュールし、定期的なチューニングとしてappdataプレビューディレクトリを手動で削除することは避けてください。プレビュージェネレーターのREADMEには、.nomedia適切な場合にフォルダとその子孫をスキップするためのファイルについても記載されています。

実際には、オンデマンドプレビューの処理速度が遅く、ピーク時の負荷が目に見える場合、バックグラウンド処理をスケジュールでき、キャッシュサイズ用のディスク容量が確保できる場合に、プレビュージェネレーターは最適な選択肢となります。同時実行数の制限を控えめに設定し、実際の表示ニーズに合ったプレビューサイズを設定し、テストを優先した一括実行を行うと効果的です。インスタンスが暗号化されている場合、シェルスケジューリングを使用せずに管理されている場合、またはプレビュー要求とは無関係の理由でCPU負荷が高い場合は、デプロイ前にこれらの制約を調査してください。
Jitsi MeetブラウザのCPUスパイクを診断し、ビデオタイル、カメラエフェクト、ブラウザグラフィック、ホスト設定をチェックすることで、クライアントの負荷を軽減します。
Jitsi Videobridgeに内蔵されたPrometheusエンドポイントを使用して、Jitsi Videobridgeの状態、会議の負荷、トラフィックを追跡し、Grafanaでデータを探索およびグラフ化できます。
Jitsi Meet Docker 用のカスタムドメインを、DNS、PUBLIC_URL、HTTPS、Let's Encrypt、ファイアウォールポート、NAT 設定、エンドツーエンド検証とともに構成します。
SSL更新後に発生するZimbra管理コンソールの404エラーを修正するには、正しいURLとポート、プロキシルーティング、サービスステータス、デプロイ済みの証明書、およびログを確認してください。
アクティブなPHP SAPI、サイズ制限、コメント、および再検証設定を確認することで、NextcloudのPHP OPcache構成警告を診断および修正する方法を学びましょう。
MySQLまたはMariaDBのアップグレード後にKopanoデータベースの移行が失敗した場合は、バックアップ、サーバーバージョン、SQLモード、文字セット、スキーマ状態、およびログを確認してトラブルシューティングを行います。
セキュアなトランスポート、ユーザーおよびグループフィルタ、ログイン属性、そしてテスト済みの展開機能を使用して、NextcloudをLDAPまたはActive Directoryに接続します。
UnifiedPush、Androidの権限設定、バッテリー設定、および信頼性の高い検証テストを設定することで、Googleサービスを削除した端末におけるElement Android通知の問題を修正します。
Nextcloudのデータベースインデックス不足警告を、公式のoccコマンドでクリアします。まずバックアップを作成し、変更内容をプレビューしてから修復を実行し、結果を確認してください。
Element Web 用の Keycloak SSO を設定するには、OIDC を Synapse に接続し、正確なコールバック URL を設定し、ユーザー クレームをマッピングし、ログアウトをテストします。