Postgresql
如何監控數據庫的總體性能和健康狀況？
我已經閱讀了@Mike 對如何判斷數據庫調整是否富有成效（PostgreSQL）的回答，這就是我正在考慮的用於監控我的數據庫（Web 應用程序、許多連接、大量寫入和一直在讀取，非常動態的數據）。
該方法總結如下：我想知道我的數據庫是否能夠跟上工作負載，隨著時間的推移它是否具有相同的準備狀態，以及最終我的調整和清理是否有用。因此，對於一般的健康指標，監控查詢時間（對於 Web 應用程序和數據流使用的代表性查詢）對我來說是明智和緊湊的（查詢時間增加而沒有實質性變化 => 性能正在下降）。但我的問題是，是嗎？除了連結的問題之外，我還沒有找到這種方法的其他來源，而且我在如何實現所有這些方面還有一些漏洞，因此從其他範例/經驗或手冊中了解更多資訊將非常有用。即使知道這種方法不值得做也會很有趣。
僅供參考，我讀過
pgbench，但它對我來說似乎很無菌，我的意思是，它確實提供了一個參考點，但它對我的表、我的索引、關於**我的數據庫的活動環境說了什麼？（我希望你能理解我的意思）也許我pgbench看錯了，但這正是我想知道的！注意：我與 Postgres 一起工作，所以我對 Postgres 的特定答案會很棒……但不是必需的！
總的來說，我有點同意：如果客戶滿意，就不要開始調整。
但是，在為時已晚之前，您肯定會在沒有註意到的情況下出現問題。以下是應引起警報的隨機列表，但不保證完整性：
- 是否有足夠的可用磁碟空間？
- CPU是否過載？
- I/O 子系統是否過載？
- 數據庫是否增長不合理？
- WAL 歸檔有問題嗎？
- 客戶端連接是否過多？
- 是否有長時間執行的查詢？
- 是否存在長時間保持開放的交易？
- 是否存在因事務環繞而面臨數據失去危險的數據庫？
- 你能連接到數據庫並執行一個簡單的查詢嗎？
- 複製延遲太多了嗎？
- 有沒有死元組太多的表？
- 您是否因數據損壞而出錯？
- 是否有任何過時的準備交易？
pgbench比您想像的更有用：您可以將它與自定義腳本一起使用，甚至支持簡單的腳本語言來模擬不同的工作負載。但當然，它本質上是一種生成人工負載的工具，以測試某些更改對性能的影響，並確保您沒有錯誤配置 PostgreSQL 或作業系統。