?前幾天寫了CPU分析與IO分析的文章，本來昨天想再湊一個內存分析的，不過因為昨天一大早就去拜訪客戶了，所以今天補上。今天早上本來和優(yōu)諾的傲寒約好了去他那里取取經(jīng)，聽聽他對智能化運維的看法，不過因為一些其他安排臨時取消了，十分遺憾。

PG數(shù)據(jù)庫遇到內存問題要立即進行分析的場景并不多，因為大多數(shù)PG數(shù)據(jù)庫的內存使用率過高的報警并不意味著內存使用情況異常，內存真的不夠用了。因為PG數(shù)據(jù)庫是使用DOUBLE BUFFERING機制的，大量的內存很可能被BUFFER/CACHE占用了。

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

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

遇到PG數(shù)據(jù)庫的空閑內存不足的問題，首先通過這些機制分析OS內存是否真的存在風險，如果沒有發(fā)現(xiàn)明顯的風險，暫時就不需要做進一步的分析了。如果真的存在風險，我們還可以繼續(xù)在OS層面查找。

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

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

如果在OS層面找到了存在問題的進程，那么可以使用上面的語句去查找其PG會話的信息，進一步進行定位。一般情況下，PG會話占用較多的內存可能是做VACUUM、ANALYZE、排序，表連接、內存臨時表等操作。

如果不存在某個進程使用內存過多，而是大量的進程都占用差不多的內存，那么很可能是數(shù)據(jù)庫并發(fā)執(zhí)行某類SQL，使用了排序，表連接等臨時內存分配。這時候就要去分析數(shù)據(jù)庫的性能是否存在問題，導致了某類SQL或者某條SQL并發(fā)執(zhí)行量較大。亦或是某條SQL的執(zhí)行計劃出現(xiàn)了錯誤，導致執(zhí)行時間過長，并發(fā)執(zhí)行量過大，占用了大量物理內存。