PG數(shù)據(jù)庫內(nèi)存告警了怎么分析
?前幾天寫了CPU分析與IO分析的文章，本來昨天想再湊一個內(nèi)存分析的，不過因為昨天一大早就去拜訪客戶了，所以今天補上。今天早上本來和優(yōu)諾的傲寒約好了去他那里取取經(jīng)，聽聽他對智能化運維的看法，不過因為一些其他安排臨時取消了，十分遺憾。
PG數(shù)據(jù)庫遇到內(nèi)存問題要立即進(jìn)行分析的場景并不多，因為大多數(shù)PG數(shù)據(jù)庫的內(nèi)存使用率過高的報警并不意味著內(nèi)存使用情況異常，內(nèi)存真的不夠用了。因為PG數(shù)據(jù)庫是使用DOUBLE BUFFERING機制的，大量的內(nèi)存很可能被BUFFER/CACHE占用了。
上面的free命令可以看到32G內(nèi)存使用了15G多，但是free只剩下599M了，BUFF/CACHE占了15G多。不過如果我們看available，有9G多，當(dāng)前這個PG服務(wù)器的內(nèi)存是充足的。從這個例子上看到，我們看fee命令的結(jié)果的時候，不應(yīng)該看free，看available更為準(zhǔn)確。
/proc/meminfo可以更詳細(xì)的看到OS的內(nèi)存情況，我們可以關(guān)注紅框里的幾個數(shù)字。Dirty是FILE CACHE中尚未寫入磁盤的臟數(shù)據(jù)，是無法快速丟棄的內(nèi)存，如果這個指標(biāo)持續(xù)較高，那么說明OS的回寫機制或者磁盤存在性能問題，是需要關(guān)注的。PageTalbes如果比較大，對于PG數(shù)據(jù)庫來說，很可能是配置了較大的shared_buffers,但是沒有啟用HugePages，這樣除了會影響PG數(shù)據(jù)庫訪問內(nèi)存的性能外，還會占據(jù)大量的不必要的內(nèi)存。AnonHugePages指標(biāo)大于零說明沒有關(guān)閉透明大頁，而且已經(jīng)使用了透明大頁，對于PG、Oracle等數(shù)據(jù)庫來說，透明大頁的缺點大于優(yōu)點，會引起內(nèi)存碎片，建議關(guān)閉。另外需要關(guān)注的是SWAP的使用率，如果FREE內(nèi)存很大，但是SWAP使用率超過20%，很可能是OS的NUMA內(nèi)存方面的配置存在問題，沒有全局分配內(nèi)存。
遇到PG數(shù)據(jù)庫的空閑內(nèi)存不足的問題，首先通過這些機制分析OS內(nèi)存是否真的存在風(fēng)險，如果沒有發(fā)現(xiàn)明顯的風(fēng)險，暫時就不需要做進(jìn)一步的分析了。如果真的存在風(fēng)險，我們還可以繼續(xù)在OS層面查找。
ps aux –sort -rss |head -20命令可以查出rss使用最高的20個進(jìn)程。然后找出存在問題的進(jìn)程，用smem做進(jìn)一步分析。
如果找到了存在問題的進(jìn)程，可以用smem進(jìn)一步去做分析。其中USS是進(jìn)程私有內(nèi)存，PSS是私有內(nèi)存+共享內(nèi)存的總和。
如果在OS層面找到了存在問題的進(jìn)程，那么可以使用上面的語句去查找其PG會話的信息，進(jìn)一步進(jìn)行定位。一般情況下，PG會話占用較多的內(nèi)存可能是做VACUUM、ANALYZE、排序，表連接、內(nèi)存臨時表等操作。
如果不存在某個進(jìn)程使用內(nèi)存過多，而是大量的進(jìn)程都占用差不多的內(nèi)存，那么很可能是數(shù)據(jù)庫并發(fā)執(zhí)行某類SQL，使用了排序，表連接等臨時內(nèi)存分配。這時候就要去分析數(shù)據(jù)庫的性能是否存在問題，導(dǎo)致了某類SQL或者某條SQL并發(fā)執(zhí)行量較大。亦或是某條SQL的執(zhí)行計劃出現(xiàn)了錯誤，導(dǎo)致執(zhí)行時間過長，并發(fā)執(zhí)行量過大，占用了大量物理內(nèi)存。
