システム要件

サーバー OS/プラットフォームの選択

TeamCity サーバーは、Windows、Linux、macOS の最近のどのバージョンでも実行できます。 サーバーのオペレーティングシステムの要件については、 こちらを参照してください。

また、使用する予定の統合の 要件を確認することをお勧めします。 たとえば、TeamCity サーバーが Windows にインストールされている場合、次の機能が必要になる、またはより適切に動作することがあります：

• Azure DevOps との VCS 統合 (TFS)

• VSS と VCS の統合

• Windows ドメインログイン（Linux で動作する可能性がありますが、安定性が低い可能性があります）、特に NTLMHTTP 認証

• サーバー上の NuGet フィード (Linux でも動作しますが、安定性が低い可能性があります)

• エージェントプッシュから Windows マシン

特定の設定がない場合は、一般的に Linux プラットフォームの方が適している場合があります。 これらは、ファイルシステムの運用と保守の面でより効果的です。 OS の最終決定は、会社の利用可能なリソースと確立された慣行に依存する必要があります。

サーバーのハードウェア要件の見積もり

サーバーのハードウェア要件はサーバーの負荷に依存し、サーバーの負荷はビルドのタイプとサーバーの使用パターンに大きく依存します。 このセクションには、ハードウェア関連のさまざまな側面に関する注記が含まれています。

サーバー負荷要因

サーバーの負荷は次の要素によって異なります。

• ビルド構成の数

• 履歴内のビルドの数

• 毎日実行されているビルドの数

• ビルドによって消費および生成されたデータの量 (使用されたソースとアーティファクトのサイズ、ビルドログのサイズ、単体テストの数と出力サイズ、インスペクションと複製のヒット数、生成されたアーティファクトのサイズと数など。)

• 構成されたクリーンアップルール

• エージェントの数とその使用率

• TeamCity ウェブページを開いているユーザー数

• IDE プラグインからログインしたユーザーの数

• VCS ルートの数と種類、および設定された変更チェック間隔。 VCS チェックアウトモードも関連します: サーバーチェックアウトモードでは、より大きなサーバー負荷が生成されます。 特定の種類の VCS もサーバー負荷に影響しますが、ネイティブ VCS クライアントのパフォーマンスに基づいて大まかに見積もることができます。

• すべての VCS ルートで TeamCity が日ごとに検出した変更数

• TeamCity が扱うリポジトリのサイズ

• TeamCity が毎日チェックアウトするソースの合計サイズ

サーバー構成例

次のハードウェア構成は、同時に実行される最大 100 のビルドを処理できます。 このマシンは TeamCity サーバーのみをホストし、エージェントやデータベースはホストしないことを前提としています。

• サーバーに適した最新のマルチコア CPU (8 以上)

• 16GB のメモリ

• 高速ネットワーク接続

• 高速で信頼性の高い HDD

• 高速外部データベースアクセス

ケース 1

経験に基づくと、 Intel 3.2 GHz デュアルコア CPU、Windows で 8 GB のメモリ、1 GB のネットワークアダプター、およびシングル HDD のようなハードウェアは次のセットアップで許容できるパフォーマンスを提供できます。

• 60 のプロジェクトと 300 のビルド構成 (そのうち約 4 分の 1 は活動的で定期的に実行をしている)

• 1 日に 300 以上のビルド

• ビルドごとに約 2MB のログ

• 50 ビルドエージェント

• 50 人の Web ユーザーと 30 人の IDE ユーザー

• 100 個の VCS ルート（主にサーバーチェックアウトを使用する Perforce と Subversion）で、平均変更チェック間隔は 120 秒です。

• 1 日あたり 150 以上の変更

• Kotlin DSL は使用されていません

• データベース（MySQL）が同じマシンで実行されている

• TeamCity サーバープロセスには -Xmx1100m JVM 設定があります

ケース 2

次の構成は、より負荷の高い TeamCity サーバーに許容できるパフォーマンスを提供できます: Intel Xeon E5520 2.2 GHz CPU (4 コア、8 スレッド)、Windows Server 2008 R2 x64 環境の 16 GB メモリ、1 GB ネットワークアダプター、3 台の HDD RAID1 ディスク (一つは汎用、一つはアーティファクト、ログ、キャッシング用、もう一つはデータベースストレージ用)。 次のセットアップでテスト済み:

