Tech JAM 2016 TEC 11 実践 SAP HANA 大解剖

[TEC-11]
実践 SAP HANA 大解剖
- HANAのアーキテクチャーとロジカルなトラブル分析のススメ -
新久保浩二, Digital Business Platform

© 2016 SAP SE or an SAP affiliate company. All rights reserved. 2Customer
免責事項
このプレゼンテーションは、弊社の一般的な製品の方向性を説明するものであり、購入の意思決定を
行う際の判断基準にはなりません。このプレゼンテーションは、SAP とのライセンス契約またはその
他の契約を前提とするものではありません。
SAP は、このプレゼンテーションに概説された事業の実現、またはこのプレゼンテーションに記載さ
れたいかなる機能の開発またはリリースに対する義務も負いません。このプレゼンテーションおよび
SAP の戦略および予定されている将来の開発は変更される可能性があり、SAP は随時、理由の如何
を問わずに事前の予告なく変更できるものとします。
本書は、商業性、特定目的への適合性または非侵害性等の黙示的保証を含めて、明示または黙示を問
わず、いかなる保証をも伴うものではありません。SAP による意図的または重大な過失に起因する損
害を除き、本書の誤記、脱落等の過失について SAP は責任を負わないものとします。

アジェンダ
 HANAのアーキテクチャー
 HANAのプロセス(サービス)
 HANAのスレッド
 HANAのモニタリングとトラブル分析の概要
 ロジカルなトラブル分析のススメ(ケーススタディ)
 シンプルな問題
 ログボリュームへのI/Oの問題
 単純なSQL文の問題
 複雑なSQL文(パラレル実行)の問題
 HANAのバックグランド処理の問題
 まとめ

HANAのアーキテクチャー

SAP HANA
SAP HANA Database
compileserver
scriptserver
webdispatcher
nameserver
indexserver
xsengine
preprocessor
ランドスケープ情報の管理
データを保持しDB操作全般を実行
HANAのアプリケーションサーバー
テキスト分析の前処理
HANAのプロセス(サービス) (1/2)
データの永続化レイヤー
Persistence
サーバーコンポーネント OSプロセスサービス名
インデックスサーバー hdbindexserver indexserver
ネームサーバー hdbnameserver nameserver
プリプロセッササーバー hdbpreprocessor preprocessor
XSエンジン hdbxsengine xsengine
コンパイルサーバー hdbcompileserver compileserver
スクリプトサーバー hdbscriptserver scriptserver
SAP Webディスパッチャー hdbwebdispatcher webdispatcher
SAP start service sapstartsrv sapstartsrv
SQLScriptなどのコンパイル
AFLの実行サーバー
XSエンジンへのHTTP(S)リクエスト
のディスパッチ

HANAのプロセス(サービス) (2/2)
確認方法
HANA Studio (Landscape->Services)
OSレベル
SQLレベル (M_SERVICES)

SAP HANA
SAP HANA Database
compileserver
scriptserver
webdispatcher
nameserver
indexserver
xsengine
preprocessor
ランドスケープ情報の管理
データを保持しDB操作全般を実行
HANAのアプリケーションサーバー
テキスト分析の前処理
データの永続化レイヤー
Persistence
SQL Listener thread
SQL Executor thread
Job Executor (Dispatcher) thread
Job Worker thread
Submit I/O thread
File Completion thread
Savepoint thread
Merge Dog thread
Commit Handler thread
Network Channel Completion thread
…
HANAのスレッド (1/3)
SQLScriptなどのコンパイル
AFLの実行サーバー
XSエンジンへのHTTP(S)リクエスト
のディスパッチ

確認方法
HANA Studio (Performance->Threads)
OSレベル
HANA Studioで確認できるThread IDを元にOS上で確認できる
スレッド名を見てみると…
Request(HANA Studio) != PoolThread(OS)
といったHANA上のスレッド名(*)とOS上のスレッド名が異なる
スレッドが多数存在します。
これに関して後ほど説明します。
(*) 基本的にHANA StudioのThread Typeはスレッド名を意味します

確認方法
SQLレベル (M_SERVICE_THREADSシステムビュー)
OS上でHANAのスレッドを見る(システムコールやライブラリコールのトレース)ことでも多くのことが分かるのですが、
M_SERVICE_THREADにはOS上で見ているだけでは分からない面白い情報がいくつかあります。
 CALLER / CALLING
対象のスレッドを起動したスレッド(CALLER)や対象のスレッドが起動したスレッド(CALLING)が簡単に分かります。
(トレースでもこれらのコールグラフは確認できますが、面倒で時間がかかります)
 STATEMENT_HASH
対象のスレッドがSQL文を実行中であれば、SQL文に関するHASH値が表示されます。このSQL文に関しては、
M_SQL_PLAN_CACHEで確認できます。
 THREAD_METHOD/THREAD_DETAIL/THREAD_STATE/LOCK_WAIT_NAME
これらは、HANAの各スレッドの内部状態を示します。特にTHREAD_STATEやLOCK_WAIT_NAMEなどはHANAが
どのようなリソースで待機しているか？を示します。

Tips M_SERVICE_THREADSのCALLER/CALLING等について
例) 並列処理のSQL文を実行した場合
1. SqlExecutorスレッド(THREAD_ID=6907)がTHREAD_ID=21164を起動(CALLING)
1. このSqlExecutorの実行中のSQL文はTHREAD_DETAILを見ると確認可能(STATEMENT_ID/HASHでも可能)
2. 自身は起動したスレッドのジョブ完了を待機(THREAD_STATE=“Job Exec Wait”)
2. THREAD_ID=21164はJobWorkerとして、さらにTHREAD_ID=(21116, 21158, 21159, 21172)の4つのスレッドを起動
1. その際、自身のCALLERは呼び出し元のThread IDとして1のSqlExecutorスレッドのTHREAD_IDを格納
2. また自身は起動したスレッドのジョブ完了を待機(THREAD_STATE=“Job Exec Wait”)
3. 呼び出された各スレッドはJobWorkerとなり処理を実行
1. 最終的に処理中の4つのスレッド(21116, 21158, 21159, 21172)は基本的にCPU上で処理中
(THREAD_STATE=“Running”)
select count(a.id) from ks_test2 a, ks_test2 b where a.id=b.id;

Tips HANAのスレッドを見る上での注意点
HANA上のスレッド名とOS上のスレッド名の違い
OS的な制限(プロセス名やスレッド名は15文字に制限される)を除いて、上記のような実際は、スレッドプールとして
OS上でスレッドが起動され(上記の場合はPoolThread)、HANAが状況に応じて適切な役割のスレッドにアサインする
(上記の場合はSqlExecutor)ようにデザインされています。
このため、実際(OS上での本名)とHANA上でのスレッド名が異なる場合が多々あります。
例) SqlExecutor、FileCompletionThread-DATA-0スレッド
HANA上のスレッド
OS上のスレッド
OSによる15文字制限
HANAのスレッドプールによ
る動的なスレッドアサインに
よるもの

