Collabora OnlineのCPU使用率が高い問題を解決する方法（loolwsd / coolwsdより）

Collabora Online が突然サーバーの CPU の大部分を使用するようになった場合、最初に行うべき最も重要な手順は、サーバーを繰り返し再起動したり、すぐに非常に低い CPU 制限を設定したりしないことです。まず、負荷の原因が通常のドキュメント作業、異常なドキュメントセッション、並列処理の過剰、クリーンアップされていないアイドルセッション、またはバージョン固有の不具合のいずれであるかを判断します。プロセス名は、coolwsd最新リリースとloolwsd古いインストールの両方で異なる場合があります。

具体例として、 Nextcloudの背後でCollabora Onlineを実行している8vCPUサーバーを想像してみてください。ドキュメントを編集しているユーザーはごく少数ですが、CollaboraコンテナのCPU使用率は数分間250%から350%程度にとどまります。これはこのガイド全体を通して使用されている架空の例であり、実際の運用環境での測定ベンチマークやレポートではありません。

2026年10月現在、Collaboraの最新安定版ブランチは26.04で、公式リリースノートにはCollabora Online 26.04.3.3が2026年9月14日にリリースされたと記載されています。現在の構成テンプレートではこのcoolwsd名前が使用されています。Collaboraの移行ツールには、6.4以前のインストール用の古い/etc/loolwsd/loolwsd.xmlパスがまだ記載されているため、管理者は両方の名前を目にする可能性があります。

1. 実際にCPUを消費しているプロセスを確認します。

オペレーティングシステムまたはコンテナレベルから始めましょう。横に高い数値が表示されていても、coolwsd必ずしもコーディネーションデーモン自体がすべての負荷の高いドキュメント処理を行っているとは限りません。Collaboraはドキュメントセッションのためにkit/forkitプロセスも実行するため、設定を変更する前にプロセスツリーとプロセスごとのCPU使用率を確認する必要があります。

ps -eo pid,ppid,pcpu,pmem,etime,cmd --sort=-pcpu | head -n 25
top -H -p $(pgrep -d, -f 'coolwsd|loolwsd|coolkit|loolkit|forkit')

Dockerの場合、コンテナ全体も確認してください。

docker stats --no-stream

具体例として、コンテナのCPU使用率が300%近くになり、キットプロセスが常にプロセスリストの上位に表示されているとします。これは、サーバー全体が過負荷状態にあるという一般的な推測ではなく、特定のドキュメントセッションがアクティブになっていることを示唆しています。

2. トップレベルの指標だけに頼るのではなく、Collabora独自の指標を確認する

Collabora Online は、Prometheus 互換のメトリクスを で公開しています/cool/getMetrics。現在の SDK マニュアルによると、このエンドポイントでは、CPU とメモリの使用状況、実行中のキットプロセス、ビュー、その他のサーバー使用状況データを報告できます。認証なしでのアクセスが明示的に設定されていない限り、管理コンソールと同じ認証方式が使用されます。

トラブルシューティングを簡略化するためだけに、メトリクスエンドポイントを公開しないでください。公式のHelm設定には、/cool/getMetricsイングレスでのブロックURLと管理URLの例も含まれています。可能な限り、認証済みの内部パスを使用してください。

CPU使用率とアクティブなドキュメントまたはビューとの関係を調べてください。正当な編集作業に伴ってCPU使用率が上昇・下降する場合は、処理能力または同時実行性に問題がある可能性があります。対応するインタラクティブな作業がないにもかかわらずCPU使用率が高いままの場合は、古いセッション、問題のあるドキュメント、繰り返し実行されるバックグラウンド作業、またはソフトウェアの問題を調査してください。

3. CPU使用率が上昇する正確な時刻前後のログを確認する

systemdによって管理されるパッケージのインストールの場合：

journalctl -u coolwsd --since "15 minutes ago" --no-pager
journalctl -u coolwsd -f

Dockerの場合：

docker logs collabora --since 15m
docker logs -f collabora

