Clever Geek Handbook

HPE Verticaのストレスとの戦い

データウェアハウスの典型的な「ジャストインタイム」シナリオは次のようになります。数十（ETL）のセッションがソースからデータをほぼ継続的にキャプチャし、ストレージに挿入します。 並行して、他の多くの（ELT）セッションがデータのフローを追跡し、統合されたレイヤーに記入し、集計とストアフロントを計算します。 同時に、ユーザー、BI、およびその他のシステムは、受信したプライマリデータおよび計算データに関する要求を満たします。 このおridgeはすべて、ピーク時の負荷に関係なく、ブレーキやプラグなしでデータウェアハウスサーバー内で適切に調理する必要があります。



HPE Verticaでは、負荷のかかったサーバーをスケジュールするために、リソースプールと呼ばれる特別なメカニズムが開発されました。 そのアイデアは、各サーバーユーザーが専用のリソースプール内で作業し、クラスターリソースへのアクセスの優先順位を調整し、クエリ実行の競争力を制限し、予約とサーバーメモリの操作のルールを記述することです。



デフォルトでは、作成されたデータベースにVerticaサーバーをインストールすると、次のようになります。











クラスターの各サーバー（ノード）で、Verticaが使用できるメモリは、一般リソースプールとして指定されます。 さまざまなサーバーのニーズに応じて、サービスプールが自動的に作成され、それ自体でメモリの一部がGeneralから切り離されます。





デフォルトでは、サーバーユーザーは一般プール自体の制御下でスピンします。 現在の設定を確認できます： 



dbadmin=> SELECT * FROM resource_pools WHERE name = 'general'; -[ RECORD 1 ]------------+------------------ pool_id | 45035996273721212 name | general is_internal | t memorysize | maxmemorysize | 30G executionparallelism | AUTO priority | 0 runtimepriority | MEDIUM runtimeprioritythreshold | 2 queuetimeout | 00:05 plannedconcurrency | 10 maxconcurrency | 20 runtimecap | singleinitiator | f cpuaffinityset | cpuaffinitymode | ANY cascadeto |


いくつかのパラメーターを解読します。





このような「デフォルト」設定は、Vertica操作ブレーキに対してほぼ100％の保証を提供します。





悲しみを助けましょう： 



 ALTER RESOURCE POOL general PLANNEDCONCURRENCY 60 MAXCONCURRENCY 10;


現在、各セッションは、リクエストの開始時に、プールに0.5 GBが割り当てられ、合計で最大10セッションを同時に実行できます。 10セッションの開始時に、5 GBのプールメモリが使い果たされ、さらに25 GBが、大量のリクエストや他のリソースプールへのメモリ割り当て用の予約として残ります。



MAXCONCURRENCYパラメーターに注意してください-値が小さいほど、クエリの動作が速くなります。 各ハードウェアには負荷制限があり、それを超えると、すべてが「利害関係」になります。 競争力が高いほど、プロセッサとディスクアレイの負荷が大きくなり、速度が低下します。 20個の要求を同時に実行するよりも、10個の要求を完了してからキューから次の10個の要求を実行する方が効率的です。 当然、MAXCONCURRENCYは主に、プールの問題を解決するために設定されたタスクとクラスターの鉄の特性に依存します。タスクは制限を特定し、それを制限のすぐ下に設定することです。 。



それでは、プールはどうですか？ これまでのところ、Generalのみを設定しましたが、ユーザーをそこに留めることは実際には悪い習慣です。 ユーザータスクグループのサンプルプールを作成しましょう。 



 --    CREATE RESOURCE POOL writers MEMORYSIZE '2G' MAXMEMORYSIZE '10G' PLANNEDCONCURRENCY 10 MAXCONCURRENCY 10 PRIORITY -50 RUNTIMECAP '3 MINUTE' RUNTIMEPRIORITYTHRESHOLD 0; --      CREATE RESOURCE POOL slowly MEMORYSIZE '0%' MAXMEMORYSIZE '20G' MAXCONCURRENCY 7 RUNTIMEPRIORITY LOW QUEUETIMEOUT '15 MINUTE' RUNTIMEPRIORITYTHRESHOLD 0; --    CREATE RESOURCE POOL readers MEMORYSIZE '4G' MAXMEMORYSIZE '10G' PLANNEDCONCURRENCY 20 MAXCONCURRENCY 10 RUNTIMECAP '5 MINUTE' PRIORITY 50 RUNTIMEPRIORITYTHRESHOLD 3 CASCADE TO slowly;


