none
Performance AX 2009 RRS feed

  • Pergunta

  • Bom dia pessoal.

    Atualmente estamos dispensando muitas horas de trabalho para melhorar a performance do DAX 2009 aqui na empresa.
    Algumas customizações foram reescritas, inclusive semana passada o amigo Josemar Xavier me deu uma dica para acelerar o processo do faturamento.
    Ainda assim, alguns pontos ficam como uma incógnita para nós e para o próprio parceiro que não tem êxito em identificar os pontos e corrigi-los.
    Vejo que sempre uma query fica em lock no SQL. Alguém já viu este código abaixo ?

    <?query --
    UPDATE CUSTVENDINVOICENUM_BR SET NEXTREC=@P1,INVOICEID=@P2,RECVERSION=@P3 WHERE (((DATAAREAID=@P4) AND (RECID=@P5)) AND (RECVERSION=@P6))
    --?>

    Temos tantos outros, inclusive na hora de a contabilidade está executando algum recálculo, um balancete e etc. 
    Nossos servidores são virtualizados, não sei se alguém tem algo a dizer sobre isso também.
    Se alguém tiver alguma sugestão, agrade.

    Abraços

    quarta-feira, 11 de dezembro de 2013 10:19

Respostas

  • Caso realmente optem por iniciar testes na nova versão deixo a você 02 dicas!

    Aguarde a versão RU3, será liberada em breve e evitara um novo processo de upgrade de RU2 pra RU3!

    Na nova versão, teste todas as possibilidades nativas antes de solicitar ao parceiro a criação de uma custom, em muitos casos a função nativa do produto já atende sua necessidade!

    Boa sorte e caso precise estaremos a disposição!


    Marque como util se esta resposta o ajudou!!!

    • Marcado como Resposta matfurrier terça-feira, 14 de janeiro de 2014 16:01
    terça-feira, 14 de janeiro de 2014 15:59

