Histórico da Página

ORIENTAÇÃO GERAL DE PERFORMANCE

Situações relacionadas a baixa performance do CorporeRM podem ter diversas origens, como: ausência de índices, bloqueios de antivírus, não-conformidades da versão, parametrizações do ambiente, dentre outras.
Porém existem determinadas ações que devem ser aplicadas independentemente da origem da baixa performance, ações que são benéficas para a performance CorporeRM.

ATUALIZAÇÃO

As soluções de decorrências de problemas de baixa performance -  que são caracterizados por alterações no sistema - são disponibilizadas em patch específicos.
Sendo assim, aplique o ultimo patch especifico disponibilizado no portal do cliente.
Verifique detalhes das correções realizadas através do seguinte link: http://tdn.totvs.com/pages/viewpage.action?pageId=440845561

MANUTENÇÃO

Realize/revise a manutenção da Base da Base de Dados conforme link abaixo:
http://tdn.totvs.com/pages/releaseview.action?pageId=233756331

Obs.: Ocorrem alterações nas procedures correspondentes (ONLINE = ON e ONLINE = OFF, com separação por edição)

NGEN

O NGEN é uma ferramenta que melhora o desempenho de aplicativos gerenciados. Ngen cria imagens nativas, que são arquivos que contém o código de máquina específico do processamento compilado e as instala no cache de imagem nativa do computador local. O tempo de execução pode usar imagens nativas do cache em vez de usar o compilador JIT (Just-In-Time) para compilar o assembly original.

http://tdn.totvs.com/pages/releaseview.action?pageId=235601768

Obs.: Em determinados cenários, a execução do NGEN pode ser estender por vários minutos, sendo assim, recomendamos que a execução seja realizada fora do horário de produção.

DELIMITAÇÃO DE REGISTROS NA VISÃO

A quantidade de registro definida para visão, pode ser caracterizado como um ofensor para performance. Recomendo que altere para 1000 a quantidade de registros na visão, conforme resultado da seguinte consulta SQL:

http://tdn.totvs.com/pages/releaseview.action?pageId=489764485

Tal cenário é importante uma vez que os registros em visão raramente são gerenciados pelo usuário. A montagem da visão difere por exemplo da construção de um relatório, que explora o potencial de processamento analítico de dados, podendo lidar com volumes maiores. Os registros carregados na visão do produto, quando superior a mil registros, podem ocasionar consumo elevado de memória e CPU nos servidores de aplicação, client e Banco de Dados ocasionando overhead destas camadas.

ISOLAMENTO DA BAIXA PERFORMANCE (TESTE LOCAL)

Com intuito de iniciar o processo de isolamento da baixa performance, recomendo que realize alguns testes.
Caso utilize um ambiente 3 ou N camadas, realize uma instalação local em um ambiente de teste, e execute os processos que apresentam baixa performance.

Esse teste tem como intuito isolar a inconsistência, indicando se o problema está no ambiente ou no Banco de Dados. Ou seja, caso o problema seja apresentado no ambiente local, existirá um forte indicio que a baixa performance está direcionada ao Banco de Dados. Caso a inconsistência não seja apresentada, existirá um indicativo que o problema está no ambiente (Corpore RM, Windows ou Produto)

BAIXA PERFORMANCE EM UM PROCESSO ESPECIFICO 

Caso a lentidão ocorra especificamente em um processo (ex.: espelho de ponto, integração bancário, dentre outros) e não acarrete em uma baixa performance generalizada.
Nesse cenário é orientado o contato com o suporte do módulo (ex.: RM Vitae, RM Fluxus, dentre outros) para orientações quanto a análise e solução.

Em determinados cenários a inconsistência pode ser caracterizado com o recorrente, com orientações já definidas ou disponibilizadas, como parametrizações e (ou) atualizações.

TESTE DE VERSÃO 

Caso a principal suspeita recaia sobre a atualização de versão, recomendamos que realize um teste em ambiente local, utilizando o patch especifico anterior.
Nesse cenário, caso existam diferenças significas de performance entre patch específicos, existirá um indicio de problemas relacionadas ao produto.

Sendo necessário em contato com suporte, preferencialmente com detalhes do teste realizado para simulação do incidente. 

Obs.; Esse teste somente é valido para cenários de atualização de patch específicos, para atualizações de release (ex.: 12.1.24 para 12.1.25)
-  devido a quantidade de variantes - devem ser consideradas as demais orientações desse documento.

1. BANCO DE DADOS

1.1 NÍVEL DE COMPATIBILIDADE 

