無需猜測，即可比較 ownCloud Infinite Scale 和 Nextcloud 28。

即使 CPU 使用率圖表看起來很低，檔案伺服器也可能感覺運行緩慢：目錄清單載入需要幾秒鐘，上傳在高峰時段會卡頓，或者進程似乎每天都在消耗更多記憶體。僅憑一個「每用戶記憶體」的數值來比較 ownCloud Infinite Scale (oCIS) 和 Nextcloud 28 並不能診斷出這個問題。目前還沒有官方的、完全公平的基準測試來評判哪個平台是最佳選擇，而且這兩個項目都指出記憶體需求取決於工作負載和配置。為了進行有效的比較，應該使用相同的檔案、客戶端、儲存、並發數和測試視窗來測試每個平台；首先要檢查瓶頸是應用程式、資料庫、儲存裝置還是後台任務。

此外，還有維護方面的限制：根據專案公佈的計劃，Nextcloud 28 已於 2024 年 12 月停止維護。它不再透過社群發布管道接收常規修復。如果 Nextcloud 28 已在使用中，請先規劃升級，然後再考慮效能調優作為整體解決方案。以下步驟有助於比較行為並定位資源壓力；但並不能保證可以安全地使用不受支援的版本。

為什麼內存讀數和速度讀數會有所不同？

Infinite Scale 和 Nextcloud 使用不同的伺服器架構。 oCIS 以服務的形式組織在一個基於 Go 的平台上；內建的管理程式會將其服務作為單一伺服器程序啟動。其記憶體需求可能包括快取的使用者和儲存元數據，而 ownCloud 文件明確指出，記憶體中儲存的空間和元資料數量與可用 RAM 以及存取或同步效能相關。伺服器在初始大規模掃描後顯示更大的工作集本身並不能證明存在記憶體洩漏。還需要檢查索引完成後記憶體是否穩定，以及延遲是否仍然在可接受的範圍內。

Nextcloud 28 是一個 PHP 應用程式。其總記憶體佔用取決於 PHP-FPM 工作進程的數量和每個工作進程的行為、已啟用的應用程式、Web 伺服器、資料庫、快取、預覽產生以及後台作業。官方管理手冊指出，記憶體需求會隨著使用者、應用程式、檔案和伺服器活動而顯著變化。增加工作進程可以提高並行請求處理能力，但也會增加峰值記憶體使用量。因此，應比較主機或容器的總記憶體佔用，而不是僅比較單一 PHP 進程和單一 oCIS 進程的記憶體佔用。

儲存效能在兩個平台上都可能佔據主導地位。磁碟、網路檔案系統、物件儲存、資料庫或防毒軟體掃描速度慢都可能導致請求看起來像是應用程式瓶頸。同樣，冷緩存和熱緩存的回應時間也不盡相同。真正重要的問題不是哪個產品的空閒時間較少，而是哪個堆疊能夠在記憶體和延遲預算範圍內完成實際工作負載。

在相同條件下比較它們

1. 記錄完整的建置和部署過程。記下 oCIS 版本、Nextcloud 28 修補程式等級、作業系統、容器限制、CPU 分配、資料庫、儲存後端、已啟用的應用程式和服務、PHP 版本以及 Web 伺服器。盡可能保持相同的硬體和資料路徑。不要將一個平台的容器記憶體限制與另一個平台的全主機記憶體使用混用。
2. 使用具有代表性的測試集。測試集應包含生產環境中運行緩慢的操作，例如：初始同步、增量同步、瀏覽大型目錄、檔案下載和上傳、共享以及並發登入。保持文件數量、文件大小分佈、活躍客戶端數量和並發數的一致性。使用測試環境副本，避免對生產資料造成壓力。
3. 先測量基準值，然後重複測量。記錄啟動後的空閒記憶體、每個工作負載期間的記憶體使用情況、峰值記憶體使用情況、CPU 使用率、磁碟 I/O 使用率、資料庫活動以及請求或同步延遲。在全新啟動後運行一次，然後在快取預熱後再次運行。重複每次運行足夠多次，以驗證結果是否穩定；不要將單次運行標記為基準測試。
4. 將應用程式記憶體與主機記憶體分離。對於容器，檢查容器的記憶體工作集和限制；對於 Linux 進程，使用進程監視器和系統記憶體統計資料。同時，觀察交換空間、記憶體不足事件和資料庫記憶體使用量。主機快取成長並不等於應用程式記憶體洩漏，而且容器記憶體限制在不同的執行時間環境中可能存在差異。

