> ## 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 核心與 3GB 記憶體。對於同時使用率較低，或可接受在高負載期間編譯時間較長的較大型群組，這個最低需求也同樣足夠。

<Danger>
  如果您考慮在小型執行個體中使用以 NFS（Network File System）為基礎的檔案系統，請參閱[疑難排解](/zh-TW/on-premises/support/troubleshooting)中的相關章節。
</Danger>

### 擴充

根據經驗法則，為了提供高水準且穩定的服務，每增加 5 到 10 位同時使用者，就應在最低配置之上增加 1 個 CPU 核心與 1GB 記憶體。

這僅應作為參考，因為一般文件的大小（較大的文件會耗用更多編譯資源）、使用者編譯的頻率，以及在高負載期間對較長編譯時間的容忍度等因素，都會影響所需的資源配置。

我們許多客戶希望在整個組織或大型團隊中部署 Server Pro。在這些情況下，我們很難提供具體的設定需求建議，因為使用情境與可用的底層硬體可能差異很大。

| 範例 1 | 範例 2 |
| - | - |
| 如果您執行的 Server Pro 安裝共有 300 位使用者，且經常預期其中 30 到 60 位會同時編譯文件，那麼 8GB 與 7 核心（5 核心 + 5GB + 基本的 2 核心與 3GB）應能提供足夠的資源，讓使用者持續享有高水準的服務。 | 舉一個較大型部署的硬體需求範例：一個共有 1,000 位使用者的 Server Pro 安裝，已成功使用單一伺服器建置，該伺服器配備兩顆 4 核心處理器與 32GB 系統記憶體。在過去一年的使用中，這已足以滿足該團隊的需求。 |

超出單一大型伺服器極限的客戶，可以參考 Server Pro 的[水平擴充](/zh-TW/on-premises/maintenance/horizontal-scaling)。

### 儲存空間

在較大型的設定中，我們不建議使用 Network File System（NFS）/Amazon EFS/Amazon EBS 作為專案/歷史記錄的儲存空間，且在水平擴充時明確**不支援**。

這些檔案系統的行為無法提供 Server Pro 在大規模運作時所需的效能與可靠性。當檔案系統跟不上負載時，應用程式會因過多的阻塞式 IO 操作而停滯。這些停滯可能導致以 Redis 為基礎的鎖定逾時，進而造成專案資料損毀。

我們建議改用[相容 S3 的物件儲存](/zh-TW/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` 容器前方執行另一個 proxy（例如用於 TLS 終止）時，Overleaf Server 執行個體中的 `NGINX_KEEPALIVE_TIMEOUT` 必須大於前一個 proxy 的設定。例如，在 Docker 主機上另有一個 nginx 程序 <strong>nginx-host</strong> 時，以下是兩個範例：</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.