Verifique o nível de compatibilidade determinado para o Base de Dados. A partir do Release 12.1.26 o Nível de Compatibilidade 2008(100) não é mais suportado pelo CorporeRM, sendo recomendado a utilização do Níveis 110 ou 120.

Porém ao utilizar o nível de compatibilidade 120 considere os seguintes itens disponibilizados pela Microsoft:

Degradação do desempenho durante a atualização do banco de dados nível de compatibilidade 120 a 130: https://support.microsoft.com/pt-br/help/3212023/performance-degradation-when-you-upgrade-from-database-compatibility-l

Alterar o nível de compatibilidade do banco de dados e usar o Repositório de Consultas: https://docs.microsoft.com/pt-br/sql/database-engine/install-windows/change-the-database-compatibility-mode-and-use-the-query-store?view=sql-server-2017

Image Added

Considere também as seguintes obervações sobres os níveis 130 e 140: BD0026_Nível_de_Compatibilidade_SQL_Server_2016_(130)

1.2 AUTO CREATE STATISTICS

Auto Create Statistics – Configurada como True, as estatísticas de índice são automaticamente criadas, sempre que você criar um índice, o SQL Server cria um conjunto de estatísticas sobre os dados contidos dentro do índice. O otimizador de consulta utiliza essas estatísticas para determinar se ele deve ou não utilizar o índice para ajudar a processar a consulta. Devido a característica das aplicações da linha RM, pode ser benéfico para o desempenho de relatórios e outros itens customizados que eventualmente demandem filtros específicos que não são compreendidos por índices padrões do produto, bem como em melhorias de planos de execução ineficientes.

Por padrão o backup de nossa base vazia, utilizada normalmente para implantação possui este parâmetro desmarcado para não gerar estatísticas em todas as tabelas. No entanto, esta é uma opção do banco de dados que poderá ser utilizada em cenários específicos de análise de desempenho mensurando o impacto, custo de manutenção e resultados obtidos com a utilização deste parâmetro como TRUE. A Microsoft recomenda a utilização deste parâmetro como TRUE por default.

A base CorporeRM possui um número elevado de índices, porém dado a possibilidade de customizações, ainda existem diversas querys que não se utilizam de índices em suas pesquisas. A ausência de estatísticas nestas colunas pode provocar a escolha de planos de execução inadequados, ocasionando lentidão e travamento.

Na alteração do parâmetro para true pode ser constatado um efeito positivo imediato, em seguida - após a otimização do processo correspondente - o parâmetro pode ser alterado para false novamente. Entendemos que para ativação definitiva desse parâmetro no Banco de Dados é necessário desprender um maior tempo de acompanhamento, para avaliação de resultados, overheads e avaliação do aumento do tempo de manutenção para atualização de estatísticas. Esse avaliação deverá ser realizada pelo DBA da empresa.

Atenção: Favor realizar o procedimento acima em ambiente/base de teste e somente após avaliar os resultados aplicar em produção.

1.2 3 - MANUTENÇÃO

Realize/revise a manutenção da Base da Base de Dados conforme link abaixo:
http://tdn.totvs.com/pages/releaseview.action?pageId=233756331

Obs.: Ocorrem alterações nas procedures correspondentes (ONLINE = ON e ONLINE = OFF, com separação por edição)

1.3 4 – ISOLAMENTO E VIRTUALIZAÇÃO

1.34.1 – ISOLAMENTO

Recomendamos que o servidor de Banco de Dados, seja utilizado exclusivamente para prover o ambiente da instância SQL Server, salve casos, onde a recomendação parte do suporte CorporeRM.
Problemas gerados pela aplicação ou aplicativos de terceiros, podem acarretar em problemas de performance no Banco de Dados.

1.34.2 – VIRTUALIZAÇÃO

Em relação a virtualização do ambiente de banco de dados, temos alguns pontos de atenção relacionados a características desta camada que tem alta demanda por ciclos de CPU, memória e IOPS, o que somado ao overhead natural do ambiente virtualizado pode gerar gargalos de processamento. Apesar de não recomendarmos, a virtualização é uma opção de escolha do cliente, caso disponha de uma equipe especializada, pode-se obter resultados de desempenho próximos de um sistema físico.

A recomendação de não virtualização do ambiente de banco de dados se dá pelas características desta camada que tem alta demanda por ciclos de CPU, memória e IOPS, o que somado ao overhead natural do ambiente virtualizado pode gerar gargalos de processamento. Apesar de não recomendarmos, a virtualização é uma opção de sua escolha, caso disponha de uma equipe especializada, você pode obter resultados de desempenho próximos de um sistema físico. Algumas questões a serem consideradas na virtualização do banco de dados.

