SQL Server extremamente lento em Xenserver

[Beto]

Pessoal, tenho o seguinte ambiente:

-Servidor físico HP Proliant G7 com 64gb de memória + 32 cores e discos sas de 15k em raid 5 totalizando 3,9tb de espaço físico

Neste servidor, tenho um xenserver 5.6 SP2 com todas as atualizações instaladas

Criei um win server 2k8 R2 com 8gb de memoria, 4 cores + 2 discos virtuais, 80gb para o SO + 600gb para o SQL Server 2k8 com todos os SPs instalados

Até ai tudo certo, porém minha equipe de desenvolvimento vem reclamando constante de lentidão para consulta, restore e qualquer tipo de teste que envolva a conexão remota com este banco, independente do terminal de origem chegando a dar timeout algumas vezes.

Pelas ferramentas de monitoramento não encontro nada que esteja causando esta lentidão, meu DBA não encontrou nada no banco que também esteja causando tal lentidão, o bixo tá me deiando maluco já, e com aquele velho discurso de DBA que virtualizar servidor de banco nao dá certo...

Outro fato que aconteceu hoje, um desenvolvedor estava conectado remotamente via mgmt studio no banco para realizar um restore, deu o start e o banco nao respondia, fui acionado e assim que loguei via TS no servidor, SEM REALIZAR NENHUMA AÇÃO, o restore se deu inicio. 

To ficando maluco já com esse problema, neste mesmo xenserver tenho mais 1 máquina com SQL + outros servidores de aplicação, ontem tive um problema com este outro servidor de SQL, ficou um patch de framework amarrado que não terminava por mais de 2h, entao o DBA baixou o serviço de SQL do outro servidor virtual neste xen e o patch rodou..muito estranho.

Se alguem puder me ajudar, que ja tenha passado por algo parecido ou que tenha alguma idéia do que verificar eu agradeço.

[Amado Tairone]

Eu tive este problema com o mysql e apenas removi a resolução de nomes(DNS) de seu conf. Ficou normalizado. Ele tentava resolver os nomes mesmo o acesso sendo em  rede local.

Espero ter ajudado.

--
--
Você recebeu esta mensagem porque está inscrito em Grupo "xen-br" do Grupos Google.
Para enviar mensagens para este grupo, envie um email para xen...@googlegroups.com
Para anular a inscrição neste grupo, envie um email para xen-br-un...@googlegroups.com
Para mais opções, visite este grupo em http://groups.google.com/group/xen-br?hl=pt-BR
Site do GU Xen-BR: http://www.xen-br.org
Antes de enviar sua primeira mensagem leia atentamente as regras para participação no site http://groups.google.com/group/xen-br/web/regras?hl=pt-BR
 
---
Você está recebendo esta mensagem porque se inscreveu no grupo "xen-br" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para xen-br+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Marcelo Busana]

Exato no Mysql tem uma config para não resolver nomes de conexões.

Outra situação que vc pode analisar é a memoria ram, 8gb pode ser pouco para um banco de dados grande, haja visto que voce colocou 600gb para partição dele presumo que talvez vc tenha um banco grande.

No MySQL memoria RAM com uma boa configuracao de caches ajuda muito pois diminui o acesso a disco. Acredito que no SQL Server tbm.

[Beto]

Obrigado pelas dicas.

Não sou eu que mexo no BD, vou falar com o DBA verificar a respeito da resolução de nomes, se tem algo no banco a ser verificado a respeito disso amanhã, vou verificar também no servidor a respeito da resolução de nomes das estações que se conectam a ele..

Marcelo, eu já dobrei a RAM do servidor, deixei em 16gb por 1 semana, o DBA realocou memória no SQL para 10gb e mesmo assim continuou lento. 

Só espero que não seja algo do xen pois vai dar um trabalhão migrar todas as VMs dele e formatá-lo.

abs

[Tiago Ribeiro]

Em 20/05/2013, às 20:40, Beto <alberto....@gmail.com> escreveu:

