#cofacts
2026-04-01
結果 staging bot 測不過，是因為 staging mongodb 太久沒用所以被 suspend orz
測完了，ES v9 運作正常～
那我覺得
我現在來進行最後的 migration 吧 XDDD
好像也沒啥拖著不做的理由
那我覺得
我現在來進行最後的 migration 吧 XDDD
好像也沒啥拖著不做的理由
現在開始到 3:30pm 會有 downtime 唷~
Cofacts 資料庫升級，全系統 1:40 ~ 3:40 會無回應唷
Cofacts 資料庫升級完畢，系統應已恢復
Replied to a thread: 2026-04-01 00:18:41
測完了，ES v9 運作正常～
那我覺得
我現在來進行最後的 migration 吧 XDDD
好像也沒啥拖著不做的理由
那我覺得
我現在來進行最後的 migration 吧 XDDD
好像也沒啥拖著不做的理由
現在開始到 3:30pm 會有 downtime 唷~
Replied to a thread: 2026-04-01 00:18:41
Cofacts 資料庫升級，全系統 1:40 ~ 3:40 會無回應唷
2026-04-02
@tomohito.oginome.ctr has left the channel
我們不是ubuntu嗎？
上面這個 15 天前的訊息，紀錄了我們從 COS 轉 ubuntu 的心境轉折
偶齁
2026-04-07
HackMD
# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2026 -
不是 這應該沒重要到上紀錄吧😅
AI 覺得重要 （？）
好啦我整理一下 lol
🤣
有種餓叫阿嬤怕你餓
有種餓叫阿嬤怕你餓
AI 覺得重要 （？）
好啦我整理一下 lol
🤣
有種餓叫阿嬤怕你餓
有種餓叫阿嬤怕你餓
2026-04-08
@sage.otomo joined #cofacts. They’re also new to g0v.
2026-04-14
# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2026 -
2026-04-15
Replied to a thread: 2026-03-02 12:28:47
rumors-deploy 更新囉，也放了張圖
https://github.com/cofacts/rumors-deploy?tab=readme-ov-file#architecture-overview
https://github.com/cofacts/rumors-deploy?tab=readme-ov-file#architecture-overview
- 👍1
2026-04-18
Cloudrun 的 browser run (原 browser rendering) 現在可以直接讓 local puppeteer 連結，也有 MCP 可以讓 coding agent 直連
https://blog.cloudflare.com/browser-run-for-ai-agents/
這樣一來就不需要像 cofacts worker repo 那樣把爬資料整個拉到 worker 去，直接接好像也可以
https://blog.cloudflare.com/browser-run-for-ai-agents/
這樣一來就不需要像 cofacts worker repo 那樣把爬資料整個拉到 worker 去，直接接好像也可以
The Cloudflare Blog
Browser Rendering is now Browser Run, with Live View, Human in the Loop, CDP access, session recordings, and 4x higher concurrency limits for AI agents
- 💡1
欸不對並沒有 MCP server，他是 devtool MCP 搭配 websocket ._.
Cloudrun 的 browser run (原 browser rendering) 現在可以直接讓 local puppeteer 連結，也有 MCP 可以讓 coding agent 直連
https://blog.cloudflare.com/browser-run-for-ai-agents/
這樣一來就不需要 cofacts worker repo 那些東西，直接接好像也可以
https://blog.cloudflare.com/browser-run-for-ai-agents/
這樣一來就不需要 cofacts worker repo 那些東西，直接接好像也可以
欸不對並沒有 MCP server，他是 devtool MCP 搭配 websocket ._.
欸不對並沒有 MCP server，他是 devtool MCP 搭配 websocket ._.
2026-04-21
# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2026 -
一則訊息只能放三個月×﹍×
我寫了簡單介紹@mrorz 之後看你怎麼改
感謝！～
感謝！～
- 💡2
1
deploy可能還需要改一下XD
我發現 rumors-deploy 上面的 elasticsearch 版本是錯的 XD
我們已經用到 9.2.3 了
我們已經用到 9.2.3 了
2026-04-22
Hmm 好像沒 dev 這過 tag，我們 dockerhub 上似乎只有 latest XDD
我確實沒跑過，如果可以把它修好發個 PR 就太棒了 🙏
我確實沒跑過，如果可以把它修好發個 PR 就太棒了 🙏
Hmm 好像沒 dev 這過 tag，我們似乎只有 master XDD
我確實沒跑過，如果可以把它修好發個 PR 就太棒了 🙏
我確實沒跑過，如果可以把它修好發個 PR 就太棒了 🙏
好的👌
好的👌
Elasticsearch官方強烈建議關閉swap 並且使用 `bootstrap.memory_lock: true` 設定，讓 Elasticsearch 啟動時呼叫 `mlockall()`，將 JVM 進程位址空間鎖定在實體 RAM 中
https://www.elastic.co/docs/deploy-manage/deploy/self-managed/setup-configuration-memory#:~:text=Most%20operating%20systems,out%20to%20disk.
https://www.elastic.co/docs/deploy-manage/deploy/self-managed/setup-configuration-memory#:~:text=Most%20operating%20systems,out%20to%20disk.
1
1
大感謝，我來調整看看
我覺得有道理，讓大家 review 一下，沒其他問題的話我在月黑風高之時換個設定
*[維運報告] Elasticsearch 記憶體優化與 Swap 調整完成*
為了避免 Elasticsearch 使用 Swap 導致效能不穩，剛才已完成 Production 設定調整：
• *問題背景*：先前主機 4GB Swap 幾乎全滿（僅剩 2MB），且 ES Container 未限制 Swap 使用，違反官方 Best Practice 且有 OOM 隱憂。
• *調整內容*：
◦ 在 `docker-compose.yml` 對 `db` 服務加上 `mem_limit: 22g` 與 `memswap_limit: 22g`。
◦ 強制 ES 容器不使用 Swap，將所有資料保留在實體 RAM 中。
*執行結果*：
◦ ✅ *Swap 成功釋放*：主機 Swap 使用量從 4GB 降至約 360MB。
◦ ✅ *效能穩定*：ES 已重啟完成，叢集狀態為 Yellow（單節點正常狀態），實體記憶體穩定在 17.4GB / 22GB。
◦ ✅ *服務正常*：API 與網站讀取功能均已確認恢復正常。
目前觀察 CPU 已降至穩定水位，後續會持續監控記憶體用量。
為了避免 Elasticsearch 使用 Swap 導致效能不穩，剛才已完成 Production 設定調整：
• *問題背景*：先前主機 4GB Swap 幾乎全滿（僅剩 2MB），且 ES Container 未限制 Swap 使用，違反官方 Best Practice 且有 OOM 隱憂。
• *調整內容*：
◦ 在 `docker-compose.yml` 對 `db` 服務加上 `mem_limit: 22g` 與 `memswap_limit: 22g`。
◦ 強制 ES 容器不使用 Swap，將所有資料保留在實體 RAM 中。
*執行結果*：
◦ ✅ *Swap 成功釋放*：主機 Swap 使用量從 4GB 降至約 360MB。
◦ ✅ *效能穩定*：ES 已重啟完成，叢集狀態為 Yellow（單節點正常狀態），實體記憶體穩定在 17.4GB / 22GB。
◦ ✅ *服務正常*：API 與網站讀取功能均已確認恢復正常。
目前觀察 CPU 已降至穩定水位，後續會持續監控記憶體用量。
Elasticsearch官方強烈建議關閉swap
https://www.elastic.co/docs/deploy-manage/deploy/self-managed/setup-configuration-memory#:~:text=Most%20operating%20systems,out%20to%20disk.
https://www.elastic.co/docs/deploy-manage/deploy/self-managed/setup-configuration-memory#:~:text=Most%20operating%20systems,out%20to%20disk.
大感謝，我來調整看看
我覺得有道理，讓大家 review 一下，沒其他問題的話我在月黑風高之時換個設定
*[維運報告] Elasticsearch 記憶體優化與 Swap 調整完成*
為了避免 Elasticsearch 使用 Swap 導致效能不穩，剛才已完成 Production 設定調整：
• *問題背景*：先前主機 4GB Swap 幾乎全滿（僅剩 2MB），且 ES Container 未限制 Swap 使用，違反官方 Best Practice 且有 OOM 隱憂。
• *調整內容*：
◦ 在 `docker-compose.yml` 對 `db` 服務加上 `mem_limit: 22g` 與 `memswap_limit: 22g`。
◦ 強制 ES 容器不使用 Swap，將所有資料保留在實體 RAM 中。
*執行結果*：
◦ ✅ *Swap 成功釋放*：主機 Swap 使用量從 4GB 降至約 360MB。
◦ ✅ *效能穩定*：ES 已重啟完成，叢集狀態為 Yellow（單節點正常狀態），實體記憶體穩定在 17.4GB / 22GB。
◦ ✅ *服務正常*：API 與網站讀取功能均已確認恢復正常。
目前觀察 CPU 已降至穩定水位，後續會持續監控記憶體用量。
為了避免 Elasticsearch 使用 Swap 導致效能不穩，剛才已完成 Production 設定調整：
• *問題背景*：先前主機 4GB Swap 幾乎全滿（僅剩 2MB），且 ES Container 未限制 Swap 使用，違反官方 Best Practice 且有 OOM 隱憂。
• *調整內容*：
◦ 在 `docker-compose.yml` 對 `db` 服務加上 `mem_limit: 22g` 與 `memswap_limit: 22g`。
◦ 強制 ES 容器不使用 Swap，將所有資料保留在實體 RAM 中。
*執行結果*：
◦ ✅ *Swap 成功釋放*：主機 Swap 使用量從 4GB 降至約 360MB。
◦ ✅ *效能穩定*：ES 已重啟完成，叢集狀態為 Yellow（單節點正常狀態），實體記憶體穩定在 17.4GB / 22GB。
◦ ✅ *服務正常*：API 與網站讀取功能均已確認恢復正常。
目前觀察 CPU 已降至穩定水位，後續會持續監控記憶體用量。
大感謝，我來調整看看
我發現 rumors-deploy 上面的 elasticsearch 版本是錯的 XD
我們已經用到 9.2.3 了
我們已經用到 9.2.3 了
我覺得有道理，讓大家 review 一下，沒其他問題的話我在月黑風高之時換個設定
2026-04-23
Replied to a thread: 2026-04-22 16:16:33
*[維運報告] Elasticsearch 記憶體優化與 Swap 調整完成*
為了避免 Elasticsearch 使用 Swap 導致效能不穩，剛才已完成 Production 設定調整：
• *問題背景*：先前主機 4GB Swap 幾乎全滿（僅剩 2MB），且 ES Container 未限制 Swap 使用，違反官方 Best Practice 且有 OOM 隱憂。
• *調整內容*：
◦ 在 `docker-compose.yml` 對 `db` 服務加上 `mem_limit: 22g` 與 `memswap_limit: 22g`。
◦ 強制 ES 容器不使用 Swap，將所有資料保留在實體 RAM 中。
*執行結果*：
◦ ✅ *Swap 成功釋放*：主機 Swap 使用量從 4GB 降至約 360MB。
◦ ✅ *效能穩定*：ES 已重啟完成，叢集狀態為 Yellow（單節點正常狀態），實體記憶體穩定在 17.4GB / 22GB。
◦ ✅ *服務正常*：API 與網站讀取功能均已確認恢復正常。
目前觀察 CPU 已降至穩定水位，後續會持續監控記憶體用量。
為了避免 Elasticsearch 使用 Swap 導致效能不穩，剛才已完成 Production 設定調整：
• *問題背景*：先前主機 4GB Swap 幾乎全滿（僅剩 2MB），且 ES Container 未限制 Swap 使用，違反官方 Best Practice 且有 OOM 隱憂。
• *調整內容*：
◦ 在 `docker-compose.yml` 對 `db` 服務加上 `mem_limit: 22g` 與 `memswap_limit: 22g`。
◦ 強制 ES 容器不使用 Swap，將所有資料保留在實體 RAM 中。
*執行結果*：
◦ ✅ *Swap 成功釋放*：主機 Swap 使用量從 4GB 降至約 360MB。
◦ ✅ *效能穩定*：ES 已重啟完成，叢集狀態為 Yellow（單節點正常狀態），實體記憶體穩定在 17.4GB / 22GB。
◦ ✅ *服務正常*：API 與網站讀取功能均已確認恢復正常。
目前觀察 CPU 已降至穩定水位，後續會持續監控記憶體用量。
- 🎉1
4/18 以來 CloudRun 運算量與主機運算量都比較高，我在懷疑是 4/18 當天我把 Block AI bots 的設定從 Block on all pages 調成 Do not block 導致的
為了確認成因，我今天再把 toggle 設回 Block on all pages，看看運算量那些會不會下降
為了確認成因，我今天再把 toggle 設回 Block on all pages，看看運算量那些會不會下降
- 👍1