Recursos:

• Perda de performance por overhead nas operações de Entrada/Saída (I/O);
• Limitações das tecnologias de virtualização para grandes infraestruturas;
• Tendência a overload do ambiente físico.

Licenciamento

• Custos com versão que possibilitam a criação de servidores com muitos recursos de CPU e memória

Administração

• Compartilhamento de recursos com outros serviços que podem gerar concorrência nestes recursos e consequentemente perda de desempenho.

1.4 5 – CONSUMO DE MEMORIA (MAX_SERVER_MEMORY)

Utilize o parâmetro max_server_memory para garantir que o sistema operacional não experimente uma pressão de memória prejudicial.
Reserve de 2 GB a 4 GB para o sistema operacional em si.
https://docs.microsoft.com/pt-br/sql/database-engine/configure-windows/server-memory-server-configuration-options

1.5 6 – TEMPDB

Afim de evitar contenção no mesmo, a Microsoft recomenda que se o número de processadores lógicos for menor ou igual a oito processadores, use o mesmo número de processadores lógicos para os arquivos de dados. 

Se o número de processadores lógicos for maior que oito, use oito arquivos de dados, se a contenção persistir poderão ser adicionados novos datafiles de 4 em 4 até o número de processadores lógicos.
Caso a contenção persista após o ajuste para 8 arquivos será necessário avaliar também que tipo de statements e aplicativos estão utilizando o tempdb e suas respectivas querys para eventualmente sugerir ajustes na carga dos mesmos.

Poderá ser planejado um ajuste para 8 datafiles, considerando a necessidade de reduzir a contenção no Tempdb.

Além disso, é importante alocar o tempdb em unidades de disco com boas taxas de Iops para que as operações nesta base que é acessada de forma concorrente por todas as bases na instancia, não impacte no desempenho das aplicações.

https://docs.microsoft.com/pt-br/sql/relational-databases/databases/tempdb-database?view=sql-server-2017

Atenção: Esse avaliação deverá ser realizada pelo DBA da empresa.

2. AMBIENTE

2.1 LATÊNCIA E REDE

Para uma boa experiência de uso, é recomendado que a latência máxima de rede entre a estação de trabalho e o servidor seja de no máximo 100 milissegundos e a largura de banda média por usuário seja de no mínimo 256 Kbps.
Embora tal cenário, seja de maior escopo da equipe de infra da empresa, segue algumas recomendações de parametrizações.

CONFIGURAÇÃO_ARQUIVO ‘HOSTS’ - TEMPO DE RESOLUÇÃO NO DNS

O arquivo Hosts, localizado no diretório " %WinDir%\System32\Drivers\Etc ", permite encontrar um ponto em uma rede de forma simples e ágil, através do relacionamento de hostname e IP incluso em sua estrutura:
http://tdn.totvs.com/pages/releaseview.action?pageId=274639875

CHECKSUM OFFLOAD (VM)

É aconselhável em servidores virtualizados a inativação do componente CheckSum Offload (IPv4, IPv6, TCP e UDP) para desabilitação das verificações cruzada de usuários:

Também recomendo que os seguintes componentes sejam desativados:

• IPv4 Checksum Offload                                  
• IPv4 TSO Offload
• Large Send Offload V2 (IPv4)                       
• Large Send Offload V2 (IPv6)
• Offload IP Options                                          
• Offload tagged traffic
• Offload TCP Options                                      
• TCP Checksum Offload (IPv4)
• TCP Checksum Offload (IPv6)                        
• UPD Checksum Offload (IPv4)       
• UPD Checksum Offload (IPv6)                      
• Recv Segment Coalescing (IPv4 e para IPv6)

IPV6

Inativação dos componentes IPV6 da placa de rede para aprimoramento do trafego de informações via IPV4.

2.2 BALANCEAMENTO NATIVO

Com o Balanceamento Nativo, todas as requisições serão balanceadas entre os hosts disponíveis descritos no arquivo de configuração do aplicativo (RM.exe.configou outros como por exemplo RMLabore.exe.config), mantendo o consumo de memória RAM e CPU dimensionado entre eles (4 serviços RM.Host.Service). Além disso, quando se utiliza Múltiplos Hots é possível obter contingência caso algum deles venha a ter inconsistência, não afetando o ambiente de produção.



RM - Frame - Balanceamento nativo (multiplos hosts)

Observações:

• Recomendado aplicar ao menos 4 Hosts.Services;
• Também deverá ser aplicado em instalação local.

2.3 JOBS

2.3.1 AJUSTE DO POOLING DO SERVIDOR DE JOB

