white cloud in vault type room representing cloud computing
データベースカタログには、テーブル、プロジェクション、ユーザー、ノード、ROSなどのメタデータが含まれています。 カタログには2種類のオブジェクトがあります。
ノード起動時に、カタログはメモリ上にキャッシュされます。
| ステップ | タスク | 結果 |
|---|---|---|
| 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; |
カタログサイズが大きく、オブジェクトが多数ある場合、不要なオブジェクトを減らすことを検討してください。次の方法でオブジェクトを削減できます。
オブジェクトが多くない場合、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 にて、関連詳細情報が確認できます。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!
