ownCloud Infinite ScaleとNextcloud 28を推測なしで比較

CPU グラフが静かであっても、ファイル サーバーの動作が遅く感じられることがあります。ディレクトリ一覧の表示に数秒かかったり、アップロードが集中時に停止したり、処理によって RAM の消費量が日ごとに増加しているように見えたりするためです。ownCloud Infinite Scale (oCIS) と Nextcloud 28 を「ユーザーあたりの RAM」という単一の数値で比較しても、この問題は診断できません。公平な比較ができる公式ベンチマークは存在せず、どちらのプロジェクトもメモリ需要はワークロードと構成に依存すると文書化しています。適切な比較を行うには、同じファイル、クライアント、ストレージ、同時実行数、テスト ウィンドウで各プラットフォームを測定し、まずボトルネックがアプリケーション、データベース、ストレージ、またはバックグラウンド処理のいずれであるかを確認してください。

また、メンテナンス上の制約もあります。Nextcloud 28 は、プロジェクトが公開しているスケジュールによると、2024 年 12 月にサポート終了となります。コミュニティ リリース チャネルでは、定期的な修正は提供されなくなります。Nextcloud 28 が既に稼働している場合は、パフォーマンス チューニングを唯一の解決策とする前に、アップグレードを計画してください。以下の手順は、動作を比較し、リソース負荷の所在を特定するのに役立ちますが、サポート対象外のバージョンを安全に公開できるものではありません。

RAM容量と速度の測定値が異なるのはなぜですか？

Infinite ScaleとNextcloudは異なるサーバーアーキテクチャを使用しています。oCISはGoベースのプラットフォームでサービスとして構成されており、組み込みのスーパーバイザーがサービスを1つのサーバープロセスとして起動します。そのメモリ要件には、キャッシュされたユーザーおよびストレージメタデータが含まれる可能性があり、ownCloudのドキュメントでは、メモリに保持されるスペースとメタデータの数と、使用可能なRAM、アクセスまたは同期パフォーマンスとの関連性が具体的に説明されています。大規模な初期スキャン後にワーキングセットが大きくなったサーバーは、それ自体ではメモリリークの証拠にはなりません。インデックス作成後にメモリが安定し、レイテンシが許容範囲内に収まるかどうかを確認してください。

Nextcloud 28 は PHP アプリケーションです。その総メモリ使用量は、PHP-FPM ワーカー数とワーカーごとの動作、有効化されたアプリケーション、Web サーバー、データベース、キャッシュ、プレビュー生成、およびバックグラウンド ジョブによって異なります。公式の管理マニュアルによると、メモリ要件はユーザー、アプリケーション、ファイル、およびサーバーのアクティビティによって大きく変動します。ワーカーを追加すると、並列リクエスト処理が改善される一方で、ピーク時の RAM 使用量が増加します。したがって、単一の PHP プロセスと単一の oCIS プロセスを比較するのではなく、ホストまたはコンテナ全体のメモリ使用量を比較してください。

ストレージはどちらのプラットフォームでも大きな影響を与える可能性があります。ディスク、ネットワークファイルシステム、オブジェクトストレージ、データベース、またはウイルス対策スキャンが遅い場合、リクエストがアプリケーションによって制限されているように見えることがあります。同様に、コールドキャッシュとウォームキャッシュでは、応答時間が同等になるとは限りません。重要なのは、どちらの製品のアイドル時間が小さいかではなく、どちらのスタックがRAMとレイテンシの予算内で実際のワークロードを完了できるかということです。

同じ条件下で比較する

1. ビルドとデプロイメントの正確な情報を記録してください。oCISバージョン、Nextcloud 28 パッチレベル、オペレーティングシステム、コンテナ制限、CPU 割り当て、データベース、ストレージバックエンド、有効になっているアプリとサービス、PHP バージョン、Web サーバーをメモしてください。可能な限り、同じハードウェアとデータパスを維持してください。一方のプラットフォームでコンテナのメモリ制限を設定し、もう一方のプラットフォームでホスト全体のメモリ使用量を混在させないでください。
2. 代表的なテストセットを使用してください。本番環境で遅く感じる操作（初期同期、増分同期、大規模ディレクトリの閲覧、ファイルのダウンロードとアップロード、共有、同時ログインなど）を含めてください。ファイル数、ファイルサイズの分布、アクティブなクライアント数、同時接続数を一定に保ってください。ステージングコピーを使用し、本番データに負荷をかけないようにしてください。
3. ベースラインを測定し、その後繰り返します。起動後のアイドルメモリ、各ワークロード中のメモリ、ピークメモリ、CPU、ディスクI/O、データベースアクティビティ、リクエストまたは同期レイテンシをキャプチャします。クリーンスタート後に1回実行し、ウォームアップキャッシュを使用して再度実行します。結果が安定しているかどうかを確認するために、各実行を十分に繰り返します。1回の実行をベンチマークとみなさないでください。
4. アプリケーションメモリとホストメモリを分離してください。コンテナの場合は、コンテナのメモリワーキングセットと制限を確認してください。Linuxプロセスの場合は、プロセスモニタとシステムメモリ統計を使用してください。また、スワップ、メモリ不足イベント、データベースメモリも監視してください。ホストキャッシュの増加はアプリケーションのメモリリークとは必ずしも同じではなく、コンテナの制限値はランタイムによって異なるメモリ使用量を報告する場合があります。

