> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 硬件要求

## 硬件要求

在为运行 Overleaf 配置硬件时，需要考虑的主要因素是会有多少并发用户在运行编译。

例如，如果你拥有 100 个用户的许可证，但预计只有约 5 人同时工作，那么最小安装就足够了。如果你预计有更高比例的用户同时工作（并编译），则应考虑配置更高规格的服务器。

### 最小安装

在约 5 个并发用户的情况下，基本运行至少需要 2 个 CPU 核心和 3GB 内存。对于并发使用较少的大型团队，或者在高负载期间可以接受较长编译时间的情况，这一最低要求同样足够。

<Danger>
  如果你考虑为小型实例使用基于 NFS（网络文件系统）的文件系统，请查看[故障排除](/zh-CN/on-premises/support/troubleshooting)部分中的相关内容。
</Danger>

### 扩展

根据经验，为了提供高水平且稳定的服务，每增加 5-10 个并发用户，应在最小安装的基础上增加 1 个 CPU 核心和 1GB 内存。

这仅应作为参考，因为典型文档的大小（较大的文档会占用更多编译资源）、用户编译的频率，以及在高负载期间对较长编译时间的容忍程度等因素，都会影响所需的资源配置水平。

我们的许多客户希望在整个组织或大型团队中部署 Server Pro。在这些情况下，我们很难给出具体的配置建议，因为使用场景和可用的底层硬件可能差异很大。

| 示例 1 | 示例 2 |
| - | - |
| 如果你为总共 300 个用户运行 Server Pro，并且经常有 30-60 个用户同时编译文档，那么 8GB 内存和 7 个核心（5 个核心 + 5GB + 2 个核心和 3GB 的基础配置）应能提供足够的资源，使用户始终获得高水平的服务。 | 举一个大型部署的硬件要求示例：一个面向总共 1,000 个用户的 Server Pro 部署，已成功在一台配备两颗 4 核处理器和 32GB 系统内存的服务器上运行。在过去一年的使用中，这一配置足以满足该团队的需求。 |

超出单台大型服务器承载能力的客户，可以参阅 Server Pro 的[水平扩展](/zh-CN/on-premises/maintenance/horizontal-scaling)。

### 存储

在较大规模的部署中，我们不建议将网络文件系统（NFS）/Amazon EFS/Amazon EBS 用于项目/历史记录存储，并且在水平扩展场景中明确**不支持**这些文件系统。

这些文件系统的表现无法提供 Server Pro 在大规模运行时所需的性能和可靠性。当文件系统无法跟上负载时，应用会因过多的阻塞式 IO 操作而停滞。这些停滞可能导致基于 Redis 的锁超时，进而可能造成项目数据损坏。

我们建议改用 [S3 兼容的对象存储](/zh-CN/on-premises/getting-started/what-is-the-overleaf-toolkit)。S3 性能较慢只会影响文件的上传/下载，最多导致与 S3 提供商之间的打开连接数增加，而不会影响应用其余部分的行为。此外，Server Pro 可以为 S3 请求设置合理的超时时间，而在应用层面无法对文件系统/IO 操作做到这一点。

<Info>
  作为参考，GitLab 在其自托管产品中也采取了类似立场，[不支持 NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html)。
</Info>

### 大型部署的 Nginx 专项配置

默认情况下，Overleaf Server 实例将连接数限制为 768。这包括持久的 Websocket 连接、顶层 HTML 导航以及 ajax 请求。一旦达到上限，编辑器可能无法连接，编辑器页面可能无法完全加载，编译请求也可能失败。Nginx 将返回状态码 500 的响应，并在 `sharelatex` 容器内的 `var/log/nginx/error`.log 中记录 `worker_connections are not enough while connecting to upstream`。

[`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) 设置限制了 nginx 每个 worker 可接受的并发连接数。worker 的数量由 [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) 设置控制，在我们的 nginx 配置中默认为 4。

与系统的其他部分相比，Nginx 的工作量并不大，因此这些限制起到安全保护作用，防止过多连接压垮系统。尽早丢弃一些多余的连接，要好过拖慢所有连接。

Overleaf Server 实例提供了用于调整这些 nginx 设置的环境变量：

* `NGINX_WORKER_PROCESSES` 对应 [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes)（默认 `4`）
* `NGINX_WORKER_CONNECTIONS` 对应 [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections)（默认 `768`）
* `NGINX_KEEPALIVE_TIMEOUT` 对应 [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout)（默认 `65`）

  <Info>当在 `sharelatex` 容器前运行另一个代理（例如用于 TLS 终止）时，Overleaf Server 实例中的 `NGINX_KEEPALIVE_TIMEOUT` 需要大于前一个代理的值。例如，在 Docker 主机 <strong>nginx-host</strong> 上运行另一个 nginx 进程时，有以下两个示例：</Info>
* 使用默认值 `NGINX_KEEPALIVE_TIMEOUT` 时，在 **nginx-host** 中使用 [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout)（upstream 中的默认值）
* 使用自定义值 `NGINX_KEEPALIVE_TIMEOUT=100s` 时，在 **nginx-host** 中使用 [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout)（upstream 中的自定义值）

### CPU 速度

LaTeX 是单线程程序，这意味着它一次只能使用一个 CPU 核心。CPU 也是编译文档时的主要限制因素。因此，CPU 的单核性能越强，编译文档的速度就越快。只有当你要同时编译的文档数量多于空闲的 CPU 核心数时，更多的核心才会有所帮助。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.