容器和 kubernetes 的 Postgresql RAM 優化
我想知道如何優化部署在 Kubernetes 中的 PostgreSQL 數據庫的 RAM 使用率。
特別是我對配置
shared_buffers和effective_cache_size值感興趣。通常，各種來源提出的建議是使用：
- 如果您的系統具有 1GB 或更多 RAM，shared_buffers 的合理起始值是系統記憶體的 1/4。如果您的 RAM 較少，則必須更仔細地考慮作業系統佔用了多少 RAM；那裡更典型的是接近 15%。在某些工作負載中，更大的 shared_buffers 設置也很有效，但考慮到 PostgreSQL 也依賴於作業系統記憶體的方式，您不太可能會發現使用超過 40% 的 RAM 比使用更小的 RAM 更好。（PostgreSQL 網站）
- 該值應設置為機器總 RAM 的 15% 到 25%（EDB 網站）
- 不超過 50% 的可用 RAM（EDB PostgreSQL 調整）
由於容器通過設計使用更少的背景 RAM，因此設置 shared_buffers 值的好建議是什麼？
現在該值設置為 25%（1GB 的 4GB 總容器限制），我注意到它很快就被填滿了。
shared_buffers 與有效記憶體大小
在 postgresql 調整中，這兩個數字代表：
- shared_buffers “有多少記憶體專用於 PostgreSQL 用於記憶體數據”
- Effective_cache_size “作業系統和數據庫本身有多少記憶體可用於磁碟記憶體”
因此，如果有很多 shared_buffers，記憶體的重複查詢將“更好”工作。但是如果有更多的 Effective_cache_size，從數據庫底層的磁碟讀取表會“更好”
如果工作負載如此多變且不重複，以至於需要重複磁碟讀取，那麼 Effective_cache_size 越高越好。如果一個小集合中有很多相同的查詢，那麼更多的 shared_buffers 會更好
值得記住的是，在正常工作的 Linux 系統上，系統將抓取任何“空閒”記憶體用於磁碟記憶體，因為可能會發生意外讀取，如果他們這樣做，否則未使用的記憶體可能會加速它們
如何確定最佳設置
值得一提的是，最常用的“方法”是不關心和過度配置所使用的記憶體。硬體很便宜，而正確解決它的時間很昂貴。那說..
有兩種方法
- 在 prod 中執行應用程序並監控記憶體壓力
- 設計一個測試來找出記憶體使用的限制
要監控 prod 中的記憶體，通常使用第三方軟體包（如 cAdvisor 或 Prometheus）來完成
查看圖表並將它們與您的傳入請求進行比較。如果明顯有很大的餘量，那麼增加參數，看看這是否有助於系統效率。
對於測試，基本上你做同樣的事情，但使用人工測試工作負載
為了計算出最好的記憶體大小，有像 senpai這樣的自動化工具。基本上，他們將在各種記憶體設置下重複執行測試工作負載，直到它停止