スケジュールされたキューを使用して、NextcloudプレビューのCPUスパイクを抑制する
サムネイル作成作業を制御されたバックグラウンドスケジュールに移行し、使用されていないプレビューサイズをトリミングし、Nextcloudサーバーに過負荷をかけることなくキューを検証します。
Nextcloudの「PHP OPcacheが正しく設定されていません」という警告を解消するには、管理設定 → 概要で警告の詳細を開き、Webサーバーで使用されているPHP設定で、警告で示されているOPcacheの制限値のみを増やしてください。該当するPHPサービスを再起動し、警告が解消されているか再度確認してください。コマンドラインのPHP設定を編集するだけでは、Nextcloudが使用する設定は変更されない場合があります。
例えば、Nextcloudがインターン文字列バッファがほぼ満杯だと報告した場合、opcache.interned_strings_bufferサーバーに十分なRAMが搭載されているのであれば、16MBから32MBに増やすのが妥当な最初の調整方法です。キャッシュされたスクリプトや共有メモリに関する別の警告の場合は、別の設定が必要になります。
OPcacheはコンパイル済みのPHPバイトコードを共有メモリに格納することで、繰り返しWebリクエストを行う際に必要なコンパイル量を削減します。また、インターン化された文字列用の領域も確保し、PHPが同一の文字列を再利用できるようにします。これらの容量はそれぞれ独立した制限であるため、一方を拡張しても他方の警告が必ずしも解消されるとは限りません。
Nextcloud 35のサーバーチューニングに関するドキュメントによると、管理パネルはOPcacheのサイズ制限が割り当て容量の90%を超えると警告を表示します。メッセージには、インターン化された文字列バッファがほぼ満杯であること、キャッシュされたスクリプトの数が限られていること、または共有メモリが不足していることなどが具体的に記載される場合があります。この詳細によって、対処方法が決まります。
Nextcloudはopcache.save_comments=1、PHPコードのコメントが保持されることに依存しているため、OPcacheも必要とします。したがって、OPcache拡張機能が無効になっている場合、またはコメントの保持が無効になっている場合は、単なるキャッシュサイズの問題ではなく、設定の問題となります。
管理者としてサインインし、「管理設定」→「概要」に移動して、OPcache警告全文をお読みください。指示が明記されている場合は、その指示を正確に記録してください。OPcache警告が表示されているからといって、必ずしもインターン文字列バッファのサイズが不足しているとは限りません。
opcache.interned_strings_buffer。opcache.memory_consumption。opcache.max_accelerated_files。opcache.enableくださいopcache.save_comments。PHP-FPM を使用する Debian または Ubuntu サーバーでは、PHP の設定は通常、PHP のバージョンとサーバー API によって整理されます。たとえば、PHP 8.3 FPM は の下のファイルを読み込む可能性があります/etc/php/8.3/fpm/conf.d/が、Apache の PHP モジュールは を使用する可能性があります/etc/php/8.3/apache2/conf.d/。
systemdホスト上に存在するPHP-FPMサービスを確認するには、以下を実行します。
systemctl list-units --type=service 'php*-fpm.service'
インストールされているPHPのバージョンに合わせて、該当するOPcacheファイルを確認してください。
sudo ls -l /etc/php/8.3/fpm/conf.d/*opcache*
sudo grep -R 'opcache\.' /etc/php/8.3/fpm/conf.d/
ファイルが見つからない場合は、お使いのディストリビューションのメインphp.iniおよびパッケージング規則を確認してください。このコマンドはCLIphp --ini PHPの設定を特定するのに役立ちますが、CLIとPHP-FPMでは異なる設定が読み込まれる可能性があります。
DockerまたはNextcloud All-in-Oneの場合、 Nextcloudコンテナ内のPHP設定を確認し、サポートされている永続的な設定方法を使用してください。ホスト/etc/phpファイルを編集しても、通常はコンテナ内のPHPは設定されません。また、生成されたコンテナファイルを編集しても、再作成によって元に戻ってしまう可能性があります。
変更を加える前に、関連する設定ファイルをバックアップしてください。一般的な Debian/Ubuntu の PHP-FPM インストールでは、保守しやすい方法の一つとして、その PHP バージョンの FPMconf.dディレクトリにローカルオーバーライドを追加する方法があります。作業を進める前に、このディレクトリが実際に PHP-FPM インストールによって読み込まれていることを確認してください。
インターン文字列バッファの例では、次のようなローカルオーバーライドを作成または編集します/etc/php/8.3/fpm/conf.d/99-nextcloud-opcache.ini。
; Example for a warning about interned strings
opcache.interned_strings_buffer=32
ここでいう「3232」は32バイトではなく、32MBを意味します。最終的な値は、実際の使用量と利用可能なRAMに合わせて調整してください。
警告メッセージに別の制限値が記載されている場合は、 3つすべてを無条件に追加するのではなく、対応する例を使用してください。
; Example only: larger shared bytecode cache
opcache.memory_consumption=256
; Example only: allow more cached script keys
opcache.max_accelerated_files=20000
の値はopcache.memory_consumptionメガバイト単位ですが、 はopcache.max_accelerated_filesスクリプトキーの制限を指定します。PHP OPcache の公式設定リファレンスには、これらの単位、デフォルト値、および変更可能性について説明されています。
警告が容量の問題ではなく、OPcacheの無効化やコメントの欠落を示している場合は、代わりに以下の設定を確認してください。
opcache.enable=1
opcache.save_comments=1
この警告を無視するためだけに、電源を切ったりopcache.validate_timestamps、大幅に時間を延長したりしないでくださいopcache.revalidate_freq。Nextcloudは、キャッシュの再検証が遅れると、設定やアップグレードの変更が速やかに反映されない可能性があると警告しています。
PHP-FPMを介してPHP 8.3を実行しているサーバーを例にとると、まずサービス構成を検証し、次に短いメンテナンス時間中に該当するサービスを再起動します。
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
8.3インストールされている PHP-FPM のバージョンに置き換え、コマンドを実行する前に実行可能ファイルとサービス名を確認してください。再起動すると、そのプールで処理されるリクエストが中断されます。Apache を使用している場合mod_php、関連するサービスは PHP-FPM ではなく Apache です。コンテナの場合は、構成を保持したまま、デプロイメントのドキュメントに記載されている再起動または再作成手順を適用してください。
サービスの再起動に失敗した場合は、バックアップした設定を復元し、PHP-FPMまたはWebサーバーのエラーログを確認してください。
PHPワーカーが再起動した後、まず「管理設定」→「概要」を再読み込みしてください。それでも同じ警告が表示される場合は、変更したディレクティブがCLIだけでなく、 Web.ini PHPランタイムによって実際に読み込まれていることを確認してください。後から読み込まれるファイルや、PHP-FPMプールのオーバーライドによって値が上書きされていないか確認してください。
管理対象のサーバーでは、アクセス権限を厳しく制限した診断エンドポイントとPHPのini_get()関数を使用して、Web PHPの値を一時的に検査できます。公開phpinfo()ページをオンラインに放置しないでください。環境情報、パス、モジュール、その他の機密性の高い設定情報が漏洩する可能性があります。検証後は、診断エンドポイントを直ちに削除してください。
持続的なサイジングアラートを設定するには、値を繰り返し倍増させるのではなく、通常のトラフィック下での実際のOPcache使用量を調べてください。PHPのopcache_get_status()ドキュメントには、実行中のPHPプロセスで使用できるメモリ、インターン文字列、およびキャッシュされたスクリプトの統計情報が記載されています。
Nextcloudの公式Dockerイメージとオールインワンデプロイメントには、それぞれ独自のPHPデフォルト設定が含まれています。ホストレベルでの編集や他のインストールで推奨された値がそのまま維持されるとは限りませんのでご注意ください。ご使用のデプロイメントに合った設定モデルについては、公式のNextcloud Dockerリポジトリまたは公式のオールインワンリポジトリを参照してください。
管理設定 → 概要に戻り、特定の OPcache 警告が消えていることを確認してください。Nextcloud のページをいくつか開いて再読み込みし、アプリケーションが正常に動作することを確認してください。通常使用後に警告が再び表示される場合は、同じ測定制限と有効な Web PHP 設定を再確認してください。目標は、OPcache に不要なメモリを割り当てずに、十分な余裕を持たせることです。
サムネイル作成作業を制御されたバックグラウンドスケジュールに移行し、使用されていないプレビューサイズをトリミングし、Nextcloudサーバーに過負荷をかけることなくキューを検証します。
Nextcloudの同期を妨げているファイル、除外ルール、接続の問題、またはクライアントデータベースの状態を特定し、アップロードとダウンロードが安全に行われることを確認します。
Nextcloudの警告を引き起こしているPHP OPcacheの制限値を特定し、適切なWeb PHP設定を更新し、安全に再起動して、結果を確認してください。
組み込みのCODEとDockerベースのCODEを比較し、安全なHTTPSリバースプロキシを介してCollabora OnlineをNextcloudに接続します。
共有ストレージ、Redisロック、クォーラム対応MariaDBルーティング、および実用的なフェイルオーバーチェックを備えた、信頼性の高いNextcloud HAデプロイメントを計画します。
ファイアウォールや制限的なNATによって直接通話メディアがブロックされる場合に、Nextcloud Talk用の到達可能なTURNリレーを設定および検証します。
無効ファイルレポートを使用して、変更された、欠落している、または余分な Nextcloud コードを特定し、信頼できるファイルを安全に復元し、結果を確認します。
Nextcloud MailでGmailまたはMicrosoft 365を使用してOAuth2を設定し、送受信を確認し、一般的な同意エラーやSMTPエラーを解決します。
OCCを使用してNextcloudへのアクセスを復元し、データベース移行のステータスを確認し、アーカイブ、Docker、またはSnapのインストールに適したコマンドを選択します。
NextcloudをLDAPまたはActive Directoryに接続し、ユーザーおよびグループフィルタを使用してアクセスを制限し、展開前に安全な認証を検証してください。