PgSQL 最佳實踐 CPU滿問題處理

2021-09-23 13:51:58 字數 3303 閱讀 5431

在資料庫運維當中,乙個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滿問題處理

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

最佳實踐 Flutter 最佳實踐

最佳實踐是乙個領域可以接受的專業標準,對於任何程式語言來說,提高 質量 可讀性 可維護性和健壯性都非常重要。讓我們探索一些設計和開發flutter應用程式的最佳實踐。class enum typedef和extension應採用駝峰命名uppercamelcase規則。class mainscree...

JUnit最佳實踐

junit最佳實踐 cherami 轉貼 參與分 20053,專家分 4960 發表 2003 9 16 下午7 57 版本 1.0 閱讀 3899次 martin fowler說過 當你試圖列印輸出一些資訊或除錯乙個表示式時,寫一些測試 來替代那些傳統的方法。一開始,你會發現你總是要建立一些新的f...