前言

前幾天我們聊過 什麼是 Page Cache，也提到在我們的專案裡，Full Page Cache（FPC）是存放在 Redis。理論上，打開 Page Cache 之後，頁面就能被快取、後端壓力下降、速度更快。
.
.
終於到現在了！
我們想要跟大家分享，我們公司在實務上真的遇到的問題，以及後續我們是怎麼解決並優化 Magento 的效能。
不過這一篇先不談解法，先把「問題」講清楚。
.
.
.

我們遇到的問題與瓶頸

在專案使用 Magento 的過程中，我們遇到了一個很棘手的狀況：

• Redis 常常爆掉（記憶體飆高、連線不穩）
• 頁面速度變慢，體感上像沒吃到快取，甚至更慢

為什麼會這樣？我們往後台與監控系統一看，就發現了端倪：

藍線是記憶體使用率，可以看到它持續衝高、頻繁觸發警戒，最終導致服務不穩。
那為什麼會這樣呢？
.
.
.

查找問題原因（一步一步看log）

遇到這個問題後，我們先去看了 Magento 的 log，結果出現了關鍵錯誤訊息：

main.CRITICAL: Lost connection to Redis server. ...
main.CRITICAL: Connection to Redis 127.0.0.1:6379 failed ...
main.CRITICAL: LOADING Redis is loading the dataset in memory ...

👉 這代表什麼意思呢？用白話翻譯給大家聽：

• Lost connection → 連到一半斷掉，Redis 當下不穩
• Connection refused → Redis 掛了，連不進去
• LOADING → Redis 剛重啟，還在忙著把資料載回記憶體

也就是說：Redis 不是斷掉，就是在重啟；此時 Magento 拿不到快取，只能重跑流程 → 網站就變慢。
.
.
我們也把當時的錯誤紀錄畫面截下來，現場會長這樣：

上圖可以看到相同訊息大量、反覆出現，代表不是偶一為之，而是系統性不穩。

.
.
.

我們的檢查

發現 log 後，我們回頭看主機資源與 Redis 狀態，觀察到：

• 記憶體與 CPU 偏高
• 錯誤與高負載是 持續重複 的，不是單一事件
• 共通點就是：記憶體被吃爆 → Redis 當機/重啟（LOADING） → Magento 快取失效 → 前台變慢

我們也注意到：

👉 PHP 7.4 的記憶體使用量，從原本大約 1000MB，突然暴增到 5000MB！
這種異常暴增直接把主機資源壓爆，Redis 當然也就跟著崩潰。
.
.
通過詳細分析，我們建立了完整的問題鏈：
PHP 記憶體異常暴增
↓
主機記憶體資源耗盡
↓
Redis 服務不穩定/被迫重啟
↓
Full Page Cache 失效
↓
Magento 必須重新執行完整的頁面生成流程
↓
前台頁面載入更慢，甚至比沒有快取時還慢

.
.
.

給讀者的小檢查清單

如果你懷疑自己的 Magento + Redis 有類似問題，可以先檢查這幾個方向：

1. 看 log → var/log/exception.log 裡有沒有 Lost connection / Connection refused / LOADING
2. 看記憶體 → 監控圖表或 top/htop，是不是長期吃高
3. 看 Redis 狀態 → redis-cli info，重點關鍵字：used_memory, loading, uptime_in_days
4. 注意 PHP → 看 php-fpm 的記憶體是不是異常膨脹（可能是導火線）

結論

• 症狀：Redis 爆、高負載、斷線；前台速度變慢
• 線索：log 不斷出現 Redis 錯誤
• 脈絡：資源長期吃高 → Redis 不穩 → FPC 失效 → Magento 重新跑流程 → 網站更慢
• 額外發現：PHP 7.4 記憶體暴增（1000MB → 5000MB），高度懷疑是根本原因之一

下一步預告

今天算是把坑挖出來給大家看了
下一篇我們就繼續跟著研究！看看 Redis 裡面到底塞了些什麼，怎麼會讓網站變得這麼卡。