Performance AX 2009

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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,

Answer 4

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.

Answer 5

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!

Answer 6

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.

Answer 7

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,

Answer 8

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

Answer 9

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

Answer 10

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!!!

Answer 11

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

Answer 12

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!!!

Answer 13

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

Answer 14

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!!!

Answer 15

Valeu mesmo Francisco !
Creio que iniciaremos alguns testes este ano, mas a migração ocorrerá apenas em 2015.
Obrigado !

Abs.,

Mateus

Answer 16

Mateus,

Poderia me adicionar no skype?

gustavobagno.

Abraço.

---

Gustavo Bagno E. da Silva