O Job Server (Servidor de Jobs) utiliza um sistema de Pooling, onde a aplicação realiza a leitura da fila de Jobs existente no banco de dados. Esta leitura ocorrerá conforme o tempo configurado na tag <JobServerPollingInterval> do arquivo Alias.dat.

Desta forma, a cada X segundos o mecanismo de job verificará a existência de Jobs pendentes de execução. Existindo processos a serem executados e threads simultâneas disponíveis, o processo será executado.  Recomendamos que o valor da tag JobServerPollingInterval seja igual a 2. Essa parametrização pode ser realizada através do campo ‘Intervalo entre verificações (polling) do Gerenciamento de Alias.

Diretório: C:/Totvs/CorporeRM/RM.Net/ RM.AliasManager.exe

Essa mudança no entanto, deverá ser efetivada considerando dois fatores iniciais:

• Medição da quantidade de conexões e acessos adicionais ao banco de dados para a leitura da fila de pooling.
• Avaliação do comportamento das interfaces de rede e eventuais firewalls diante deste ajuste.

Obs.: Em ambiente com instalação local, essa parametrização não é necessária.

2.3.2 PROCESSOS NÃO SÂO EXECUTADOS

Na decorrência da execução de processo que não são executados (0% processamento), recomendo que leitura dos seguintes artigos:

RM - Frame - Processos não executam

Observações:

• Caso o problema persista, recomendo que entre em contato com o suporte RM Framework
• Em ambiente com instalação local, essa parametrização não é necessária.

2.4 FRACIONAMENTO DE PROCESSOS.

O fracionamento de processos, é um recurso que possibilita uma melhora na execução de determinados Jobs.
Tal recursos permite um certo nível de paralelismo, possibilitando que o processo utilize mais de thread para sua execução.

Sendo assim, recomendo que utilize o ‘Fracionamento de processos’ para os seguinte itens:

• Lançamento de Grupo de Eventos em Grupo;
• Cálculo global do ponto;
• Recálculo da folha.

http://tdn.totvs.com/display/public/LRM/DT_Fracionamento_Calculo

Porém tal parametrização poderá acarretar em um maior consumo de recursos do Banco de Dados, já que determinados processos serão fracionados e executados em simultâneo no Banco de Dados.
Sendo assim, inicialmente recomendamos que o fracionamento seja realizado indicando apenas duas threads.

Em paralelo o processo deverá ser monitorado quanto ao tempo total de execução, e o Banco de Dados em relação a consumo de recursos.

Referente ao ‘Fracionamento de Processos’, recomendamos o acompanhamento da equipe infra da empresa, devido a necessidade de monitoramento de recursos do servidor de Banco de Dados. 

Obs.: Em caso de dúvidas, relacionadas a parametrização indicada, recomendo que entre em contato com o suporte do RM Labore.

2.5 CONSUMO DE RECURSOS

Em determinados cenários, a baixa performance do sistema pode ser ocasionada pelo consumo excessivo de recursos, seja pelo serviços RM.Host.Service ou aplicações de terceiros.

Para comprovar a relação do consumo excessivo (RM.Host.Service) e a performance, realize um teste reiniciando os serviços correspondentes.
Caso constate uma melhoria significativa na performance, pode-se comprovar a correlação.

RM - Frame - Reiniciar Host e Apagar _Broker.dat

Vale ressaltar que a ausência de recursos, pode ser atrelada ao sub-dimencionamento do ambiente, sendo necessário o enquadramento de hardware ao documento de portabilidade:
http://tdn.totvs.com/display/public/LRM/PORTABILIDADE

Caso verifique um consumo excessivo dos serviços RM.Host.Service, que comprovadamente onera a performance do sistema, favor entrar em contato com suporte RM Framework.

2.6 ANTIVÍRUS

Por segurança a maioria dos antivírus realizam as verificações em tempo real nos diretórios TOTVS e Banco de Dados, prejudicando qualquer execuções e/ou gravação a serem realizadas nos diretórios. Deste modo é aconselhável tratar os diretórios abaixo como exceção, em todos ambientes que possuem a estrutura instalada:

Linha RM

• ... :\TOTVS
• ... :\CorporeRM
• ... :\WINDOWS\Microsoft.Net
• ... :\Windows\Assembly

OBS.: E todos os diretórios referentes a instalação do produto.

2.7 WINDOWS

O objetivo deste documento é listar uma série de procedimentos referentes à configurações e ajustes no sistema operacional e no .net framework com o intuito de se maximizar a performance das aplicações da linha RM.

http://tdn.totvs.com/pages/releaseview.action?pageId=23375634