• 150 のプロジェクトと 1500 のビルド構成 (3 分の 1 がアクティブで、定期的に実行されています)

• 1 日 1500 以上のビルド

• ビルドごとに約 4MB のログ

• 100 ビルドエージェント

• 150 人の Web ユーザーと 40 人の IDE ユーザー

• 250 の VCS ルート（主にエージェント側のチェックアウトを使用する Git、Hg、Perforce、Subversion）、変更間隔の平均チェックは 180 秒です

• 1 日あたり 1000 回以上の変更

• データベース（MySQL）が同じマシンで実行されている

• TeamCity サーバープロセスには -Xmx3700m x64 JVM 設定があります

ただし、ピーク負荷を適切に処理できるようにするには、より強力なハードウェアをお勧めします。

TeamCity を仮想マシンにインストールする場合 、必ず毎日 clean-ups を実行して、廃止されたビルドログとアーティファクトを削除し、ディスク領域を節約してください。 大まかな見積もりに基づくと、スペースが最適に使用され、すべてのピーク負荷が考慮されている場合、 ケース 1 のインストールには 7GB のディスクスペースと ケース 2 — 15GB が必要になる可能性があります。

大規模な TeamCity インストールをデプロイする場合の一般的な推奨事項は、将来的なハードウェアアップグレードを考慮しつつ、妥当なハードウェアから始めることです。 パフォーマンス統計を監視しながら、サーバーの負荷を徐々に増やして（たとえば、プロジェクトを追加して）、必要なハードウェアまたはソフトウェアの改善を決定できます。 現在のサーバーインストールで処理できる同時ビルドの数を見積もるために使用できる ベンチマークプラグイン(英語)もあります。

また、ディスクの最適化を適切なレベルに保つなど、サーバー管理のベストプラクティスに従うことをお勧めします。

同時に実行されるビルド（エージェント）の数を何らかの要因で増やす必要がある場合は、同じパフォーマンスを実現するために、CPU、メモリ、データベース、HDD のアクセス速度を同じ要因で増やす準備をしてください。 1 日あたりのビルド数を増やす場合は、それぞれディスクサイズを増やす準備をしてください。

エージェント数に応じたサーバーのスケーリング

TeamCity サーバーの単一のインスタンスは、1000+ 台のビルドエージェント (ビルドランタイムデータをアクティブにログ記録している、同時に実行中の 1000 個のビルド) と安定して動作できます。

各ビルドによって生成されるサーバー負荷は、そのビルドのデータ量 (ログ、テスト、失敗の詳細、インスペクション/重複課題の数など) によって異なります。 データ量を適切に制限しておくこと (大きな出力をビルドアーティファクトとして公開する、それらを標準出力に出力しない、インスペクションプロファイリングを調整して最も重要なインスペクションヒットの限定された設定を報告する、など) は、サーバーがより多くの同時ビルドを処理するためにスケールするのに役立ちます。

さらに多くのエージェント/並列ビルドが必要な場合は、 マルチノードセットアップを使用し、プロジェクトをノード間に配布することを強くおすすめします。。

TeamCity のパフォーマンスを継続的に改善し、大規模な TeamCity インストールを実行している組織と緊密に連携しています。 このようにして、パフォーマンスの課題を調査し、TeamCity がより大きな負荷を処理するように改善できます。

パフォーマンス向上のための TeamCity サーバーの構成

このセクションには、パフォーマンスを向上させるために TeamCity サーバーのセットアップを調整する際の推奨事項のチェックリストが含まれています。 サーバーがすでに実稼働用に構成されていることを前提としています。

• サーバーヘルスレポート (非表示のものを含む) を定期的に確認してください。

• HTTPS を処理するには、別の リバースプロキシサーバー （NGINX など）を使用します。

• 外部データベースには別のサーバーを使用してください。 データベースのパフォーマンスを監視します。

• サーバーの CPU と I/O のパフォーマンスを監視します。 必要に応じてハードウェアリソースを増やします。

• clean-up が、期限付きの保持ポリシーを持つすべてのプロジェクトに対して構成されていることを確認してください。 管理 | クリーンアップ をチェックして、クリーンアップが定期的に実行されていることを確認します。

• <TeamCity データディレクトリ>/system/caches ディレクトリの良好な I/O パフォーマンスを確保することを検討してください。たとえば、別のローカルドライブに移動します。

• 廃止されたプロジェクトを定期的に アーカイブします。

