Nextcloud AIO 全文檢索 Elasticsearch 故障排除筆記：從 cURL error 52 到 OutOfMemoryError
發佈於 2025年5月18日 (最後修改於 2025年5月31日) • 4 分鐘 閱讀 • 1,893 字記錄一次 Nextcloud AIO 中 Elasticsearch 全文檢索服務出現 cURL error 52，最終發現並解決 OutOfMemoryError 的過程與方法。
我的 Nextcloud All-in-One (AIO) 實例中，從安裝完成後，fulltextsearch_elasticsearch 應用程式的日誌持續出現一條重複的錯誤：
Retry 0: cURL error 52: Empty reply from server (see [https://curl.haxx.se/libcurl/c/libcurl-errors.html](https://curl.haxx.se/libcurl/c/libcurl-errors.html)) for http://elastic:***@nextcloud-aio-fulltextsearch:9200/nextcloud-aio/_doc/files%3A19230?pipeline=attachment「Empty reply from server」—— 這通常意味著客戶端成功連接到伺服器，但伺服器在沒有給出任何回應的情況下關閉了連接。當時，我檢查了 Elasticsearch 容器的狀態，它看似仍在運行。這讓avidin的故障判斷變得有些棘手，不確定是 ingest-attachment 插件處理特定檔案時發生錯誤，還是資源分配上存在潛在問題。利用Google搜尋關鍵字，導引到Nextcloud AIO的論壇，但沒看到對應的解決方法。
初步查看 Elasticsearch 的啟動日誌，情況似乎還算正常，除了幾條關於記憶體鎖定 (memory locking) 和 AttachmentProcessor 即將變更預設行為的警告外，並沒有直接指向崩潰的錯誤訊息。
然而，當問題持續，我開始注意到一個更為根本的現象：Elasticsearch 容器似乎在異常退出。從 Nextcloud AIO 的監控或其他系統日誌中，我觀察到「ERROR: Elasticsearch exited unexpectedly, with exit code 3」的訊息。
使用 docker ps -a 查看容器狀態，證實了 nextcloud-aio-fulltextsearch 容器處於一種不穩定的重啟循環中。它會啟動，短暫地顯示為「Up X seconds (healthy)」，然後很快又消失並被 Docker 或 AIO 的管理機制自動重啟。這種短暫的「健康」狀態，讓我誤以為整個容器是正常運作中，也解釋了為什麼錯誤訊息會頻繁的不斷出現
為了弄清真相，我獲取了 Elasticsearch 容器在崩潰前的完整日誌 (es_crash_full_logs.txt)。這份日誌最終揭示了問題的癥結所在：
{"@timestamp":"2025-05-14T11:19:00.049Z", "log.level": "WARN", "message":"[gc][103] overhead, spent [898ms] collecting in the last [1.1s]", ...}
{"@timestamp":"2025-05-14T11:19:01.227Z", "log.level": "WARN", "message":"[gc][104] overhead, spent [1.1s] collecting in the last [1.1s]", ...}
java.lang.OutOfMemoryError: Java heap space
Dumping heap to data/java_pid73.hprof ...
Unable to create data/java_pid73.hprof: File exists
Terminating due to java.lang.OutOfMemoryError: Java heap space日誌清晰地記錄了在 UTC 時間 2025-05-14 11:19:01 左右（即我下定決心找出問題的台灣時間晚上 7:19 左右），Elasticsearch 因 java.lang.OutOfMemoryError: Java heap space 而終止。在此之前，出現了多次垃圾回收 (GC) 負載過高的警告，這是記憶體即將耗盡的典型信號。
JVM 參數顯示，Elasticsearch 的堆記憶體設定為 -Xms512M -Xmx512M。對於需要處理文件內容提取（透過 ingest-attachment 插件）的 Elasticsearch 來說，512MB 的堆記憶體顯然不足以應對工作負載。
鑑於問題的根本原因是記憶體不足，再加上決定撤下用途太單一的DS216+II後多了兩顆大容量的硬碟，所以決定重新安裝 Nextcloud AIO，並在初始設定時就為 Elasticsearch 分配更充裕的記憶體。
對於 Nextcloud AIO 使用單一 docker run 指令啟動主控制容器的模式，正確設定 ES_JAVA_OPTS 的方法是將此環境變數直接傳遞給主控制容器的 docker run 指令。
我的伺服器配備 32GB RAM，除了 Nextcloud AIO，還計劃運行 Ollama 和 Metabase。綜合考量後，我決定為 Elasticsearch 分配 2GB 的堆記憶體。以下是調整後的 docker run 指令：
# 確保 Nextcloud 數據目錄存在
sudo mkdir -p /home/ncdata
# 執行 Nextcloud AIO 主控制容器的指令
sudo docker run \
--init \
--sig-proxy=false \
--name nextcloud-aio-mastercontainer \
--restart always \
--publish 80:80 \
--publish 8080:8080 \
--publish 8443:8443 \
--volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config \
--volume /var/run/docker.sock:/var/run/docker.sock:ro \
--env NEXTCLOUD_DATADIR="/home/ncdata" \
--env ES_JAVA_OPTS="-Xms2G -Xmx2G" \
ghcr.io/nextcloud-releases/all-in-one:latest(請注意：上述 --env NEXTCLOUD_DATADIR="/home/ncdata" 指令會將 Nextcloud 的資料存放在主機的 /home/ncdata 目錄下，AIO 主容器會處理相應的內部掛載。)
在解決了 Elasticsearch 的主要問題，並準備重新安裝的過程中，我也一併處理了 Nextcloud 設定中出現的另外兩個提示，以確保系統配置的完整性。
Mimetype 遷移：
Nextcloud 提示「One or more mimetype migrations are available…」。解決方法是執行 occ maintenance:repair --include-expensive。
操作步驟如下（建議在維護模式下進行）：
# 開啟維護模式
sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ maintenance:mode --on
# 執行 Mimetype 修復
sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ maintenance:repair --include-expensive
# 關閉維護模式
sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ maintenance:mode --off此過程可能需要一些時間，具體取決於實例的大小。
設定預設手機國際冠碼：
提示「您並未設定手機國際冠碼…」。解決方法是設定 default_phone_region。
對於台灣地區，ISO 3166-1 alpha-2 代碼為 TW。執行以下指令：
sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ config:system:set default_phone_region --value=TW這將簡化使用者輸入電話號碼的流程。
這次 Elasticsearch 的故障，從最初的 cURL error 52 到最終定位於 OutOfMemoryError，再次證明了詳細查閱日誌和理解系統架構的重要性。對於 Nextcloud AIO 這樣的整合環境，了解其主容器如何管理和配置子服務（如 Elasticsearch 的 ES_JAVA_OPTS）是排除問題的關鍵。希望這次的經驗記錄，對遇到類似問題的朋友能有所幫助。合理的資源配置是系統穩定運行的基石。