国产成人av在线免播放观看更新,亚洲国产精品亚洲,国产a∨片免费看

問題描述

阿里云云數據庫RDS PostgreSQL使用過程中，可能會遇到CPU使用率過高甚至達到100%的情況。本文將介紹造成該狀況的常見原因以及解決方法，并通過CPU使用率為100%的典型場景，來分析引起該狀況的排查及其相應的解決方案。

解決方案

CPU使用率到達100%，首先檢查是不是業務高峰活躍連接陡增，而數據庫預留的資源不足。需要查看問題發生時，活躍的連接數是否比平時多很多。對于RDS PostgreSQL，數據庫上的連接數變化，可以從控制臺的監控信息中看到。而當前活躍的連接數，可以直接連接數據庫，使用下列查詢語句得到。

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

追蹤慢SQL

如果活躍連接數的變化處于正常范圍，則可能是當時有性能很差的SQL被大量執行。由于RDS有慢SQL日志，可以通過這個日志，定位到當時比較耗時的SQL來進一步做分析。但通常問題發生時，整個系統都處于停滯狀態，所有SQL都慢下來，當時記錄的慢SQL可能非常多，并不容易找到目標。這里介紹幾種追查慢SQL的方法。

第一種方法是使用pg_stat_statements插件定位慢SQL，僅適用于PostgreSQL，步驟如下。
1. 如果沒有pg_stat_statements插件，需要先手動創建。要利用插件和數據庫系統里面的計數信息（如SQL執行時間累積等），而這些信息是不斷累積的，包含了歷史信息。為了更方便的排查當前的CPU過高問題，要先使用以下命令重置計數器。
```
create extension pg_stat_statements;
select pg_stat_reset();
select pg_stat_statements_reset();
```
2. 等待一段時間（例如1分鐘），使計數器積累足夠的信息。
3. 參考以下命令查詢最耗時的SQL，一般就是導致問題的直接原因。
```
select * from pg_stat_statements order by total_time desc limit 5;
```
4. 參考以下SQL語句，查詢讀取Buffer次數最多的SQL，這些SQL可能由于所查詢的數據沒有索引，而導致了過多的Buffer讀，也同時大量消耗了CPU。
```
select * from pg_stat_statements order by shared_blks_hit+shared_blks_read desc limit 5;
```

第二種方法是直接通過pg_stat_activity視圖，參考以下查詢SQL語句，查看當前長時間執行，一直不結束的SQL。這些SQL也可能造成CPU過高。

select datname,
       usename,
       client_addr,
       application_name,
       state,
       backend_start,
       xact_start,
       xact_stay,
       query_start,
       query_stay,
       replace(query, chr(10), ' ') as query
from
  (select pgsa.datname as datname,
          pgsa.usename as usename,
          pgsa.client_addr client_addr,
          pgsa.application_name as application_name,
          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種方法是從數據表上表掃描（Table Scan）的信息開始查起，查找缺失索引的表。數據表如果缺失索引，大部分熱數據又都在內存時（例如內存8G，熱數據6G），此時數據庫只能使用表掃描，并需要處理已在內存中的大量無關記錄，導致耗費大量CPU。特別是對于表記錄數超過100的表，一次表掃描占用大量CPU（基本把一個CPU占滿）和多個連接并發（例如上百連接）。
1. 參考以下SQL語句，查出使用表掃描最多的表。
```
select * from pg_stat_user_tables where n_live_tup > 100000 and seq_scan > 0 order by seq_tup_read desc limit 10;
```
2. 參考以下SQL語句，查詢當前正在運行的訪問到上述表的慢查詢。
```
select * from pg_stat_activity where query ilike '%<table name>%' and query_start - now() > interval '10 seconds';
```
  說明
  也可以通過pg_stat_statements插件定位涉及到這些表的查詢，如下所示。 select * from pg_stat_statements where query ilike '%<table>%'order by shared_blks_hit+shared_blks_read desc limit 3;

處理慢SQL

對于上面的方法查出來的慢SQL，如下所示，首先需要做的是結束掉它們，使業務先恢復。

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

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

對查詢涉及的表，執行ANALYZE [$Table]或VACUUM ANZLYZE [$Table]語句，更新表的統計信息，使查詢計劃更準確。為避免對業務影響，最好在業務低峰執行。
說明
[$Table]為查詢涉及的表。
選擇一條如下SQL語句執行，查看SQL的執行計劃，第一條SQL語句不會實際執行SQL語句，第二條SQL語句會實際執行而且能得到詳細的執行信息，對其中的Table Scan涉及的表，建立索引。
```
explain [$Query_Text]
explain (buffers true, analyze true, verbose true) [$Query_Text]
```
說明
[$Query_Text]為SQL文件或語句。
重新編寫SQL語句，去除掉不必要的子查詢、改寫UNION ALL、使用JOIN CLAUSE固定連接順序等，都是進一步深度優化SQL語句的手段，這里不再深入說明。

適用于

云數據庫RDS PostgreSQL版

日本熟妇hd丰满老熟妇,中文字幕一区二区三区在线不卡 ,亚洲成片在线观看,免费女同在线一区二区

云數據庫PostgreSQL實例CPU使用率高的排查及解決辦法

問題描述

解決方案

適用于