HANAのスレッド
代表的なスレッドについて(今回のケースで取り上げるもの中心)
処理スレッド(HANA)
* M_SERVICE_THREADS.THREAD_TYPE
スレッド(OS)
* psコマンドの結果
コネクション確立のためのリスナー SqlListener PoolThread
シンプルなSQLの実行 SqlExecutor PoolThread
複雑なSQLの実行 JobWorker
JobWrk####
(####は数値)
SQLプランキャッシュのメンテナンス SQLPlanCacheThread SQLPlanCacheTh
JobWorkerの制御やディスパッチ(管理ガイドではJobExecutorという表記) JobexMainDispatcher JobexMainDispat
セーブポイント PeriodicSavepoint Savepoint
デルタマージ(自動)
MergedogMonitor
MergedogMerger
PoolThread
ログの自動バックアップ LogBackupThread LogBackupThread
組み込みStatistics Serverによるアクティビティ WorkerThread (StatisticsServer) WorkerThread (S
非同期I/O発行のための専用スレッド
SubmitThread-DATA-#
SubmitThread-LOG-#
SubmitThread-DATA_BACKUP-#
SubmitThread-LOG_BACKUP-#
SubmitThread-DA
SubmitThread-LO
非同期I/Oの完了状態を監視、通知
FileCompletionThread-DATA-#
FileCompletionThread-LOG-#
FileCompletionThread-DATA_BACKU
FileCompletionThread-LOG_BACKUP
FileCompletionThread-DA
FileCompletionThread-LO
データボリュームへの書き込みを制御 FlushResourcesThread FlushResourcesT

HANAのモニタリングとトラブル分析の概要 (1/5)
今までに説明したHANAの各スレッドがどのような状態にあるのかを時系列でチェックする
ことが重要です。
その際、各スレッドの状態や待機理由がドリルダウン可能になっていることが重要です。
 各スレッドの状態を時系列に把握 = “システム全体の状態の把握”
- CPU使用中
- 別の処理を待機中
 データベース全体の状態に問題がる場合は、どのような処理(理由で)何を待機中なのかと
いった待機情報をドリルダウン
- I/O関連(Read/Write)
- トランザクションロック待ち
- データベースの内部ロック(ラッチ)待ち
* このラッチ待ちが長時間になるとシステムハングの一種となります
システム全体のパフォーマンス状態
をを単純なKPIで継続モニタリング
問題のある時間帯が発見された場合、
その時間帯に取得済みの待機情報を
ドリルダウンして問題の解析、状況
の把握を行う。
以降のモニタリングは、既存のHANAのアラートやNoteに多数あるMini Checkなどを否定するものではありません。
組み合わせてみて頂けるとよりきめ細かい運用が可能になると思います。

実施ゴール設定分析測定
データベース
が必要として
いるリソース
量は適切か?
必要としたの
は待機リソー
スか?
必要としたの
はCPUリソー
スか?
それぞれの待
機情報に適し
たチューニン
グ
CPUを使わせ
ない/CPUの増
強をする
チューニング
CPUを使わせ
るチューニン
グチューニング
のゴール設定
チューニング
の実施

測定 - 各スレッドの状態(Running or Waiting)
0
2
4
6
8
10
12
Running Waiting
以下は、直近１時間における1分ごとにサマリーした各スレッドの状態別(Running/Waiting)のスレッド数のチャートです。
(M_SERVICE_THREADS(or それに類するビュー)をベースにチャートにしますが、詳細は後述します)
これを仮に”データベースパフォーマンス指標(仮)”と名付けることにします。この指標により、問題のある時間帯が一目瞭然になります。
基本的なKPIはシンプルで、HANAでアサインされた論理CPU数を上回っているか否か?のみです。以下、少しだけ見ていきましょう。
論理CPU数
トラブル状態(or チューニング対象の時間帯)
待機情報のドリルダウン

分析 - Waiting状態のスレッドをドリルダウンする
Semaphore_Wait.POSTCOMMIT_FINISH_SMP
92%
Barrier_Wait.NULL
8%
M_SERVICE_THREADS(or それに類するビュー)のTHREAD_TYPE、THREAD_STATE、THREAD_MOTHOD、
THREAD_DETAIL、LOCK_WAIT_NAMEなどドリルダウンします。以下は、問題のあった時間帯での、THREAD_STATE ＋
LOCK_WAIT_NAMEでのサマリーです。
“Semaphore Wait”はHANA内部のロック(ラッチ)を待機しているこ
とを示しています
問題のあった時間帯のTHREAD_STATEの92%は”Semaphore Wait”
であったことが分かります
このロック(ラッチ)が何を意味するかは以降のケーススタディの中で
説明していこうと思います。
ここでは、この”POSTCOMMIT_FINISH_SMP”で待機しない、もしく
は待機を減らす方向のチューニングが必要ということが分かります。
実際、どのようなロック(ラッチ)を待機していたかは、
LOCK_WAIT_NAMEを見ると分かります

0
2
4
6
8
10
12
Running Waiting
ゴール設定 – データベースパフォーマンス指標(仮)からの予測
0
2
4
6
8
10
12
Running Waiting
論理CPU数
論理CPU数チューニング前の“データベースパフォーマ
ンス指標(仮)”のCPUリソースは問題ある期
間で概ね0.8
仮に今回の待機リソースの半分程度が
チューニングにより解消されて、すべて
CPUリソースに移ったと仮定してみます
約5倍のCPUリソースを使えることになり、
結果、処理時間を5倍程度高速化すること
ができる予測が立てられます。
チューニング後(シミュレーション値)の
“データベースパフォーマンス指標(仮)”の
CPUリソースは4.0
実際のデータベースパフォーマンス指標(仮)
予測値のデータベースパフォーマンス指標(仮) ただしチューニングのゴールや
優先度はシステム要件だけでな
く業務要件からも決定される必
要があります

Tips モニタリングするのに便利なシステムビュー (1/3)
(M_SERVICE_THREAD_SAMPLES)
これまで、スレッドの名前やその状態のモニタリングにM_SERVICE_THREADSシステムビューを見てきました。
しかし、M_SERVICE_THREADSはクエリーで参照した時点の瞬間値を示すビューです。過去の異常状態の分析には継続的なデータの蓄積
といった仕組みが別途必要になります。
HANAでは、自動でこのM_SERVICE_THREADSのアクティブなスレッドのデータを1秒間隔(デフォルト)で取得しています。そのデータ
はM_SERVICE_THREAD_SAMPLESシステムビューに格納されます。
* パラメーターの説明
- service_thread_sampling_monitor_enabled
- service_thread_sampling_monitor_max_sample_lifetime
- service_thread_sampling_monitor_max_samples
- service_thread_sampling_monitor_sample_interval
- service_thread_sampling_monitor_thread_detail_enabled
- …
自分で、M_SERVICE_THREADSをクエリーで検索して履歴データを収集するといった手間や余計なパフォーマンスオーバヘッドを掛けず
に手軽にトラブルシュート、パフォーマンス分析に着手できるので、M_SERVICE_THREAD_SAMPLESシステムビューは非常に便利で有効
なデータだと言えます。
もう少し真面目に説明する
パラメーター(global.ini -> [resource_tracking]) パラメーターの意味デフォルト値
service_thread_sampling_monitor_enabled スレッドのサンプリング機能の有効化/無効化を指定します。 true
service_thread_sampling_monitor_max_sample_lifetime メモリー内に蓄積する時間を秒で指定します。(デフォルト: 7200(秒)=2時間/概
ね500MB) 新しいサンプリングデータはFIFOにより古いデータを上書きします。
7200
service_thread_sampling_monitor_max_samples 蓄積可能な最大レコード数を指定します。(デフォルト:1500000/概ね1GB) これ
はservice_thread_sampling_monitor_max_sample_lifetimeより優先されるパ
ラメーターです。
15000000
service_thread_sampling_monitor_sample_interval サンプリング間隔を秒で指定します。 1
service_thread_sampling_monitor_thread_detail_enabled THREAD_DETAILカラムにデータを入れるか否かを指定します。 false

SELECT top 60
to_char(TIMESTAMP,'yyyy/mm/dd hh24:mi') as TIME,
round(sum(case when (THREAD_STATE ='Running') then 1 else 0 end)/60,1) as "Running",
round(sum(case when (THREAD_STATE!='Running') then 1 else 0 end)/60,1) as "Waiting",
round(count(*)/60,1) as "ALL”
FROM M_SERVICE_THREAD_SAMPLES
WHERE THREAD_STATE != 'Job Exec Waiting’
AND THREAD_STATE != 'Sleeping’
AND THREAD_METHOD != 'joining’
AND LOCK_WAIT_NAME != 'CSPlanExecutorLock’
AND LOCK_WAIT_NAME != 'SaveMergedAttributeJobSemaphore’
GROUP BY to_char(TIMESTAMP,'yyyy/mm/dd hh24:mi')
ORDER BY 1 DESC;
以降のセッションでは、M_SERVICE_THREAD_SAMPLESのデータを使用してケーススタディを検証していきます。その前に、先ほどの
THREAD_STATE(Running/Waiting)でのサマリー情報や各待機情報のドリルダウンに使うSQL文のサンプルを以下に示しておきます。
THREAD_SATE(Running/Waiting)別サマリー(直近１時間における1分サマリーのデータ)
* 1999998 - FAQ: SAP HANA Lock Analysis からIDLE状態の待機は無視可能と判断し、幾つかの待機イベントや状態を無視しています。また1999998 のノート内の情報だけでは
なく、私の検証の結果から無視可能だと思われる待機イベント、状態を無視しています。

SELECT to_char(TIMESTAMP,'yyyy/mm/dd hh24:mi') as TIME,
THREAD_TYPE,
THREAD_METHOD,
THREAD_STATE,
LOCK_WAIT_NAME,
round(count(*)/60,1) as "DBPerformanceIndicator"
WHERE TIMESTAMP >= add_seconds(CURRENT_TIMESTAMP, -300)
AND THREAD_STATE != 'Job Exec Waiting'
AND THREAD_STATE != 'Running’
AND THREAD_STATE != 'Sleeping'
AND THREAD_METHOD != 'joining'
AND LOCK_WAIT_NAME != 'CSPlanExecutorLock'
AND LOCK_WAIT_NAME != 'SaveMergedAttributeJobSemaphore'
GROUP BY to_char(TIMESTAMP,'yyyy/mm/dd hh24:mi'),
THREAD_TYPE,
THREAD_METHOD,
THREAD_STATE,
LOCK_WAIT_NAME
ORDER BY 1 desc, 6 desc;
* 1999998 - FAQ: SAP HANA Lock Analysis からIDLE状態の待機は無視可能と判断し、幾つかの待機イベントや状態を無視しています。また1999998 のノート内の情報だけでは
なく、私の検証の結果から無視可能だと思われる待機イベント、状態を無視しています。
待機情報のドリルダウン (直近5分間における1分サマリーのデータ)

Tips Workload Analyzer – SAP HANA Cockpit (>= SPS12)
SPS12からはHANA Cockpitに、M_SERVICE_THREAD_SAMPLEの情報を分析するGUIツールがつきました。
ただ、本資料では
 原理原則を理解する
 SQLで柔軟に分析
 SPS11以前でも使用可能
という理由から本GUIツールを使用
せずに説明します。

ロジカルなトラブル分析のススメ(ケーススタディ)

シンプルな問題
先ほど、少し触れた“データベースパフォーマンス指標(仮)”をもう少し体感してもらいたいので、極端ですがとても
シンプルなデータベース内のリソースの使われ方をしたケースを紹介します。
注意) 以下はかなり極端なケースをシュミレートしたもので、実際の環境ではそこまで酷く(分かりやすく)状況が分かるわけではないかも知れません。
ここでは、実際の障害時にこのケーススタディから直接的な解を得ることよりも、ここから、HANAのアーキテクチャーや動作原理を理解するヒントが得られることを目的としています。
また、大切ですので、”データベースパフォーマンス指標(仮)”を算出するSQL文を再掲しておきます。
SELECT top 60
to_char(TIMESTAMP,'yyyy/mm/dd hh24:mi') as TIME,
round(sum(case when (THREAD_STATE ='Running') then 1 else 0 end)/60,1) as "Running",
round(sum(case when (THREAD_STATE!='Running') then 1 else 0 end)/60,1) as "Waiting",
round(count(*)/60,1) as "ALL”
WHERE THREAD_STATE != 'Job Exec Waiting’
AND THREAD_STATE != 'Sleeping’
AND THREAD_METHOD != 'joining’
AND LOCK_WAIT_NAME != 'CSPlanExecutorLock’
AND LOCK_WAIT_NAME != 'SaveMergedAttributeJobSemaphore’
GROUP BY to_char(TIMESTAMP,'yyyy/mm/dd hh24:mi')
ORDER BY 1 DESC;

シンプルなCPU負荷
0
1
2
3
4
5
6
7
8
9
10
Running Waiting
データベースパフォーマンス指標(仮)
論理CPU数
SELECT count(*) FROM test_table_1 A, test_table_2 B WHERE A.column1=B.column1;
複数セッションから同時にパラレル実行可能なSQL文を実行
リソース不足HANAの同時実行や並列実行の制御には
複数の種類(パラメーター、スレッド)が
存在します。
詳細は後述しますが、パラメーター
max_sql_executors(hard limit)の場合
は、このようにCPU待機であることが判
明しませんので、もっと別の方法で監視
する必要があります(後述)。
そのスレッドのステータスのほとんどが
Running(≒On CPU)となっています
データベースパフォーマンス指標(仮)が論理
CPU(KPI)を大きく超えています
これ以上の処理能力向上が見込めません
(CPUボトルネック)
この場合、単体のSQLをよりCPUを使わない
方法にチューニングするか、システムのCPU
能力(コア能力、コア数)を上げる必要がある
ことが分かります

Tips SQL文の実行に関して (1/2)
HANAはSQL文の実行に関して、SqlExecutorスレッドおよびJobWorkerの2つのスレッドで実行を担当します。
「SAP HANA管理ガイド」には、少しだけ2つのスレッドの説明があります。
 SqlExecutor
このスレッドプールは、受信クライアント要求を処理し、単純な文を実行します。1つの文実行につき、スレッドプール
から1つのSqlExecutorスレッドがその文を処理します。
カラムストアに対する単純な (OLTPのような)文、およびローストアに対するほとんどの文については、このタイプの
スレッドのみが関与します。
 JobExecutor
JobExecutorはジョブのディスパッチを行うサブシステムです。残りの並列タスクのほぼすべてが、JobExecutorおよび
関連付けられたJobWorkerスレッドにディスパッチされます。
「SAP HANA管理ガイド」より
”
“

Thread Pool Job Worker Thread Pool
Tips SQL文の実行に関して (2/2)
Job WorkerJob Worker
SQL Executor
(PoolThread)
SQL Executor
(PoolThread)
Client SqlListener SqlExecutor
JobExecutor
(JobexMainDispatcher)
JobWorker
接続要求
クライアントからの接続要求を待機
SqlExecutorをアサイン
SQL文を実行
SQL文のParse
SQL_PLAN_CACHEの確認
実行計画の作成
SQL_PLAN_CACHEのメンテナンス
PLANにより、各プランオペレーター
(POP)ごとに並列ジョブ化
JobExecutorはプラオリティの
高いジョブから取り出し、
JobWorkerにディスパッチする
さらに並列化が可能か?
Yes
ジョブの分割
ジョブの実行
No
不要になったJobWorker
はスレッドプールに返却
クライアントからのSQL文を待機
SQLの結果
Queryの最適化
indexserver.ini ->
sql_executors
SQL文の実行
Job Queue
並列化されたジョブをエンキュー
接続完了
必要な数のJobWorkerにジョブをアサイン
分割(並列化)されたジョブをエンキュー
indexserver.ini ->
max_sql_executors global.ini -> max_concurrency
ここを詳しく知りたい方は
次のスライドもどうぞ
OLTP(単純) or OLAP(複雑)?
OLTP OLAP

Tips コネクション確立の仕組みに関して
PoolThread
① connect(2)によるTCP/IP接続
⑤ epoll_wait(2)でepoll fd内のfd(socket)がread(2)可能か確認
SqlExecutor #N
accept(2)
epoll_create(2)
epoll_ctl(2)
epoll fd#1 epoll fd#N epoll fd#M
② epoll fdが存在しない場合は作成
③ accept(2)で作成したfd(socket)をepoll fdに追加
⑥ read(2)可能であればread(2)でクライアントからのSQLをfd(socket)から読み込む
この時点でListenerは新規セッション受付
のため、Listen状態に戻る
… …
データベース起動時にactiveになるSqlExecutorの数は
パラメータ”sql_executors”で決まる
“sql_executors”の数で不足する場合は”max_sql_executors”の数まで増加
する。また、必要なくなれば”sql_executors”の数まで減少する。
④ write(2)でsocketにSQLを書き込む
fd
(socket)
fd
(socket)
fd
(socket)
fd
(socket)
fd
(socket)
fd
(socket)
fd
(socket)
fd
(socket)
fd
(socket)
fd
(socket)
fd
(socket)
fd
(socket)
SqlExecutor #1 SqlExecutor #M
SqlListenerClient
Clientにひもづくsocket 及び epoll fd はコネク
ション確立後は不変です。しかし、epoll fdを監
視しているSqlExecutorスレッドは変わる可能
性があります。それは、sql_executors、
max_sql_executorsパラメーターの関連で、ス
レッドの増減があり得るのと関連していて、ス
レッドが減る際に既存のepoll fdを監視するス
レッドが変わる可能性があります。

Tips max_sql_executorsパラメーターに関して (1/4)
以下のパラメーターによるHANAの同時実行数の制御はあくまでソフトリミットです。つまり設定数を超えて
同時に実行される場合があります。その際は、今まで見た”データベースリソース指標(仮)”から、その状況を
特定することが可能です。
 indexserver.ini -> sql_executors (デフォルト値=0 : システムの論理CPU数)
 global.ini -> max_concurrency (デフォルト値=0 : システムの論理CPU数)
しかし、以下のパラメーターはハードリミットで、基本的には設定数を超えてアクティブにはなりません。
 indexserver.ini -> max_sql_executors (デフォルト値=0 : No limit)
明示的にmax_sql_executorsパラメーターが設定された場合、基本的にその数を超えてSqlExecutorスレッドが
Runningになることはありません。設定値を超えてSqlExecutorスレッドが必要になっても(その場合SqlExecutor
を必要とするセッションは待機します)その状況を把握することができません。
以下、簡単なテストを行ってみます。

0
10
20
30
40
50
60
70
80
Running Waiting
80セッションから以下の単純なSQL文を連続で実行してみます。
SELECT primary_key_column FROM sql_exec_test WHERE primary_key_column = 1;
論理CPU数
テスト実施期間
64
max_sql_executors
4
テスト実施時のセッション数
80
実際は、SqlExecutorを待機していたに
もかかわらず、待機していたか否か不明

この場合、M_SERVICE_THREADSやM_SERVICE_THREAD_SAMPLESからでは、待機状況が不明なので、代わりに以下の
SQLを実行することである程度の状況がつかめます。
* 以下のSQL文は少し乱暴な部分もありますが(IDLE_TIME <= 10のあたり)、基本的なコンセプトは
 M_CONNECTIONからCONNECTION_STATUSが”IDLE”以外はRunning=実行中として計測
 また、CONNECTION_STATUSが”IDLE“かつ、そのIDLE_TIMEが10(ms)以下を”SqlExecutor Waiting”として計測
(非常に短いIDLE状態をずっと繰り返しているセッションを”SqlExecutor Waiting”とする)
としています。
SELECT sum(case when (CONNECTION_STATUS =’Running') then 1 else 0 end) as "Running",
sum(case when (CONNECTION_STATUS ='IDLE' and IDLE_TIME <= 10) then 1 else 0 end) as ”SqlExecutor Waiting”
FROM M_CONNECTIONS
WHERE AUTHENTICATION_METHOD != 'INTERNAL'
AND CONNECTION_TYPE != 'History (remote)’;
また、M_SERVICE_THREADSにおけるM_SERVICE_THREAD_SAMPLESのように、HANAが定期的にM_CONNECTIONSの履歴
を取得することはないので、独自にM_CONNECTIONSから情報を取得する仕組みが必要です。
* ただし、SqlExecutor自体を待機する場合、上記SQLの実行自体も待機する可能性があり、あくまでも参考値として考えてください

0
10
20
30
40
50
60
70
80
Running SqlExecutor Waiting
論理CPU数
テスト実施期間
64
max_sql_executors
4
テスト実施時のセッション数
80
SqlExecutorを待機していた状況をつかむこ
とが可能です。
また、待機セッション数が判明するので、
実際、適切な”max_sql_executors”パラ
メーターの値を推測可能になります。

トランザクションロック(行ロック) (1/2)
5セッションから同時にUPDATEを実行し、4セッションが行ロックで待機
UPDATE test_table SET column1=2 WHERE column2=1;
0
2
4
6
8
10
12
Running Waiting
論理CPU数
データベース内でのリソース待機
4
ぴったり、30分間待機状態が続く

トランザクションロック(行ロック) (2/2)
100%
THREAD_TYPE
SqlExecutor
100%
LOCK_WAIT_NAME
TransactionLockWaitCondStat
その際の待機イベントとして
は”TransactionLockCondWaitStat”と
なっています
該当スレッドがトランザクションロック
(テーブルロックも含む)で待機していること
を示しています
待機していたスレッドの100%が
SqlExecutorとなっいてます。
ここから、UPDATE分を実行するスレッドが
待機していたことが分かります

0
2
4
6
8
10
12
Running Waiting
だめ押しでデータベースパフォーマンス指標(仮)の理解
先ほどの倍、9セッションから同時にUPDATEを実行し、8セッションが行ロックで待機
UPDATE test_table SET column1=2 WHERE column2=1;
論理CPU数
8
先ほど(4セッションがロック待ち状態)に比べ、データベースパフォーマンス指標
(仮)は2倍ほど劣化していることが分かります。4 -> 8 (待機スレッドが増加して
います)
つまり、このデータベースパフォーマンス指標(仮)が論理CPUを超えない程度に
チューニングされていればシステムとして健全と言えます。逆に、データベースパ
フォーマンス指標(仮)に問題がある場合は、その程度(気にする必要性の有無=
チューニングコストの必要性)と原因(待機情報のドリルダウン)の分析を行いま
す。
また、データベースパフォーマンス指標(仮)が低い(すぎる)場合は、データベース
で処理されておらずアプリケーションやネットワークなどデータベース以前の問題
である可能性が高いと言えます。

Tips トランザクションロック待ちの詳細に関して (1/2)
先ほど、待機イベント”TransactionLockCondWaitStat”はトランザクションロックを意味します。しかしトランザクション
ロックが原因である場合、そのロックのタイプ(行ロック、テーブルロック)、ロックを保持している(待たせている)
セッションは誰なのか？どのオブジェクトで待機しているのか？などは、もう少し詳細な調査が必要になります。
 M_BLOCKED_TRANSACTIONS
- “待たされている”トランザクションの情報(BLOCKED_xxx)と”待たせている”トランザクションの情報
(LOCK_OWNER_xxx)を保持しています。合わせてロック対象のオブジェクトやロックモードも確認可能で
す。”待たされている”、”待たせている”双方のトランザクションはM_CONNECTIONSと結合することでセッ
ションの特定が可能です。
 M_RECORD_LOCKS
- M_BLOCKED_TRANSACTIONSとは異なり、競合の有無に関係なく取得中レコードロックの状態を保持
 M_OBJECT_LOCKS
- M_BLOCKED_TRANSACTIONSとは異なり、競合の有無に関係なく取得中オブジェクトロックの状態を保持
つまり、M_BLOCKED_TRANSACTIONS、(M_CONNECTIONS)、M_RECORD_LOCKS、M_OBJECT_LOCKSから、
トランザクションロックの詳細(誰が、何を、どんなふうに、待っているのか)を確認することが可能です。
＋ M_ACTIVE_STATEMENTSを組み合わせると待機しているSQL文も確認可能です。

Tips トランザクションロック待ちの詳細に関して (2/2)
“待たされている”セッション、”待たせている”セッション及び”待っている”テーブルやそのロックの種類を確認するSQL
SELECT bc.start_time "Session Start Time",
bc.connection_id "Blocked Connection ID",
bc.user_name "Blocked Session User Name",
ba.statement_string "Blocked Session Statement String",
bc.client_ip "Blocked Session Client IP",
bc.client_pid "Blocked Session Client PID",
lc.start_time "Lock Owner Session Start Time",
lc.connection_id "Lock Owner Connection ID",
lc.user_name "Lock Owner Session User Name",
la.statement_string "Lock Owner Session Statement String",
lc.client_ip "Lock Owner Session Client IP",
lc.client_pid "Lock Owner Session Client PID",
bt.blocked_time "Blocked Time",
bt.waiting_object_name "Waiting Object Name",
bt.waiting_object_type "Waiting Object Type",
bt.lock_type "Lock Type",
bt.lock_mode "Lock Mode"
FROM m_blocked_transactions bt,
m_connections bc LEFT OUTER JOIN m_active_statements ba ON bc.current_statement_id=ba.statement_id,
m_connections lc LEFT OUTER JOIN m_active_statements la ON lc.current_statement_id=la.statement_id
WHERE bt.blocked_transaction_id=bc.transaction_id
AND bt.blocked_connection_id=bc.connection_id
AND bt.lock_owner_transaction_id=lc.transaction_id
AND bt.lock_owner_connection_id=lc.connection_id;

Tips トランザクションロックタイムアウトに関して
ちなみに、この”TransactionLockCondWaitStat”による待機が30分間続いた後に正常に戻っているのには理由が
あります。
パラメーター indexserver.ini -> [transaction] -> lock_wait_timeout
のデフォルト値は1800000 (ms)となっています。つまり30分間で待機しているトランザクションはabortします。

Thread Pool
SQL Executor
(PoolThread)
SQL Executor
(PoolThread)
SqlExecutor
SQL文のParse
クライアントからのSQL文を待機
indexserver.ini ->
sql_executors
SQL文の実行
OLTP(単純) or OLAP(複雑)?
OLTP OLAP
SQL_PLAN_CACHEの確認
実行計画の作成
SQL_PLAN_CACHEのメンテナンス
CREATE PROCEDURE TOO_MANY_PLANS (
IN in_var INT)
LANGUAGE SQLSCRIPT
SQL SECURITY INVOKER
AS
BEGIN
DECLARE v_index INT;
DECLARE v_rand DOUBLE = RAND();
FOR v_index IN 1 .. in_var DO
EXEC 'SELECT /* '||:v_index||'_'||:v_rand||' */ '||:v_index||' FROM dummy';
END FOR;
END;
-- 以下を100セッションから同時に実行
CALL TOO_MANY_PLANS(30000);
複数100セッションから同時に異なるSQL文を実行
100セッション x 30,000回のSQLのメンテナンスを”SQLPlanCacheThread”が実施する必要が
あり、SQLプランキャッシュのメンテナンスコストが上がることが予想されます。
これによりSqlExecutorにより実行される軽量のSQLも影響を受けることが考えられます。以降
で”データベースパフォーマンス指標(仮)”とともに見ていきます。
SQLの(リ)コンパイル負荷 (1/3)

0
20
40
60
80
100
120
Running Waiting
論理CPU数
100

SqlExecutor
100%
Request
0%
THREAD_TYPE
ExclusiveLock Enter
100%
Mutex Wait
0%
THREAD_STATE
RWLock[query_plan_cache.cc:198]@0x00007fc9462a7be8:
ptime::Query::PlanCache::PlanCache
100%
NULL
0%
LOCK_WAIT_NAME
まず、今回はSQLを実行する
SqlExecutorが待機し、そのス
テータスは”ExclusiveLock
Enter”だったことがわかります
どのロック(ラッチ)を取得しよう
としていたかは、
LOCK_WAIT_NAMEか
ら”RWLock…PlanCache”だった
ことがわかります
ここから、SQLプランキャッシュ
をメンテナンスする
SQLPlanCacheThreadが高負荷状
態となり、その処理を待っている
SqlExecutorスレッドの多く
が”RWLock…PlanCache”で待機
したと考えられます。
これは、リテラルを使用した再利
用できなSQLが多く実行されてい
ることを意味しています。

パーシスタンスレイヤー
HANAデータベースのストレージ管理、トランザクションログ管理、
システムリスタート時のリカバリー管理などを行う
 データボリューム
• データとUndoを保持するストレージ領域
 ログボリューム
• トランザクションログ(REDO)を保持するストレージ領域
• データベースの変更(トランザクション)ログを保存するエリア
同期、非同期によるディスクへの書き込み
 セーブポイント(非同期)
• メモリー上の変更データをデータボリュームに書き込む(デ
フォルトで300秒ごとの遅延書き込み)
 コミット(同期)
• トランザクション確定のログエントリーを含むログバッファー
上のデータをログボリュームに書き込む
メモリー
ストレージ
データベース
ログボリューム
データボリューム
トランザクションログ
(WAL)の書き出し
- Log Buffer FULL
- Commit
定期的な自動
セーブポイント
SAP HANA
UNDO DATAREDO
Log Buffer Row Store Column Store
ログセグメント
ログボリュームへのI/Oの問題 (1/2)

ログボリュームへのI/Oの問題 (2/2)
6セッションから以下のプロシージャーを実行し、断続的にINSERT + COMMITを実行し続けます。
(6セッションから10万件のINSERT及び10万回のCOMMITを実行し続ける)
* 以降の検証は、ログボリュームへのI/O負荷を発生させるため、デバイスのパフォーマンスが著しく低速なものを使用しています。
CREATE PROCEDURE INSERTS (IN in_var INT)
LANGUAGE SQLSCRIPT
SQL SECURITY INVOKER
AS
BEGIN
DECLARE v_index INT;
FOR v_index IN 1 .. in_var DO
INSERT INTO KS_TEST2 VALUES (:v_index); -- 要はINSERTを実行するたびに
COMMIT; -- COMMITを実行
END FOR;
END;
-- 以下を6セッションから同時実行
call INSERTS(100000);

0
2
4
6
8
10
12
14
Running Waiting
ログボリュームへのI/Oの問題
コミットによるログセグメントへの(非)同期I/O (1/3)
論理CPU数
6

コミットによるログセグメントへの(非)同期I/O (2/3)
SqlExecutor
61%
WorkerThread
(StatisticsServer)
32%
Request
7%
THREAD_TYPE
POSTCOMMIT_FINISH_SMP
92%
?
7%
BTree GuardContainer
1%
LOCK_WAIT_NAMETHREAD_TYPE別で見ると多くは、
SqlExecutorスレッド(61%)です
DMLの実行を担うSqlExecutorが
INSERT/COMMITを繰り返し、待機
していたことを示しています
これも定期的にシステムビューを検
索し、問題の兆候を警告するため別
テーブルにINSERTする組み込みの
Statistics Serverによるアクティビ
ティを示しています
残りの多くは“WorkerThread
(StatisticsServer)”です(32%)
LOCK_WAIT_NAMEを見ると、
92%は
“POSTCOMMIT_FINISH_SMP”
です
これは、非同期I/Oを実行した後、
I/Oの完了をI/O完了通知スレッドか
ら待っている(同期しようとしてい
る)状態を示しています
このイベントが多い場合、小さいサ
イズのI/Oが頻繁に実行された結
果、I/OデバイスのIOPSが飽和した
か、I/Oデバイスのスループット不
足が考えられます

0
2
4
6
8
10
12
14
Running Waiting
コミットによるログセグメントへの(非)同期I/O (3/3) まともなデバイスに変更後
論理CPU数
I/Oデバイスで書き込み待ちが多数
発生した場合と比べ、I/Oデバイス
での書き込み待ちが減少し、その
分、CPU処理へ移動していること
が分かります。

Tips コミット時におけるI/Oの仕組みに関して
LocalPostCommit
Handler
MVCCGarbage
Collector
FileCompletion
Thread-LOG-0
Log Segment
② io_submit(2)により非同期I/O (ログバッファーからログセグメントへの書き込み)
③ futex(2)によりログセグメントに書き込み完了をLocalPostCommitHandlerに通知
⑤ futex(2)によりMVCCGarbageCollectorの起床
②’ io_getevents(2)で非同期I/Oの完了を監視
②’ futex(2)によるCommitHandlerへI/O完了通知
④ LocalPostCommitHandlerが最終的にfutex(2)によりSqlExecutorに通知
SqlExecutor
COMMITによる物理I/Oを待機
= “POSTCOMMIT_FINISH_SMP”
> COMMIT;
Commit
Handler
Submit
Thread-LOG-0
① futex(2)によりSubmitThread-LOG-0にI/Oの依頼
LocalPostCommit
Handler
LocalPostCommit
Handler
LocalPostCommit
Handler

以下のようにデータがメモリー上にロードされていない状況を作り、非常に単純なSQL文を実行した場合、
メモリーロードがどのように観測できるか確認してみます。
* 以降の検証は、データボリュームへのI/O負荷を発生させるため、デバイスのパフォーマンスが著しく低速なものを使用しています。
hdbsql> UNLOAD test_table;
# sync
# echo 3 > /proc/sys/vm/drop_caches
hdbsql> SELECT count(*) FROM test_table WHERE column1=1;
一旦、メモリー上のデータをアンロード
OSのファイルキャッシュを含めてフラッシュ
メモリーロードを伴う(はずの)SQL文を実行
単純なSQL文の問題
メモリーロードを伴うSQL文 (1/3)

0
1
2
3
4
5
6
7
8
Running Waiting
論理CPU数問題があるのか否か分かりづらいですが、
説明のために待機情報を見てみます

SqlExecutor
92%
PeriodicSavepoint
8%
THREAD_TYPE
PrefetchIteratorCallback
94%
ResourceFlushWaitB
4%
WaitAndSwitchCounterResource
1%
PrefetchCallback
1%
LOCK_WAIT_NAME
PeriodicSavepointはセーブポイン
ト関連なのでここでは無視します
SqlExecutor(メモリーロードを伴う
SQLを実行するスレッド)がほぼ待機
状態だったことが分かります
主な待機イベントとし
て”PrefetchIteratorCallback”およ
び”PrefetchCallback”になっている
ことが分かります
“PrefetchXXXCallback”は、物理
ディスクから必要なページを読み込
むのを待機しているという意味です
厳密には”PrefetchXXXCallback”が
メモリーロードでの待機(だけ)を意
味するというわけではありません
ただ、多くの場合におい
て”SqlExecutor”
が”PrefetchXXXCallback”で待機す
るということはメモリーロードを待
機している可能性が高いと言えます

Tips 複数セッションで同一オブジェクトのメモリーロードを要求(1/3)
メモリーロードが発生する場合、メモリーロードを要求するセッションが一つとは限りません。
どちらかというと、複数のセッションから(同じか否かは問いませんが)SQLにより同一のオブジェクト
(メモリー上にロードされていない)にアクセスすることの方が一般的かもしれません。
ここでは、より一般的なケースを考えてみます。
* 以降の検証は、データボリュームへのI/O負荷を発生させるため、デバイスのパフォーマンスが著しく低速なものを使用しています。
hdbsql> UNLOAD test_table;
# sync
# echo 3 > /proc/sys/vm/drop_caches
hdbsql> SELECT count(*) FROM test_table WHERE column1=1;
一旦、メモリー上のデータをアンロード
OSのファイルキャッシュを含めてフラッシュ
10セッションから、メモリーロードを伴う(もしくはメモリーロード中のオブジェクトにアクセスする)SQL文を実行

Tips 複数セッションで同一オブジェクトのメモリーロードを要求 (2/3)
0
2
4
6
8
10
12
14
Running Waiting
論理CPU数
(待機セッション(スレッド)は10)

Tips 複数セッションで同一オブジェクトのメモリーロードを要求 (3/3)
SqlExecutor
100%
PeriodicSavepoi
nt
0%
THREAD_STATE
PrefetchIteratorCallback
10%
PrefetchCallback
0%
TRexConfig_IndexMgrIndex_ReplayLock
43%
AttributeStore Resource Load
47%
ResourceFlushWaitB
0%
ResourceFlushWaitA
0%
LOCK_WAIT_NAME
“PrefetchXXXCallback”つまり実際にメモ
リーロードを実行中で待機しているスレッ
ドが10%(今回だと1スレッド)だと分かり
ます
“AttributeStore Resource Load”
と”TRexConfig_IndexMgrIndex_Replay
Lock”で待機していたスレッドは90%(今
回だと9スレッド)だと分かります
“AttributeStore Resource Load”およ
び”TRexConfig_IndexMgrIndex_Replay
Lock”の待機は、別のセッション(スレッ
ド)が該当オブジェクトをメモリーにロー
ド中であり、そのメモリーロードの完了を
待機していることを示しています

今回は大量データのソートに関連する問題を見てみます。
まず、問題のないパターンを見た後で、問題のパターンを見てみます。
SELECT column1 FROM sort_test_table WHERE column2=’test' order by column1 LIMIT n OFFSET m;
大量データでソート処理を伴うSQL文
複雑なSQL文(パラレル実行)の問題
大量データでソート処理を伴うSQL文 (1/4)

データベースパフォーマンス指標(仮) (以下は問題ではないパターン)
0
5
10
15
20
25
30
35
40
45
50
55
60
65
Running Waiting
論理CPU数
特におかしな状況ではありません
特に問題ではないですが、
待機情報を確認してみます

待機情報のドリルダウン(今回は問題ではないパターン)
JobWorker
100%
THREAD_TYPE
Mutex Wait
100%
THREAD_STATE
ZipResultInput_SectionLock
100%
LOCK_WAIT_NAME
待機中のスレッドは
JobWorkerだったことが分
かります
JobWorkerは、ステータス
(THREAD_STATE)として
は”Mutex Wait”で待機して
いることが分かります
JobWorkerによる複雑な
SQL文を処理中に、
“Mutex Wait”で待機してい
ことが分かります。”Mutex
Wait”は”Semaphore
Wait”同様にHANAの内部
的なロックで待機中という
ことを示しています
待機イベントをみると
“ZipResultInput_SectionL
ock”となっています
並列でのソート処理実行時
にどうしても必要なシリア
ライズ処理を待機している
ことを意味しています
ソート処理のステップにお
いてある程度の待機は致し
方ないため、本イベントで
CPUリソースが回らないほ
どの待機が発生していない
のであれば、通常の処理状
況と言えると思います

0
5
10
15
20
25
30
35
40
45
50
55
60
65
Running Waiting
データベースパフォーマンス指標(仮) (以下は問題のパターン)
論理CPU数
待機は全くないですが、CPUも使えなくなっています…
SqlExecutor
91%
JobWorker
8%
WorkerThread
(StatisticsServer)
1%
THREAD_TYPE(STATE=Running)
Optimizerの問題で、上手くパラレル処理
を選択できず、CPUリソースを有効に使
えていない問題です。その際、パラレル
処理を選択していないので、SqlExecutor
が1スレッドでSQL文を処理していること
が分かります。

Tips M_JOBEXECUTORSシステムビュー
JOB_WAITING_WORKER_COUNT
SYS_WAITING_WORKER_COUNT
YIELD_WAITING_WORKER_COUNT
FREE_WORKER_COUNT
PARKED_WORKER_COUNT
実行中(Running)
他のジョブの処理を待機中
システムレベルの同期処理
を待機中
他のより重要な処理に自分
の実行を明け渡して待機中
利用可能
一時的に設定値を超えて生成
されたスレッドの一部は将来
の再利用のために残される
TOTAL_WORKER_COUNT
* including one extra worker thread for
emergency diagnostic purposes
* Running = total - (free + job waiting
+ sys waiting + yield waiting + 1)
QUEUED_WAITING_JOB_COUNT
* Number of jobs queued for execution
Job Worker Thread Pool
Job WorkerJob WorkerJobExecutor
(JobexMainDispatcher)
JobWorker
PLANにより、各プランオペレーター
(POP)ごとに並列ジョブ化
JobExecutorはプラオリティの
高いジョブから取り出し、
JobWorkerにディスパッチする
さらに並列化が可能か?
Yes
ジョブの分割
ジョブの実行
No
Queryの最適化
Job Queue
並列化されたジョブをエンキュー
必要な数のJobWorkerにジョブをアサイン
分割(並列化)されたジョブをエンキュー
OLAP

パーシスタンスレイヤー
HANAデータベースのストレージ管理、トランザクションログ管理、
システムリスタート時のリカバリー管理などを行う
 データボリューム
• データとUndoを保持するストレージ領域
 ログボリューム
• トランザクションログ(REDO)を保持するストレージ領域
• データベースの変更(トランザクション)ログを保存するエリア
同期、非同期によるディスクへの書き込み
 セーブポイント(非同期)
• メモリー上の変更データをデータボリュームに書き込む(デ
フォルトで300秒ごとの遅延書き込み)
 コミット(同期)
• トランザクション確定のログエントリーを含むログバッファー
上のデータをログボリュームに書き込む
メモリー
ストレージ
データベース
ログボリューム
データボリューム
トランザクションログ
(WAL)の書き出し
- Log Buffer FULL
- Commit
定期的な自動
セーブポイント
SAP HANA
UNDO DATAREDO
Log Buffer Row Store Column Store
HANAのバックグランド処理の問題
セーブポイント (1/3)

0
0.2
0.4
0.6
0.8
1
1.2
Running Waiting
データベースパフォーマンス指標(仮) (PeriodicSavepoint)

待機情報のドリルダウン (PeriodicSavepoint)
doSavepoint
100%
THREAD_METHOD
ResourceFlushWaitB
98%
ResourceFlushWaitA
2%
LOCK_WAIT_NAME
今回はセーブポイントに注目する
ためPeriodicSavepointスレッドを
注目してみます
PeriodicSavepointスレッドの
THREAD_METHOD
は”doSavepoint”として待機中
だったことが分かります
セーブポイントの処理に時間がか
かっている場合、待機スレッドと
してはセーブポイントの実行を担
う”PeriodicSavepoint”が特徴的に
現れます。
LOCK_WAIT_NAMEとしては
ResourceFlushWait[A|B]として
観測できます
これは、物理書き込みを待機して
いることを示します。
ただし、書き込むデータ量が多
く、I/Oデバイスが非常に高速な場
合、実際にデータボリュームへ非
同期I/Oを実行している
SubmitThread-DATA-0スレッド
のCPU負荷として”も”現象が観測
されます
今回は、セーブポイントにて書き
込むべきデータ量をデバイスで処
理しきれないI/Oボトルネックだっ
たことが分かります

Tips セーブポイントの仕組み (1/2)
PeriodicSavepoint Data Volume
④ io_submit(2)によるデータボリュームへ非同期I/O(書き込み)
FlushResourcesThread FileCompletionThread-DATA-0
⑥ futex(2)による起床
① futex(2)による待機(global.ini->[persistence]->savepoint_interval_sで設定された秒数)
② futex(2)による起床
④’ io_getevents(2)による非同期I/Oの完了を監視
SubmitThread-DATA-0
④’’ I/O完了の場合はfutex(2)で待機スレッドに通知
③ futex(2)による起床
⑤ futex(2)による起床
⑦ futex(2)による待機(global.ini->[persistence]->savepoint_interval_sで設定された秒数)
セーブポイントによる物理I/Oを待機
= “ResourceFlushWait[A|B]”
FlushResourcesThreadの起床待ち
= “WaitAndSwitchCounterResourceSemaphore”

Tips セーブポイントの仕組み (2/2)
PREPARE
prepare
Savepoint
PAGEFLUSH
flushPageinNonCriticalPhase
PRECRITICAL
preCritical
Phase
ENTER
CRITICAL
enterCritical
Phase
CRITICAL
processCritical
Phase
POST
CRITICAL
enterPost
CriticalPhase
EXIT
CRITICAL
exitCritical
Phase
M_SAVEPOINTS
M_SERVICE_THREADS
1 2 3 4 5
完了
メモリー上の更新ページ
1 2 3 4 5
ディスク上に永続化
されるページ
5’
5’
前回のセーブポイント以降で更新されたデータ
(ページ)がこのフェーズでディスクに書き出さ
れます。また、このフェーズでは他の処理はブ
ロックされません。このフェーズは何度かリト
ライされ、CRITICALフェーズでの書き出し
(ロック)時間を最小化させます。
ここまで
ページの
書き出し
の完了を
待機しま
す。
Savepoint
Lock(Consis
tentChange
Lock)の排他
ロックを取
得します。
必要な更新デー
タを非同期I/O
で書き出し、
SAVEPOINTの
バージョンを変
更します。
Savepoint
Lockの排
他ロックを
リリースし
ます。
CRITICAL
フェーズ中
の非同期
I/Oの完了
を待ちま
す。
セーブポイント開始
DML、DDLはブロックされます
DURATION
STATE
THREAD_DETAIL
CRITICAL_PHASE_WAIT_TIME
CRITICAL_PHASE_DURATION
6
6
FINISHING
Finish
Savepoint
不要なリ
ソースの
解放など
の後処理
1’
1’

Tips M_SAVEPOINTSシステムビューでの監視
基本的にセーブポイントにかかる時間は、セーブポイント間(前回と今回)での更新データ(ページ)量に依存します。
多少時間がかかっていても、デフォルトで300秒おきに実行されるセーブポイントに大きな影響がなければシステムとしては正常です。
ただし、セーブポイントの特定のフェーズ(CRITICAL)や、セーブポイント全体の実行時間が異常に長い場合は、付随するいくつの問題を
誘発する恐れがあります。
また、今まで説明した”データベースパフォーマンス指標(仮)”では、システム全体としてセーブポイントに問題があるか否か判定することは
難しいと言えます。それは、セーブポイントの実行スレッド(PeriodicSavepoint)1スレッドのみが待機するので、システム全体としての問題
として表面化しづらいからです。
ここでは、”データベースパフォーマンス指標(仮)”と同時にM_SAVEPOINTSシステムビューを監視しておくことをお勧めします。
誘発される問題の幾つかを以下にあげておきます。
 クリティカルフェーズの長期化によるDML、DDLがブロックされる問題
-> M_SAVEPOINTSのCRITICAL_PHASE_WAIT_TIME(μs)やCRITICAL_PHASE_DURATION(μs)の監視
 ログセグメントの増加によるデータベース停止
-> M_SAVEPOINTSのDURATION(μs)の監視
などの思いもよらない障害につながりますので、しっかり注意しておきましょう。

データベースパフォーマンス指標(仮) – 約10分間での指標
0
5
10
15
20
25
30
Running Waiting
この時間帯(1分)だけ、異常にWaitingのスレッド数が多い
(約30セッションで更新処理を実行中)
セーブポイントの問題に起因するクリティカルフェーズの問題 (1/3)

待機情報のドリルダウン (異常な時間帯(1分間))
JobWorker
7%
MergedogMerger
9%
PeriodicSavepoint
4%
SqlExecutor
80%
THREAD_TYPE
MergeMonitor_Lock
3%
AttributeValueContainer readLock
4%
WaitAndSwitchCounterResourceS
emaphore
3%
ConsistentChangeLock
83%
LOCK_WAIT_NAME
この時間帯はセーブポイント
(PeriodicSavepoint)をはじめ、い
くつかのスレッドが待機していま
すが、多くの待機はSqlExecutorで
発生しています
この時間帯の”データベースパ
フォーマンス指標(仮)”では約23ス
レッドが待機中でした。
この内80% = 18.4スレッドが
SqlExecutorとなります。この時間
帯は30セッションから更新処理を
実行中でしたので、多くの更新処
理が待機したことになります。
LOCK_WAIT_NAMEとして
は”ConsistentChangeLock”が多
く観測できます
ここに出していませんが、
THREAD_STATEの多く
は”SharedLock Enter”であ
り、”ConsistentChangeLock”
を”Share”モードで取得しようとし
て待機したことがわかります
“ConsistentChangeLock”とは
セーブポイントのクリティカル
フェーズで”Exclusive“モードで取
得される”Savepoint Lock”のこと
です。DMLやDDLはこのロック
を”Share”モードで取得する必要が
あり、クリティカルフェーズでは
処理がブロックされることになり
ます

M_SAVEPOINTSで見ると (* SAP HANA Troubleshooting and Performance Analysis Guide の Savepoint Performanceより)
SELECT start_time, volume_id,
round(duration / 1000000) as "Duration in Seconds",
round(critical_phase_duration / 1000000) as "Critical Phase Duration in Seconds",
round(total_size / 1024 / 1024) as "Size in MB",
round(total_size / duration) as "Appro. MB/sec",
round (flushed_rowstore_size / 1024 / 1024) as "Row Store Part MB"
FROM m_savepoints
WHERE volume_id in ( SELECT volume_id FROM m_volumes WHERE service_name = ‘indexserver’) ;
SELECT to_char(SERVER_TIMESTAMP,'yyyy.mm.dd') as "time",
sum(case when (critical_phase_duration <= 1000000) then 1 else 0 end) as "<= 1 s",
sum(case when (critical_phase_duration > 1000000 and critical_phase_duration <=2000000) then 1 else 0 end) as "<= 2 s",
Sum(case when (critical_phase_duration > 4000000 and critical_phase_duration <=5000000) then 1 else 0 end) as "<= 5 s",
sum(case when (critical_phase_duration > 60000000 ) then 1 else 0 end) as “> 60 s",
count(critical_phase_duration) as "ALL"
FORM "_SYS_STATISTICS"."HOST_SAVEPOINTS"
WHERE volume_id in (select volume_id from m_volumes where service_name = 'indexserver')
AND weekday (server_timestamp) not in (5, 6)
GROUP BY to_char(SERVER_TIMESTAMP,'yyyy.mm.dd')
ORDER BY to_char(SERVER_TIMESTAMP,'yyyy.mm.dd') desc;
セーブポイントの時間とサイズ
クリティカルフェーズにかかった時間のヒストグラム

よくある問題(良くはないのですが)として、気づかないうちに、ログセグメント(デフォルト1GBのファイルが3つ)が大量に存在していて、
ディスクフルでデータベースが停止するといった障害を見ることがあります。
これは、どのような理由から発生してしまうのでしょうか？
ログ
セグメント#1
(Free)
ログ
セグメント#2
(Writing)
ログ
セグメント#3
(Free)
ログスイッチ
ログ
セグメント#1
(Free)
ログ
セグメント#2
(BackedUp)
ログ
セグメント#3
(Writing)
ログスイッチ
ログ
セグメント#1
(Writing)
ログ
セグメント#2
(BackedUp)
ログ
セグメント#3
(BackedUp)
ログスイッチ
ログ
セグメント#1
(BackedUp)
ログ
セグメント#2
(BackedUp)
ログ
セグメント#3
(BackedUp)
ログ
セグメント#4
(Writing)
ログ
セグメント#1
(Free)
ログ
セグメント#2
(Free)
ログ
セグメント#3
(Free)
ログ
セグメント#4
(Writing)
ALTER SYSTEM RECLAIM LOG;
ログ
セグメント#1
(Free)
ログ
セグメント#2
(Free)
ログ
セグメント#4
(Writing)
増加してしまったログ
セグメントの削除は
ALTER SYSTEM
RECLAIM LOG;で行っ
てください。決して手
動で削除しないでくだ
さい。
このままだと、ログセグ
メントは増加し続ける
セーブポイント完了
セーブポイントが完了し
ないとログセグメントを
再利用できない
デフォルトでは1GBのファ
イルが3つ。どれか一つが
Writing(書き込み中)とな
り、書き込みファイルは
ローテーションされる
セーブポイントの問題に起因するログセグメントの増加 (1/2)

ログセグエメントは、セーブポイントの性能によっては増加する可能性があります。
また、セーブポイントがどれほど時間がかかるのか？及びその際の更新トランザクション量はどれほどか？
によっては、急激にログボリュームを圧迫するほどのログセグメントが生成される可能性あります。
OS的な見地からのログボリュームの容量確認とHANAからセーブポイントの実行時間の確認が重要です。
セーブポイントの問題に起因するログセグメントの増加 (2/2)
SELECT start_time, volume_id,
round(duration / 1000000) as "Duration in Seconds",
round(critical_phase_duration / 1000000) as "Critical Phase Duration in Seconds",
round(total_size / 1024 / 1024) as "Size in MB",
round(total_size / duration) as "Appro. MB/sec",
round (flushed_rowstore_size / 1024 / 1024) as "Row Store Part MB"
FROM m_savepoints
WHERE volume_id in ( SELECT volume_id FROM m_volumes WHERE service_name = ‘indexserver’) ;
セーブポイントの時間とサイズ
## 定期的にログボリュームの容量を監視することが重要です
# df –h /hana/log
ログボリュームの容量を確認

まとめ
実施ゴール設定分析測定
データベース
が必要として
いるリソース
量は適切か?
必要としたの
は待機リソー
スか?
必要としたの
はCPUリソー
スか?
それぞれの待
機情報に適し
たチューニン
グ
CPUを使わせ
ない/CPUの増
強をする
チューニング
CPUを使わせ
るチューニン
グチューニング
のゴール設定
チューニング
の実施
データベースパフォーマンス
指標(仮)＋α
様々な待機情報に関するナレッジと経験データベースパフォーマンス
指標(仮)＋α
やる気

ご清聴ありがとうございました。
問い合わせ先:
新久保浩二
SAPジャパン株式会社
ソリューション統括本部
デジタル・ビジネス・プラットフォーム部
シニア・ソリューション・スペシャリスト
koji.shinkubo@sap.com

Tech JAM 2016 TEC 11 実践 SAP HANA 大解剖

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à Tech JAM 2016 TEC 11 実践 SAP HANA 大解剖

Similaire à Tech JAM 2016 TEC 11 実践 SAP HANA 大解剖 (20)

Plus de Koji Shinkubo

Plus de Koji Shinkubo (12)

Dernier

Dernier (11)

Tech JAM 2016 TEC 11 実践 SAP HANA 大解剖