Todas as Respostas

  • Bom dia,

    Trabalho desde a versão 2009 na parte de infraestrutura do Produto, sinceramente tivemos poucos problemas de desempenho nessa versão que geralmente era causado por customizações ou Hardware insuficiente.

    Na versão atual 2012 r2 o sistema ficou bastante roubusto sendo assim é necessário seguir a risca as recomendações de infraestrutura do documento Implementation Guide.

    Nesse seu ambiente você possui quantos usuários? Numero de transações? Qual é a infraestrutura de servidores para o Dynamics? No seu ambiente virtual existe placas de redes dedicadas para cada VM ou estão compartilhando com outras VM's?

    Fico no aguardo.

    Obrigado.

    Skype: marcos_tadeu_wolf

    domingo, 15 de dezembro de 2013 14:30
  • Bom dia Marcos !

    Obrigado pelo retorno.
    Nossos servidores, de AOS's e SQL estão configurados assim:

    AOS's (04 AOS's)
    Windows Server 2008 R2 64Bits - SP1
    Intel Xeon X5660 2.80Ghz (2 processadores)
    4 Gb RAM
    As placas de rede são compartilhadas, mas cada uma tem seu túnel de 1gb/s  indiferente se a outra VM estiver consumindo muita banda de rede, pois temos uma switch blade HP que faz todo gerenciamento disso.

    SQL Server 2008 R2
    Windows Server 2008 R2 SP1
    Intel Xeon X5660 2.80Ghz (08 Processors) 64 Bit
    50GB RAM
    Arquivos TMP do BDSQL = RAID1
    LOG do BDSQL: RAID5
    DADOS: RAID5
    Aplicação: RAID5

    Muito obrigado !

    Abs.

    segunda-feira, 16 de dezembro de 2013 10:18
  • Bom dia,

    Quantos usuários simultaneos utilizam o sistema?

    Sabe me dizer se as AOS estão em cluster ou configuradas para balanceamento de carga?

    Os processos que geram lentidão tem baixo desempenho em qualquer horario do dia? Por exemplo se você executar esse processo quando possui poucos usuarios utilizando o sistema  ou  nenhum tem a mesma performance de quando o sistema esta em uso pela maioria dos usuários?

    Já monitorou atraves do perfmon(ferramenta de monitoramento do windows) os servidores de AOS e SQL conseguiu pegar algum gargalo de hardware?

    Fico no aguardo.

    Desde já obrigado.

    Att,

    segunda-feira, 16 de dezembro de 2013 11:14
  • Marcos, obrigado pelo retorno.

    Em média, temos 200 usuários ativos diariamente.
    Das 04 AOS, 0 estão balanceadas para nossas 30 filiais e 01 fica apenas para a matriz onde estou.
    A lentidão não tem um horário exato, mas, dificilmente ocorre no período da manhã.
    Geralmente, ocorre após as 16:00. 
    As 17:30 fica extremamente difícil faturar uma NF.
    Já utilizamos o monitoramento do Windows, e o que conseguimos verificar é um consumo alto do processador no final da tarde. 
    Verificamos também que o I/O fica muito alto, e, já ocorreram vezes do TEMPDB deixar o disco rígido de 250GB cheio, precisando parar o Bd e realizar o shrink.

    Obrigado !

    Abraços.

    segunda-feira, 16 de dezembro de 2013 11:30
  • Foram criados para esse ambiente arquivos adicionais de TEMPDB de acordo com o numero de cores que no seu caso são 8? Recomendo criar esses arquivos adicionais com o crescimento estipulado em 200 Mega.

    Como se trata de um problema complexo tera que analisar a fundo muito dificil de afirmar que se trata de hardware insuficiente ou problemas na propria aplicação, na parte de hardware eu achei seu ambiente muito bom.

    Como está o consumo de memoria do seu SQL, vi que tem 50 GB a memoria foi limitada para quanto?

    Você pode usar alguns scripts recomendados para analisar algum problema por parte dos dados no seu SQL:

    https://community.dynamics.com/ax/b/axinthefield/archive/2012/08/01/database-maintenance-strategies-for-dynamics-ax.aspx

    http://community.dynamics.com/ax/f/33/t/69851.aspx

    Essa ferramenta é muito boa:

    http://blogs.technet.com/b/mspfe/archive/2011/08/04/how_2d00_to_2d00_set_2d00_up_2d00_the_2d00_performance_2d00_analyzer_2d00_for_2d00_microsoft_2d00_dynamics_2d00_ax.aspx

    Caso não consiga resolver seu problema recomendo que seja aberto um caso de suporte na Microsoft isso já foi feito alguma vez?

    Obrigado!

    segunda-feira, 16 de dezembro de 2013 12:11
  • Marcos,

    muito obrigado pela ajuda.
    Já abrimos um chamado com a nossa parceira, mas está difícil do pessoal resolver.
    Estamos com este problema há alguns meses e não tivemos solução ainda.
    Vou verificar estes scripts que você recomendou e posto aqui se tiver mais evolução.

    Obrigado mesmo.

    Abraços.

    segunda-feira, 16 de dezembro de 2013 12:16
  • Sim entendo esse tipo de problema leva tempo a ser resolvido precisa ser feitas varias analises do que esta sendo executado no AX.

    Essa ferramenta de performance é muito boa seria interessante rodar, outro ponto a analisar seria a fragmentação dos indexes , realizar um rebuild reorganize, atualizar as estatisticas entre outras tarefas de manuentenção do SQL.

    Fico no aguardo de novidades.

    Att,

    segunda-feira, 16 de dezembro de 2013 13:48
  • O que você pode fazer, é esperar o horário da tarde, ligar o SQL Profiler e ir debugando o faturamento da OV.

    No momento em que houver a lentidão (ou não), você já consegue saber a query que fez isto.

    Depois disto, rode-a no SQL Server diretamente, e veja o plano de execução da mesma.

    Pode ser uma tabela mal indexada. O ideal é que no momento em que haja o lock, você tire um report padrão do SQL de todas as transações em bloqueio. Aí você verá quem está bloqueado por quem e porque.

    Isto já te ajuda a filtrar os problemas.

    Aqui tínhamos este problemas, após esta investigação, reescrevi toda a customização e o problema sumiu.

    Abraço.


    Gustavo Bagno E. da Silva

    terça-feira, 7 de janeiro de 2014 14:08
  • Pessoal, boa tarde.

    Creio que as dezenas de customizações estão ocasionando este processo lento em nosso BD.
    estamos avaliando reescrever várias delas, pois já identificamos muitas inconsistências.
    Agradeço a ajuda.

    Abs,

    Mateus

    quinta-feira, 9 de janeiro de 2014 15:15
  • Todos os servidores mencionados são dedicados ao AX?

    Existem outros Jobs, tanto no AX quanto no SQL, sendo executados neste mesmo período de lentidão do sistema?


    Marque como util se esta resposta o ajudou!!!

    terça-feira, 14 de janeiro de 2014 15:06
  • Olá Francisco,

    Então, antigamente haviam alguns jobs, mas hoje não rodam mais, foram desativados.
    Os servidores são todos dedicados apenas ao AX.
    Não sei se tem algo relacionado, mas, aqui, nossos servidores são todos virtualizados.
    O problema que vejo é que, são sempre os mesmos scripts ou o Fetch API que ficam criando gargalo, mas, ainda não conseguiram identificar exatamente qual processo.
    Às vezes um processo de cálculo contábil ou balancete, fica mais de 30 minutos sendo executado...isso não pode ser normal.
    Em situações extremas, pedimos aos usuários que saim do AX para que reiniciemos as AOS e o BD, se não, ninguém consegue trabalhar.
    Imagino que as customizações sejam responsáveis por alguns destes problemas, mas não consigo aceitar que não possamos corrigir.

    Obrigado !
    Abs.,

    Mateus
    terça-feira, 14 de janeiro de 2014 15:33
  • Não vejo problemas relacionados a hardware neste caso, acredito que a fragmentação de disco do servidor(es) de banco de dados esteja ok, correto? Assim como as rotinas de desfragmentação de índices das tabelas do AX no SQL, pelo que me lembro vocês possuem rotinas pra essas tabelas!

    A analise de tantos códigos será bem complicada no seu caso, e com certeza com alto custo.

    Analisaram a possibilidade de "contruir" um novo AX? talvez já na versão atual?


    Marque como util se esta resposta o ajudou!!!

    terça-feira, 14 de janeiro de 2014 15:48
  • Então, realmente, nossos scripts de desfragmentação são executados semanalmente.
    A parceira começou a análise destas customizações e realmente, estão ficando custosas demais e não estamos vendo nenhuma melhora.
    Estamos pensando nesta nova implantação do AX, mas já para a versão 2012 e não mais a 2009 pois o suporte dela acaba em breve e posteriormente não queremos migrar novamente.
    Novamente estaremos analisando esta possibilidade, visto que estamos "patinando" há mais de 01 ano.

    Valeu mesmo !

    Abs.,

    Mateus

    terça-feira, 14 de janeiro de 2014 15:54
  • Caso realmente optem por iniciar testes na nova versão deixo a você 02 dicas!

    Aguarde a versão RU3, será liberada em breve e evitara um novo processo de upgrade de RU2 pra RU3!

    Na nova versão, teste todas as possibilidades nativas antes de solicitar ao parceiro a criação de uma custom, em muitos casos a função nativa do produto já atende sua necessidade!

    Boa sorte e caso precise estaremos a disposição!


    Marque como util se esta resposta o ajudou!!!

    • Marcado como Resposta matfurrier terça-feira, 14 de janeiro de 2014 16:01
    terça-feira, 14 de janeiro de 2014 15:59
  • Valeu mesmo Francisco !
    Creio que iniciaremos alguns testes este ano, mas a migração ocorrerá apenas em 2015.
    Obrigado !

    Abs.,

    Mateus

    terça-feira, 14 de janeiro de 2014 16:02
  • Mateus,

    Poderia me adicionar no skype?

    gustavobagno.

    Abraço.


    Gustavo Bagno E. da Silva

    terça-feira, 14 de janeiro de 2014 16:28