oCIS の監視については、サービス メトリクスと Prometheus エンドポイントに関するバージョン対応のドキュメントを参照してください。ownCloud 8.2 のドキュメントには、サポートされているサービスのメトリクスが記載されています。メトリクスはサービスとリリースによって異なります。Nextcloud の管理概要とシステム ツールではセットアップの警告を確認できますが、総 RAM 量を把握するにはオペレーティングシステムとデータベースの監視が必要です。テストの計測は可能な限り同一にし、単位とサンプリング間隔を記録してください。

最初に何を調整すべきですか？

1. 実際にメモリ負荷がかかっていることを確認する

スワッピング、メモリ不足による強制終了、コンテナの再起動、リクエストレイテンシの上昇など、高負荷状態が継続している場合は注意が必要です。RAM使用量が高いだけであれば、キャッシュが効果的に機能している可能性があります。スキャン中に使用量が上昇し、その後安定する場合は、メモリを増やす必要はないかもしれません。負荷が安定しているにもかかわらず使用量が上昇し続ける場合は、ログ、サービスレベルのメモリ、および制限を変更する前に実行されていたジョブを調べてください。

2. 回避可能なバックグラウンド作業を削減する

プレビュー生成、ウイルス対策スキャン、インデックス作成、同期バースト、およびスケジュールされたメンテナンスを特定してください。これらのタスクは、対話型リクエストと競合する可能性があります。負荷の高いジョブは、比較的負荷の低い時間帯に移動するか、インストールされているバージョンのドキュメントに記載されている制御機能を使用して同時実行数を減らしてください。グラフを小さく見せるためだけにセキュリティスキャンや必要なメンテナンスを無効にしないでください。まず、ジョブのコストとユーザーへの影響を定量化してください。

3. NextcloudのPHPとキャッシュの設定を意図的に調整する

Nextcloudの場合、バージョン28でサポートされているPHP構成を確認し、利用可能なRAMに合わせてPHP-FPMワーカーのサイズを設定してください。ワーカーが少なすぎるとリクエストがキューイングされ、多すぎるとメモリが枯渇する可能性があります。バージョン28のマニュアルに従い、必要に応じてサポートされているメモリキャッシュとトランザクションファイルロック用のRedisを設定してください。キャッシュはメモリを消費しますが、繰り返し操作のパフォーマンスを向上させることができるため、レイテンシとメモリ使用量を合わせて比較してください。バージョン固有のドキュメントを確認せずに、現在のNextcloudリリースからバージョン28に設定をコピーすることは避けてください。

4. oCISのメタデータとストレージの選択肢を確認する

Infinite Scale の場合、スペース数、ファイルおよびディレクトリのメタデータ、ストレージドライバ、キャッシュの動作を評価してください。公式の前提条件ドキュメントには、メモリに保持されるメタデータがアクセスと同期のパフォーマンスに影響することが説明されています。大規模なリスト表示または同期ワークロードがメモリ負荷と一致する場合は、RAM を追加する前に、関連するサービスとストレージのメトリックを比較してください。ストレージ固有のオプションは、正確な oCIS リリースに合わせて確認してください。ストレージバックエンド間でメモリの動作が同じであると想定しないでください。

5．制約要因を特定してから容量を増やす

測定対象のワークロードのレイテンシが安定していて許容範囲内であるにもかかわらずメモリ制限に達した場合は、RAMを追加するかリソース割り当てを調整して、同じテストを繰り返してください。メモリに余裕があるにもかかわらずレイテンシが悪い場合は、データベースクエリ、ストレージレイテンシ、ネットワークスループット、ロック、CPU飽和度を調査してください。適切に設計されたデプロイメントでは、oCISサービスのスケーリングやワーカーの追加によってスループットを向上させることができますが、リソース需要と運用上の複雑さも変化します。結果の帰属を明確にするため、一度に1つの変数のみを変更してください。

結果を確認する方法

変更を加えるたびに元のワークロードを繰り返し実行し、ピーク時および定常状態のRAM使用量、スワップアクティビティ、p95リクエストまたは同期レイテンシ（利用可能な場合）、完了した転送数、エラーまたは再起動回数などの同じ指標を比較してください。修正が成功すれば、他のメモリ負荷を発生させることなく、ユーザーが報告した動作が改善されるはずです。公平なプラットフォーム比較のために、結果の横にテスト条件を記載し、キャッシュがコールド状態かウォーム状態かを明記してください。小規模なサーバーやデータセットから一般化しないでください。

最後に、Nextcloud 28 のサポート終了は、別途の運用上の問題として扱ってください。プロジェクトのアップグレードガイダンスに従ってサポート対象のリリースに移行し、その後比較を再実行してください。新しいコード、PHP バージョン、アプリ、および移行の変更によってフットプリントが変わる可能性があるためです。現在のデプロイメント要件とリリース固有の設定については、ownCloud Infinite Scale 8.2 の前提条件、Prometheus 用の ownCloud メトリクス、Nextcloud 28 のシステム要件、Nextcloud 28 のメモリ キャッシュ、およびNextcloud のメンテナンスとリリース スケジュールを参照してください。