次のような問題が存在しないかどうか確認します。
| ステップ | タスク | 結果 |
|---|---|---|
| 1 | 特定のクエリの性能が遅いですか？ | 特定のクエリの性能が遅い場合、クエリの性能が突然低下した場合の対処方法チェックリストを参照します。
特定のクエリの性能が遅くない場合、 Step 2 へ。 |
| 2 | データベース全体が遅いですか？ | データベース全体が遅い場合、 Step 3 へ。
データベース全体が遅くない場合、このチェックリストは完了です。 |
| 3 | 全ノードが起動しているかどうか確認します。
=> SELECT node_name, node_address, node_state FROM nodes WHERE node_state != 'UP'; |
任意のノードがDOWNしている場合、
$ admintools –t restart_nodes –d <database> -s <nodes_address>ノードが再起動したが、性能がまだ遅い場合、 Step 4 へ。 ノードが再起動しない場合、 データベースノードが停止した場合の対処方法チェックリストへ。 |
| 4 | 大量のデリートベクターが存在していないかどうか確認します。
=> SELECT count(*) FROM delete vectors; |
1000以上のデリートベクターが存在する場合、デリートベクターの対処方法チェックリストを参照します。
それほど多くのデリートベクターが存在しない場合、Step 5 へ。 |
| 5 | エポックが進んでいるかどうか確認します。
=> SELECT current_epoch, ahm_epoch, last_good_epoch, designed_Fault_tolerance, current_fault_tolerance FROM system ; |
エポックが進んでいない場合、AHM（Ancient History Mark）が進まない場合の対処方法チェックリストを参照します。
エポックが進まない場合、Step 6 へ。 |
| 6 | 任意のノードが他のノードよりも遅延していないかどうか確認します。
クラスター内の各ノード上でSELECT文を実行し、遅いノードを特定します。
$ `grep -P "^v_" /opt/vertica/config/admintools.conf|awk '{print $3}'|
awk -F, '{print $1}'`; do echo ----- $host -----; date ; vsql -h
$host -c ";select /*+kV*/ 1 ;";date ; done |
任意のノードが他のノードよりも遅い場合、
$ admintools –t restart_node –d <database> -s
停止:
$ admintools –t stop_node –s <node_ip/Host slow>
全てのノードが同様の性能である場合、Step 7 へ。 |
| 7 | ワークロードがすべてのノード上でバランスがとれている状態かどうか確認します。
=> SELECT node_name,count(*) FROM dc_requests_issued WHERE
time > sysdate() -1 group by 1 ORDER BY 1; |
ひとつのノードのワークロードがより高い場合、全てのノード上にワークロードが分散するようにします。
Load balancing のドキュメンテーションの内容を参照してください。
ワークロードのバランスがとれている場合、Step 8 へ。 |
| 8 | リソース不足でREJECTが発生していないかどうか確認します。
=> SELECT * FROM resource_rejections ORDER BY last_rejected_timestamp; |
リソース不足のREJECTが発生している場合、クエリの性能が突然低下した場合の対処方法 チェックリストを参照します。
遅延を決定づけるようなリソース不足のREJECTが発生していない場合、Step 9 へ。 |
| 9 | 待ち状態であるセッションが存在しないかどうか確認します。
=> SELECT * FROM resource_queues; |
リソース待ち状態のクエリが存在する場合、Step 10 へ。 |
| 10 | 大量のリソースを使用する長時間実行中のセッションが存在しないかどうか確認します。
=> SELECT r.pool_name, s.node_name AS initiator_node, s.session_id,
r.transaction_id, r.statement_id, max(s.user_name) AS user_name,
max(substr(s.current_statement, 1, 100)) AS statement_running,
max(r.thread_count) AS threads, max(r.open_file_handle_count)
AS fhandlers, max(r.memory_inuse_kb) AS max_mem,
count(DISTINCT r.node_name) AS nodes_count, min(r.queue_entry_timestamp)
AS entry_time, max(((r.acquisition_timestamp - r.queue_entry_timestamp)))
AS waiting_queue, max(((clock_timestamp() - r.queue_entry_timestamp)))
AS running_time FROM (v_internal.vs_resource_acquisitions r
JOIN v_monitor.sessions s ON (((r.transaction_id = s.transaction_id)
AND (r.statement_id = r.statement_id)))) WHERE
(length(s.current_statement) > 0) GROUP BY r.pool_name, s.node_name,
s.session_id, r.transaction_id, r.statement_id ORDER BY r.pool_name; |
長時間実行されているステートメントがあり、サーバーのリソースを高い割合で使用している場合、次のSQLでステートメントを停止することを検討します。=> SELECT interrupt_stament(‘session_id’,’statement_id’);
ステートメントをキャンセルすると、リソースが解放され、性能の向上が見込めます。
性能が向上しない場合、Step 11 へ。
セッションが正常に終了しない場合、Verticaテクニカルサポートまでお問い合わせください。 |
| 11 | ロック待ちしているトランザクションが存在しないかどうか確認します。
=> SELECT * FROM locks where grant_timestamp is null; |
トランザクションがロック待ちの場合、ロックを保持しているセッションを特定し、トランザクションの完了を待つか、あるいは、ロックを保持しているセッションをキャンセルし、ロックを解放することを検討します。
=> SELECT interrupt_stament(‘session_id’,’statement_id’);
ステートメントの完了またはキャンセルでのロックの解放時に、性能が向上するはずです。性能が向上しない場合、Step 12 へ。
セッションが正常に終了しない場合、Verticaテクニカルサポートにセッションハングの問題としてお問い合わせください。 |
| 12 | メモリ上のカタログサイズを確認します。
=> SELECT node_name,max(ts) as ts, max(catalog_size_in_MB) as catlog_size_in_MB FROM
( SELECT node_name,trunc((dc_allocation_pool_statistics_by_second."time")::TIMESTAMP,
'SS'::VARCHAR(2)) AS ts, sum((dc_allocation_pool_statistics_by_second.total_memory_max_value - dc_allocation_pool_statistics_by_second.free_memory_min_value))/(1024*1024)
AS catalog_size_in_MB from dc_allocation_pool_statistics_by_second group by 1,2)
foo group by 1 ORDER BY 1 limit 50; |
カタログがホストのメモリの5％より大きい場合、VerticaプロセスはOOMでカーネルによって停止されるリスクがあるため、リソースプール設定で、カタログで必要な空きメモリを調整する必要があります。
Verticaテクニカルサポートにお問い合わせいただき、カタログサイズの増加の原因について調査し、カタログ分の空きメモリを確保するための代替案について検討してください。8.0.0以前のバージョンの代替手段は次のとおりです。（8.0.1以降のバージョンでは、METADATAリソースプールで自動調整されます。） 多くの場合、ノードを再起動するとカタログで使用されるメモリが解放される可能性があります。Verticaテクニカルサポートにお問い合わせいただくことにより、最善のアクションプラン決定の支援を行えるでしょう。 |
| 13 | 常駐メモリと仮想メモリの使用状況と、生成されたメモリのマップを確認します。
=> SELECT * FROM ( SELECT time, node_name, files_open,
other_open,sockets_open,virtual_size,resident_size,thread_count,map_count,
row_number() over (partition by node_name ORDER BY time::timestamp desc)
as row FROM dc_process_info ) a where row <=3 ; |
仮想メモリまたは常駐メモリが高い場合、数値が小さくなるどうかを監視してください。
数値が小さくならない場合、問題をデバッグするために、Verticaテクニカルサポートまでお問い合わせください。 ノードを再起動すると問題は解決するはずですが、適切なデバッグを行う必要があります。カタログサイズの問題については、カタログサイズ肥大化の対処方法チェックリストをご確認ください。 |
関連詳細情報
Vertica Documentation の Load Balancing にて、関連情報が確認できます。About the Author
Soniya Shah
Information Developer
Currently, a first year law student with a background in science and technology. Experienced technical writer, with specializations in software documentation, big data, blog development, and website development. I build user-centered content to communicate complex and technical information more easily.
I used to work for Vertica full time for about 3 years. I still work at Vertica part time while going to law school.
Update: Soniya is now doing her law internship, and no longer working at Vertica. Good luck, Soniya!
