我每天早上（美股收盤後）要跑 SEPA，一次要掃 3537 支那斯達克股票、算指標、篩選。這功能一開機就是重活。而且zeabur主機是 k3s，你動不了它的設定，記憶體爆了它就直接把整個程式殺掉重開。所以問題就變成：怎麼讓這隻吃記憶體的怪，跑一整輪不要把自己撐爆。

---

1. 一次把全部股票的資料疊在一起 → 記憶體瞬間爆高

- 原本：算 RS 評分時，用 pd.concat 把每一批股票的收盤價「疊」成一大張表。疊的當下會同時放著舊的+新的兩份，一下衝到 300MB。

- 改法：不要疊大表，改成一支一支收進一個字典。峰值直接從 300MB 掉到 15MB。順便把同時開的工人從 20 個減到 5 個。

2. 季報資料算完不丟，全堆著 → 越跑越腫

- 原本：SEPA 會把每支股票的季報存進一個快取，但這快取要等 3537 支「全部跑完」才清一次。等於跑到第 3000 支時，前面 3000 支的資料還全在記憶體裡。

- 改法：改成每支算完就馬上把那支的季報丟掉。記憶體裡永遠只留正在跑的那幾支。

3. 記憶體一直偷偷變多，但不知道是誰 → 先裝個監視器

- 狀況：不是只有早上 SEPA，連下午到深夜記憶體也一直慢慢變多，可是不知道是哪個排程任務害的。

- 改法：寫一個小探針，每個排程任務跑完就記一下「這任務吃掉多少沒還」，跑一整晚，看誰是慣犯。

4. 抓到慣犯：一個沒新聞也照樣開連線的任務

- 原因：抓即時新聞那個任務，「沒新聞就早點結束」那行程式碼被我自己註解掉了。結果就算沒新聞，它每幾分鐘還是開一個網路連線（而且沒關），一次一點點漏，27 次累積漏了 116MB。

- 改法：把「沒新聞就直接 return」加回去，沒新聞就什麼都不做。

5. 我明明清了，數字卻不降 → 記憶體其實還沒還給系統

- 原因：Python 這邊我叫它回收（gc.collect()）了，Python 也覺得乾淨了，但底層的 C 記憶體管理器把空出來的位子先「留著備用」，沒真的還給作業系統。所以外面看數字還是不降。

- 改法：多加一步，直接叫底層把空位還給系統；再設一個環境變數少留一點備用空間。雙保險。

6. 反正修不完，給自己一個安全重開機（逃生艙）

- 原因：漏這種東西不可能一次修到完全乾淨，而且我又動不了 k3s。

- 改法：加一個看門狗，隨時盯記憶體，快到上限（92%、連續三次）就自己乾淨地重開一次。因為存檔是斷點續跑的，重開後可以從剛剛的地方接著跑，使用者無感。

---

一句話：因為 SEPA 早上要一口氣掃三千多支股票、又不能爆記憶體，所以我從「別一次全載」、「算完就丟」、「裝監視器抓漏」、「還記憶體給系統」一路弄到「真的撐不住就自己安全重開」。