> Obrigado pelas dicas.
>
> Não sou eu que mexo no BD, vou falar com o DBA verificar a respeito da resolução de nomes, se tem algo no banco a ser verificado a respeito disso amanhã, vou verificar também no servidor a respeito da resolução de nomes das estações que se conectam a ele..
>
> Marcelo, eu já dobrei a RAM do servidor, deixei em 16gb por 1 semana, o DBA realocou memória no SQL para 10gb e mesmo assim continuou lento.
>
> Só espero que não seja algo do xen pois vai dar um trabalhão migrar todas as VMs dele e formatá-lo.
>
> abs
>

Alberto, por mais que você tenha passado bastante informação, não custa perguntar, esta vm está com xentools?
Outra coisa, as outras vms neste servidor não estão apresentando nada de lentidão? Como está o acesso a disco do dom0?
Tive um 2008 (foudation) que dava umas loucuras, só que o problema era um aplicativo antigo que tinha que rodar com realtime, caso contrario o sistema todo ficava travando.

[Beto]

Oi Tiago,

Sim, está com o xentools instalado, atribuí uma placa com dupla conexão, aquele bond que o xen oferece, e aparece 2gb na placa do servidor.

Neste mesmo xen tenho + 3 win XP x64 + 1 XP x86 + 2 win server 2003 com SQL também

Nunca tive problemas nas outras máquinas, a unica coincidencia que ocorreu foi no domingo, ao aplicar patch nos servidores uma das maquinas server 2k3 ficou travada no update ate que parei o serviço do sql neste servidor 2008 com problema.

[Gunther Boeckmann]

Cara você conseguiu detectar onde está o problema exatamente, se no processamento, se na resposta de rede ou no acesso ao Disco? Rodasse o Performance Monitor do Windows para verificar onde está essa lentidão?

Gunther

[Beto]

Gunther, não conseguí detectar, por isso estou pedindo ajuda para o pessoal do forum :) 

No performance monitor tanto do servidor quanto do sql nenhuma atividade anormal é detectada, a resposta de rede está ok segundo minha ferramenta de monitoramento, o acesso ao disco também, tempo de resposta satisfatório. Esse servidor foi criado há 3 meses somente, muito estranho este comportamento dele.

[Alexandre Trevizoli]

Faz um teste de dentro da vm de velocidade de acesso a disco usando o crystalmark. Posta o resultado.
Testa no c: e depois na partição do sql.

[Artur Bjega]

Cara,

Eu sofri, problema similar ao que está acontecendo, em um equipamento DELL com 128gb de memória + 32 cores e storage EMC 6,9tb.


Meu problema foi resolvido com a troca da controladora de disco, ela estava abrindo falha quando se utilizava mais de 90% da sua capacidade (Trocaram Controladora e Fibra), e não estava retornando para o equipamento a falha, somente quando por obra no nosso Senhor Jeova, ao expulsar do local o cacique que foi enterrado em baixo do Datacenter, risos, a falha baixava é que os processos voltavam a rodar perfeitamente.

Em 20 de maio de 2013 18:29, Amado Tairone <amado...@gmail.com> escreveu:

--

Artur Soares Bijega
Fone (41) 8415-0771

[Gunther Boeckmann]

Cara me desculpa, mas se você diz que a VM está lenta, algum recurso está demorando a responder. Sugiro pegar a documentação da Microsoft para verificar os indicadores de performance adequados.
Se realmente estiver tudo bem, então o problema não é o SO nem o hardware virtual, mas deve ser no serviço SQL (alguma configuração?atualização?) ou também pode ser em alguma variável externa, como a rede (IP duplicado? portas HalfDuplex? linkAggregation? vírus de DoS?), resolução de nome, sincronização de tempo (NTP) etc.

Boa sorte!!

Gunther

[Beto]

Seguem resultados nos 2 drives do servidor:

-----------------------------------------------------------------------

CrystalDiskMark 3.0.2 x64 (C) 2007-2013 hiyohiyo

                           Crystal Dew World : http://crystalmark.info/

-----------------------------------------------------------------------

* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

           Sequential Read :   187.665 MB/s

          Sequential Write :    12.507 MB/s

         Random Read 512KB :    34.351 MB/s

        Random Write 512KB :    18.853 MB/s

    Random Read 4KB (QD=1) :     0.844 MB/s [   206.0 IOPS]

   Random Write 4KB (QD=1) :     0.308 MB/s [    75.2 IOPS]

   Random Read 4KB (QD=32) :     4.266 MB/s [  1041.4 IOPS]

  Random Write 4KB (QD=32) :     1.591 MB/s [   388.5 IOPS]

  Test : 1000 MB [C: 31.7% (25.3/79.9 GB)] (x5)

  Date : 2013/05/21 11:01:59

    OS : Windows Server 2008 R2 Server Standard Edition (full installation) SP1 [6.1 Build 7601] (x64)

  

-----------------------------------------------------------------------

CrystalDiskMark 3.0.2 x64 (C) 2007-2013 hiyohiyo

                           Crystal Dew World : http://crystalmark.info/

-----------------------------------------------------------------------

* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

           Sequential Read :   153.660 MB/s

          Sequential Write :    13.431 MB/s

         Random Read 512KB :    31.228 MB/s

        Random Write 512KB :    11.787 MB/s

    Random Read 4KB (QD=1) :     0.518 MB/s [   126.5 IOPS]

   Random Write 4KB (QD=1) :     0.227 MB/s [    55.3 IOPS]

   Random Read 4KB (QD=32) :     3.111 MB/s [   759.6 IOPS]

  Random Write 4KB (QD=32) :     0.786 MB/s [   191.9 IOPS]

  Test : 1000 MB [E: 49.2% (295.0/600.0 GB)] (x5)

  Date : 2013/05/21 11:19:02

    OS : Windows Server 2008 R2 Server Standard Edition (full installation) SP1 [6.1 Build 7601] (x64)

[Beto]

Ghunter, realmente algum recurso relacionado ao Banco de Dados está demorando para responder.

IP duplicado não é, verifiquei o DHCP, DNS...etc..NTP está ok, fiz um teste agora de nslookup para várias estações a partir do servidor e resolve ok...

[Gunther Boeckmann]

Eu estou achando os dados de escrita lentos! Tenho uma controladora SAS e discos em RAID 5 de 15K, mas de 143GB, e a performance no Windows 7 está melhor do que a sua:

1GB           READ    WRITE
Seq     –     84,26    95,97
512K    –    37,97    58,61
4K     –     1,074    2,317
4KQD     –     3,145    2,409

Mas essas aferições não são precisas, tendo em vista os Caches que o Hypervisor realiza, mas dão uma ideia geral.

Sugiro você atualizar o Xenserver para a versão 6.02 ou 6.1. Pode ser que não resolva mas seria uma coisa a menos a testar.

Gunther

[Beto]

Rodei o mesmo diagnóstico no servidor de banco de produção, ele tem as mesmas configurações mas está em outro servidor xen, este com as mesmas especificações físicas que mencionei no primeiro post, vejam os resultados:

Servidor Produção:

Sequential Read :   226.768 MB/s

          Sequential Write :   169.618 MB/s

         Random Read 512KB :    37.547 MB/s

        Random Write 512KB :   140.988 MB/s

    Random Read 4KB (QD=1) :     0.923 MB/s [   225.3 IOPS]

   Random Write 4KB (QD=1) :     2.937 MB/s [   717.1 IOPS]

   Random Read 4KB (QD=32) :     2.729 MB/s [   666.2 IOPS]

  Random Write 4KB (QD=32) :     1.982 MB/s [   484.0 IOPS]

  Test : 1000 MB [C: 31.9% (25.5/79.9 GB)] (x5)

  Date : 2013/05/21 15:21:20

    OS : Windows Server 2008 R2 Server Standard Edition (full installation) SP1 [6.1 Build 7601] (x64)

Servidor Homologação (com a reclamação de lentidão no SQL):

[Gunther Boeckmann]

