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

Estágio 1: Aguardando recursos de agendamento

Sintomas:

• O log da tarefa indica que ela está aguardando o gateway.

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

Causa: O resource group 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: No console do DataWorks, acesse a página Run diagnostics para verificar quais tarefas consomem recursos enquanto a tarefa atual aguarda.

Se você utiliza shared resource groups para agendamento, migre suas tarefas para um exclusive resource group ou um Serverless resource group.

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

Sintoma: O log da tarefa exibe wait.

Causa: O resource group de integração de dados não possui slots de concorrência restantes suficientes para a tarefa.

Por exemplo: um resource group 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 Run diagnostics para identificar quais tarefas consomem recursos.

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

3. Se as tarefas estiverem executando normalmente, aguarde sua conclusão e a liberação dos 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 reenvie-a.

6. Escale horizontalmente o resource group. Para mais informações, consulte Operações de escalonamento.

O número máximo de slots concorrentes varia conforme a especificação do resource group. Para mais detalhes, consulte Métricas de desempenho e faturamento .

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

Sintoma: O log da tarefa mostra run com velocidade igual a 0. O Detail log apresenta um valor alto 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 full table scan.

• O banco de dados de origem está sob alta carga durante a 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 full table scans.

• 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.

• Se a tabela de origem for 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 elevado)

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

Causas:

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

• O banco de dados de destino está sob alta carga durante a 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 writer.

• 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 mostra 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 foi configurada ou está incorreta, invalidando a configuração de concorrência. 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 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 UI codeless.

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

3. Trate dirty data. Para mais informações, consulte Data Integration.

4. Use uma rede privada para sincronização entre clouds ou 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.

Concorrência e CPU

Em um exclusive resource group, 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 nova tarefa 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 exclusive resource group 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.

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

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 resource group. Se esse limite for ultrapassado, 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 Writer

Plug-ins Reader