Enquanto conectada ao nosso servidor de produção (SQL Server 2008, máquina muito poderosa), essa instrução SELECT leva 2 segundos , retornando todos os campos (4 MB de dados no total).
SELECT TOP (30000) *
FROM person
WITH(NOLOCK);De qualquer outra caixa na mesma rede (conexão usando autenticação SQL ou autenticação do Windows), a mesma consulta leva 1 minuto, 8 segundos .
Estou testando com esta declaração muito simples para ilustrar que não é um problema de indexação ou relacionado a consultas. (Temos problemas de desempenho com todas as consultas no momento ...)
As linhas vêm em pedaços, e nem todos de uma vez. Recebo minhas primeiras linhas instantaneamente e espero mais de um minuto para que os lotes de linhas entrem.
Aqui estão as estatísticas do cliente da consulta, quando é executada a partir da caixa remota:
Query Profile Statistics
Number of INSERT, DELETE and UPDATE statements 0
Rows affected by INSERT, DELETE, or UPDATE statements 0
Number of SELECT statements 2
Rows returned by SELECT statements 30001
Number of transactions 0
Network Statistics
Number of server roundtrips 3
TDS packets sent from client 3
TDS packets received from server 1216
Bytes sent from client 266
Bytes received from server 4019800
Time Statistics
Client processing time 72441 ms (72 seconds)
Total execution time 72441 ms
Wait time on server replies 0Podemos ver que o "Tempo de processamento do cliente" é igual ao tempo total de execução.
Alguém sabe quais etapas eu posso executar para diagnosticar por que a transferência dos dados reais está demorando muito?
Existe um parâmetro de configuração SQL que restrinja ou limite a velocidade de transferência de dados entre máquinas?
fonte
Respostas:
Seu problema é definitivamente relacionado à rede, com base em suas informações. Como tal, tem que ser tratado com profissionais da rede (não sou eu).
Coisas que podem ajudar:
O servidor da web está na mesma sub-rede que o servidor SQL?
Existem roteadores / pontes etc. entre eles?
Não há muitas alterações possíveis no servidor SQL:
Você está usando um tamanho padrão: consulte suas estatísticas: "Pacotes TDS recebidos do servidor 1216" (4MB / 1K = 4KB). Sim, o tamanho do buffer TDS pode ser alterado: consulte no google: "Tamanho do lote do protocolo TDS"
Boa discussão sobre o tópico: "o tamanho do pacote de rede do sql realmente determina o tráfego de ida e volta?"
No entanto, alterar o tamanho do pacote TDS (inevitavelmente) terá efeitos imprevisíveis e só deve ser usado na produção em casos excepcionais.
A alteração da arquitetura ou a introdução do armazenamento em cache de dados na camada intermediária também ajudaria.
fonte
Este problema está agora resolvido.
Era um problema de rede e a caixa SQL estava usando uma placa NIC de 100 MB / s em vez de uma placa NIC de 10 GB / s ...
Uma alteração na configuração da rede para usar a placa de rede correta corrigiu o problema. Agora estamos obtendo desempenho semelhante para todas as consultas da caixa SQL de produção e de outras caixas na rede.
Obrigado a todos por sua ajuda.
fonte
Na leitura inicial, parece que você está enfrentando alguns problemas de latência da rede. Você já viu alguns dos contadores do Network Perfmon? Isso pode lhe dar alguma indicação do que está acontecendo com a rede.
Citação de Quais balcões de Perfmon devo monitorar e o que cada um deles significa?
fonte
Algumas perguntas preliminares: 1) O servidor possui um cliente SQL no Prod. configuração da máquina do servidor, certo? Então, se você fizer a mesma consulta do cliente localizado na mesma máquina, ela será concluída em 2 segundos? Você tentou fazer isso? São realmente 2 segundos? 2) Você mencionou que a configuração do seu ambiente de produção foi alterada (ou o servidor de produção foi movido para outra rede / reconstrução total do servidor), certo? Qual foi o tempo de consumo da consulta no antigo ambiente de produção?
Por curiosidade: este é um exemplo da consulta? ou redação exata da consulta? A consulta NÃO contém realmente a cláusula WHERE? Concordo comigo que isso é muito incomum .. A tabela possui um índice em cluster ou é um Heap? A tabela contém quantas linhas no total? A tabela está muito fragmentada? Por curiosidade: por que SELECT TOP NNN? Por que não SET ROWCOUNT NNN - depois SELECT *? Esta consulta é emitida quantas vezes pelo cliente por dia? 1? 100? 1MLN? Os dados subjacentes são estáticos ou dinâmicos e são muito alterados? Quanto (0,01% ao dia? 1% ao dia? 10% ao dia?) A saída da consulta é processada programaticamente? (não por um usuário?) Por que não é armazenado em cache / não é armazenado na camada intermediária? obrigado Alexei
fonte