none
Sistemas da Senior - Lentidão RRS feed

  • Discussão Geral

  • Bom Dia a Todos!

    Gostaria de saber se alguns dos colegas já passou ou está passando por algum problema de performance e/ou outros problemas com os sistemas da Senior, pois implantamos a solução deles e temos muita reclamação de lentidão. Mesmo coletando diariamente dados via perfmon, manutenção no banco de dados (Desfragmentação/Atualizaçao de Estatisticas). O que percebo, é a ocorrência de Asyn_Network_IO, tempo elevado de transação aberta, e blocking. No caso dos blockings, ocorre situações onde o mesmo usuário é responsável pelo seu própria blocking, ou seja, executa uma rotina com uma transação muito longa. Vale ressaltar que temos outros aplicativos nesse mesmo servidor que não temos nenhum tipo de problemas de performance.

    Em conversa com a consultoria, levantou-se a hipótese de desabilitar o lock_escalation das tabelas, enfim, até o presente momento estamos verificando outras possibilidades, mas se alguém tiver uma sugestão!

    Desde já agradeço a todos.

    Anderson

    • Tipo Alterado Marcos SJ segunda-feira, 28 de março de 2016 15:16
    segunda-feira, 28 de março de 2016 14:56

Todas as Respostas

  • Bom dia Anderson,

    Cara não sei se desabilitando o lock_escalation você vai ganhar esta performance que esta procurando, mas sempre é bom testar.

    Seria legal entender o pq de tantos locks, são rotinas de Update, Select... estudar a possibilidade de uma leitura suja com NOLOCK ou até mesmo um nivel de isolamento mais eficiente para LOCKS como o snapshot isolation.

    Sobre o wait asyn_network a maioria dos casos é a forma como a aplicação esta fazendo a consulta, normalmente ela deve esta consumindo linha a linha, seria bom estudar essas querys tbm.

    Qualquer novidade posta ae.

    Att

    Reginaldo Silva

    segunda-feira, 28 de março de 2016 16:12
  • AndersonAS.SP,

    Já tentou entrar em contato com o fornecedor (Senior) para ver se este comportamento é esperado pela aplicação e se eles já não passaram por isso em outro cliente?

    Geralmente o tipo de espera ASYNC_NETWORK_IO é o SQL Server esperando a aplicação responder. Isto pode ocorrer se o servidor de aplicação não está conseguindo realizar o processamento no tempo correto. Já realizou uma verificação no servidor de aplicação procurando algum tipo de contenção (Memória, CPU, disco, rede, etc.)? 

    Verifique o link abaixo por gentileza:

    http://www.tiagobalabuch.com/problemas-de-rede-async_network_io/

    Espero ter ajudado..


    Felipe Lauffer
    MCSA: SQL Server | MCP

    [ Blog ] - [ Profile ] - [ Wiki ] - [ Gallery ] - [ LinkedIn ]


    segunda-feira, 28 de março de 2016 18:35
  • Anderson,

    Qual é o driver ou provider de conexão que a aplicação utiliza para realizar acesso ao SQL Server?

    Em relação ao Lock_Escalation realizar isso no nível de tabela é um trabalho enorme e muito arriscado, talvez uma possibilidade seja analisar o nível de isolamento do banco de dados, digo novamente talvez e vou repetir talvez uma mudança do nível de isolamento possa refletir na mudança do comportamento de uma maneira melhor ou piorar tudo.

    Por acaso este banco de dados foi migrado de algum outro servidor ou versão de SQL Server?

    Você já realizou alguma análise de fragmentação e estatísticas deste ambiente?


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 29 de março de 2016 15:38
  • Reginaldo, Bom Dia!

    Com relação ao Async_Network_IO, já passei as varias evidencias para a consultoria que foi responsável pela implantação e, a mesma ficou de entrar em contato com a fabricante do software. Agora com relação aos locks, os databases dessa solução utilizam Read Commited Snapshot ON.

    Já passei para o pessoal de suporte avaliar realmente os servidores de aplicação.

    Muito obrigado pela ajuda.

    Att

    Anderson

    quinta-feira, 31 de março de 2016 12:52
  • Felipe, bom Dia!

    Todas as minhas coletas são passadas para os analistas responsáveis pelo ERP, dessa forma dificulta um pouco minha atuação. Mas em contato com um amigo já fui informado que eles passaram os mesmos problemas e foi necessário uns investimentos extras para que o problema fosse resolvido.

    Esse link que você passou foi minha referencia para indicar que a aplicação poderia não estar trabalhando da forma correta.

    Quanto ao servidor de aplicação, o pessoal de infra está realizando esse trabalho, mas até o presente momento não recebi o feedback.

    Agradeço muito pelo sua ajuda.

    Att

    Anderson

    quinta-feira, 31 de março de 2016 13:02
  • Junior, Tudo bem com você?

    Vamos as respostas:

    Essa aplicação utiliza driver ODBC e JDBC, todos com a ultima versão do client para SQL Server.

    Com relação ao Lock_Escalation, trata-se de uma recomendação do fabricante do software, mas que eu ainda estou relutando em desabilitar, uma vez que fazendo isso, estarei aumentando a carga sobre a memória/CPU.

    Quando o nivel de isolamento do database, estou usando o Read Commited Snapshot.

    Essa solução utiliza 3 databases, um database já estava em produção a mais de um ano e nunca tivemos problemas, ai a empresa resolveu adquirir o pacote completo do ERP, dessa forma, foram criados mais dois databases em ambiente de homologação (Mesma versão e SP) e ao concluir todo processo, esses databases foram migrados de homologação para produção através de backup/restore.

    Com relação a fragmentação de e estatísticas desse ambiente, todo domingo eu realizo a manutenção, mas já estou em fase final das analises para realizar essa mesma tarefa em mais dois dias da semana, pois realmente a fragmentação é alta. Vale ressaltar que para essa tarefa utilizo os script do Ole Hallengrer, na qual andei trocando uns e-mails para saber justamente sobre o processo de desfragmentação e atualização de estastiticas e, vi que me atenderia. Utilizo essas rotinas a mais de 2 anos.

    A comparação de meu baseline com os contadores coletados a cada 5 minutos, mostram somente 2 picos durante o dia, mas nada que possa comprometer a performance, pois além dessa solução, tenho outras soluções nesse mesmo servidor de banco de dados e sem reclamações.

    Para algumas analises e referencias, sempre procuro seu blog e de mais um pessoal da pesada, buscando me aperfeiçoar cada vez mais.

    Um grande abraço.

    Anderson

    quinta-feira, 31 de março de 2016 13:23
  • A Microsoft não é fabricante de sistemas ERP, o senhor tem que entrar em contato com o fabricante do seu sistema.


    Ana Gauna (Senior System Analist, MCSE, MCDBA, CCNA2) - Skype: amgauna

    quinta-feira, 31 de março de 2016 13:28
  • Ótimo Anderson. Que bom que os links te ajudaram.

    Se tiver algum retorno e precisar de mais algum apoio fique a vontade para responder nesta thread ou até mesmo criar uma nova.


    Felipe Lauffer
    MCSA: SQL Server | MCP

    [ Blog ] - [ Profile ] - [ Wiki ] - [ Gallery ] - [ LinkedIn ]


    quinta-feira, 31 de março de 2016 18:01
  • Anderson,

    Ok, ótimo obrigado pelas respostas.

    Você destacou que esta utilizando o isolation level Read Commited Snapshot?

    Talvez isso possa estar gerando seus problemas, veja o que a documentação oficial Microsoft informa:

    • Se READ_COMMITTED_SNAPSHOT estiver definido como OFF (o padrão), o mecanismo de banco de dados usa bloqueios compartilhados para impedir que outras transações modifiquem linhas enquanto a transação atual está executando uma operação de leitura. Os bloqueios compartilhados também bloqueiam a instrução de ler linhas modificadas por outras transações até que a outra transação seja concluída. O tipo de bloqueio compartilhado determina quando será lançado. Bloqueios de linha são liberados antes que a próxima linha é processada. Bloqueios de página são liberados quando a próxima página é lida, e bloqueios de tabela são liberados quando a instrução termina.

    • Se READ_COMMITTED_SNAPSHOT estiver definido como ON, o mecanismo de banco de dados usa a versão de linha para apresentar cada instrução com um instantâneo transacionalmente consistente dos dados, tal como existia no início da instrução. Bloqueios não são usados para proteger os dados de atualizações por outras transações.

    • Quando o banco de dados READ_COMMITTED_SNAPSHOT for ON, você pode usar a dica de tabela READCOMMITTEDLOCK para solicitar um bloqueio compartilhado em vez de versão de linha para instruções individuais em transações em execução no nível de isolamento READ COMMITTED.


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    sexta-feira, 1 de abril de 2016 13:20