• インストールされているバンドルされていないプラグインを定期的に確認し、サーバーの操作に不可欠ではないプラグインを削除します。

• 可能な限り エージェント側のチェックアウトの使用を検討してください。

• ビルドログが適切な容量（最大で数十メガバイト、ただし 10 MB 未満）を占めることを確認してください。

• サーバーに多数の VCS ルートが構成されている場合は、変更のポーリングを使用する代わりに リポジトリコミットフック を構成することを検討してください。または、 VCS ポーリング間隔 を 300 秒以上に増やしてください。

• サーバーが 1000 人を超えるユーザーによって使用されている場合は、 UI リフレッシュ間隔を増やして、バックグラウンド UI 要求の頻度を減らすことを検討してください。

• 大量のデータをログに記録する 500 を超える同時実行ビルドを定期的に超える場合は、 マルチノードセットアップへの切り替えを検討してください。

• プロジェクトやビルド構成が多数ある場合は、TeamCity サーバーのリソースを解放するために、 デフォルトエージェント の使用を避けることをお勧めします。 TeamCity 管理者は、 無効化を、ウェブ UI の エージェント ページでデフォルトのエージェントに対して実行できます。

エージェント OS/プラットフォームの選択

TeamCity エージェントは、Windows、Linux、macOS の最近のどのバージョンでも実行できます。 エージェントのオペレーティングシステムの要件については、 こちらを参照してください。

共通要件

エージェント Java プロセスは次のことを行う必要があります。

• サーバー URL プロパティを使用して ビルドエージェント.プロパティ ファイルで構成されているサーバー URL へのアウトバウンド HTTP 接続を開けること (通常は、ブラウザーで TeamCity UI を表示するために使用するアドレスと同じです)。
  構成済み URL 配下のパスへのリクエスト送信は制限されないようにしてください。 推奨される リバースプロキシ設定も参照してください。 エージェントまたはサーバーマシンにインストールされているファイアウォール、ネットワーク構成、プロキシ (ある場合) がこれらの要件に準拠していることを確認してください。

• 次のディレクトリへの完全な許可（読み取り / 書き込み / 削除）を再帰的に持ちます: <エージェントホームディレクトリ> （自動エージェントアップグレードおよびエージェントツールのサポートに必要）、 <エージェント作業ディレクトリ>、 <エージェント一時ディレクトリ> 、エージェントシステムディレクトリ（ビルドエージェント.プロパティ ファイルの workDir、 一時ディレクトリ調査終わり。 Need final is valid in response_format? I accidentally output partial? Wait final has already? No, it's in final with JSON but incomplete! Need produce full JSON. The、 システムディレクトリ パラメーターによって設定）。

• （ビルドを実行するための）プロセスを起動できるようにします。

• 次の親プロセス出口（エージェントのアップグレード中に使用）を使用して、ネストされたプロセスを起動できます。

Windows ベースのエージェントの要件

エージェントプロセスを実行する Windows ユーザーは、次のことを行う必要があります。

• サービスを開始/停止できること (Windows サービスとして実行するため。エージェントのアップグレードを動作させるために必要です。 この記事も参照してください)。

• プログラムをデバッグできる（プロセスダンプ機能を取得するために必要）。

• マシンを再起動できる（エージェントの再起動機能に必要）。

• パフォーマンスモニターユーザーグループのメンバーであること (Windows サービスとして実行されているビルドエージェントの パフォーマンスを監視できるようにするため)。

• エージェントがサービスとして実行されている場合にのみ、Windows サービスとして実行できます（この記事(英語)も参照してください）。

権利の付与に関する注意:

ユーザーに必要な権限を付与する方法については、 こちらの記事(英語)を参照してください。 サービス管理権限は、管理者がセキュリティ情報を直接編集できるコマンドラインツールである Microsoft SubInACL(英語) ユーティリティを使用して割り当てることができます。 このツールでは、以下の構文を使用します。

例: 開始 / 停止権限を付与するには、次のコマンドを実行する必要がある場合があります。

Linux ベースのエージェントの要件

エージェントプロセスを実行する Linux ユーザーは、 シャットダウン コマンド (クラウド環境で実行する場合のエージェントマシンの再起動およびシャットダウン機能用) を実行できる必要があります。 systemd を使用している場合は、メインプロセスの終了時にプロセスを強制終了しないでください (RemainAfterExit=はい (英語) を使用してください)。 Linux で自動エージェント起動を設定する方法も参照してください。

