PgSQL 最佳實踐 CPU滿問題處理

在資料庫運維當中，乙個dba比較常遇到又比較緊急的問題，就是突發的cpu滿（cpu利用率達到100%），導致業務停滯。dba不一定非常熟悉業務實現邏輯，也不能掌控來自應用的變更或負載變化情況。所以，遇到cpu滿，往往只能從後端資料庫開始排查，追溯到具體sql，最終定位到業務層。這裡我們總結下這個問題具體的處理方法。

cpu利用率到達100%，首先懷疑，是不是業務高峰活躍連線陡增，而資料庫預留的資源不足造成的結果。我們需要檢視下，問題發生時，活躍的連線數是否比平時多很多。對於rds for pg，資料庫上的連線數變化，可以從控制台的監控資訊中看到。而當前活躍的連線數可以直接連線資料庫，使用下列查詢語句得到：

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

如果活躍連線數的變化處於正常範圍，則很大概率可能是當時有效能很差的sql被大量執行導致。由於rds有慢sql日誌，我們可以通過這個日誌，定位到當時比較耗時的sql來進一步做分析。但通常問題發生時，整個系統都處於停滯狀態，所有sql都慢下來，當時記錄的慢sql可能非常多，並不容易排查罪魁禍首。這裡我們介紹幾種在問題發生時，即介入追查慢sql的方法。

1. 第一種方法是使用pg_stat_statements外掛程式定位慢sql，步驟如下。

1.1. 如果沒有建立這個外掛程式，需要手動建立。我們要利用外掛程式和資料庫系統裡面的計數資訊（如sql執行時間累積等），而這些資訊是不斷累積的，包含了歷史資訊。為了更方便的排查當前的cpu滿問題，我們要先重置計數器。

create extension pg_stat_statements;
select pg_stat_reset();
select pg_stat_statements_reset();

1.2. 等待一段時間（例如1分鐘），使計數器積累足夠的資訊。

1.3. 查詢最耗時的sql（一般就是導致問題的直接原因）。

select * from pg_stat_statements order by total_time desc limit 5;

1.4. 查詢讀取buffer次數最多的sql，這些sql可能由於所查詢的資料沒有索引，而導致了過多的buffer讀，也同時大量消耗了cpu。

select * from pg_stat_statements order by shared_blks_hit+shared_blks_read desc limit 5;

2. 第二種方法是，直接通過pg_stat_activity檢視，利用下面的查詢，檢視當前長時間執行，一直不結束的sql。這些sql對應造成cpu滿，也有直接嫌疑。

3. 第3種方法，是從資料表上表掃瞄（table scan）的資訊開始查起，查詢缺失索引的表。資料表如果缺失索引，大部分熱資料又都在記憶體時（例如記憶體8g，熱資料6g），此時資料庫只能使用表掃瞄，並需要處理已在記憶體中的大量的無關記錄，而耗費大量cpu。特別是對於表記錄數超100的表，一次表掃瞄占用大量cpu（基本把乙個cpu佔滿），多個連線併發（例如上百連線），把所有cpu佔滿。

3.1. 通過下面的查詢，查出使用表掃瞄最多的表：

select * from pg_stat_user_tables where n_live_tup > 100000 and seq_scan > 0 order by seq_tup_read desc limit 10;

3.2. 查詢當前正在執行的訪問到上述表的慢查詢：

select * from pg_stat_activity where query ilike '%%' and query_start - now() > interval '10 seconds';

3.3. 也可以通過pg_stat_statements外掛程式定位涉及到這些表的查詢：

select * from pg_stat_statements where query ilike '%%'order by shared_blks_hit+shared_blks_read desc limit 3;

對於上面的方法查出來的慢sql，首先需要做的可能是cancel或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確實是業務上必需的，則需要對他們做優化。這方面有「三板斧」：

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

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

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

需要說明的是，這些方法對於rds for ppas產品同樣適用，但在使用我們所列的命令時，由於許可權限制，需要把上面提到的檢視、函式、命令做如下轉換：

pg_stat_statements_reset() => rds_pg_stat_statements_reset()
pg_stat_statements => rds_pg_stat_statements()
pg_stat_reset() => rds_pg_stat_reset()
pg_cancel_backend() => rds_pg_cancel_backend()
pg_terminate_backend() => rds_pg_terminate_backend()
pg_stat_activity => rds_pg_stat_activity()
create extension pg_stat_statements => rds_manage_extension('create', 'pg_stat_statements')

上面我們分析了處理cpu滿，追查問題sql的一些方法。大家可以按部就班的嘗試我們列出的命令，定位問題。

PgSQL 最佳實踐 CPU滿問題處理

PgSQL 最佳實踐 CPU滿問題處理

最佳實踐 Flutter 最佳實踐

JUnit最佳實踐

PgSQL 最佳實踐 CPU滿問題處理

PgSQL 最佳實踐 CPU滿問題處理

最佳實踐 Flutter 最佳實踐

JUnit最佳實踐

相關推薦