サービスまたはコンテナに別の名前が付いている場合は、その名前に置き換えてください。ドキュメントの読み込みの繰り返し、キットの作成の繰り返し、保存の失敗、クラッシュ、再接続ループ、または同じドキュメントキーが繰り返し出現するなどのエラーがないか確認してください。ドキュメントのオープン、再計算、レンダリング、変換、エクスポート中に一時的にCPU使用率が高くなるのは正常な動作の場合があります。より深刻な警告サインは、CPU使用率が継続的に高いにもかかわらず、有用な処理が進まない、または同じエラーが繰り返される場合です。

4. 一度に1つのドキュメントでスパイクを再現する

仮想サーバーに戻ります。キットプロセスのいずれかが高負荷状態にある場合は、疑わしいドキュメントを閉じるか隔離し、CPU使用率が低下するかどうかを確認します。次に、プロセスリストとメトリクスを監視しながら、静かな時間帯に同じファイルを開きます。簡単なテストドキュメントを使用して、この手順を繰り返します。

この比較は、サービス全体を即座に再起動するよりも有用です。

• もし特定のファイルだけが確実にパフォーマンスの急上昇を引き起こすのであれば、そのファイルの内容、数式、埋め込みオブジェクト、レンダリングの負荷、あるいはドキュメント固有のバグが原因である可能性が高い。
• 複数のユーザーが同時にアクセスした際に、どのファイルでも同様のアクセス集中が発生する場合は、サーバーの容量と同時接続数を調査してください。
• ユーザー操作がすべて停止した後もCPU使用率が高いままの場合は、クリーンアップ、古いキット、繰り返されるバックグラウンドタスク、またはリグレッションに焦点を当ててください。
• 問題がアップグレード直後に発生した場合は、他の多くの変数を変更する前に、旧バージョンと新バージョンを記録してください。

5. 1つのドキュメントがコアを独占できる場合は、ドキュメントごとの同時実行数を減らす。

現在のCollabora構成テンプレートでは、per_document.max_concurrencyドキュメント処理中に使用されるスレッドの最大数を規定しています。テンプレートのデフォルト値は4です。ホストの規模が小さい場合や、複雑なドキュメント1つがマシンの処理能力を占有してしまう可能性がある場合は、この値を減らすことでCPU使用率をより予測しやすくなります。

例えば、値2をテストすることができます。

<per_document>
    <max_concurrency>2</max_concurrency>
</per_document>

数字の2を盲目的にコピーしないでください。ユーザーが日常的に大規模なスプレッドシートやプレゼンテーションを操作し、サーバーに十分なコア数がある場合、低い値を設定すると処理速度が低下する可能性があります。設定を1つ変更し、同じワークロードを再現して、CPU、応答性、および完了時間を比較してください。

6. クリーンアップとアイドルセッションの設定を積極的にする前に確認してください。

現在のcoolwsd.xmlテンプレートには、リソースを大量に消費するアイドル状態のドキュメントをクリーンアップするロジックが含まれています。執筆時点では、クリーンアップチェックの間隔は10,000ミリ秒、異常動作期間は60秒、アイドル状態のしきい値は300秒、CPU使用率が85%を超えた場合にドキュメントがクリーンアップ対象となります。また、ドキュメントごとのアイドルタイムアウトは3,600秒です。

同じテンプレートには、ビューごとのタイムアウト設定が含まれています。現在の設定では、フォーカスが外れたブラウザビューが暗くなり更新が停止するまで300秒、非アクティブなビューが同様に処理されるまで900秒となっています。これらのビュータイムアウトは、ドキュメントセッション全体を即座にアンロードすることとは異なります。

グラフの見栄えを良くするためだけに、CPUしきい値を極端に低く設定することは避けてください。クリーンアップの目的は、リソースを大量に消費する不良ドキュメントやアイドル状態のドキュメントを検出することであり、通常の編集作業が計算負荷の高いものになったからといって終了させることではありません。

7. 制御された構成変更を保存した後のみ再起動してください。

まず、現在アクティブな設定をバックアップしてください。パッケージのインストールでは通常、. を使用します/etc/coolwsd/coolwsd.xml。Docker デプロイメントでは、環境変数またはコマンドラインのオーバーライドとしてオプションを渡したり、設定ファイルをコンテナにマウントしたりする場合があります。編集する前に、実際にどのソースがアクティブになっているかを確認してください。

パッケージのインストール方法：

sudo cp /etc/coolwsd/coolwsd.xml /etc/coolwsd/coolwsd.xml.before-cpu-tuning
sudo systemctl restart coolwsd
systemctl status coolwsd --no-pager

