myVertica  

データベースの性能が劣化した場合の対処方法

データベースの性能が劣化した場合に、次のチェックリストを使用してトラブルシューティングを行います。
次のような問題が存在しないかどうか確認します。

ステップ タスク 結果
1 特定のクエリの性能が遅いですか? 特定のクエリの性能が遅い場合、Query Performance チェックリストを参照します。
特定のクエリの性能が遅くない場合、 Step 2 へ。
2 データベース全体が遅いですか? データベース全体が遅い場合、 Step 3 へ。
データベース全体が遅くない場合、このチェックリストは完了です。
3 全ノードが起動しているかどうか確認します。 => SELECT node_name, node_address, node_state FROM nodes WHERE node_state != 'UP'; 任意のノードがDOWNしている場合、
  • ノードが停止している理由について調査を行うために、 Node Down チェックリストを確認します。
  • ノードを再起動します。 $ admintools –t restart_nodes –d <database> -s <nodes_address>
  • ノードが再起動し、性能が向上した場合、このチェックリストは完了です。

    ノードが再起動したが、性能がまだ遅い場合、 Step 4 へ。
    ノードが再起動しない場合、 Node Down チェックリストへ。
    4 大量のデリートベクターが存在していないかどうか確認します。 => SELECT count(*) FROM delete vectors; 1000以上のデリートベクターが存在する場合、Manage Delete Vectors チェックリストを参照します。

    それほど多くのデリートベクターが存在しない場合、Step 5 へ。
    5 エポックが進んでいるかどうか確認します。 => SELECT current_epoch, ahm_epoch, last_good_epoch, designed_Fault_tolerance, current_fault_tolerance FROM system ; エポックが進んでいない場合、AHM not Advancing チェックリストを参照します。

    エポックが進まない場合、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 任意のノードが他のノードよりも遅い場合、
  • ホストの性能の問題について調査します。
  • 該当のノード上のVerticaプロセスを再起動します。
  • 起動: $ 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が発生している場合、Query Performance チェックリストを参照します。
    遅延を決定づけるようなリソース不足の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リソースプールで自動調整されます。)
  • GeneralプールのMaxmemorysizeを95%以下に設定する。
  • カタログを格納するのに必要なサイズのリソースプールを追加作成する。


  • 多くの場合、ノードを再起動するとカタログで使用されるメモリが解放される可能性があります。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テクニカルサポートまでお問い合わせください。

    ノードを再起動すると問題は解決するはずですが、適切なデバッグを行う必要があります。カタログサイズの問題については、Catalog Size Debugging チェックリストをご確認ください。

    関連詳細情報

    Vertica Documentation の Load Balancing にて、関連情報が確認できます。