カタログサイズ肥大化の対処方法

Posted June 18, 2018 by Soniya Shah, Information Developer

white cloud in vault type room representing cloud computing
カタログのサイズが10 GBを超えるか、あるいは、カタログが1日あたり5%を超えて増えている場合、カタログサイズが大きいといえます。 このチェックリストには、データベースカタログのサイズをモニタリング、および、削減するための提案事項と推奨事項が記載されています。

データベースカタログには、テーブル、プロジェクション、ユーザー、ノード、ROSなどのメタデータが含まれています。 カタログには2種類のオブジェクトがあります。

  • グローバルオブジェクトはノード固有ではありません。グローバルオブジェクトには、テーブル、ユーザー、およびノードが含まれます。 どのノードもクエリのイニシエーター(実行開始ノード)として機能するため、グローバルオブジェクトは全ノード上に完全に複製されます。
  • ローカルオブジェクトはノード固有です。ローカルオブジェクトには、ROS、WOS、および依存関係が含まれます。ストレージレイアウトはノードによって異なる可能性があるため、ローカルオブジェクトは複製されません。各ノード上で、独立してストレージレイアウト情報を保持します。

  • ノード起動時に、カタログはメモリ上にキャッシュされます。

    ステップ タスク 結果
    1 全ノード上のカタログサイズを確認します。 => SELECT DATE_TRUNC('day',ts) date, node_name, MAX(catalog_size_in_MB)::int as END_CATLOG_SIZE_MEM_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, TRUNC((dc_allocation_pool_statistics_by_second."time") ::TIMESTAMP,'SS'::VARCHAR(2)) ) foo GROUP BY 1,2 ORDER BY 1 DESC, 2; 大規模なカタログサイズで徐々にサイズが増加していて、データベースのパフォーマンスに影響する可能性がある場合は、Vertica 7.2.3-15以上にアップグレードすることを検討してください。または、このチェックリストを使用してカタログサイズ肥大化の原因を特定してください。

    メモリ上のカタログサイズがメモリ全体の5%未満で、Verticaのパフォーマンスが許容範囲である場合、ここでこのチェックリストは完了です。

    カタログサイズが5%以内であるが10GBを超える場合は、このチェックリストを使用し、大きなカタログサイズの根本原因を特定してください。このチェックリストの内容を確認し、カタログサイズを縮小することを検討してください。
    2 カタログが増加しているかどうかを確認し、データベースにオブジェクトが多すぎるかどうかを確認するには、次のクエリを使用します。 => SELECT COUNT(*) FROM tables; => SELECT COUNT(*) FROM Projections; => SELECT COUNT(*) FROM columns;   カタログサイズが大きく、オブジェクトが多数ある場合、不要なオブジェクトを減らすことを検討してください。次の方法でオブジェクトを削減できます。
  • 使用していないオブジェクトを削除する。
  • オブジェクトの依存関係を減らす。例えば、JOIN、WHERE句、およびGROUP BYによって使用される列の統計情報のみ取得する。 オブジェクト数が削減できない場合、リソースプールを調整するために、Step 12 へ。

  • オブジェクトが多くない場合、Step 3 へ。  
    3 デリートベクターの増加により、カタログサイズの増大しているかどうかを確認します。 => SELECT node_name, COUNT(*) FROM delete_vectors GROUP BY 1; 多数のデリートベクターがある場合は、デリートベクターの削除を検討してください。より詳細情報は、デリートベクターの対処方法チェックリストを参照してください。

    デリートベクターを削除することにより、メモリ上のカタログサイズを小さくすることが可能です。
    デリートベクターを削除後、カタログサイズを縮小するために、データーベースあるいはノードを再起動する必要があります。

    大量のデリートベクターがない場合、Step 4 へ。
    4 ROSコンテナが大量にあるかどうかを確認します。 => SELECT node_name, COUNT(*) FROM storage_containers GROUP BY 1; ROSコンテナ数が多い場合、Step 5 へ。ROSコンテナが多すぎるプロジェクションを確認します。
    Verticaテクニカルサポートにお問い合わせいただければ、カタログが大きい原因について詳細に分析することも可能です。
    5 より多くのROSコンテナを保持するプロジェクションを特定します。 => SELECT node_name, COUNT(*) num_proj, AVG(ROS_COUNT) AVG_ROS_COUNT FROM Projection_storage WHERE ROS_COUNT > 300 GROUP BY node_name; 大量のROSコンテナを持つプロジェクションが大量にあるが、ROS数の平均が300未満である場合、Step 11 へ。

    それほど大量のプロジェクションは無いが、ROS数の平均が500以上の場合、Step 6 へ。
    6 テーブルの設計方法に基づいて、パーティションが多すぎるかどうかを確認します。 => SELECT projection_id, table_schema, projection_name, COUNT(distinct partition_key) FROM partitions WHERE node_name = (SELECT local_node_name()) GROUP BY 1,2,3 ORDER BY 4 DESC; 該当のテーブルがパーティション化されていない、あるいは、パーティション数が600未満の場合、Step 7 へ。

    一意のパーティションIDが大量にあるプロジェクションが存在する場合、プロジェクションごとにより少ないパーティション数になるようにテーブルのパーティションキーを変更するために、Step 7 へ。
    7 その特定のプロジェクションに対してmergeoutが機能しているかどうかをモニターします。 => SELECT operation_start_timestamp, node_name, operation_status FROM tuple_mover_operations WHERE projection_id = <ID of step 6> and operation_name = 'Mergeout' ORDER BY 1 DESC; 最後のステータスがCOMPLETEではない場合、mergeoutが完了するまで待機し、下記クエリでROSコンテナをカウントします。 => SELECT node_name, projection_id, projection_schema, projection_name, ROS_COUNT FROM projection_storage WHERE ROS_COUNT > 30 ORDER BY ROS_COUNT DESC limit 10;最後のステータスがCOMPLETEであるが、mergeoutが直近一時間で実行されていない場合、Step 8 へ。mergeoutが正しく機能しているにもかかわらず、プロジェクションに依然として多くのROSコンテナがある場合、Verticaテクニカルサポートにお問い合わせください。
    8 手動でmergeoutを実行します。 => SELECT DO_TM_TASK(‘mergeout’,’projection_schema.projection_name’); 実行完了後、ROSコンテナの数を確認します。 mergeoutがROSコンテナの数を減らさない場合、Verticaテクニカルサポートにお問い合わせください。
    9 カタログオブジェクトの調整後、メモリをリセットするためにノードを再起動し、メモリ上のカタログサイズを確認します。 => SELECT node_name, DATE_TRUNC('day',time::timestamp) date, MAX(size/1024^2)::int catalog_disk FROM DC_catalog_persistence_events WHERE event_action = 'write complete' GROUP BY 1,2 ORDER BY 1, 2 DESC; ノードの再起動が難しい場合、Step 10 へ。
    10 Verticaのバージョンが8.0.1より前の場合、メモリのスワップを避けるためにリソースプールの設定を調整します。
    100 – (Generalプールのメモリサイズ) – (メモリ上のカタログサイズ) のサイズ(%)のリソースプールを作成します。

    例えば、メモリ上のカタログが8%で、Generalプールのメモリサイズが95%(デフォルト)の場合、計算は、100 – 95 – 8 = –3となります。

    カタログサイズが大きくなることを考え、2%多めに割り当てます。 => CREATE RESOURCE POOL CATALOG_MEM MEMORYSIZE '5%’; このリソースプールにより、スワップやメモリ不足を避けるために、再起動せずに調整することができます。 Vertica 8.0.1以降では、Verticaは、METADATAプールで自動調整します。
    カタログサイズを反映するようにリソースプールを調整し、リソースマネージャーがこのメモリを使用してクエリを実行しないようにすることで、OOMまたはスワップを回避します。

    このリソースプールの調整ではパフォーマンスの問題は解決されません。パフォーマンスの問題を解決するには、カタログサイズを縮小する手段を検討してください。
    11 パーティション化されたテーブルが多すぎるが、パーティションの数はまだ推奨内である場合、次のいずれかを実行します。
  • カタログの増加を避けるために、より多くの行を含むテーブルのみをパーティション化する。
  • 少ない粒度でテーブルをパーティション化する。
  •  
    小さいテーブルをパーティション化しないようにすることが難しい場合、リソースプールの調整のために Step 10 へ。
    12 より少ない行のパーティションを持つテーブルはパーティションが推奨されないため、より少ない行のパーティションがあるかどうかを特定します。パーティションごとに100を超える行を持つテーブルをパーティション化します。 => SELECT projection_id,table_schema, projection_name, COUNT(distinct partition_key), AVG (ROS_ROW_COUNT) FROM partitions GROUP BY 1,2,3 having avg(ros_row_count) < 100000 ORDER BY 5; 各テーブルで行が少ない複数のパーティションを持つテーブルの再パーティションを検討してください。 あるいは、これらのテーブルをまったくパーティション化しないでください。
    テーブル定義の変更ができない場合、リソースプールの調整のために Step 10 へ。

    関連詳細情報

    Vertica Troubleshooting Checklists の Database Performance is Slow にて、関連詳細情報が確認できます。