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

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

症状：

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

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

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

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

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

ステージ 2：実行リソースの待機

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

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

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

修正：

1. 運用分析ページに移動し、どのタスクがリソースを消費しているかを確認します。

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

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

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

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

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

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

ステージ 3：データ読み取りの低速化 (高い WaitReaderTime)

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

原因：

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

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

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

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

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

修正：

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

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

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

• ログをクエリしてブロッキングしている SQL 文を特定し、データベース管理者と協力して解決します。

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

ステージ 4：データ書き込みの低速化 (高い WaitWriterTime)

症状： タスクログに速度 0 の run が表示されます。詳細ログ には 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 の同時実行数クォータを提供します。これは次のことを意味します。

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

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

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

並行性とメモリ

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

Min{768 + (同時実行数 - 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 プラグイン