ownCloud Infinite Scale 與 Nextcloud 28：效能與記憶體使用情況詳解

ownCloud Infinite Scale 和 Nextcloud 28 都能提供自架的檔案同步和共享功能，但它們實現這一目標所採用的伺服器架構截然不同。這種差異在預測記憶體壓力、請求延遲、擴展行為以及部署所需的調優工作量時至關重要。

首先要說明的是：沒有像「Infinite Scale 使用 X MB，而 Nextcloud 28 使用 Y MB」這樣絕對可靠的通用數字。記憶體消耗會隨著啟用的服務、使用者並發數、後台作業、儲存後端、PHP 工作進程數、快取、預覽、辦公室整合和應用程式等因素而變化。官方文件對這兩款產品的記憶體使用指南也各不相同，因此直接將這些數據作為基準是具有誤導性的。

此外，還有生命週期問題。 Nextcloud 28（也稱為 Hub 7）於 2023 年 12 月發布，並於 2024 年 12 月停止維護；最後一個 28.x 版本是 28.0.14。自 2026 年 10 月起，它不再接收常規的錯誤修復或安全性更新。因此，此比較最適用於了解現有的 Nextcloud 28 安裝或規劃遷移，而不是用於推薦新的 Nextcloud 28 部署。請參閱 Nextcloud 的官方維護和發布計劃。

ownCloud Infinite Scale 和 Nextcloud 28 的架構對比，一側展示 Go 服務，另一側展示 PHP、資料庫和快取堆疊。 — 這是一個簡化的架構對比。它說明了為什麼兩個平台上的記憶體行為有所不同；它並非實際測量的基準測試或吞吐量證明。

架構差異是造成效能權衡的主要原因。

ownCloud Infinite Scale（在設定和文件中通常簡稱為 oCIS）由一組 Go 服務建構而成。其預設運行時可以在單一進程內啟動內建服務，並使用嵌入式 Supervisor 對其進行監控。 ownCloud 表示，這種設計有助於減少記憶體佔用，同時，當部署需要橫向擴展時，各個服務也可以遷移到其他節點。該平台的核心運行不需要 PHP 或傳統的應用程式資料庫。請參閱官方的 Infinite Scale 架構文件和Infinite Scale 管理概述。

Nextcloud 28 沿用了常見的 PHP Web 應用模型。典型的生產環境架構包括 Web 伺服器（例如 Apache 或 Nginx）、PHP 或 PHP-FPM 工作進程、支援的關聯式資料庫，以及通常的記憶體快取。 Nextcloud 官方文件建議在本地部署中使用 APCu，在組織級部署中使用 Redis 進行分散式快取和事務性文件鎖定。這使得 Nextcloud 具有高度的靈活性，但也意味著總記憶體預算分散在多個獨立的進程和服務中，而不是由單一伺服器進程分配。

記憶體使用率：官方數據究竟意味著什麼

區域	ownCloud 無限擴展	Nextcloud 28
已發布的記憶指南	ownCloud 的生產環境 Compose 範例建議完整的範例部署至少需要 4-6 GB 的空間。	Nextcloud 28 文件規定每個進程至少需要 128 MB RAM，並建議每個進程至少需要 512 MB RAM。
這些數據可以直接比較嗎？	不。「無限擴展」的數據涵蓋了一個部署範例，其中包括線上辦公室元件等其他軟體，而「Nextcloud」的數據是每個進程的數據，而不是伺服器總記憶體的數據。
主要變數	已啟用服務、辦公室整合、防毒、儲存類型、服務拓撲、並發性。	PHP-FPM 工作流程數、應用程式、預覽、資料庫緩衝區、Redis/APCu、定時任務/背景作業、並發性。

ownCloud 目前的生產部署範例明確建議至少使用 4-6 GB 內存，並指出啟用防毒掃描時需要額外的內存。但這並不意味著「oCIS 本身始終佔用 4-6 GB 記憶體」。文件中的設定還引入了辦公室軟體和其他必需元件。請參閱官方的 Infinite Scale 生產部署範例。

