資料與儲存 2026 年 7 月 29 日

2026-07-29 — ClickHouse Managed Postgres 導入嚴格記憶體超額分配以隔離 OOM 故障,同時文件站遷移至 Mintlify 強化 agent 存取

primary=https://clickhouse.com/blog/strict-memory-overcommit-for-postgres primary=https://clickhouse.com/blog/clickhouse-docs-on-mintlify

ClickHouse Managed Postgres 啟用嚴格記憶體超額分配,把整機當機降級為單一查詢失敗

clickhouse.com · 2026-07-28

ClickHouse 於 2026 年 7 月 28 日在官方部落格公布,Managed Postgres 服務預設在所有伺服器上啟用嚴格記憶體超額分配(vm.overcommit_memory=2。這項變更的目標是把過去 Linux OOM killer 觸發的整個 Postgres 實例重啟,轉換成單一查詢失敗、其餘連線不受影響。作者 Kaushik Iska(ClickHouse Postgres 工程總監)在文章中用 Postgres 16 搭配 EC2 m7i.2xlarge(8 vCPU、30.8GiB RAM)做了對照實驗。

原本的問題

Linux 預設的記憶體超額分配策略(vm.overcommit_memory=0)允許程序申請超過實體可用量的記憶體,代價是當系統真的耗盡記憶體時,OOM killer 會挑一個程序直接送出 SIGKILL。問題在於 Postgres 的 backend 程序共用一塊 shared memory,裡面存放 shared buffers、WAL buffer 與 lock table。

一旦某個 backend 被 OOM killer 強制砍掉,Postgres 無法確認共享記憶體是否已經損毀,只能假設它壞了。於是 postmaster 會終止所有其他 backend、砍斷全部連線,並透過 WAL 重播做 crash recovery,讓整個實例離線一段時間才能恢復服務。

採用的方法

ClickHouse 的作法是讓核心在配置階段就依據明確的可承諾記憶體上限拒絕分配,而不是等到實體記憶體真的用盡才動手。具體設定包括:

  • vm.overcommit_memory=2 — 切換為嚴格模式,核心依 commit limit 拒絕超額配置
  • vm.overcommit_kbytes — 設為扣除 huge pages 後可用記憶體的約 80%,再加 2GB 緩衝
  • shared_buffers=6864MB — 佔總記憶體 25%,以 2MB huge pages 保留,不計入 commit limit

在嚴格模式下,超額的記憶體申請會讓 malloc 直接回傳 ENOMEMPostgres 把 ENOMEM 當成一般錯誤處理:該查詢失敗並回報 "out of memory",交易 rollback,其餘連線照常運作,不會觸發 postmaster 層級的清場。

實際效果

測試情境是 3GB 的 pgbench 資料集,搭配 20 條閒置的旁觀 session,另外每 0.3 秒嘗試建立新連線,同時有測試 session 透過 generate_series 聚合建立 2GB 的記憶體陣列來製造壓力。兩種策略下系統的記憶體用量走勢完全不同

指標預設超額分配嚴格超額分配
尖峰已提交記憶體23.6GiB(超出 11.6GiB 建議上限)19.8GiB(低於 20.5GiB 強制上限)
失敗模式SIGKILL 砍掉持有 2.4GB 的 backend單一查詢回報 out of memory
受影響 session 數20 個全部斷線0 個斷線,僅 1 個查詢失敗
停機時間30.2 秒0 秒

吞吐量方面,文章給出的數字顯示啟用嚴格模式幾乎沒有額外成本:唯讀負載下為 216,606 對 211,882 TPS(差異 2.2%,落在 4-5% 的跑分誤差範圍內),讀寫混合負載下為 15,790 對 15,878 TPS(差異 0.6%)。

原始來源:ClickHouse Blog


ClickHouse 文件站遷移至 Mintlify,把 coding agent 讀者也當成一等公民

clickhouse.com · 2026-07-27

ClickHouse 於 2026 年 7 月 27 日發文宣布,官方文件站 clickhouse.com/docs 從 Docusaurus 遷移到 Mintlify 這個文件平台。作者群(Shaun Struwig、Dominic Tran、Alexey Milovidov)在文中指出,遷移的主要動機是「超過一半的開發文件流量來自 coding agent,而不只是人類」,因此舊平台以人類讀者為唯一設計對象的假設已經站不住腳。

平台與架構變動

新平台會自動偵測存取來源是 agent 還是瀏覽器,對 agent 直接回傳 Markdown 而非 HTML,減少解析開銷。文件內容也從原本分散在 ClickHouse/ClickHouseClickHouse/clickhouse-docs 兩個 repo,整併進核心開發 repo 底下的 github.com/ClickHouse/ClickHouse/tree/master/docs,讓文件與程式碼改動可以在同一個 PR 內一起送出。

資訊架構重新劃分為四大區塊:Get started(快速上手、遷移、安裝、資料集)、Concepts(核心概念與最佳實務)、Guides(長篇情境案例)、Reference(函式、設定、資料型別、格式、table engine)。API Playground 則是直接由 OpenAPI spec 產生,Cloud 與 ClickStack 兩條產品線各自有可互動、可帶入憑證測試的「Try it」介面。

對 agent 的整合

新站提供官方 MCP server,可用以下指令加入 Claude Code:

claude mcp add --transport http clickhouse-docs https://clickhouse.com/mcp --scope user

這個 MCP server 提供類似檔案系統的 shell 式導覽方式,並內建 feedback 機制。此外,ClickHouse 26.6 版本已經把文件內嵌進資料庫本身:透過新增的 system.documentation 系統表,使用者可以在終端機直接下 help <topic>\h <topic> 查文件,不必離開 CLI。

其他變動

本地化語言從 5 種(英文、日文、韓文、簡體中文、俄文)擴增到 9 種,新增巴西葡萄牙文、西班牙文、法文與阿拉伯文,翻譯流程以 LLM 為主、輔以社群貢獻校對。文件站另外加入跨文件、部落格、GitHub issue 的統一搜尋、「Ask AI」問答,以及複製為 Markdown、下載 PDF 等功能。

原始來源:ClickHouse Blog


End of article
0
Would love your thoughts, please comment.x
()
x