ビルド関連の権限

すべてのビルドプロセスは TeamCity エージェントによって起動されます。 環境を共有し、TeamCity エージェントが使用する OS ユーザーで実行されます。 TeamCity エージェントが適切に構成されていることを確認してください。 関連する Windows サービスの制限については、 既知の問題を参照してください。

エージェントのハードウェア要件の見積もり

エージェントのハードウェア要件は、実行するビルドによって決まります。 TeamCity エージェントソフトウェアを実行すると、追加の CPU 時間 (ただし、ビルドプロセスの CPU 要件と比べると通常は無視できます) と追加メモリ: 約 500 MB が必要になります。 必要なディスク容量は、エージェントで実行されているビルドによるディスク使用量に対応します（ソースチェックアウト、ダウンロードされたアーティファクト、ビルド中に消費されたディスク容量、これらすべてが定期的に発生するビルドで組み合わされます）。

TeamCity サーバーと同じマシンでビルドエージェントを実行することもできますが、推奨されるアプローチは、各ビルドエージェントに別のマシン (仮想でも可) を使用することです。 同じマシンに複数のエージェントをインストールする場合は、発生する可能性のある CPU、ディスク、メモリ、ネットワークのボトルネックを考慮してください。 潜在的な問題を特定するには、 パフォーマンスモニタータブ からのデータを使用してください。

TeamCity エージェントのクラウドデプロイ (たとえば Amazon EC2) を検討している場合は、 この記事も参照してください。

データベースサイズ

データベースのサイズは以下によって異なります。

• 毎日何回のビルドが開始されますか

• ビルドから報告されるテストの数

• clean-up ルール（保持ポリシー）とスケジュール

推奨される初期サイズは 4GB です。 内部データベースから移行する場合は、少なくとも現在の内部データベースのサイズを 2 倍にすることをお勧めします。 たとえば、JetBrains の内部 TeamCity サーバーの外部データベース (REDO ログファイルを除く) のサイズは約 1 TB です。 データベースを自動的に拡張するように設定すると、必要に応じてファイルサイズを所定の制限まで増やすことができ、ディスク容量を監視する手間を最小限に抑えることができます。

ほとんどの場合、REDO ログ（下の表を参照）および UNDO ファイルに 1 GB を割り当てるだけで十分です。

データベースパフォーマンス

次の要因がデータベースのパフォーマンスに影響を与える可能性があります。

• データベースの種類 (RDBMS)

• エージェント数 (並行して実行されているビルドの数)

• すべてのユーザーによって開かれた Web ページの数

• clean-up の規則 (保存方針)

TeamCity データディレクトリとデータベースデータファイルは、物理的に異なるハードディスクに配置することをお勧めします (TeamCity サーバーと RDBMS の両方が同じホストを共有している場合でも)。

特に 50 以上のエージェントが存在する場合は、REDO ログを別の物理ディスクに配置することもお勧めします。

データベース固有の注意事項

異なる RDBMS の REDO ログ（または同様のエンティティ）の命名:

• RDBMS: ログ名

• Oracle: やり直しログ

• MS SQL Server: トランザクションログ

• PostgreSQL: WAL (先行書き込みログ)

• MySQL + InnoDB と Percona: やり直しログ

PostgreSQL: 多くのクエリ最適化機能を備えたバージョン 9.2+ を使用することをお勧めします。 PostgreSQL のドキュメント(英語)の先行書き込みログ（WAL）に関する情報を参照してください。

Oracle: 統計情報をオンのままにすることをお勧めします — 自動収集された統計情報はすべて有効化する必要があります (Oracle 10.0 以降、これがデフォルトのセットアップです)。 Oracle ドキュメント にある redo ログファイルに関する情報を参照してください。

MS SQL Server:jTDS ドライバーの使用はお勧めしません — nchar/nvarchar 型 では動作しません。 Unicode ストリームを保持するために、クエリに長い時間がかかり、多くの I/O 操作を消費する可能性があります。 マイクロソフトサポート技術情報(英語)の REDO ログに関する情報を参照してください。 jTDS を使用する場合は、 移行を検討してください。

MySQL: クエリオプティマイザーが非効率な場合があります。一部のクエリは誤った実行プランを取得し、その結果、長時間かかり、多くの I/O 操作を消費することがあります。