server硬件需求

硬件需求

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

例如,如果您有一个 100 个用户的许可,但预计同时只有约 5 人在工作,则最低安装就足够。如果您预计同时工作的(并进行编译的)比例更高,则应考虑配置规格更高的服务器。

最低安装

基本操作的最低基础要求是 2 个内核和 3GB 内存,可支持大约 5 个并发用户。对于并发使用较少的较大团队,或在使用高峰期间允许编译时间更长的情况,这个最低要求也足够。

triangle-exclamation

扩展

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

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

我们的许多客户希望在整个组织或大型团队范围内部署 Server Pro。在这些情况下,我们很难对具体的设置要求给出建议,因为用例和可用的底层硬件可能非常多样。

示例 1
示例 2

如果您为 300 名总用户运行 Server Pro 安装,并且经常预计其中 30-60 名用户会同时编译文档,则 8GB 和 7 个内核(5 个内核 + 5GB + 基础的 2 个内核 & 3GB)应为您的用户提供持续高水平的服务所需的充足资源。

举例说明较大部署的硬件需求:一个为 1000 名总用户设置的 Server Pro 安装已成功使用一台配置为双 4 核处理器和 32GB 系统内存的服务器进行部署。这在过去一年的使用中已满足该团队的需求。

超出单台大服务器限制的客户可以查看 水平扩展 针对 Server Pro。

存储

我们建议在较大规模的部署中不要将网络文件系统(NFS)/Amazon EFS/Amazon EBS 用于项目/历史记录存储,并明确地 不予支持 用于水平扩展。

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

我们建议改用 兼容 S3 的对象存储 。较慢的 S3 性能只会影响文件的上传/下载,这仅会导致与您的 S3 提供商建立更多的打开连接,并不会影响应用其余部分的行为。此外,Server Pro 可以为 S3 请求指定合理的超时,而这是在应用层面无法为文件系统/IO 操作实现的。

circle-info

作为参考,GitLab 在其自托管产品中也采取了类似的立场: 不支持 NFS/Amazon EFSarrow-up-right

针对大型部署的 Nginx 特定配置

默认情况下,Overleaf Server 实例将连接数限制为 768。这包括持久的 Websocket 连接、顶级 HTML 导航和 ajax 请求。一旦达到限制,编辑器可能无法连接,编辑器页面可能无法完全加载,编译请求可能失败。Nginx 会返回 500 状态响应并记录 在连接到上游时 worker_connections 不足var/log/nginx/error.log 在 sharelatex 容器内。

worker_connectionsarrow-up-right ” 设置限制了 nginx 每个 worker 可接受的并发连接数。worker 的数量由 worker_processesarrow-up-right 设置控制,在我们的 nginx 配置中默认设置为 4。

与系统的其他部分相比,Nginx 的工作量不大,因此这些限制作为一种安全措施,防止过多连接使系统不堪重负。最好早期丢弃一些多余连接,而不是让每个连接都变慢。

Overleaf Server 实例公开用于调整这些 nginx 设置的环境变量:

CPU 速度

LaTeX 是单线程程序,这意味着它一次只能使用一个 CPU 内核。CPU 也是编译文档时的主要限制因素。因此,CPU 单核性能越快,编译文档的速度就越快。更多的内核只有在您尝试同时编译的文档数量超过空闲 CPU 内核数量时才会有帮助。

最后更新于