Dockerコンテナの場合：

docker restart collabora
docker ps --filter name=collabora

再起動だけで一時的にCPUの問題が解消されても、問題が繰り返し再発する場合は、それは診断情報であって、恒久的な解決策ではありません。どのようなワークロードや状態が再発の原因となっているのかを説明できるまで、調査を続けてください。

8. 同じ作業負荷の下で、前後を比較する

同じドキュメント、ほぼ同じユーザー数、同じ操作手順を使用してください。単一の瞬間を比較するのではなく、数分間測定してください。この例のシナリオでは、再現されたワークロード中にサーバーが飽和状態を維持せず、ドキュメントの開き、編集、保存、およびコラボレーションが許容範囲内で動作する状態が成功とみなされます。

チューニングではなくアップデートを行うべきタイミングは？

特定の Collabora バージョンで問題が発生し、特定のファイルまたは操作で再現できる場合は、設定の調整だけではソフトウェアの不具合を隠蔽するだけかもしれません。Collabora では、現在の安定版ブランチの最新バージョンを使用することをお勧めします。2026 年 10 月 7 日現在、公式の 26.04 リリース ノート ページには、最新の Collabora Online リリースとして 26.04.3.3 が記載されています。

CODEユーザーの皆様へ：Collaboraは、開発版は小規模チーム、家庭での使用、開発、新機能の試用に適していると説明しており、本番環境での使用を想定していないことをご留意ください。そのため、CODEで本番環境における問題が発生した場合は、開発版の動作を延々と調整するよりも、サポート対象のCollabora Online製品に移行する方が賢明な選択となる可能性があります。

やってはいけないこと

• coolwsd数値が大きいからといって、メモリリークや無限ループが発生していると決めつけないでください。
• CPU障害発生時にデバッグログやトレースログを永続的に有効にするのは、実際に必要な場合を除いて避けてください。詳細なログ記録は、それ自体がオーバーヘッドとストレージ負荷を増加させます。
• 監視の利便性のためだけに、管理コンソールやメトリクスエンドポイントをインターネット上に公開しないでください。
• 通常のセッションが強制終了されるまでは、クリーンアップのしきい値を下げないでください。
• CPUクォータを最初の診断手順として使用しないでください。ハードリミットは共有ホスト上の隣接ユーザーを保護するのに役立ちますが、CPUの問題が原因を明らかにせずにドキュメントのレンダリング速度の低下やタイムアウトにつながる可能性があります。

推奨されるトラブルシューティング手順

1. ビジー状態のプロセスがcoolwsd、古いプロセスloolwsd、または子キット/フォークキットプロセスであるかどうかを確認してください。
2. DockerまたはホストのCPU、メモリ、アクティブなドキュメント、およびビューを記録します。
3. ログをスパイクが発生した正確な時間帯と関連付ける。
4. 疑わしい文書を1つ用意し、次に単純な対照文書を用意して、再現を試みてください。
5. per_document.max_concurrency1つのドキュメントが並列CPUを過剰に使用している場合にのみテストしてください。
6. クリーンアップとアイドル設定を見直し、不必要に攻撃的な設定にならないようにしてください。
7. 制御された構成変更を行うたびに再起動し、サービスの状態を確認してください。
8. 同じワークロードを前と後で比較し、動作がバージョン固有のものであるように見える場合は、現在の安定版リリースを確認してください。

公式資料

このガイドに記載されている設定の詳細は、現在の Collabora Online ソース テンプレート ( Collabora Online coolwsd.xml 設定テンプレート)に基づいています。公式 SDK マニュアルには、ログ記録、パフォーマンス制御、および Prometheus 互換のメトリクス エンドポイントについて記載されています ( Collabora Online SDK マニュアル)。バージョンを確認するには、メーカーのCollabora Online 26.04 リリース ノートを参照してください。開発版の想定される使用方法については、公式のCODE 26.04 リリース アナウンスを参照してください。

実際の目標は、Collabora OnlineのCPU使用率を可能な限り低く抑えることではありません。編集やコラボレーションのパフォーマンスを許容範囲内に保ちつつ、CPU使用率を説明可能で、かつ有用な作業量に見合ったものにすることです。