修復 Nextcloud 警告“PHP OPcache 配置不正確”

如果 Nextcloud 報告「PHP OPcache 設定不正確」，正確的解決方法並非直接從舊論壇貼文複製貼上一大段設定碼。首先要確定 Nextcloud 遇到的 OPcache 限製或設定問題，然後修改 Web 伺服器實際使用的 PHP 配置。

在目前的 Nextcloud 35 管理文件中，OPcache 被視為重要的 PHP 效能最佳化層。 Nextcloud 表示，當 OPcache 的大小限制超過其分配容量的 90% 時，其管理面板會發出相關警告。它還要求保留快取的程式碼註釋。 PHP 的官方手冊記錄了相關的指令及其預設值。這些資訊為您提供了一種更安全的 OPcache 調優方法：僅增加受限資源，保持必要的行為啟用，並避免進行任何會使升級複雜化的更改，除非您有充分的理由。

Nextcloud 管理概覽頁面頂部附近顯示 PHP OPcache 設定警告。 — 應將此警告視為診斷線索：在更改記憶體或檔案計數限制之前，請確定特定的 OPcache 限制。

Nextcloud OPcache 警告通常意味著什麼

OPcache 將編譯後的 PHP 字節碼儲存在共享記憶體中，這樣 PHP 就不必在每次請求時都解析和編譯相同的應用程式檔案。 Nextcloud 將其描述為一項效能最佳化功能，而 PHP 自 5.5 版本起就已將 Zend OPcache 整合到核心程式碼中。

出現此警告的原因可能不只一個。最常見的情況是 OPcache 容量接近滿、Web SAPI 的 OPcache 被停用，或者諸如保留註釋之類的必要行為已更改。 Nextcloud 目前的調優指南指出，當 OPcache 大小限制超過其分配容量的 90% 時，會顯示大小警告，並且明確要求opcache.save_comments = 1…

官方參考資料：Nextcloud 伺服器調優和 OPcache 指南、Nextcloud PHP 設定說明和PHP OPcache 運行時配置。

根據警告訊息選擇修復方案，而不是採用一刀切的通用方法。

情況	第一次換胎	權衡
OPcache 記憶體使用量已超過 Nextcloud 的警告閾值	`opcache.memory_consumption`適度增加	使用更多共享內存，但減少緩存變更
內部字串幾乎已滿	增加`opcache.interned_strings_buffer`	會消耗額外的共享記憶體；提高無關的限制並不會有任何好處。
快取的腳本/檔案插槽已接近滿載	增加`opcache.max_accelerated_files`	更大的哈希表會佔用更多內存
OPcache 已停用	設定`opcache.enable=1`Web PHP 配置	適用於 Nextcloud 的正常且建議做法；請驗證正確的 SAPI
`opcache.save_comments`已停用	放`opcache.save_comments=1`	沒有針對 Nextcloud 的實質理由禁用它；Nextcloud 需要保留評論。

PHP 目前列出的預設值分別為：128 MB（用於 `<module>`）opcache.memory_consumption、8 MB（用於 `<module>`）opcache.interned_strings_buffer和 10,000 MB（用於opcache.max_accelerated_files`<module>`）。這些預設值僅供參考，並非 Nextcloud 的通用目標值。小型個人伺服器可能滿足這些要求，而安裝大量應用程式的大型部署則可能需要更大的記憶體空間。

步驟 1：確認 Nextcloud 實際使用的 PHP 配置

這步驟可以避免很多修復失敗的情況。 Nextcloud 文件指出，Web 伺服器和命令列 PHP 可以載入不同的設定檔。在 Debian 和 Ubuntu 等系統上，常見的路徑包括 `/etc/web/`、`/etc/web/`/etc/php/<version>/fpm/php.ini和/etc/php/<version>/apache2/php.ini` /etc/web /etc/php/<version>/cli/php.ini/`。

執行此命令php --ini可查看 CLI 配置，但請勿假定它與 PHP-FPM 或 Apache 使用的檔案相同。對於 Web SAPI，phpinfo()僅當您可以保護並立即刪除臨時頁面時才使用臨時頁面，或檢查您的 PHP-FPM 池/服務配置和特定於發行版的模組檔案。

建議：如果 Nextcloud 運行在 Nginx 或 Apache 伺服器（使用 PHP-FPM），請修改 FPM 的 OPcache 設定。如果 Apache 使用 mod_php，請修改 Apache 的 PHP 配置。當後台作業需要相同的行為時，請保持 CLI 設定一致，但請記住，瀏覽器警告是由 Web 請求路徑產生的。

步驟 2：編輯能夠解決問題的最小 OPcache 指令集。

文字編輯器顯示 OPcache 設定文件，其中包含啟用、記憶體、字串駐留、加速檔案和保存註解指令。 — 編輯 Web SAPI 使用的 OPcache 設定。僅增加受限資源，而不是盲目複製過大的預設值。

下面展示的是一個配置適中的伺服器的保守範例。請將數值視為初始值，而非保證值：

[opcache]
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.save_comments=1

如果 Nextcloud 明確提示 OPcache 內存即將用完，且伺服器有足夠的可用內存，那麼從 128 MB 增加到 256 MB 是一個合理的增量調整。如果警告指向的是字串駐留或快取腳本，則應提高這些限制，而不是僅增加記憶體。在記憶體受限的 VPS 上，直接增加到 512 MB 可能會減少 PHP-FPM 工作進程、資料庫、Redis 和作業系統可用的記憶體。

