DataWorks:Limitar a velocidade da sincronização em lote

Estágio 1: Aguardando recursos de agendamento

Sintomas:

• O log da tarefa indica que ela aguarda o gateway.

• A página de propriedades da instância exibe um longo tempo de espera por recursos.

Causa: O grupo de recursos de agendamento atingiu seu limite máximo de tarefas. Novas tarefas aguardam até que as tarefas em execução sejam concluídas e liberem recursos.

Solução: Acesse a página Operation Analysis para verificar quais tarefas consomem recursos enquanto a tarefa atual aguarda.

Se você utiliza grupos de recursos compartilhados para agendamento, migre suas tarefas para um grupo de recursos exclusivo ou um grupo de recursos Serverless.

Estágio 2: Aguardando recursos de execução

Sintoma: O log da tarefa exibe wait.

Causa: O grupo de recursos do Data Integration não possui slots de concorrência restantes suficientes para a tarefa.

Por exemplo: um grupo de recursos suporta no máximo 8 slots concorrentes. Se duas tarefas estiverem em execução com concorrência de 3 cada, elas ocupam 6 slots e restam 2 disponíveis. Uma terceira tarefa que necessite de 3 slots concorrentes precisará aguardar.

Solução:

1. Acesse a página Operation Analysis para identificar quais tarefas consomem recursos.

2. Verifique se alguma tarefa em execução está travada ou anormalmente lenta. Nesse caso, pare-a ou resolva o problema primeiro.

3. Se as tarefas executarem normalmente, aguarde a conclusão delas para liberar recursos.

4. Coordene com os responsáveis pelas tarefas para reduzir a concorrência das tarefas concorrentes.

5. Reduza a concorrência da tarefa atual e envie-a novamente.

6. Escale horizontalmente o grupo de recursos. Para mais informações, consulte Operações de dimensionamento.

O número máximo de slots concorrentes varia conforme a especificação do grupo de recursos. Para mais informações, consulte Métricas de desempenho e faturamento .

Estágio 3: Leitura de dados lenta (WaitReaderTime alto)

Sintoma: O log da tarefa exibe run com velocidade 0. O Detail log mostra um valor elevado para WaitReaderTime, indicando que a tarefa aguarda dados da origem por muito tempo.

Causas:

• A chave de divisão não está configurada corretamente, tornando lenta a execução do SQL de recuperação de dados.

• Os parâmetros where ou querySql não possuem índice, resultando em varredura completa da tabela (full table scan).

• O banco de dados de origem está sob alta carga no momento da sincronização.

• Problemas de largura de banda ou latência de rede.

Não é possível garantir a velocidade de sincronização pela rede pública.

Solução:

• Crie índices nos campos usados para filtragem de dados a fim de evitar varreduras completas de tabela.

• Evite ou reduza funções complexas nas instruções pre-SQL ou post-SQL. Se necessário, execute essas operações no banco de dados antes do início da sincronização.

• Caso a tabela de origem seja muito grande, divida a tarefa em várias tarefas menores.

• Consulte os logs para identificar a instrução SQL causadora do bloqueio e trabalhe com o administrador do banco de dados para resolvê-la.

• Verifique a carga do banco de dados de origem no momento da sincronização.

Estágio 4: Gravação de dados lenta (WaitWriterTime alto)

Sintoma: O log da tarefa exibe run com velocidade 0. O Detail log mostra um valor elevado para WaitWriterTime, indicando que a tarefa demora muito para gravar no destino.

Causas:

• As instruções preSql ou postSql no plug-in de gravação (writer) apresentam execução lenta.

• O banco de dados de destino está sob alta carga no momento da sincronização.

• Problemas de largura de banda ou latência de rede.

Não é possível garantir a velocidade de sincronização pela rede pública.

Solução:

• Revise e otimize as instruções preSql e postSql na configuração do plug-in de gravação.

• Verifique a carga do banco de dados de destino no momento da sincronização.

Estágio 5: Velocidade diferente de zero, mas progresso geral lento

Sintoma: O log da tarefa exibe run com velocidade diferente de zero, mas a tarefa de sincronização leva muito mais tempo do que o esperado.

Causas:

• A chave de divisão para uma tarefa de banco de dados relacional não está configurada ou está configurada incorretamente, tornando a configuração de concorrência ineficaz. A tarefa executa com uma única thread em vez da concorrência configurada.

• A configuração de concorrência está muito baixa.

• Um grande volume de dados incorretos (dirty data) é gerado durante a sincronização.

• O desempenho do banco de dados é insuficiente para sustentar a concorrência configurada.

• Problemas de largura de banda ou latência de rede.

Não é possível garantir a velocidade de sincronização pela rede pública.

Solução:

1. Configure a chave de divisão corretamente. Para etapas de configuração, consulte Configurar uma tarefa na interface sem código.

2. Aumente a concorrência da tarefa. Dentro da cota máxima de concorrência suportada pelo grupo de recursos, planeje a concorrência entre todas as tarefas e aumente a concorrência da tarefa atual conforme necessário. Configure a concorrência na interface sem código ou defina-a diretamente no editor de código. Para limites de grupos de recursos, consulte Métricas de desempenho e faturamento. Para tarefas distribuídas, garanta que: concorrência da tarefa ÷ número de máquinas no grupo de recursos ≤ concorrência máxima por máquina

3. Trate os dados incorretos. Para mais informações, consulte Data Integration.

4. Use uma rede privada para sincronização entre nuvens ou entre regiões. Para opções de conectividade de rede, consulte Soluções de conectividade de rede.

5. Verifique a carga do banco de dados no momento da sincronização.

"setting": {
  "speed": {
    "throttle": true,  // Set to true to enable rate limiting.
    "mbps": 1          // The rate limit in MB/s.
  }
}

JobContainer - Job set Channel-Number to 2 channels

Concorrência e CPU

Em um grupo de recursos exclusivo, a proporção entre concorrência e vCPU é de 1:0,5. Uma instância ECS com 4 vCPUs e 8 GiB de memória fornece uma cota de concorrência de 8. Isso significa:

• Até 8 tarefas de sincronização offline com concorrência de 1, ou

• Até 4 tarefas de sincronização offline com concorrência de 2.

Se uma tarefa recém-enviada exigir mais concorrência do que a cota restante disponível, ela aguardará até que as tarefas em execução sejam concluídas e liberem recursos.

Concorrência e memória

O uso de memória por tarefa em um grupo de recursos exclusivo segue esta fórmula:

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

Substitua essa configuração no editor de código definindo o caminho JSON $.setting.jvmOption.

Para manter a estabilidade das tarefas, a memória total usada por todas as tarefas em execução deve permanecer pelo menos 1 GB abaixo da memória total de todas as máquinas no grupo de recursos. Se esse limiar for excedido, o Linux OOM Killer poderá encerrar tarefas forçadamente.

Se você não substituir as configurações de memória no editor de código, apenas o limite da cota de concorrência será aplicado ao planejar o envio de tarefas.

Plug-ins de gravação (Writer)

Plug-ins de leitura (Reader)