DWS 內存問題定位三板斧

1?內存相關知識

數據庫節點中使用內存包括：

存儲引擎使用的緩存（參數shared_buffers（行存）和cstore_buffers（列存））

通信庫使用的緩沖區（參數comm_usable_memory）

內存上下文管理的內存（max_process_memory?–?shared memory(>shared_buffers)?–?cstore_buffers?–?comm_usable_memory）

其他（動態庫申請的內存，一般很少，如果模塊使用較多，請自行控制）

2?內存問題可能原因

問題原因大類

問題原因小類

集群參數配置

OS配置

業務層面

業務并發度增加

業務SQL計劃變化（含有hash、sort、agg等）

是否新增業務

CN報錯

SQL是否下推

參數優化

集群內存相關參數

并發控制參數

業務優化

增加內存

集群擴容

內存泄漏

軟件BUG

3?內存問題定位方法

如果為CN報內存不可用錯誤，很大程度上是因為某個SQL的不下推導致。直接可從報錯CN的pg_log中查找到報錯信息下面的STATEMENTS就能找到SQL。在CN上執行explain verbose可以確認SQL是否存在不下推；

查看集群配置情況和關鍵參數

a. 集群每個物理節點內存、每個節點dn個數；

b. 在一個CN和DN上“show max_process_memory”，“show work_mem”，“show enable_dynamic_workload”；

業務SQL如果存在多表jion&sort&多個group by語句，這幾個算子都是高內存操作，并且單算子內存使用上限為work_mem值，因此如果這幾個算子的內存都達到使用上限，可能會報內存不足的問題。

4.?登錄任一DataNode節點，觀察分析此節點的內存消耗信息(視圖pv_total_memory_detail)?，主要為dynamic_used_memory/ max_dynamic_memory信息，發現dynamic_used_memory持續增長，在接近max_dynamic_memory的時候就會報錯；詳細查看內存上下文

5.?根據日志報錯時間點確認是否為單個SQL執行使用內存大導致（此情況下，該SQL一般都是比較復雜的SQL）。

先查找CN pg_log中對應報錯時間點第一次報該錯誤對應的statement（即執行的sql語句）；如果確認該SQL比較復雜，可以通過在gsql中打印explain verbose?的方式查看該SQL的查詢計劃，確認是否存在使用work_mem比較大的算子；

6.?確認是否存在作業大量并發的場景，如存在該場景，可以通過調整max_active_statements限制全局并發

7.?業務執行過程中動態查看并發SQL和內存使用情況,

（1）監控某一sql運行過程中DN的內存使用情況

select sessid, contextname, level,parent,totalsize,freesize,usedsize,? datname,query_id? from pv_session_memory_detail a , pg_stat_activity b? where? split_part(a.sessid,'.',2) = b.pid and b.state='active' order by usedsize desc limit 20 ;

（2）監控session total memory size占用最多的TOP20 session?。

select sessid, sum_total, sum_free,sum_used, query_id, query_start, state, waiting, enqueue,query from (select sessid, sum(totalsize) as sum_total, sum(freesize) as sum_free, sum(usedsize) as sum_used from pv_session_memory_detail group by sessid? order by sum_total desc limit 20 ) a , pg_stat_activity b? where? split_part(a.sessid,'.',2) = b.pid;

（3）監控session中占用內存最多的context TOP20 session.

select sessid, contextname, level,parent, pg_size_pretty(totalsize),pg_size_pretty(freesize),pg_size_pretty(usedsize),? datname,query_id, query? from pv_session_memory_detail a , pg_stat_activity b? where? split_part(a.sessid,'.',2) = b.pid? order by totalsize desc limit 20 ;

（4）監控當前實例總totalsize memroy大小

select pg_size_pretty(sum(totalsize)) from pv_session_memory_detail;

（5）監控當前實例總usedsize memroy大小

select pg_size_pretty(sum(usedsize)) from pv_session_memory_detail;

（6）監控當前實例內存總體使用情況

select * from pg_total_memory_detail;

（7）監控共享內存實時使用情況

select * from pg_shared_memory_detail;

4?建議措施

1.?如果確認為配置不合理導致，可以通過調高單節點邏輯內存(max_process_memory )上限；

2.?如果確認業務SQL中使用work_mem的算子較多，可以通過降低work_mem上限(需要注意觀察對其它業務SQL性能的影響，如果某SQL因此導致性能下降，需要分析后此query執行時的work_mem設置)

3.?如果是由于業務并發量大，而每個業務使用的內存實際并不大導致，可以通過調整max_active_statements（全局SQL并發數，該參數僅對普通用戶有限制，對管理員用戶執行的SQL不限制）

4.?通過打開active sql開關來分析某一時間段并發量和單個sql執行使用的內存信息（如果enable_resource_track和enable_resource_record為off表示該功能關閉）

SQL 數據倉庫服務 GaussDB(DWS)

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。