Compartilhar via

Ajustando e monitorando o desempenho

  • Artigo

É recomendável usar a seguinte abordagem para o desempenho de sincronização:

  • Configuração de cada servidor e banco de dados, além do código do aplicativo, para obter o melhor desempenho

  • Desenvolvimento de linhas de base de desempenho

  • Monitoramento e ajuste para atender ou exceder as linhas de base

Configuração

A primeira etapa do ajuste de desempenho é assegurar que o hardware e o software estejam configurados adequadamente.

Considerações sobre servidores e rede

  • Verifique se cada computador tem um subsistema de E/S adequado e se os arquivos do banco de dados estão alocados corretamente.

    Normalmente, a velocidade de leitura e gravação de alterações em disco é mais importante que a velocidade da rede; assim, um subsistema de E/S adequado é essencial. É recomendável usar várias matrizes de discos RAID e ter uma matriz dedicada no servidor para tempdb, bancos de dados do usuário e logs de transações. O tempdb, os bancos de dados do usuário e os logs de transações devem ser criados em grupos de arquivos separados. Se uma ou mais tabelas de usuário se mostrarem como um afunilamento de processamento, mova-as para grupos de arquivos separados.

  • Considere adicionar memória aos computadores nas topologias de sincronização.

    Isso é especialmente importante para os servidores envolvidos em um grande número de sessões de sincronização simultâneas. Normalmente, as sessões de sincronização envolvem transações demoradas; por isso, é importante ter uma quantidade significativa de memória que possa ser endereçada diretamente pelo banco de dados do servidor. No caso do SQL Server, use a opção /3GB para sistemas de 32 bits ou para mover para um sistema de 64 bits. Para obter mais informações, consulte "Espaço de endereço de processo" nos Manuais Online do SQL Server.

  • Defina a quantidade mínima e máxima de memória alocada para o banco de dados do servidor.

    Por exemplo, por padrão, o Mecanismo de Banco de Dados altera seus requisitos de memória de forma dinâmica de acordo com os recursos do sistema disponíveis. Para evitar baixa disponibilidade de memória durante as atividades de sincronização, use a opção memória mínima do servidor para definir a memória mínima disponível. Para evitar que o sistema operacional busque memória no disco, você também pode definir uma quantidade máxima de memória com a opção memória máxima do servidor. Para obter mais informações, consulte os Manuais Online do SQL Server.

Design de bancos de dados e aplicativos

  • Siga as práticas recomendadas para o design de bancos de dados.

    Em geral, um banco de dados envolvido na sincronização se beneficia das mesmas otimizações de desempenho que qualquer banco de dados semelhante. Para obter mais informações sobre a otimização de bancos de dados, consulte os Manuais Online do SQL Server. Esteja ciente das seguintes considerações sobre índices:

  • Defina valores apropriados para o tempo limite de bloqueio do banco de dados e o tempo limite de consulta.

  • Minimize os conflitos por meio do design de publicação e do comportamento do aplicativo.

    Se possível, os aplicativos devem ser projetados para evitar conflitos, uma vez que sua detecção e resolução adicionam complexidade, processamento e tráfego de rede. As formas mais comuns de evitar conflitos são as seguintes:

    • Atualizar uma tabela em um único nó ou

    • Filtrar dados de forma que apenas um nó atualize um determinado conjunto de linhas. Por exemplo, em um cenário cliente-servidor, você poderia particionar os dados horizontalmente pelos clientes de forma que cada cliente altere apenas uma "fatia" dos dados, como informações de contato de clientes em Washington.

  • Usar a filtragem de forma criteriosa.

    A filtragem de dados é ótima para reduzir conflitos e copiar menos dados em cada nó. Porém, lembre-se que cláusulas de filtragem complexas podem afetar o desempenho. Se um filtro unir muitas tabelas, considere outras formas de implementar a mesma lógica.

  • Cuidado com a lógica de aplicativo em gatilhos e consultas de sincronização.

    A execução de lógica adicional em cada consulta e gatilho pode reduzir significativamente o desempenho.

  • Usar procedimentos armazenados para comandos do banco de dados.

    O Sync Framework usa várias consultas para selecionar e aplicar alterações de dados e metadados durante uma sessão de sincronização. Se você criar essas consultas manualmente, encapsule-as em procedimentos armazenados. Normalmente, isso resulta em melhor desempenho e sustentabilidade, e também pode ajudar a proteger os aplicativos. Se o seu aplicativo exibir o SQL embutido em vez de procedimentos armazenados, use o método Prepare() do ADO.NET para todos os comandos. Isso melhora o desempenho do SQL embutido.

  • Sincronizar apenas os dados necessários em cada nó.

    Pode ser tentador publicar todas ou a maioria das tabelas em um banco de dados, "por via das dúvidas". Evite publicar tabelas que não são realmente necessárias para um aplicativo e sincronize cada nó com menos frequência.

  • Criar escopos e grupos de sincronização apropriadamente e usar o direção de sincronização adequada pra cada escopo.

    Um escopo é um conjunto de tabelas que são sincronizadas como uma unidade. Uma ou mais das tabelas de um escopo podem ser filtradas e as tabelas podem ser incluídas em mais de um escopo. Verifique se os escopos refletem a estrutura e os padrões de uso das tabelas que eles contêm. Considere as quatro tabelas a seguir em um aplicativo da equipe de vendas:

    • Orders e OrderDetails

      As linhas são inseridas nestas tabelas somente em um computador cliente, mas podem ser atualizadas no servidor. As alterações devem ser confirmadas na mesma transação. Estas tabelas devem estar no mesmo escopo, com uma sincronização bidirecional.

    • Pricing

      As linhas são inseridas e atualizadas frequentemente, mas apenas no servidor. Esta tabela e as tabelas semelhante a ela devem estar em um escopo, com uma direção de sincronização somente para download do ponto de vista do cliente.

    • Products

      As linhas são inseridas e atualizadas no servidor com pouca frequência. Provavelmente, esta tabela deveria estar em um escopo separado de Pricing, pois ela não é atualizada com a mesma frequência e pode ser sincronizada com menos frequência.