Nextcloud 28 的系統要求文件採用了不同的方法：它指出 RAM 需求會因用戶、應用、文件和活動的不同而變化很大，然後給出了每個進程 128 MB 的最低內存需求和 512 MB 的推薦內存需求。這點對於 PHP-FPM 尤其重要，因為 PHP-FPM 可能同時運行多個工作進程。因此，配置為高並發的伺服器可以預留比每個進程建議值多得多的記憶體。請參閱Nextcloud 28 的系統需求。

在以文件為中心的工作負載下，哪一款可能會感覺更輕？

如果工作負載主要包括身份驗證、瀏覽、同步、上傳、下載和共享，Infinite Scale 的 Go 運行時和服務設計可以減少與 PHP 請求堆疊相關的一些開銷。 ownCloud 也在其部分服務通訊內部使用 gRPC 等二進位協定。從架構上看，這為 Infinite Scale 提供了一條無需增加 PHP 工作進程即可實現高並發的可靠途徑。

但這並不意味著吞吐量具有普遍優勢。儲存延遲可能會主導文件操作，TLS 和反向代理會增加開銷，元資料行為取決於所選的儲存驅動程序，可選服務也會改變效能表現。 ownCloud 本身的儲存文件明確討論了針對本地儲存、NFS 和 S3 支援的部署，如何以不同的方式優化記憶體和效能。請參閱「無限擴充儲存注意事項」。

Nextcloud 28 在正確調優後也能表現出色。其文件指出，記憶體快取可以顯著提升伺服器效能。 APCu 可以避免在本地重複重建頻繁使用的 PHP 對象，而 Redis 則可以處理分散式快取資料和交易性檔案鎖定。對於單一組織伺服器，Nextcloud 28 建議使用 APCu 作為本機緩存，使用 Redis 作為分散式快取和鎖定。請參閱Nextcloud 28 記憶體快取文件。

Nextcloud的內存都去哪了？

對於 Nextcloud 28 來說，「Nextcloud 記憶體使用量」實際上是多個預算的總和。 PHP-FPM 工作進程會根據啟用的 PHP 模組和應用程式程式碼消耗記憶體。資料庫需要自己的緩衝區和連接記憶體。 Redis 會為快取物件和鎖消耗記憶體。 APCu 在每個 PHP 環境中維護一個本機快取。預覽生成、防毒整合、Talk、全文搜尋和第三方應用程式可能會佔用各自的進程或後台活動。

這種模型為管理者提供了許多調優手段。降低 PHP-FPM 工作進程數限制可以在記憶體受限的情況下維持小型伺服器的運行，但高負載時請求可能會排隊。增加工作進程數可以提高並發性，直到 CPU、記憶體、資料庫連接或 I/O 成為瓶頸。在記憶體不足的環境中，使用 Redis 作為本地快取可以節省一些內存，但 Nextcloud 的官方文件指出，在記憶體充足的情況下，APCu 的本地快取速度更快。這實際上是效能與記憶體之間的權衡，而不是針對每個主機的單一建議設定。

Infinite Scale的RAM去哪了？

Infinite Scale 也包含許多邏輯服務，但其嵌入式執行時間可以在一個進程內管理內建服務，並在 Go 例程中執行每個服務。 ownCloud 將此描述為一種便於管理員打包平台的方式，同時仍允許將各個服務分開以進行分散式部署。嵌入式 Supervisor 還會重新啟動故障服務，並且有文件明確指出，與在外部 Supervisor 下運行每個服務相比，它可以顯著減少記憶體佔用。

