システム要件

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

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

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

• Azure DevOps との VCS 統合 (TFS)

• VSS と VCS の統合

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

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

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

  へ

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

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

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

サーバー負荷率

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

• ビルド構成の数

• 履歴内のビルドの数

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

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

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

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

• TeamCity Web ページを開いているユーザーの数

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

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

• すべての VCS ルートで 1 日あたり 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 ディスク (1 つは一般用、1 つはアーティファクト、ログ、キャッシュ用、1 つはデータベースストレージ用)。次のセットアップでテスト済み:

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

• 1 日 1500 以上のビルド

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

• 100 ビルドエージェント

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

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

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

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

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

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

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

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

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

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

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

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

各ビルドによって生成されるサーバーの負荷は、このビルドのデータの量（ログ、テスト、障害の詳細、インスペクション / 重複する問題の数など）によって異なります。データの量を合理的に制限する（大きな出力をビルドアーティファクトとして公開する、標準出力に出力しない、インスペクションプロファイルを微調整して、最も重要なインスペクションヒットの限定されたセットを報告するなど）と、サーバーをスケーリングしてより多くの同時処理を処理できます。ビルドします。

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

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

パフォーマンスのための TeamCity サーバーの設定

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

• サーバーの状態レポート（非表示のレポートを含む）を定期的に確認してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一般的な要件

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

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

• 次のディレクトリへの完全な許可（読み取り / 書き込み / 削除）を再帰的に持ちます: <Agent Home Directory> （自動エージェントアップグレードおよびエージェントツールのサポートに必要）、<Agent Work Directory>、<Agent Temp Directory>、エージェントシステムディレクトリ（buildAgent.properties ファイルの workDir、tempDir、systemDir パラメーターによって設定）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ビルド関連の権限

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

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

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

TeamCity サーバーと同じマシンでビルドエージェントを実行できますが、推奨されるアプローチは、ビルドエージェントごとに個別のマシン（仮想の場合もあります）を使用することです。同じマシンに複数のエージェントをインストールすることを選択した場合は、発生する可能性のある潜在的な CPU、ディスク、メモリ、ネットワークのボトルネックを考慮してください。パフォーマンスモニタービルド機能は、ライブデータの分析に役立ちます。

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

データベースサイズ

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

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

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

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

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

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

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

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

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

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

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

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

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

特に 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 操作を消費する可能性があります。