序文
日常的にデータベースを使用していると、メモリの問題に遭遇することは避けられません。このブログでは、主にHuawei Cloud Digital Warehouse GaussDB (DWS)のメモリと基本的なビューの使用に関する基本的なフレームワークを紹介します。
このブログ記事はHuawei Cloud Digital Warehouse GaussDB (DWS)バージョン8.0に基づいています。
一般的なメモリ・ビュー
PV_TOTAL_MEMORY_DETAIL
このビューには、現在のデータベース・ノードのメモリ使用量に関する情報が MB 単位で表示されます。
nodename: ノード名、memorytype: メモリタイプ、memorymbytes: 対応するメモリタイプのサイズ。
一般的に使用されるメモリの種類は以下の通りです：
- max_process_memory：GUCパラメータmax_process_memoryから取得した構成で、データベース・ノードで利用可能な最大物理メモリを示します。
- process_used_memory: /proc/pid/statm (2番目の値) * pagesize から取得した値で、pid は現在のノードが参加しているプロセスのプロセス番号に置き換えられています。現在のノードが参加しているプロセスによって使用されたメモリを示します。
- max_dynamic_memory = max_process_memory- max_cstore_memory - udf_reserved_memory - max_shared_memory ;
- max_dynamic_memory = max_process_memory - max_cstore_memory - udf_reserved_memory - max_shared_memory ；
- dynamic_used_memory: GaussDBカーネルによって使用されるメモリで、GaussDBメモリ管理によってメモリ要求時にカウントされます。
- dynamic_peak_memory: GaussDBカーネル使用メモリピーク、GaussDBメモリ管理によってメモリ要求時にカウントされます。
- dynamic_used_shrctx: GaussDBカーネルが使用するスレッド間共有メモリコンテキストメモリのサイズです。
- dynamic_peak_shrctx: GaussDBカーネルは、メモリ要求時にGaussDBメモリ管理によってカウントされた、スレッド間共有メモリコンテキストメモリピークを使用しました。
- max_shared_memory: プロセス間の共有メモリの最大サイズ
- shared_used_memory: /proc/pid/statm(third value) * pagesize value からカウントされる、プロセス間で使用される共有メモリのサイズ。
- max_cstore_memory：GUCパラメータcstore_buffersで設定される、カラムストアが使用できる最大メモリ。
- cstore_used_memory: カラムストアの使用メモリ。通常、カラムストアまたはHDFSの使用中に消費されたメモリを含みます。
- other_used_memory: 通常はGaussDBカーネルが使用する以外のメモリ使用量を示し、通常はLLVMやKerberosなどのサードパーティライブラリによって消費されるメモリです。
postgres=# select * from PV_TOTAL_MEMORY_DETAIL;
nodename | memorytype | memorymbytes
--------------+-------------------------+--------------
coordinator1 | max_process_memory | 12288
coordinator1 | process_used_memory | 240
coordinator1 | max_dynamic_memory | 11564
coordinator1 | dynamic_used_memory | 229
coordinator1 | dynamic_peak_memory | 234
coordinator1 | dynamic_used_shrctx | 1
coordinator1 | dynamic_peak_shrctx | 1
coordinator1 | max_shared_memory | 211
coordinator1 | shared_used_memory | 139
coordinator1 | max_cstore_memory | 512
coordinator1 | cstore_used_memory | 0
coordinator1 | max_sctpcomm_memory | 0
coordinator1 | sctpcomm_used_memory | 0
coordinator1 | sctpcomm_peak_memory | 0
coordinator1 | other_used_memory | 0
coordinator1 | gpu_max_dynamic_memory | 0
coordinator1 | gpu_dynamic_used_memory | 0
coordinator1 | gpu_dynamic_peak_memory | 0
coordinator1 | pooler_conn_memory | 0
coordinator1 | pooler_freeconn_memory | 0
coordinator1 | storage_compress_memory | 0
coordinator1 | udf_reserved_memory | 0
(22 rows)
PV_SESSION_MEMORY_DETAIL
Huawei Cloud Digital Warehouse GaussDB (DWS)のメモリ管理フレームワークは、メモリコンテキストの考え方に従っています。PV_SESSION_MEMORY_DETAILのビューでは、メモリ使用量は各スレッドのメモリコンテキストディメンション統計でカウントされます。
ビューのフィールドの意味は以下の通り：
Sessid: セッションIDを表し、スレッド開始時間＋スレッドIDからスプライスされます。
スレッド名
Contextname: メモリコンテキスト名。
レベル：メモリコンテキストレベル。
Parent: 親メモリーコンテキストの名前。
Totalsize：現在のメモリコンテキストのメモリサイズ
Freesize：現在のメモリーコンテキストで解放されたメモリーのサイズ
Usedsize：現在のメモリコンテキストの使用サイズ。
postgres=# select * from PV_SESSION_MEMORY_DETAIL order by totalsize desc;
sessid | sesstype | contextname | level | parent | totalsize | freesize | usedsize
----------------------------+-------------------------+------------------------------+-------+------------------------------+-----------+----------+----------
0.140169093357952 | postmaster | Postmaster | 1 | TopMemoryContext | 26566912 | 23912 | 26543000
0.140169093357952 | postmaster | gs_signal | 1 | TopMemoryContext | 4272464 | 2050224 | 2222240
1594694378.140168361137920 | WLMCollectWorker | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 268488 | 1186544
1594694378.140168296134400 | WLMarbiter | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 266696 | 1188336
1594694378.140168465999616 | JobScheduler | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 239584 | 1215448
1594708276.140168270964480 | postgres | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 316392 | 1138640
1594694438.140168207001344 | postgres | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 329944 | 1125088
1594694378.140168344356608 | WLMmonitor | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 269528 | 1185504
1594708276.140168270964480 | postgres | TempSmallContextGroup | 0 | | 550592 | 160320 | 114
1594694438.140168207001344 | postgres | TempSmallContextGroup | 0 | | 530816 | 148256 | 107
1594708276.140168270964480 | postgres | SRF multi-call context | 5 | FunctionScan_140168270964480 | 496704 | 8032 | 488672
PG_SHARED_MEMORY_DETAIL
Huawei Cloud Digital Warehouse GaussDB（DWS）には、汎用メモリコンテキストに加えて、スレッド間でデータを共有するための共有メモリコンテキストタイプがあります。共有メモリコンテキストはプロセスに属するため、PV_SESSION_MEMORY_DETAILと比較してこのビューにはsessidがなく、他のフィールドも同じ意味を持ちます。
postgres=# select * from PG_SHARED_MEMORY_DETAIL order by totalsize desc;
contextname | level | parent | totalsize | freesize | usedsize
----------------------------------------+-------+----------------------------------------+-----------+----------+----------
Workload manager memory context | 1 | ProcessMemory | 1056832 | 6080 | 1050752
PoolerAgentContext | 2 | PoolerMemoryContext | 57344 | 36000 | 21344
PoolerCoreContext | 2 | PoolerMemoryContext | 57344 | 30544 | 26800
ProcessMemory | 0 | | 57344 | 28304 | 29040
wlm iostat info hash table | 2 | Workload manager memory context | 24576 | 10832 | 13744
WaitCountGlobalContext | 1 | ProcessMemory | 24576 | 9984 | 14592
wlm user info hash table | 2 | Workload manager memory context | 24576 | 10832 | 13744
OBS connector cache | 1 | ProcessMemory | 24576 | 15056 | 9520
Resource pool hash table | 2 | Workload manager memory context | 17984 | 2704 | 15280
Dummy server cache | 1 | ProcessMemory | 8192 | 2832 | 5360
Node Pool | 3 | PoolerCoreContext | 8192 | 768 | 7424
メモリー関連データ収集
先に説明したいくつかのメモリビューは、Huawei Cloud Digital Warehouse GaussDB (DWS)メモリの全体的な理解を与えてくれます。以下では、メモリ関連のデータ収集機能をいくつか紹介します。
注：フォーラムの問題のほとんどはリリースバージョンであることを考えると、デバッグバージョンの様々なメモリ関連の機能は、混乱を避けるために再び導入されません。同時に、データを収集すると、いくつかの消費をもたらす、次のスキームの長期的な大規模な使用を避けるために、唯一の問題の診断データ分析として使用されます。
pv_session_memctx_detail
PV_SESSION_MEMORY_DETAIL ビューは、上記のビューの紹介を通して理解できます。スレッドのメモリコンテキストの詳細は pv_session_memctx_detail で表示できます。最初のパラメータは、スレッドIDを示し、スレッドIDの導入によると、sessidの後半であることに注意してください。2番目のパラメータは、TopMemoryContextの再帰的な印刷メモリコンテキスト情報からであることを有効にするには、リリースではnullである、印刷するメモリコンテキストの名前を示します。リリースバージョンには、チャンクの詳細は含まれていません。
例
select * from pv_session_memctx_detail(140168207001344,'');
生成されたファイルはデフォルトで/tmp/dumpmemの下にあり、ファイル内の3つの列はメモリコンテキスト名、合計サイズ、残りサイズを示します。
文書内容のサンプル
_1594695418.ログ
TopMemoryContext, 460808, 24728
Record information cache, 24576, 14928
TableSpace cache, 8192, 2304
set params hash table, 8192, 2832
VecFuncHash, 122272, 20928
MaskPasswordCtx, 8192, 8144
RowDescriptionContext, 8192, 7104
MessageContext, 8192, 7104
Operator class cache, 8192, 768
smgr relation table, 24576, 8880
memory_tracking_mode
上記のメモリ・コンテキスト・データ統計に加えて、memory_tracking_modeによってメモリ情報統計のモードを設定することができ、合計4つのモードがサポートされています：
**none:**メモリ統計機能を起動しません。
**normal:**メモリのリアルタイム統計のみが行われ、ファイルは生成されません。
**executor:**は、実行レイヤで使用される全ての割り当てられたメモリに関するコンテキスト情報を含む統計ファイルを生成します。executorモードの場合、cvs形式のファイルがGaussDBプロセスのpg_logディレクトリにmemory_track_
**fullexec:**生成されたファイルには、実行レイヤーによって要求されたすべてのメモリコンテキストに関する情報が含まれます。fullexecモードに設定された場合、出力される情報はexecutorモードと同じですが、いくつかのメモリコンテキストが増加する可能性があります。
コンテキスト割り当て情報は、メモリ要求に関連するすべての情報が印刷されるため。メモリ要求情報のみが記録されるため、記録内のメモリコンテキスト使用量のピークはすべて0になります。
csvファイルの内容のサンプル：
memory_track_datanode1_query_72339069014639220.csv
0, 0, ExecutorState, 0, (null), 0, 8K, 656K, 4
1, 4, CStoreScan_139944754403072, 0, ExecutorState, 1, 272K, 625K, 4
2, 9, cstore scan per scan memory context, 1, CStoreScan_139944754403072, 2, 24K, 24K, 4
3, 8, cstore scan memory context, 1, CStoreScan_139944754403072, 2, 328K, 328K, 4
4, 2, VecToRow_139944754403072, 0, ExecutorState, 1, 23K, 23K, 4
0, 0, ExecutorState, 0, (null), 0, 8K, 144K, 0
1, 13, Stream_72339069014639220_4, 0, ExecutorState, 1, 72K, 72K, 0
2, 10, Sort_72339069014639220_3, 0, ExecutorState, 1, 8K, 40K, 0
3, 16, TupleSort, 2, Sort_72339069014639220_3, 2, 32K, 32K, 0
4, 2, Agg_72339069014639220_2, 0, ExecutorState, 1, 24K, 24K, 0
いくつかの診断シナリオ
メモリの膨張
デバッグ・ツールのリリース・バージョンでは、情報が限られているため、基本的にまず前述の 3 つのビューから一般的な関数を特定します。まず、PV_TOTAL_MEMORY_DETAILビューを見て、どのメモリが肥大化しているか、またはリークしているかを判断します。OTHER_USED_MEMORYの場合は、3ウェイ・ビン・シナリオを検討します。dynamic_used_memoryの方が大きい場合は、PV_SESSION_MEMORY_DETAILビューをチェックして、どのスレッドでどのメモリコンテキストが大量のメモリを使用しているかを確認します。この情報に基づいて、一般的な問題のシナリオを推測します。
メモリ不足
カーネルが十分なメモリがないことを発見すると、メモリが一時的に使用できないというログメッセージが表示されます。まずログを観察し、ログがデータベース・メモリの制限に達している場合は、カーネルがmax_dynamic_memoryに達するためにメモリを使用していることを意味します。ビジネスシナリオを分析します。ログがREACHING THE OS MEMORY LIMITATIONとなっている場合は、OSによるメモリ割り当ての失敗が原因であることを意味し、OSパラメータとメモリハードウェアの構成を調べる必要があります。
まとめ
本番環境でのメモリの問題は、一般的に、より困難であり、メモリ検出ツールのリリースバージョンとデータ情報の使用がより制限されている、問題が発生した場合は、上記の解決策と手段を通じて、メモリの問題に関連するビジネスシナリオを迅速に見つける必要があります。ビジネスシナリオでは、我々はASANアドレスサニタイズとデバッグバージョンでJemallocプロファイリングを使用することにより、より速く問題を見つけることができます。
