Reference architecture: up to 10,000 users · Gitlab 中文文檔

# Reference architecture: up to 10,000 users > 原文：[https://docs.gitlab.com/ee/administration/reference_architectures/10k_users.html](https://docs.gitlab.com/ee/administration/reference_architectures/10k_users.html) * [Footnotes](#footnotes) # Reference architecture: up to 10,000 users[](#reference-architecture-up-to-10000-users "Permalink") 該頁面描述了多達 10,000 個用戶的 GitLab 參考架構. 有關參考架構的完整列表，請參見[可用參考架構](index.html#available-reference-architectures) . > * **支持的用戶（大約）：** 10,000 > * **高可用性：** True > * **測試 RPS 速率：** API：200 RPS，網站：20 RPS，Git：20 RPS | Service | Nodes | 配置（ [8](#footnotes) ） | GCP | AWS | Azure | | --- | --- | --- | --- | --- | --- | | 亞搏體育應用程序軌道（ [1](#footnotes) ） | 3 | 32 個 vCPU，28.8GB 內存 | n1-highcpu-32 | c5.9xlarge | F32s v2 | | PostgreSQL | 3 | 4 個 vCPU，15GB 內存 | n1-standard-4 | m5.xlarge | D4s v3 | | PgBouncer | 3 | 2 個 vCPU，1.8GB 內存 | n1-highcpu-2 | c5.large | F2s v2 | | 吉塔利（ [2](#footnotes) ）（ [5](#footnotes) ）（ [7](#footnotes) ） | X | 16 個 vCPU，60GB 內存 | n1-standard-16 | m5.4xlarge | D16s v3 | | Redis（ [3](#footnotes) ）-緩存 | 3 | 4 個 vCPU，15GB 內存 | n1-standard-4 | m5.xlarge | D4s v3 | | Redis（ [3](#footnotes) ）-隊列/共享狀態 | 3 | 4 個 vCPU，15GB 內存 | n1-standard-4 | m5.xlarge | D4s v3 | | Redis 前哨（ [3](#footnotes) ）-緩存 | 3 | 1 個 vCPU，1.7GB 內存 | g1-small | t2.small | B1MS | | Redis 前哨（ [3](#footnotes) ）-隊列/共享狀態 | 3 | 1 個 vCPU，1.7GB 內存 | g1-small | t2.small | B1MS | | Consul | 3 | 2 個 vCPU，1.8GB 內存 | n1-highcpu-2 | c5.large | F2s v2 | | Sidekiq | 4 | 4 個 vCPU，15GB 內存 | n1-standard-4 | m5.xlarge | D4s v3 | | 對象存儲（ [4](#footnotes) ） | - | - | - | - | - | | NFS 服務器（ [5](#footnotes) ）（ [7](#footnotes) ） | 1 | 4 個 vCPU，3.6GB 內存 | n1-highcpu-4 | c5.xlarge | F4s v2 | | 監控節點 | 1 | 4 個 vCPU，3.6GB 內存 | n1-highcpu-4 | c5.xlarge | F4s v2 | | 外部負載平衡節點（ [6](#footnotes) ） | 1 | 2 個 vCPU，1.8GB 內存 | n1-highcpu-2 | c5.large | F2s v2 | | 內部負載平衡節點（ [6](#footnotes) ） | 1 | 2 個 vCPU，1.8GB 內存 | n1-highcpu-2 | c5.large | F2s v2 | ## Footnotes[](#footnotes "Permalink") 1. 在我們的體系結構中，我們使用 Puma Web 服務器運行每個 GitLab Rails 節點，并將其工作程序數量設置為 90％的可用 CPU 以及四個線程. 對于運行帶有其他組件的 Rails 的節點，應該相應地降低 worker 的值，我們發現 50％達到了很好的平衡，但這取決于工作量. 2. Gitaly 節點的要求取決于客戶數據，特別是項目數量及其規模. 對于 HA 環境，我們建議絕對最少使用兩個節點，并且在支持 50,000 個或更多用戶時，至少應使用四個節點. 我們還建議每個 Gitaly 節點存儲的數據不得超過 5TB，并且將[`gitaly-ruby`工作者](../gitaly/index.html#gitaly-ruby)的數量設置為可用 CPU 的 20％. 根據以上建議，應結合其他節點并結合對預期數據大小和分布的審查. 3. 推薦的 Redis 設置因架構的大小而異. 對于較小的體系結構（少于 3000 個用戶），一個實例就足夠了. 對于中型安裝（3,000-5,000），我們建議為所有課程使用一個 Redis 集群，并且 Redis Sentinel 與 Consul 一起托管. 對于較大的體系結構（10,000 個或更多用戶），我們建議分別為 Cache 類和隊列和 Shared State 類運行一個單獨的[Redis 群集](../redis/replication_and_failover.html#running-multiple-redis-clusters) . 我們還建議您為每個 Redis 群集分別運行 Redis Sentinel 群集. 4. 對于 LFS，Uploads，Artifacts 等數據對象.由于性能和可用性更好，我們建議盡可能在 NFS 上使用[對象存儲服務](../object_storage.html) . 5. NFS 可以用作存儲庫數據（替代 Gitaly）和對象存儲的替代方法，但是出于性能原因，通常不建議使用 NFS. 請注意，但是[GitLab Pages](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/196)是必需的. 6. 我們的架構已通過[HAProxy](https://www.haproxy.org/)作為負載均衡器進行了測試和驗證. 盡管也可以使用具有類似功能集的其他負載均衡器，但這些負載均衡器尚未經過驗證. 7. 我們強烈建議為任何 Gitaly 或 NFS 節點設置 HDD 之上的 SSD 磁盤，其讀操作的吞吐量至少為 8000 IOPS，寫操作的吞吐量至少為 2,000 IOPS，因為這些組件的 I / O 繁重. 這些 IOPS 值僅建議作為啟動器使用，因為隨著時間的推移，它們可能會根據環境工作負載的規模而調整得更高或更低. 如果您正在 Cloud provider 上運行環境，則可能需要參考其文檔以了解如何正確配置 IOPS. 8. 這些架構是使用 GCP 上的[Intel Xeon E5 v3（Haswell）](https://cloud.google.com/compute/docs/cpu-platforms) CPU 平臺構建和測試的. 在不同的硬件上，您可能會發現需要對 CPU 或節點數進行相應的調整，無論是較低還是較高. 有關更多信息，請在[此處](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks)找到 CPU 的[Sysbench](https://github.com/akopytov/sysbench)基準.