那麼重新驗證設定呢？

Nextcloud 目前的調優指南指出，PHP 預設每兩秒檢查一次快取腳本的更改，並且沒有建議所有使用者更改此預設設定。提高檢查頻率opcache.revalidate_freq可以減少檔案系統檢查次數，但缺點是：應用程式升級和修改config.php可能需要更長時間才能生效。完全停用時間戳驗證則更為激進，可能會導致舊程式碼一直處於活動狀態，直到手動清除 OPcache 或重新啟動 PHP。

對於大多數只想清除警告的管理員來說，除非您了解部署工作流程，否則請保持預設設置opcache.validate_timestamps，opcache.revalidate_freq無需進行任何更改。 Nextcloud 特別警告，升級後出現異常行為可能是由於重新驗證機制變更後快取程式碼過期所致。

步驟 3：重新啟動正確的 PHP 服務

修改 INI 檔案後，請重新啟動或重新載入執行 Nextcloud 的 PHP 進程。例如，systemctl restart php8.2-fpm如果使用了 PHP-FPM 或 mod_php，則需要重新啟動/重新載入 Apache。請將版本號碼和服務名稱替換為您系統實際運作的版本和服務名稱。

如果您更改了重新驗證行為，這一點就顯得尤為重要。重啟正確的服務可以確保載入新的 OPcache 配置，並消除關於過期字節碼的歧義。

步驟 4：驗證這些值，同時也要驗證 Web SAPI。

終端機顯示 php --ini 和 php -i OPcache 的輸出，包括啟用狀態和關鍵配置值。 — CLI 檢查對於尋找 INI 檔案和確認語法很有用，但 Web SAPI 可以載入不同的設定。

有用的命令列檢查包括：

php --ini
php -i | grep -i opcache

這些命令可以確認 PHP 是否識別了指令，但它們只能驗證 CLI 配置。如果 Nextcloud 警告仍然存在，請將 Web SAPI 載入的設定與 CLI 結果進行比較。這在維護獨立 `.web` cli、fpm`.web` 和apache2`.in.config` 樹的系統上尤其重要。

步驟 5：重新檢查管理 > 概覽

Nextcloud 管理概覽，不顯示 OPcache 警告，並顯示正常的系統狀態指示燈。 — 重新載入 PHP 後，重新整理「管理」>「概覽」頁面。當 Web SAPI 使用適當的限制和必要的設定後，OPcache 警告應該會消失。

PHP 服務重新啟動後，重新整理 Nextcloud 管理概覽。如果警告消失，則表示配置正在正確的 SAPI 讀取，並且不再超過報告的閾值。

如果問題仍然存在，請不要隨意增加數值。請按以下順序檢查四項：您是否編輯了正確的 INI 檔案；是否有其他稍後載入的 INI 檔案覆蓋了您的設定；相關的 PHP 服務是否已重新啟動；以及警告中提及的 OPcache 資源是否與您增加的資源不同。

應該分配多少 OPcache 記憶體？

沒有絕對的最佳值。理想的目標是預留足夠的記憶體空間，既能確保快取不會持續接近其極限，又不會影響其他元件的正常運作。對於小型 VPS，建議保守配置，並密切注意記憶體壓力。對於運行大量應用程式或 PHP 程式碼量較大的實例，如果實際 OPcache 使用情況顯示 128 MB 記憶體不足，則可能需要 256 MB 或更多記憶體。在大型伺服器上，記憶體大小的設定應結合 PHP-FPM 工作進程數和其他共享服務的需求來考慮。

實際比較很簡單：增加 OPcache 記憶體可以減少快取清除和重新編譯，但減少 OPcache 記憶體可以為並發 PHP 工作進程和資料庫騰出更多 RAM。選擇時應基於實際使用情況和 Nextcloud 的警告報告，而不是伺服器所能接受的最大值。

導致警告持續存在的常見錯誤

僅編輯 CLI PHP：瀏覽器仍使用 PHP-FPM 或 mod_php。
提高錯誤的限制：增加記憶體並不能解決加速檔案表已滿的問題。
忘記重新啟動：正在運行的 PHP 進程可能仍然保留舊的 INI 值。
已停用opcache.save_comments： Nextcloud 要求保留評論。
複製過時的調優片段：舊的指南可能會建議激進的重新驗證設置，從而導致升級問題。

按伺服器類型推薦的方法

小型個人 Nextcloud 伺服器：保留重新驗證的預設設置，保留評論，並且僅在實際超過閾值時才提高限制。這樣可以最大限度地減少記憶體使用和運行意外情況。

繁忙的多用戶伺服器：監控 OPcache 的使用情況，並在管理員發出警告表明伺服器壓力過大時增加可用記憶體。協調 OPcache 記憶體與 PHP-FPM 工作進程的記憶體大小，避免一項最佳化操作導致系統範圍內的交換空間不足。

託管主機或容器鏡像：首先要確定需要覆蓋哪些 PHP 設定。在臨時容器中編輯的檔案在重新部署後可能會遺失，而服務提供者可能會透過其控制面板或環境配置公開自訂的 INI 值。

最終檢查

正確的修復方案包含三個部分：Nextcloud 的 Web PHP 進程已啟用 OPcache，所需行為opcache.save_comments=1保持不變，並且之前接近滿載的特定 OPcache 資源現在有足夠的剩餘空間。一旦滿足這些條件並重新載入 PHP，警告應該就會消失，而無需進行過多的記憶體分配或冒險的快取驗證變更。