對於 oCIS 監控，請參考版本相符的文件以取得服務指標和 Prometheus 端點資訊。 ownCloud 8.2 文件描述了受支援服務的指標；指標會因服務和版本而異。 Nextcloud 的管理概覽和系統工具可以顯示設定警告，而作業系統和資料庫監控則用於解釋總記憶體使用量。盡可能保持測試工具的一致性，並記錄單位和採樣間隔。

你該先調哪個頻道？

1. 確認是否有真正的記憶壓力

觀察是否有持續高記憶體使用率，以及是否出現交換、OOM 終止、容器重新啟動或請求延遲上升等情況。單獨的高記憶體使用率可能代表有效的快取機制。如果在掃描過程中記憶體使用率上升後趨於穩定，則可能無需增加記憶體。如果在穩定的工作負載下記憶體使用率持續上升且沒有穩定下來，則需要檢查日誌、服務級記憶體使用情況以及在更改限制之前正在運行的作業。

2. 減少不必要的後台工作

識別預覽產生、防毒掃描、索引、同步突發和計畫維護等任務。這些任務可能會與互動式請求衝突。將高負載任務移至非尖峰時段，或使用已安裝版本中提供的控制措施降低其並發性。不要僅僅為了讓圖表看起來更小而停用安全掃描或必要的維護；首先要量化任務的成本和對使用者的影響。

3. 有意識地調整 Nextcloud 的 PHP 和快取配置

對於 Nextcloud，請驗證版本 28 支援的 PHP 配置，並根據可用記憶體調整 PHP-FPM 工作進程的數量。工作進程過少會導致請求排隊，過多則可能耗盡記憶體。請根據版本 28 手冊，在適當情況下配置受支援的​​記憶體快取和 Redis 以實現事務性檔案鎖定。快取會消耗內存，但可以優化重複操作，因此請同時考慮延遲和記憶體佔用。切勿在未查閱特定版本文件的情況下，將目前 Nextcloud 版本的設定複製到版本 28。

4. 審查 oCIS 元資料和儲存選擇

對於無限擴展，請評估空間數量、檔案和目錄元資料、儲存驅動程式以及快取行為。官方先決條件文件解釋說，保留在記憶體中的元資料會影響存取和同步效能。如果大規模清單或同步工作負載與記憶體壓力同時出現，請在新增 RAM 之前比較相關的服務和儲存指標。請根據特定的 oCIS 版本檢查特定於儲存的選項；不要假設不同的儲存後端具有完全相同的記憶體行為。

5. 只有在找到瓶頸之後才能增加產能。

如果測得的工作負載延遲穩定且可接受，但記憶體已達上限，則增加記憶體或調整資源分配，然後重複相同的測試。如果延遲較高但記憶體仍然充足，則應檢查資料庫查詢、儲存延遲、網路吞吐量、鎖以及 CPU 飽和度。在設計合理的部署中，擴展 oCIS 服務或增加工作進程可以提高吞吐量，但也會改變資源需求和運作複雜性。每次只更改一個變量，以便結果可歸因。

如何驗證結果

每次變更後重複執行原始工作負載，並比較相同的指標：峰值和穩定狀態下的記憶體使用量、交換活動、p95 請求或同步延遲（如有）、已完成的傳輸次數以及錯誤或重新啟動次數。成功的修復應改善使用者報告的操作效能，且不會在其他地方造成記憶體壓力。為了進行公平的平台比較，請在結果旁邊公佈測試條件，並說明快取是冷緩存還是熱緩存；不要僅基於一台小型伺服器或資料集進行概括。

最後，請將 Nextcloud 28 的生命週期結束視為一個獨立的維運問題。請依照專案的升級指南遷移到支援的版本，然後重新執行比較，因為更新的程式碼、PHP 版本、應用程式和遷移變更可能會改變資源佔用情況。有關目前部署要求和特定於版本的設置，請參閱ownCloud Infinite Scale 8.2 的先決條件、ownCloud Prometheus 指標、Nextcloud 28 系統需求、Nextcloud 28 記憶體快取以及Nextcloud 維護和發布計畫。