PG資料庫記憶體告警了怎麼分析

前幾天寫了CPU分析與IO分析的文章，本來昨天想再湊一個記憶體分析的，不過因為昨天一大早就去拜訪客戶了，所以今天補上。今天早上本來和優諾的傲寒約好了去他那裡取取經，聽聽他對智慧化運維的看法，不過因為一些其他安排臨時取消了，十分遺憾。

PG資料庫遇到記憶體問題要立即進行分析的場景並不多，因為大多數PG資料庫的記憶體使用率過高的報警並不意味著記憶體使用情況異常，記憶體真的不夠用了。因為PG資料庫是使用DOUBLE BUFFERING機制的，大量的記憶體很可能被BUFFER/CACHE佔用了。

上面的free命令可以看到32G記憶體使用了15G多，但是free只剩下599M了，BUFF/CACHE佔了15G多。不過如果我們看available，有9G多，當前這個PG伺服器的記憶體是充足的。從這個例子上看到，我們看fee命令的結果的時候，不應該看free，看available更為準確。

/proc/meminfo可以更詳細的看到OS的記憶體情況，我們可以關注紅框裡的幾個數字。Dirty是FILE CACHE中尚未寫入磁碟的髒資料，是無法快速丟棄的記憶體，如果這個指標持續較高，那麼說明OS的回寫機制或者磁碟存在效能問題，是需要關注的。PageTalbes如果比較大，對於PG資料庫來說，很可能是配置了較大的shared_buffers,但是沒有啟用HugePages，這樣除了會影響PG資料庫訪問記憶體的效能外，還會佔據大量的不必要的記憶體。AnonHugePages指標大於零說明沒有關閉透明大頁，而且已經使用了透明大頁，對於PG、Oracle等資料庫來說，透明大頁的缺點大於優點，會引起記憶體碎片，建議關閉。另外需要關注的是SWAP的使用率，如果FREE記憶體很大，但是SWAP使用率超過20%，很可能是OS的NUMA記憶體方面的配置存在問題，沒有全域性分配記憶體。

遇到PG資料庫的空閒記憶體不足的問題，首先透過這些機制分析OS記憶體是否真的存在風險，如果沒有發現明顯的風險，暫時就不需要做進一步的分析了。如果真的存在風險，我們還可以繼續在OS層面查詢。

ps aux –sort -rss |head -20命令可以查出rss使用最高的20個程式。然後找出存在問題的程式，用smem做進一步分析。

如果找到了存在問題的程式，可以用smem進一步去做分析。其中USS是程式私有記憶體，PSS是私有記憶體+共享記憶體的總和。

如果在OS層面找到了存在問題的程式，那麼可以使用上面的語句去查詢其PG會話的資訊，進一步進行定位。一般情況下，PG會話佔用較多的記憶體可能是做VACUUM、ANALYZE、排序，表連線、記憶體臨時表等操作。

如果不存在某個程式使用記憶體過多，而是大量的程式都佔用差不多的記憶體，那麼很可能是資料庫併發執行某類SQL，使用了排序，表連線等臨時記憶體分配。這時候就要去分析資料庫的效能是否存在問題，導致了某類SQL或者某條SQL併發執行量較大。亦或是某條SQL的執行計劃出現了錯誤，導致執行時間過長，併發執行量過大，佔用了大量實體記憶體。