RM TOTVS lento é causado principalmente por Oracle ou SQL Server com buffer cache insuficiente, o RM realiza muitas leituras de metadados e configurações que devem permanecer em memória. O segundo fator mais comum é a camada Java (Servidor de Aplicação RM) com heap subdimensionado, causando GC frequente que paralisa o sistema por segundos. Storage com alta latência amplifica ambos os problemas.
O RM TOTVS lê tabelas de configuração e metadados frequentemente. Com buffer cache insuficiente (Oracle SGA pequena, ou SQL Server com pouca RAM), essas leituras vão para disco a cada sessão, visível como db file sequential read wait no Oracle.
O Servidor de Aplicação RM (host) usa JVM. Com heap insuficiente, GC Full pausas ocorrem frequentemente, cada pausa congela todas as requisições dos usuários por 1 a 30 segundos dependendo do tamanho do heap.
O RM realiza queries com muitos joins em tabelas de dados mestres (PPESSOA, GCOLIGADA). Com storage de alta latência, cada join aumenta o tempo de resposta de forma acumulativa, especialmente em módulos como Educacional e RH com muitas entidades relacionadas.
No Oracle, aumente a SGA_TARGET para cobrir o working set de dados do RM, em geral 60 a 70% da RAM disponível no DBserver. No SQL Server, configure max server memory para 80% da RAM. Com mais dados em cache, as leituras de disco caem drasticamente.
Configure -Xms e -Xmx com valores iguais no start do host RM. Para ambientes com até 50 usuários, comece com -Xmx8g. Use G1GC para manter pausas abaixo de 200 ms. Monitore com GC logs para ajustar.
Storage NVMe dedicado reduz a latência de I/O de dezenas de milissegundos para abaixo de 500 µs. O impacto é maior no RM Educacional e RH, onde queries com múltiplos joins se beneficiam da baixa latência em cada leitura.
Rodar o Servidor de Aplicação RM e o banco na mesma VM gera competição por RAM entre o heap Java e o buffer cache do banco. A separação é a mudança de maior impacto na estabilidade e performance do RM.
A Boreal Tecnologias oferece diagnóstico gratuito de ambientes RM TOTVS, analisando wait statistics do banco, GC logs do servidor de aplicação e métricas de I/O. Cloud privada no Brasil com NVMe dedicado, vCPU sem overcommit e SLA 99,99% em reais.
Na maioria dos casos, infraestrutura, especialmente memória (buffer cache do banco e heap Java) e I/O de storage. O diagnóstico com wait statistics do Oracle/SQL Server e GC logs do host RM confirma a origem em 30 minutos.
Ambos são suportados. Oracle é historicamente mais comum em grandes empresas com RM, especialmente RM Educacional. SQL Server tem menor custo de licença e mais profissionais disponíveis. A performance é similar quando ambos estão bem configurados com RAM e NVMe adequados.
Para ambientes acima de 20 usuários, servidor (VM) dedicado para o banco é necessário. O Servidor de Aplicação RM pode compartilhar recursos com outros serviços leves, mas o banco precisa de RAM e I/O exclusivos para performance previsível.
No Oracle: consulte v$session_wait para ver as esperas ativas. No SQL Server: consulte sys.dm_os_wait_stats. Para o host RM: habilite GC logging e verifique os logs durante período de lentidão. Os dois primeiros itens identificam 90% dos casos em menos de 1 hora.
Receba um diagnóstico estratégico gratuito e descubra o que está limitando performance, estabilidade e escala hoje.
Sem compromisso. Resposta em até 15 minutos em horário comercial.