目次
はじめに
ROSコンテナが上限値に達した場合は、以下のエラーが発生します。<ERROR> @v_rebodb_node0001: 53000/5065: Too many ROS containers exist for the following projections:
public.TEST1_super (limit = 65550, ROS files = 65500, DV files = 50, new files = 60)
public.TEST1_super (limit = 65550, ROS files = 65500, DV files = 50, new files = 60)
public.TEST1_super (limit = 65550, ROS files = 65500, DV files = 50, new files = 60)
public.TEST1_super (limit = 65550, ROS files = 65500, DV files = 50, new files = 60)
本記事では、ROSコンテナが上限値に達した場合のトラブルシューティングをご紹介します。
原因
各プロジェクション毎のROSコンテナ(※1)の上限値は、デフォルトで1024です。データが更新された場合は、新しくROSコンテナは作成されますが、 10分間隔で、Touple MoverがMergeout(※2)を行い、既存のROSコンテナへマージされます。
しかし、多数の更新処理によって、Mergeoutが実行される10分の間に多くのROSコンテナが作成され、 上限値を超えてしまうと[too many ROS containers]エラーが発生します。
具体的には、以下の様なケースが挙げられます。
・多数の更新処理(COPY、INSERT、DELETE、UPDATE)を短時間で繰り返して実行している
・多数のパーティションを作成しているテーブルで、多くのパーティションを対象として更新処理を行っている
・多数のパーティションを作成しているテーブルで、多くのパーティションを対象として更新処理を行っている
※1 ROSコンテナの詳細は、以下の記事をご参照ください。
・Verticaのデータ格納方法（WOSとROS）
http://vertica-tech.ashisuto.co.jp/vertica-hybrid-data-store/
※2 Mergeoutの詳細は、以下の記事をご参照ください。
・MoveoutとMergeout
http://vertica-tech.ashisuto.co.jp/moveout-mergeout
対処方法
対処方法は以下が考えられます。①何もしない（経過観察）
②複数回のSQLを一回のSQLにまとめる
③対象テーブルのパーティション数を減らす
④更新処理中、定期的に手動でMergeoutを実行する
⑤Mergeout実行間隔を短くする(設定変更)
⑥一時的にROSコンテナの上限値を増やす(設定変更)
各対処方法の説明やメリット・デメリットは、以下のとおりです。
| 対処方法 | 説明 |
|---|---|
| ①何もしない（経過観察） | エラー発生が一度きりの場合は、様子をみることも選択肢として挙げられる。 メリット：作業工数が発生しない。 デメリット：更新処理が多数行われた場合、エラーが再発する可能性が考えられる。 |
| ②複数回の更新処理を一回のSQLにまとめる | エラーが発生した処理が、ループ処理等でSQLを複数実行している場合、一回のSQLにまとめることで、生成されるROSコンテナの数を抑えられる。 メリット：他処理へのパフォーマンス影響なく対処が出来る。 デメリット：バッチ処理の改修等の工数がかかる。 |
| ③対象テーブルのパーティション数を減らす | エラーが発生したテーブルにて、パーティションを多数作成している場合に有効。 パーティション1つにつきROSコンテナが1つ確保される仕様のため、パーティション数を減らすことで、常に確保されるROSコンテナ数を減らす。 メリット：データ挿入時に生成できるROSコンテナ数の許容数が増えることで、エラー発生の可能性を減らすことが出来る。 デメリット：テーブル構造を変更する必要がある。 |
| ④更新処理中、定期的に手動でMergeoutを実行する | 自動Mergeoutが行われる10分の間に手動Mergeoutを実行することで、ROSコンテナ数が上限値に達することを防ぐ。 メリット：Verticaのコマンド実行による対応のため、SQLの改修に比べて、容易に対応が出来る。 デメリット：都度対応が必要である。 |
| ⑤Mergeout実行間隔を短くする(設定変更) | 自動Mergeoutが行われる間隔を、デフォルトの10分間から短くし、ROSコンテナ数が上限値に達する前にMergeoutが実行されるようにする。 メリット：一度の設定変更のみで対応可能である。 デメリット：Mergeoutの頻度が増えることで、全体へのパフォーマンス影響が考えられる。 |
| ⑥処理実行時、一時的にROSコンテナの上限値を増やす(設定変更) | 処理実行時、ROSコンテナの上限値を、デフォルトの1024から一時的に引き上げることで、エラーを発生させないようにする。 メリット：エラーの発生を確実に回避できる。 デメリット：バッチ処理に組み込む等の工数がかかる。上限値変更中は全体へのパフォーマンス影響が考えられる。 |
上記の対処方法の中で、③～⑥は他処理への影響が考えられるため、可能であれば①～②で対応することをお薦めします。
本記事では、③～⑥の対処方法を説明します。
③対象テーブルのパーティション数を減らす
パーティション単位を日付で設定している等で、参照頻度の低いデータも細かくパーティション分けしている場合は、階層的なパーティション管理を使用し、参照頻度の低い過去のデータは大きなパーティションとして纏めることが出来ます。パーティション数を減らすことで、ROSコンテナの最低確保数を少なくすることが出来ます。階層的なパーティション管理の設定方法については、以下の記事をご確認ください。
・階層的なパーティション管理(Vertica9.0新機能)
http://vertica-tech.ashisuto.co.jp/hierarchical_partitioning
④更新処理中、定期的に手動でMergeoutを実行する
Mergeoutの手動実行については、以下の記事をご確認ください。・MoveoutとMergeoutの手動実行
http://vertica-tech.ashisuto.co.jp/moveout_mergeout_manual
⑤Mergeout実行間隔を短くする
制御パラメータ[MergeOutInterval]の値を小さくすることで、自動Mergeoutの頻度を増やします。以下の手順で対応します。Step1：[MergeOutInterval]設定値の確認
Step2：設定値の変更
Step3：変更後の設定値確認
Step1：[MergeOutInterval]設定値の確認
以下のコマンドで、MergeOutIntervalの設定値を確認します。|
1 2 3 4 5 |
SQL=> select get_config_parameter('MergeOutInterval'); get_config_parameter ---------------------- 600★ (1 row) |
MergeOutIntervalは、600秒(10分)であることが分かります。
Step2：設定値の変更
以下コマンドで、MergeOutIntervalを変更します。この例では300秒(5分)に短縮しています。|
1 |
SQL=> select set_config_parameter('MergeOutInterval','300'); |
※短縮する時間の目安はないため、少しずつ減らしながら他処理への影響がないかご確認ください。
Step3：変更後の設定値確認
Step2で変更した値が反映されていることを確認します。|
1 2 3 4 5 |
SQL=> select get_config_parameter('MergeOutInterval'); get_config_parameter ---------------------- 300 (1 row) |
⑥処理実行時、一時的にROSコンテナの上限値を増やす
制御パラメータ[ContainersPerProjectionLimit]の値を大きくすることで、ROSコンテナの上限値を上げることができます。データ更新時、一時的に設定変更することで、エラーが発生しないようにします。なお、ROSコンテナの上限値を増やした場合、カタログのメモリサイズが大きくなってしまい、 具体的に、以下のようなデータベース操作が遅くなる可能性があります。
・データベース起動
・システム・テーブルのSELECT実行
・データベース・バックアップ
・リカバリ
・システム・テーブルのSELECT実行
・データベース・バックアップ
・リカバリ
そのため、一時的な設定値変更にてご対応いただくことをお勧めします。
以下の手順で対応します。
Step1：現在のROSコンテナの上限値を一時的に変更
Step2：更新処理を実行
Step3：処理を行ったプロジェクションに対して、手動Mergeoutを実行
Step4：ROSコンテナの上限値をデフォルトに変更
Step1：現在のROSコンテナの上限値を一時的に変更
本記事では、一時的にROSコンテナの上限値を2000に変更する手順をご案内します。なお、変更する上限値について、推奨値はございません。可能な限りデフォルトに近い方が他への影響が少ないことが考えられます。小さな値から徐々に増やし、対象の処理が正常に実行できる値を確認してください。
|
1 2 3 4 5 6 7 8 |
/*現在のROSコンテナの上限値を確認*/ SQL=> select get_config_parameter('ContainersPerProjectionLimit'); /*現在のROSコンテナの上限値を一時的に2000に変更*/ SQL=> select set_config_parameter('ContainersPerProjectionLimit', 2000); /*変更後のROSコンテナの上限値を確認*/ SQL=> select get_config_parameter('ContainersPerProjectionLimit'); |
Step2：更新処理を実行
Step1にて上限値変更後、更新処理を実行します。Step3：更新処理を行ったプロジェクションに対して、手動Mergeoutを実行
存在するROSコンテナ数がデフォルト値(1024)よりも多い場合、上限値をデフォルトに戻せません。そのため、対象の処理完了後、手動でMergeoutを実行します。|
1 |
SQL=> select do_tm_task('mergeout','<プロジェクション名>'); |
プロジェクションのROSコンテナ数の現在値を確認する方法は、以下の記事で説明しています。ご確認ください。
・MoveoutとMergeoutの手動実行
http://vertica-tech.ashisuto.co.jp/moveout_mergeout_manual
Step4：ROSコンテナの上限値をデフォルトに変更
ROSコンテナの上限値をデフォルトに戻します。|
1 2 3 4 5 6 7 8 |
/*現在のROSコンテナの上限値を確認*/ SQL=> select get_config_parameter('ContainersPerProjectionLimit'); /*現在のROSコンテナの上限値をデフォルトに変更*/ SQL=> select set_config_parameter('ContainersPerProjectionLimit', 1024); /*変更後のROSコンテナの上限値を確認*/ SQL=> select get_config_parameter('ContainersPerProjectionLimit'); |