Dica

A direção de sincronização pode ser alterada para cada sessão, enquanto o escopo persiste nas sessões. Não há uma conexão direta entre escopo e direção de sincronização, mas este exemplo ilustra como se pode considerar os dois ao criar um aplicativo.

  • Para DbSyncProvider, use SelectTableMaxTimestampsCommand para otimizar a enumeração.

    A consulta especificada para esta propriedade seleciona o carimbo de data/hora máximo de cada tabela base ou tabela de controle. Este carimbo de data/hora é usado para determinar se, para cada tabela, o destino já tem todas as alterações da origem. Se o destino já tiver as alterações, muitas vezes o Sync Framework poderá evitar a execução de consultas de enumeração, o que pode melhorar o desempenho.

  • Usar o processamento em lotes para compensar problemas com redes não confiáveis e de pouca memória.

    Por padrão, o Sync Framework entrega alterações para cada nó em um único objeto DataSet. Esse objeto é mantido na memória enquanto as alterações são aplicadas a um nó. O comportamento padrão funciona bem quando há memória suficiente no computador em que as alterações são aplicadas e a conexão com o computador é confiável. Porém, alguns aplicativos podem se beneficiar das alterações divididas em lotes. O processamento em lotes introduz uma sobrecarga adicional, mas pode ser realmente uma vantagem para o desempenho de alguns aplicativos. Para obter mais informações, consulte Como entregar alterações em lotes (SQL Server).

  • Escalonar as agendas de sincronização.

    Se um grande número de nós for sincronizado com um nó central, escalone as agendas para reduzir a pressão na memória e a contenção no nó central. As agendas podem ser baseados no tempo de relógio ou no tempo relativo. Por exemplo, um aplicativo pode ser sincronizado a cada hora ou pode iniciar uma sessão de sincronização uma hora após a conclusão bem-sucedida da última sessão desse nó.

  • Usar agendas de limpeza de metadados apropriadas.

    Grandes quantidades de metadados podem afetar o desempenho das consultas de sincronização.

Linhas de base

Após a configuração da sincronização, é recomendável desenvolver uma linha de base de desempenho, que permite determinar o comportamento da sinconização com uma carga de trabalho típica de seus aplicativos e de sua topologia. Use eventos de sincronização e o Monitor do Sistema para determinar os números típicos das cinco dimensões do desempenho de sincronização a seguir:

  • Latência: o tempo necessário para uma alteração de dados ser propagada entre os nós em uma topologia.

  • Taxa de transferência: a quantidade de atividades de sincronização (medida em linhas entregues em um período) que um sistema pode sustentar ao longo do tempo.

  • Simultaneidade: o número de nós que podem ser sincronizados simultaneamente com um nó específico. Frequentemente, esse é o número de clientes que podem ser sincronizados com um determinado servidor.

  • Duração da sincronização: quanto tempo leva para a conclusão de uma determinada sessão de sincronização.

  • Consumo de recursos: hardware e recursos de rede usados como resultado do processamento da sincronização.