這種整合可以簡化單一主機上的資源行為分析，但並不能固定記憶體使用量。新增 Collabora 或 OnlyOffice、防毒掃描、外部身分識別服務、基於 Redis 或 NATS 的元件、縮圖處理或更大的快取都會改變記憶體佔用。將服務遷移到單獨的容器或 Kubernetes Pod 中，雖然可以提高隔離性和橫向擴展性，但也會增加基礎開銷。

按工作負載進行效能比較

工作量	可能的優勢	為什麼
整合功能較少的小型檔案同步設備	無限尺度	較少的傳統 Web 技術堆疊元件，以及核心平台不需要 PHP/資料庫層，可以簡化執行時間。
龐大的應用生態系和大量群件的部署	Nextcloud	更廣泛的 PHP 應用生態系統可能比伺服器的原始效率更重要，儘管記憶體規劃變得更加重要。
高並發性，檔案操作可預測	無限尺度在建築上極具吸引力。	Go 服務和橫向擴充服務模型避免了將並發性直接綁定到大型 PHP 工作池。
現有的最佳化 LAMP/LEMP 基礎設施	Nextcloud 在操作上可能更容易	已經精通 PHP-FPM、MariaDB/PostgreSQL、Redis 和 Web 伺服器調優的團隊可能更喜歡熟悉的技術堆疊。
非常有限的記憶體預算	取決於功能範圍	兩家廠商的官方數據都無法得出絕對的記憶體佔用優勢；剔除可選服務，並測量您的實際工作負載。

如何公平地對它們進行基準測試

如果效能是決定性因素，則應在相同的硬體上對兩款產品進行基準測試，而不是依賴社群提供的螢幕截圖或孤立的記憶體測試資料。使用相同的儲存設備或後端、網路路徑、TLS 終止方法、測試檔案集、使用者數量和客戶端行為。在記錄穩定狀態測試結果之前預熱緩存，但也要單獨測量冷啟動效能。

有用的指標包括目錄清單、元資料操作、小檔案上傳、大檔案上傳、下載和共享建立的延遲中位數和第 95 個百分位數；每秒完成的請求數；所有相關進程的總駐留記憶體；CPU 使用率；儲存 IOPS；Nextcloud 的資料庫延遲；以及後台作業的影響。請將空閒記憶體和已載入記憶體分開測量，因為系統在空閒時看起來記憶體佔用量較小，但在並發使用時可能會分配更多記憶體。

對於 Nextcloud，應將 Web 伺服器、PHP-FPM、資料庫、Redis 以及任何其他應用服務都計算在內。對於 Infinite Scale，應將 oCIS 服務以及反向代理、身分元件、Office 整合、快取和儲存相關服務都計算在內。否則，結果就變成了偽裝成基準測試的架構比較。

你應該選擇哪一個？

如果您優先考慮現代化的檔案平台，重視基於 Go 的服務架構，並且希望避免使用 PHP 工作進程加上核心伺服器所需的關聯資料庫這種維運模式，那麼ownCloud Infinite Scale 是您的理想之選。對於計劃進行橫向服務擴展或建立大型文件共享環境的組織而言，它尤其具有吸引力。

如果 Nextcloud 應用生態系統、群組整合、現有管理知識或應用相容性比減少執行時間層更重要，請選擇支援的 Nextcloud 版本。如果您目前運行的是 Nextcloud 28，效能調優可能在短期內仍然有所幫助，但出於安全考慮，升級才是更重要的理由，因為 28 版本自 2024 年 12 月起已停止支援。

如果決策僅針對記憶體（RAM），那麼兩家供應商公佈的要求都不足以斷言哪一家是絕對的贏家。 Infinite Scale 的架構從核心堆疊中移除了 PHP 和傳統的應用程式資料庫，並專門針對高效的服務執行而設計；而 Nextcloud 則提供了成熟的快取控制和高度可配置的 PHP 並發性。更合理的選擇是，比較您實際計劃運行的完整生產環境堆疊，使用相同的工作負載，並測量系統總內存，而不是孤立地測量單個進程的內存。