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

# Reference architecture: up to 1,000 users > 原文：[https://docs.gitlab.com/ee/administration/reference_architectures/1k_users.html](https://docs.gitlab.com/ee/administration/reference_architectures/1k_users.html) * [Setup instructions](#setup-instructions) * [Footnotes](#footnotes) # Reference architecture: up to 1,000 users[](#reference-architecture-up-to-1000-users "Permalink") 該頁面描述了最多可容納 1,000 位用戶的 GitLab 參考架構. 有關參考架構的完整列表，請參見[可用參考架構](index.html#available-reference-architectures) . > * **支持的用戶（大約）：** 1,000 > * **高可用性：** False | Users | Configuration([8](#footnotes)) | GCP | AWS | Azure | | --- | --- | --- | --- | --- | | 500 | 4 個 vCPU，3.6GB 內存 | `n1-highcpu-4` | `c5.xlarge` | F4s v2 | | 1000 | 8 個 vCPU，7.2GB 內存 | `n1-highcpu-8` | `c5.2xlarge` | F8s v2 | 除上述之外，即使您當前有足夠的可用 RAM，我們也建議您在服務器上至少有 2GB 的交換空間. 如果您的可用內存發生更改，那么進行交換將有助于減少發生錯誤的機會. 我們還建議將內核的 swappiness 設置配置為較低的值（例如`10`以充分利用您的 RAM，同時在需要時仍可使用交換功能. 對于需要服務多達 1,000 個用戶的情況，具有[頻繁備份](index.html#automated-backups-core-only)的單節點解決方案適用于許多組織. 通過自動備份 GitLab 存儲庫，配置和數據庫，如果您對可用性沒有嚴格的要求，這是理想的解決方案. ## Setup instructions[](#setup-instructions "Permalink") * 對于此默認參考體系結構，請使用標準[安裝說明](../../install/README.html)來安裝 GitLab. **注意：**您還可以選擇將 GitLab 配置為使用[外部 PostgreSQL 服務](../postgresql/external.html)或[外部對象存儲服務](../high_availability/object_storage.html) ，從而以降低的復雜性成本來提高性能和可靠性. ## 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. Recommended Redis setup differs depending on the size of the architecture. For smaller architectures (less than 3,000 users) a single instance should suffice. For medium sized installs (3,000 - 5,000) we suggest one Redis cluster for all classes and that Redis Sentinel is hosted alongside Consul. For larger architectures (10,000 users or more) we suggest running a separate [Redis Cluster](../redis/replication_and_failover.html#running-multiple-redis-clusters) for the Cache class and another for the Queues and Shared State classes respectively. We also recommend that you run the Redis Sentinel clusters separately for each Redis Cluster. 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)基準.