記一次Postgres CPU爆滿故障

公司專案測試環境呼叫某些介面的時候，伺服器立即崩潰，並一定時間內無法提供服務。

第一反應是伺服器需要公升配啦，花錢解決一切！畢竟測試伺服器配置確實不高，2cpu + 4gib，能幹啥？不過問題是今天突然發生的，而且說崩就崩。憑著嚴謹的態度，還是要刨根問底地找下問題。

記憶體占用並不大，忘記截圖了，反正看下來不是記憶體過高導致的崩潰

業務高峰活躍連線陡增，活躍的連線數是否比平時多很多

select 

count(*) 
from 
pg_stat_activity 
where 
state not like '%idle';

如果活躍連線數的變化處於正常範圍，則可能是當時有效能很差的sql被大量執行。

可以看到，確實有一條慢sql，而且屬於奇慢無比，執行了接近1分鐘還沒執行完畢，基本可以定位，是慢sql導致的cpu占用陡增。

對於上面的方法查出來的慢sql，首先需要做的是kill掉他們，使業務先恢復。

select pg_cancel_backend(pid) from pg_stat_activity where  query like '%%' and pid != pg_backend_pid();

select pg_terminate_backend(pid) from pg_stat_activity where query like '%%' and pid != pg_backend_pid();

如果這些sql確實是業務上必需的，則需要對他們做如下優化：

對查詢涉及的表，執行analyze或vacuum anzlyze，更新表的統計資訊，使查詢計畫更準確。為避免對業務影響，最好在業務低峰執行。

執行explain或explain (buffers true, analyze true, verbose true)命令，檢視sql的執行計畫（前者不會實際執行sql，後者會實際執行而且能得到詳細的執行資訊），對其中的table scan涉及的表，建立索引。

重新編寫sql，去除掉不必要的子查詢、改寫union all、使用join clause固定連線順序等，都是進一步深度優化sql的手段，這裡不再深入說明。

在查詢語句中，儘量減少不必要的子查詢，公司使用的orm框架是spring jpa，針對一些特別慢的hql，可以採用直接執行sql的方式來優化查詢效率。

@query(value = "select count(*) from example_table where example_id = :exampleid", nativequery = true)

int examplenativequery(@param("exampleid") long exampleid);

postgresql/ppas cpu使用率高的原因及解決辦

記一次除錯

這是我最近幾個月來遇到的最棘手的乙個問題 昨天花了4個小時找出第一層次的原因 這個糾結啊，本來和老婆說好準時下班回家吃飯的，結果被這個問題拖了老久。這是乙個gradle的plugin，用來resolve公司內部的dependency的，弄完了跑測試專案的，拋乙個npe，而且npe還不在自己的 裡面。...

記一次 EqualsAndHashCode的疑惑

lombok的使用真的是讓開發人員欲罷不能，乙個 data不管有多少屬性全部搞定，以後加字段也不用從新生成get和set方法。不過這裡還是有乙個小坑需要注意一下，舉個例子 public class equalsandhashcodetest data noargsconstructor access...

記一次除錯

這是我最近幾個月來遇到的最棘手的乙個問題 昨天花了4個小時找出第一層次的原因 這個糾結啊，本來和老婆說好準時下班回家吃飯的，結果被這個問題拖了老久。這是乙個gradle的plugin，用來resolve公司內部的dependency的，弄完了跑測試專案的，拋乙個npe，而且npe還不在自己的 裡面。...