Beto,
Parece que realmente tem alguma coisa errada com o servidor de homologação... Será que ele não está reconstruindo o RAID (quando um disco falha) para provocar essa lentidão?

Gunther

[Artur Bjega]

Beto,

Quando eu executava os testes de performance de discos, não apresentava falha, a falha que acontecia era somente quando ultrapassava a 70% a taxa de utilização. tenta mover um pacote grande de uma vm para a outra, entre por exemplo 3 VMs diferentes, e veja se não apresenta este problema.

No meu caso existia uma rotina de conciliação e fechamento contábil, onde foco era a conversão para um padrão de contabilização internacional que era enviado para a matriz da empresa da alemanha, então como tinhamos uma transação alta, com muitos inserts e updates no banco, e que utiliza um IO alto com o disco apresentava o problema.

Em 21 de maio de 2013 17:00, Beto <alberto....@gmail.com> escreveu:

--
--
Você recebeu esta mensagem porque está inscrito em Grupo "xen-br" do Grupos Google.
Para enviar mensagens para este grupo, envie um email para xen...@googlegroups.com
Para anular a inscrição neste grupo, envie um email para xen-br-un...@googlegroups.com
Para mais opções, visite este grupo em http://groups.google.com/group/xen-br?hl=pt-BR
Site do GU Xen-BR: http://www.xen-br.org
Antes de enviar sua primeira mensagem leia atentamente as regras para participação no site http://groups.google.com/group/xen-br/web/regras?hl=pt-BR
 
---
Você está recebendo esta mensagem porque se inscreveu no grupo "xen-br" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para xen-br+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--

[Tiago Ribeiro]

Em Tue, 21 May 2013 07:52:47 -0700 (PDT)
Beto <alberto....@gmail.com> escreveu:

> Ghunter, realmente algum recurso relacionado ao Banco de Dados está
> demorando para responder.
>
> IP duplicado não é, verifiquei o DHCP, DNS...etc..NTP está ok, fiz um
> teste agora de nslookup para várias estações a partir do servidor e
> resolve ok...
>
> On Tuesday, May 21, 2013 11:12:37 AM UTC-3, gunther wrote:

E ai, alguma novidade? Conseguiu alguma coisa?

--
http://www.bsdjf.com.br

[Beto]

Fala Tiago. Realizei mais alguns testes nas VMs que estão neste servidor físico. Desliguei o servidor de Banco de Dados em que está apresentando lentidão e realizei o teste nos outros servidores que estão neste servidor físico e os resultados continuaram ruins. Estou migrando alguns para outro servidor Xen e depois de migrar todos vou abrir um chamado na HP para analisarem o HW.

[Lucas Felipe de Paula Cruz]

Cara estava com o mesmo problema verifiquei o Storage do meu Server estava 90% acabei tendo que apagar uma VM caiu para 70% e voltou a funcionar na hora.

[hamacker]

O problema de virtualizar banco de dados é que foi constatado perda de performance quando estão envolvidos raid5 e controladoras de disco com cache de apenas de leitura.

Mas teria o mesmo problema se não estivesse virtualizado e com esse mesmo cenário, isso não é uma regra para todos, mas como grangrena todo mundo evita esse cenário.

Sobre o banco de dados, o banco de dados quando está em reparo ou fazendo algum dump é lento mesmo, especialmente se o log for antigo.

inte+

--

--
Você recebeu esta mensagem porque está inscrito em Grupo "xen-br" do Grupos Google.
Para enviar mensagens para este grupo, envie um email para xen...@googlegroups.com
Para anular a inscrição neste grupo, envie um email para xen-br-un...@googlegroups.com
Para mais opções, visite este grupo em http://groups.google.com/group/xen-br?hl=pt-BR
Site do GU Xen-BR: http://www.xen-br.org
Antes de enviar sua primeira mensagem leia atentamente as regras para participação no site http://groups.google.com/group/xen-br/web/regras?hl=pt-BR

---

Você recebeu essa mensagem porque está inscrito no grupo "xen-br" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para xen-br+un...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.