Dependendo do seu aplicativo, algumas dessas medidas de desempenho podem ser mais importantes que outras. Por exemplo, pode ser aceitável ter uma taxa de transferência relativamente baixa, desde que seja possível manter um alto nível de simultaneidade. Ao estabelecer uma linha de base, lembre-se de que o Sync Framework não foi projetado como um sistema servidor a servidor com alta taxa de transferência e baixa latência como a replicação de transação do SQL Server. Ele foi criado para a sincronização cliente a servidor e cliente a cliente que dá suporte a aplicativos de offline e de colaboração.

Depois de estabelecer os números de linha de base, monitore o sistema procurando afunilamentos de desempenho e escalabilidade, e os ajuste conforme necessário.

Monitoramento e manutenção

O monitoramento pode ser usado durante o desenvolvimento de linhas de base de desempenho, periodicamente em ambientes de produção e mais intensivamente caso ocorra um problema de desempenho. As seguintes ferramentas de monitoramento da atividade e do desempenho da sincronização são recomendadas:

  • Eventos de sincronização

    Use os seguintes eventos para determinar quanto tempo as fases específicas estão consumindo:

    • Eventos por tabela em cada provedor: SelectingChanges, ChangesSelected, ApplyingChanges e ChangesApplied

    • Evento por sessão em cada provedor: SyncProgress

    Mantenha o tempo de cada fase na memória e grave os resultados em um arquivo de log ou em um banco de dados de desempenho após o final da sessão de sincronização.

  • SQL Server Profiler

    Use o modelo TSQL_SPs e identifique as consulta mais demoradas que um determinado limite, como 10 segundos. Se você gravar informações de rastreamento em um arquivo de log ou um banco de dados de desempenho, mantenha os dados na memória e execute as gravações após o final da sessão de sincronização.

  • SQL Server Management Studio

    O Management Studio pode ser usado para verificar o plano de consulta de cada consulta de sincronização a fim de assegurar que o plano ideal seja usado.

  • Monitor do Sistema

    Use os seguintes contadores e objetos de desempenho para monitorar as áreas importantes para a sincronização:

    • Contadores sob o SQL Server: Gerenciador de Memória. Por exemplo, você pode verificar se o SQL Server está usando a memória disponível para ele comparando a Memória do Servidor de Destino e a Memória Total do Servidor.

    • Contadores sob PhysicalDisk. Por exemplo, Comprimento Médio da Fila de Leitura de Disco e Comprimento Médio da Fila de Gravação de Disco ajudam a identificar se o desempenho da sincronização está ligado à E/S ou se a memória do computador é insufisiente. Se os comprimentos da fila não foram aceitáveis, adicione memória e atualize ou adicione unidades.

      O padrão é que o contador relate as médias em todas as unidades. Adicione um contador para cada unidade.

    • Contadores sob o SQL Server: Transações. Por exemplo, Transações de Instantâneo e Tamanho do Armazenamento de Versão podem ser usados para determinar se as consultas de enumeração de alteração geram um aumento grande de tempdb. As consultas de enumeração de alteração usam transações de instantâneo, e as informações de versão de instantâneo são armazenadas em tempdb. Um armazenamento de versão grande significa que talvez seja necessário redimencionar tempdb.

    • Contadores sob o SQL Server: Bloqueios. Por exemplo, Tempo de Espera de Bloqueio e Número de Deadlocks podem ser usados para determinar se a contenção é um problema durante a atividade simultânea no banco de dados.

  • Rastreamento da sincronização

    O Sync Framework inclui rastreamento baseado na classe TraceListener. O rastreamento pode ser usado para coletar informações sobre as sessões de sincronização, que podem ser úteis para o monitoramento e a solução de problemas. Porém, lembre-se que o rastreamento gera uma sobrecarga adicional e que deve ser usado principalmente durante o desenvolvimento. Para obter mais informações, consulte Como rastrear o processo de sincronização (este tópico enfoca o DbServerSyncProvider, mas as informações também se aplicam a outros provedores).

Além do monitoramento, é recomendável executar as seguintes tarefas de manutenção periodicamente:

  • Dependendo do nível de desfragmentação, reorganize ou reconstrua os índices nas tabelas base e nas tabelas de metadados.

  • Atualize as estatísticas do índice.

  • Limpe os metadados de sincronização.

Consulte também

Conceitos

Considerações sobre implantação e design de aplicativos