> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/zh-tw/kai-shi-shi-yong/requirements/hardware-requirements.md).

# 硬體需求

## 硬體需求

在佈建用於執行 Overleaf 的硬體時，主要考量因素是將有多少並行使用者會執行編譯。

例如，若您擁有 100 名使用者的授權，但預期同時只有約 5 人在工作，則最基本的安裝配置已足夠。若您預期會有較高比例的使用者同時工作（及編譯），則應考慮佈建規格較高的伺服器。

### 最基本的安裝配置

對於約 5 名並行使用者的基本操作，最低基本需求為 2 個核心及 3GB 記憶體。對於並行使用率較低的較大群組，或是在高使用量期間可接受較長編譯時間的情況下，此最低需求也已足夠。

{% hint style="danger" %}
若您考慮為小型執行個體使用基於 NFS（網路檔案系統）的檔案系統，請參閱 [疑難排解](/on-premises/zh-tw/zhi-yuan/troubleshooting.md) 章節。
{% endhint %}

### 擴充

根據經驗法則，為了提供高且一致的服務水準，每增加 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 系統記憶體。在過去一年的使用期間，這已足以滿足團隊的需求。 |

超出單一大型伺服器限制的客戶可以參閱 [水平擴充](/on-premises/zh-tw/wei-hu/horizontal-scaling.md) 以瞭解 Server Pro。

### 儲存空間

我們不建議在較大型的設定中使用網路檔案系統（NFS）/Amazon EFS/Amazon EBS 來儲存專案／歷程記錄，且明確 **不支援** 用於水平擴充。

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

我們建議改用 [相容 S3 的物件儲存空間](/on-premises/zh-tw/kai-shi-shi-yong/what-is-the-overleaf-toolkit.md) 。S3 效能緩慢僅會影響檔案的上傳／下載，這只會增加與您 S3 供應商的開放連線數量，而不會影響應用程式其餘部分的行為。此外，Server Pro 可以為 S3 請求指定合理的逾時時間，這在應用程式層級的檔案系統／IO 操作中無法做到。

{% hint style="info" %}
供參考，GitLab 對其自行管理的產品採取類似立場， [不支援 NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) 。
{% endhint %}

### 大型部署適用的 Nginx 特定設定

預設情況下，Overleaf Server 執行個體會將連線數限制為 768。這包括持續性的 WebSocket 連線、頂層 HTML 導覽及 ajax 請求。一旦達到此限制，編輯器可能無法連線、編輯器頁面可能無法完整載入，且編譯請求可能會失敗。Nginx 會傳回狀態碼 500 的回應，並記錄 `連線至上游時 worker_connections 不足` 至 `var/log/nginx/error`位於 `sharelatex` 容器內的 .log。

此 [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) 設定會限制每個 worker 可接受的 nginx 並行連線數。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`)

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>當在該 <code>sharelatex</code> 容器前方執行另一個 Proxy（例如用於 TLS 終止）時， <code>NGINX_KEEPALIVE_TIMEOUT</code> Overleaf Server 執行個體中的值必須大於前一個 Proxy。例如，在 Docker 主機上使用另一個 nginx 程序時 <strong>nginx-host</strong>，以下有兩個範例：</p></div>
* 預設值 `NGINX_KEEPALIVE_TIMEOUT`，使用 [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) （上游的預設值）於 **nginx-host**
* 自訂值 `NGINX_KEEPALIVE_TIMEOUT=100s`，使用 [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) （上游的自訂值）於 **nginx-host**

### CPU 速度

LaTeX 是單執行緒程式，這表示它一次只能使用一個 CPU 核心。編譯文件時，CPU 也是主要限制因素。因此，CPU 的單核心效能越快，您編譯文件的速度就越快。只有當您嘗試編譯的文件數量超過可用 CPU 核心數時，更多核心才會有所幫助。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ayakaleaf-pro.ayaka.space/on-premises/zh-tw/kai-shi-shi-yong/requirements/hardware-requirements.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.