# 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)基准.