DataWorks:バッチ同期のスロットリング

段階 1：スケジューリングリソースの待機

症状：

• タスクログに、タスクがゲートウェイを待機していることが示されます。

• インスタンスプロパティページに、長いリソース待機時間が表示されます。

原因：スケジューリングリソースグループが最大タスク制限に達しています。新しいタスクは、実行中のタスクが完了してリソースが解放されるまで待機します。

修正：DataWorks コンソールで、実行診断ページに移動し、現在のタスクが待機している間にどのタスクがリソースを使用しているかを確認します。

スケジューリングに共有リソースグループを使用している場合は、タスクを専用リソースグループまたはサーバーレスリソースグループに移行してください。

段階 2：実行リソースの待機

症状：タスクログに wait が表示されます。

原因：データ統合リソースグループに、タスク用の残りの同時実行スロットが不足しています。

例えば、あるリソースグループが最大 8 つの同時実行スロットをサポートしているとします。同時実行数がそれぞれ 3 のタスクが 2 つ実行されている場合、6 つのスロットが使用され、残りは 2 つになります。3 つの同時実行スロットを必要とする 3 番目のタスクは待機する必要があります。

修正：

1. 実行診断ページに移動して、どのタスクがリソースを消費しているかを確認します。

2. 実行中のタスクがスタックしていないか、異常に遅くないかを確認します。もしそうであれば、まずそれらのタスクを停止または解決します。

3. タスクが正常に実行されている場合は、完了してリソースが解放されるのを待ちます。

4. タスクの所有者と調整して、競合するタスクの同時実行数を減らします。

5. 現在のタスクの同時実行数を減らして再送信します。

6. リソースグループをスケールアウトします。詳細については、「スケーリング操作」をご参照ください。

同時実行スロットの最大数は、リソースグループの仕様によって異なります。詳細については、「パフォーマンスメトリックと課金」をご参照ください。

段階 3：データ読み取りの遅延 (高い WaitReaderTime)

症状：タスクログに run が速度 0 で表示されます。詳細ログには WaitReaderTime の値が大きく、タスクがソースからのデータを長時間待機していることを示します。

原因：

• 分割キーが正しく設定されていないため、データ取得の SQL が遅く実行されます。

• where または querySql パラメーターにインデックスが付けられていないため、全表スキャンが発生します。

• 同期時にソースデータベースの負荷が高くなっています。

• ネットワーク帯域幅またはレイテンシの問題。

パブリックネットワーク経由での同期速度は保証できません。

修正：

• データフィルタリングに使用されるフィールドにインデックスを付けて、全表スキャンを回避します。

• pre-SQL または post-SQL 文での複雑な関数の使用を避けるか、減らします。必要な場合は、同期が開始される前にデータベースでこれらの操作を実行します。

• ソーステーブルが非常に大きい場合は、タスクを複数の小さなタスクに分割します。

• ログを照会してブロッキングしている SQL ステートメントを特定し、データベース管理者と協力して解決します。

• 同期時のソースデータベースの負荷を確認します。

段階 4：データ書き込みの遅延 (高い WaitWriterTime)

症状：タスクログに run が速度 0 で表示されます。詳細ログには WaitWriterTime の値が大きく、タスクが宛先への書き込みに長時間かかっていることを示します。

原因：

• writer プラグインの preSql または postSql 文の実行が遅いです。

• 同期時にターゲットデータベースの負荷が高くなっています。

• ネットワーク帯域幅またはレイテンシの問題。

パブリックネットワーク経由での同期速度は保証できません。

修正：

• writer プラグイン設定の preSql および postSql 文を確認し、最適化します。

• 同期時のターゲットデータベースの負荷を確認します。

段階 5：速度はゼロではないが、全体の進捗が遅い

症状：タスクログに run がゼロではない速度で表示されますが、同期ジョブが予想よりもはるかに長くかかります。

原因：

• リレーショナルデータベースタスクの分割キーが設定されていないか、不適切に設定されているため、同時実行数の設定が有効になっていません。タスクは設定された同時実行数ではなく、単一のスレッドで実行されます。

• 同時実行数の設定が低すぎます。

• 同期中に大量のダーティデータが生成されます。

• 設定された同時実行数を維持するのにデータベースのパフォーマンスが不十分です。

• ネットワーク帯域幅またはレイテンシの問題。

パブリックネットワーク経由での同期速度は保証できません。

修正：

1. 分割キーを正しく設定します。設定手順については、「コードレス UI でタスクを設定する」をご参照ください。

2. タスクの同時実行数を増やします。リソースグループでサポートされている最大同時実行数クォータ内で、すべてのタスクにわたって同時実行数を計画し、必要に応じて現在のタスクの同時実行数を増やします。コードレス UI で同時実行数を設定するか、コードエディタで直接設定します。リソースグループの制限については、「パフォーマンスメトリックと課金」をご参照ください。分散タスクの場合は、次のことを確認してください：タスクの同時実行数 ÷ リソースグループ内のマシン数 ≤ マシンごとの最大同時実行数

3. ダーティデータを処理します。詳細については、「Data Integration」をご参照ください。

4. クラウド間またはクロスリージョンの同期にはプライベートネットワークを使用します。ネットワーク接続オプションについては、「ネットワーク接続ソリューション」をご参照ください。

5. 同期時のデータベースの負荷を確認します。

同時実行性と CPU

専用リソースグループでは、同時実行数と vCPU の比率は 1:0.5 です。4 vCPU と 8 GiB のメモリを持つ ECS インスタンスは、8 の同時実行数クォータを提供します。これは、次のことを意味します：

• 最大 8 つのオフライン同期タスク (同時実行数 1)、または

• 最大 4 つのオフライン同期タスク (同時実行数 2)。

新しく送信されたタスクが残りのクォータよりも多くの同時実行数を必要とする場合、実行中のタスクが完了してリソースが解放されるまで待機します。

同時実行性 と メモリ

専用リソースグループでのタスクごとのメモリ使用量は、次の数式に従います：

Min{768 + (concurrency - 1) × 256, 8029} MB

これをオーバーライドするには、コードエディタで $.setting.jvmOption JSON パスを設定します。

"setting": {
    "errorLimit": {
        "record": "0"
    },
    "speed": {
        "throttle": false,
        "concurrent": 1
    },
    "jvmOption": "-Xms1024m -Xmx1024m"
}

タスクを安定させるには、実行中のすべてのタスクが使用する合計メモリが、リソースグループ内のすべてのマシンの合計メモリより少なくとも 1 GB 低く保たれる必要があります。このしきい値を超えると、Linux の OOM Killer がタスクを強制的に停止する可能性があります。

コードエディタでメモリ設定をオーバーライドしない場合、タスク送信を計画する際には同時実行数クォータ制限のみが適用されます。

Writer プラグイン

Reader プラグイン