一般的な「体重減少」があります：









私たちは何をしましたか：



  1. 長い重いリクエストを読んでそれを実行するセッション・スクイーラーのグループに散らばっています。
  2. リーダーとライターのプールに初期メモリを割り当てたため、ほとんどの短いクエリでは、Generalと交換することなく、プールの予約プールからすぐにメモリが取得されました。
  3. 重いリクエストのプールにメモリを割り当てませんでした。それでも、彼のセッションは多くのメモリを必要とし、それらのために予約します。貴重なメモリをGeneralから切り離します。それは意味がありません。
  4. LOW実行では、重い要求プールを低い優先度に設定します。
  5. ライターとリーダーのプールでは、リソースへのアクセスに優先順位が付けられているため、MEDIUM実行の優先順位に従って、ライタープールは部外者（優先順位50）、一般プールは中央（優先順位0）、リーダーのプールはこれらのプール（優先順位50）よりも高くなりました。
  6. プールの競争力の値を合理的に設定します。同時に、ライターからの10リクエスト、リーダーからの10リクエスト、および7重いリクエストを実行できます。
  7. ユーザーがリーダープールで大量のリクエストを起動した場合（5分以上続く場合）、そのようなリクエストが重いリクエストプールにカスケードされることを示しました。 これにより、長いリクエストを実行する際にリーダープールがクリープしないようにします。これにより、競合他社の実行スロットが詰まり、クイックリクエストキューからの実行パイプラインが遅くなります。 ライターのプールでは、クエリ実行制限が3分以内に設定されていたため、最適化されていない挿入または更新データ要求が失敗する可能性がありました。
  8. 大量の要求プールの場合、キューのタイムアウトは15分でした。 プール内のすべての競合スロットがビジーの場合、15分間待機した後、キューに入れられた要求はエラーで終了します。 これにより、サーバーがハングしていないことがユーザーに明確になりますが、単にプール内ですべてがビジーであることがわかります。
  9. リーダープールの場合、3秒の時間を設定します。その間、起動後のリクエストはリソースに対して最も高い優先度を持ちます。 これにより、短いリクエストをすばやく実行し、プール内のスペースを他のリクエスト用に解放できます。


これで、必要なプールをユーザーに割り当て、ジョブが完了しました。 



 ALTER USER user_writer RESOURCE POOL writers; ALTER USER user_reader RESOURCE POOL readers; ALTER USER user_analytical RESOURCE POOL slowly RUNTIMECAP '1 HOUR' TEMPSPACECAP '10G';


ここでは、プールに加えて、user_analyticalユーザーはクエリで1時間に制限されており、TEMPで使用できるスペースは10 GB以下です。



記事の上記はすべて「どこを掘る」アクションであり、「構成するもの」の例ではないことに注意してください。 リソースプールの数と数、特性を指定します。これらはすべてユーザーが決定する必要があります。 小規模に開始できます。たとえば、同様の3つのプールを作成し、クラスターの負荷を調べて、プールのパラメーターを徐々に調整し、異なるプールのユーザーグループを強調表示します。 覚えておくべき主なことは：



  1. 一般プールは、すべてのプールに共通のメモリの保管場所であり、ユーザーセッションに直接使用しないことをお勧めします
  2. 競合他社が少ないほど、ピーク負荷での鉄の沈下率が低くなります
  3. すべてのプールの最大許容メモリの合計は、一般のメモリと重複しないようにする必要があります


More articles:


All Articles