前言
在資料庫運維當中，乙個dba比較常遇到又比較緊急的問題，就是突發的cpu滿（cpu利用率達到100%），導致業務停滯。dba不一定非常熟悉業務實現邏輯，也不能掌控來自應用的變更或負載變化情況。 所以，遇到cpu滿，往往只能從後端資料庫開始排查，追溯到具體sql，最終定位到業務層。這裡我們總結下這個問題具體的處理方法。
檢視連線數變化
cpu利用率到達100%，首先懷疑，是不是業務高峰活躍連線陡增，而資料庫預留的資源不足造成的結果。我們需要檢視下，問題發生時，活躍的連線數是否比平時多很多。對於rds for pg，資料庫上的連線數變化，可以從控制台的監控資訊中看到。而當前活躍的連線數可以直接連線資料庫，使用下列查詢語句得到：
select count( * ) from pg_stat_activity where state not like '%idle';追蹤慢sql
如果活躍連線數的變化處於正常範圍，則很大概率可能是當時有效能很差的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滿，也有直接嫌疑。
query_start, query_stay, replace(query, chr(10), ' ') as query from (select pgsa.datname as datname,
pgsa.state as state, pgsa.backend_start as backend_start, pgsa.xact_start as xact_start,
extract(epoch from (now() - pgsa.xact_start)) as xact_stay, pgsa.query_start as query_start,
extract(epoch from (now() - pgsa.query_start)) as query_stay , pgsa.query as query from pg_stat_activity
as pgsa where pgsa.state != 'idle' and pgsa.state != 'idle in transaction' and pgsa.state != 'idle in transaction (aborted)') idleconnections order by query_stay desc limit 5;
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
對於上面的方法查出來的慢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...