Histórico da Página
Checklist de configurações a serem realizadas nos ambientes Datasul para mitigar problemas como:
- Performance
- Queda de serviços
- Sobrecarga de servidores
- Mau funcionamento em geral
| Índice |
|---|
Checklist configurações Datasul
Estas validações se aplicam ao Datasul com qualquer banco de dados.
| ID | O que | Por que | Como | |||||
|---|---|---|---|---|---|---|---|---|
| 1 | Desativar logs na tabela de Programas do Menu Datasul | Quando ativado, este flag dispara a geração de logs extensos, que podem comprometer o desempenho geral do backend (camada Progress, tanto Client como Appserver/PASOE). Recomenda-se manter desativado. Somente ativar casos de exceção, mediante alinhamento com a consultoria/suporte. | Em um editor Progress conectado aos bancos de dados: Para consultar: output to c:\temp\log_gera_log_exec.txt. Para desativar: FOR EACH prog_dtsul exclusive-lock: | |||||
| 2 | Configurar utp/ut-apsv-sessionclear.r nos eventos do Appsever
| Este processo é um Garbage Collector. Ele realiza a limpeza da memória dos agentes do Appserver/PASOE ao final de cada requisição, retirando objetos sem uso, evitando locks, travamentos e sobrecarga de recursos do servidor. | Appserver clássico (Progress 11) No arquivo ubroker.properties, configurar estes parâmetros junto a cada Broker consumido pelo Datasul (menu, Automação de Tarefas Datasul e quaisquer outros processos que utilizem Broker Escalável): srvrDisconnProc=utp/ut-apsv-sessionclear.r srvrShutdownProc=utp/ut-apsv-sessionclear.r Na tela do Progress Admin Services, aparece desta forma: PASOE (Progress 12) No arquivo conf/openedge.properties (na instância do PASOE) configurar estes parâmetros: sessionDisconnProc=utp/ut-apsv-sessionclear.r | |||||
| 3 | Configurar Operating Mode do Appserver (apenas Progress 11) | Quando este parâmetro está incorreto, a comunicação entre o Frontend (Tomcat) e o Backend (Appserver) não opera corretamente, podendo causar gargalos, sobrecarga e perda de requisições. | Valor correto (ubroker.properties / Progress Admin Services): operatingMode=State-reset | |||||
| 4 | Garantir que a variável de ambiente JAVA_HOME esteja corretamente setada no servidor onde é executado o Appserver/PASOE | O backend do Datasul possui alguns processos que realizam chamada direta a programas em Java (ex: utils/TotvsCompactador.jar, entre outros). As chamadas dependem desta variável de ambiente para executarem corretamente. | Windows Definir junto às variáveis de ambiente do sistema. Ex: JAVA_HOME=c:\Java\jdk-11.0.11 Linux No Linux cada distro pode possuir particularidades, mas de modo geral as variáveis de ambiente são definidas no arquivo /etc/environment. Ex: JAVA_HOME="/usr/lib/jvm/java-11-openjdk-11.0.14.0.9-1.el7_9.x86_64" | |||||
| 5 | Configurações de performance no script.pf de conexão aos bancos de dados | Diversos parâmetros podem afetar o desempenho do sistema a nível de cache, buffers, tamanho de segmentos de memória, etc. | Resumo dos parâmetros mais impactantes: -l 50000 Mais detalhes aqui: https://centraldeatendimento.totvs.com/hc/pt-br/articles/360034643513-Framework-Linha-Datasul-TEC-Configura%C3%A7%C3%A3o-do-Appserver-Progress-para-o-Datasul-for-THF | |||||
| 6 | Parâmetro -q no script.pf | A presença do parâmetro -q no seu script.pf de conexão as bancos de dados irá aprimorar a performance. Isso reduzirá no I-O a cada vez que um binário Progress é chamado, pois ele é salvo na memória RAM e reutilizado, sem ser buscado novamente do disco em chamadas posteriores.
| No arquivo.pf de conexão aos bancos de dados, garantir que exista esta linha: -q | |||||
| 7 | Tamanho dos logs do Appserver (apenas Progress 11) | Muitas vezes o log do Appserver está muito grande (Gigabites), causando alto consumo de I-O, e deteriorando a performance geral do sistema. Recomenda-se limitar o tamanho máximo de um log de Appserver em 15MB. Essa mesma técnica pode ser aplicada para o clientlog de sessões Client Progress e RPW. Atenção também para sempre apontar a geração do arquivo para o disco do mesmo servidor onde o Appserver/PASOE é executado, e não para caminhos de rede, o que pode comprometer o desempenho. | https://knowledgebase.progress.com/articles/Article/000051593 | |||||
| 8 | Configurar timeout da sessão | Quando os usuários abrem diversas telas do sistema e esquecem de encerrá-las ao concluírem sua atividade, os recursos do Sistema Operacional (processamento, memória, banco de dados) continuam alocados desnecessariamente. É importante configurar o Timeout para que as sessões sejam encerradas automaticamente após determinado tempo de inatividade, evitando sobrecarga de recursos. | Podem ser adotadas duas abordagens:
Obs: O timeout se aplica apenas para telas abertas na estação do usuário. Já os processos RPW não são afetados por este controle de timeout. | |||||
| 9 | Configurações de performance para deploy do Tomcat | A instalação default do Tomcat prevê a utilização de diversos recursos que não são necessários para o Datasul. As recomendações deste artigo reduzem consideravelmente o volume de processamento, consumo de recursos e tempo de carga da instância do Tomcat com Datasul | Configuração de Performance Tomcat x Datasul | |||||
| 10 | Gerenciar espaço em disco no servidor do Tomcat | Os diversos aspectos relacionados à gestão dos servidores, inclusive o espaço em disco, são de responsabilidade da infraestrutura do cliente e/ou consultoria de infraestrutura contratada. Ainda assim, para prevenir esgotamento de disco, algumas orientações úteis podem ser passadas ao cliente:
Alguns ofensores conhecidos que podem gerar volume considerável de arquivos na pasta temp:
| Cada cliente pode definir sua política de governança dos servidores. Recomenda-se utilizar serviços de agendamento/cron para realizar o saneamento de arquivos antigos / temporários / desnecessários e garantir que o disco nunca fique esgotado, pois isso ocasionará parada do sistema. | |||||
| 11 | Configurar as permissões do usuário de serviço do Tomcat | Assim como os demais serviços que compõem o produto Datasul, o Tomcat deve ser configurado no servidor do cliente para ser executado com permissão de administrador. Caso falte qualquer permissão de escrita durante a usa execução, implicará em mau funcionamento do sistema. Isso se aplica tanto para Windows como Linux. Exemplo que já vimos ocorrer: caso durante a instalação o usuário estiver com seu próprio login, e não Administrador/root, corre-se o risco de o serviço ficar instalado no sistema operacional com o login do próprio usuário. Isso pode gerar a sensação de que a instalação está funcionando corretamente nos primeiros testes unitários, e apresentar erros de permissão posteriormente, ao subir o serviço em produção. Por isso, é importante ter atenção especial no momento da configuração. | Windows
Linux
| |||||
| 12 | Riscos de enviar arquivos.war ao cliente | Assim como qualquer programa Progress enviado ao cliente de forma "avulsa", um arquivo.war também corre riscos de desestabilização de processos. Quando ocorrer esta necessidade, sempre ter em mente:
|
Checklist configurações Datasul com banco de dados Oracle (Schema Holder)
Além das validações acima, é fundamental checar estes pontos para clientes com banco de dados Oracle.
| ID | O que | Por que | Como |
|---|---|---|---|
| 101 | Checar open_cursors | Cada conexão a um banco de dados no Oracle consome uma sessão, que fica aberta durante todo o escopo do programa. Isto se aplica tanto para usuários que abrem tela GUI (tela Progress) como Agentes de Appserver. Exemplos:
Portanto, o número sugerido neste parâmetro é uma configuração que se aplica à grande maioria dos casos, mas deve ser bem dimensionado com clientes com muitos usuários e agentes de Appserver. | Executar em uma sessão conectada ao banco de dados Oracle, com privilégios de administrador:
Se o resultado for inferior a: open_cursors: 30000 Então os referidos parâmetros devem ser ajustados para esses valores, com os seguintes comandos: alter system set open_cursors=30000 scope=both sid='*'; Obs: o listener do Oracle deve ser reiniciado para que as alterações tenham efeito.
|
| 102 | Checar o -c no .pf | No arquivo.pf de conexão aos bancos de dados, conferir o valor do parâmetro -c, que não deve ser inferior a: -c 10000
-db \\cxs-gcad-rep01\schemaholder\shemsfnd -ld shemsfnd -RO -db emsfnd -ld emsfnd -U susemsfnd/susemsfnd@squad -c 10000 Atenção para refletir os ajustes de .pf também na tabela EMSFND.BCO_EMPRES | |
| 103 | Erro de estouro de limite de 32k da linha no banco de dados | O Oracle Data Server (Schema Holder do Progress para comunicar com banco Oracle) possui uma limitação de 32k para o tamanho das linhas no banco. | Caso este erro se manifeste: https://community.progress.com/s/article/19074 Recomendamos reportar ao nosso canal de suporte, e adotar o seguinte paliativo:
Detalhes: https://community.progress.com/s/article/Error-6447-when-NLS-LANG-environment-variable-is-set |
Checklist configurações Autorizador Web e Foundation Saúde (Jboss)
Para clientes Saúde que utilizam Autorizador Web e/ou Foundation Saúde.
| ID | O que | Por que | Como |
|---|---|---|---|
| 201 | Configurações do pool Appserver x Jboss (Apenas para Progress 11 com Appserver clássico) | Caso as configurações do pool não estejam compatíveis nas duas pontas (Appserver e Jboss), a aplicação apresentará instabilidades. | No Appserver - entrar no Progress OpenEdge Explorer (http://<seu_servidor>:9090): Checar nas propriedades do Broker qual é o Operating Mode que está configurado. O recomendado é stateless: Checar nas propriedades do Agent o valor do campo Maximum servers: progress.server.mode=1 1 equivale a Stateless (este é o valor default). Seu valor deve estar compatível com o Operating Mode do Appserver (acima). for State-reset, então trocar para 2.
o número aqui deve ser igual ao Maximum servers do Appserver (conforme visto acima). Obs: Tanto Appserver como Jboss devem ser reiniciados caso algum dos parâmetros seja alterado. Referência: Documentação "datasul_framework.properties" |
| 202 | Tamanho máximo do HTTP POST | Se não estiver corretamente configurado, este parâmetro pode limitar o tamanho da mensagem trafegada no Foundation Saúde, interrompendo a comunicação. Exemplo de problema frequente: guias trafegando normalmente quando tiverem até 6 procedimentos, e começarem a falhar quando tiver mais que 6 procedimentos. | No arquivo .../deploy/jboss-web.deployer/server.xml da instalação do Jboss, acrescentar os atributos:
Obs: este valor é configurado em bytes. O valor "-1" indica que o tamanho será ilimitado. Exemplo:
Dica: se hoje esta configuração não estiver preenchida, e não estão sendo observados problemas, significa que a limitação default (2MB) é suficiente. Para evitar o risco de configurar com "-1" e receber anexos muito grandes, que possam comprometer o processo, o parâmetro pode ser configurado com uma certa margem (ex: 4 ou 8MB). Mais informações: https://docs.jboss.org/jbossweb/7.0.x/config/http.html |
| 203 | Configurar utp/ut-apsv-sessionclear.r nos eventos do Appsever | Este processo realiza a limpeza da memória dos agentes do Appserver/PASOE ao final de cada requisição, evitando locks, travamentos e sobrecarga de recursos. | Mesma ação do item 2 deste documento. |
| 204 | Ao virar para Progress 12, atualizar as libs de comunicação do Jboss com o backend. | A mudança de tecnologia do Progress 11 para 12 exigiu ajustes em libs de comunicação entre as camadas. Atenção especial para o artefato datasul-saude-connection-progress-11.5.9.jar (.../jboss/server/default/lib). Se a sua versão for anterior a 20/10/2023, atualize imediatamente, sob risco de alocação total das sessões do PASOE, gerando travamento do sistema, que só se resolve com reinicialização, e o problema torna a ocorrer em pouco tempo. | Detalhes neste documento: DT Autorizador e Foundation com Progress 12 |
| 205 | Dimensionar max-pool-size das conexões JDBC | Dependendo do volume de acessos e requisições, o pool dimensionado pode ser insuficiente, gerando erros no log do Jboss e recusando as transações. Neste caso recomenda-se aumentar o valor. | Nos arquivos progress-ds.xml (para clientes com banco Progress), oracle-ds.xml (para clientes com banco Oracle) e erp-ds.xml, que ficam na instalação do Jboss/server/default/deploy, revisar a tag <max-pool-size>. Exemplo: <?xml version="1.0" encoding="UTF-8"?> </datasources> |
Checklist configurações - Geral
Validações que se aplicam a qualquer aplicação.
| ID | O que | Por que | Como |
|---|---|---|---|
| 301 | Checar quantidade de processadores | Em situações com apenas 1 ou 2 processadores, já presenciamos o cenário de o cliente possuir diversos agentes de Appserver, mas a CPU não dar conta de executar processos em paralelo. Como efeito, 2 a 3 agentes acabam consumindo 100% de CPU, causando enfileiramento das atividades, e lentidão na percepção do usuário.
| Verificar o número de processadores virtuais da máquina. Se for Windows, pode ser verificado pelo Task Manager: |
Boas práticas e recomendações
| ID | O que | Por que | Como |
|---|---|---|---|
| 401 | Migrar RPW Clássico para o novo Automação de Tarefas Datasul (Task Manager) | Enquanto o RPW Clássico é executado em sessões Client Progress, o novo Automação de Tarefas Datasul (Task Manager) é executado em Appserver/PASOE, tornando a gestão mais simples, estável, incorporando novas funcionalidades e possibilitando a utilização do recurso de Broker Escalável. | Detalhes aqui: Configuração Automação de Tarefas Datasul - Novo RPW |
| 402 | Se o cliente possui aplicações próprias que consomem o Datasul via REST:
| Exemplo com Broker Escalável Digamos que o cliente possui no seu portal uma funcionalidade para os seus clientes Pessoa Física solicitarem a geração da 2a via de boletos, e que o vencimento é no dia 10 de cada mês. Isso abre margem para um pico de utilização deste recurso próximo à data de vencimento. Se a chamada desta customização estiver compartilhando o mesmo Appserver/PASOE do menu do Datasul, poderá ser percebida lentidão/travamento/indisponibilidade do sistema nos momentos de pico. Com o Broker Escalável, configura-se um Appserver/PASOE dedicado para a customização, sem comprometer o restante da operação. Exemplo com Tomcat Dedicado Seguindo o mesmo exemplo acima, digamos que há um momento de pico de utilização que está comprometendo a resposta do Tomcat do Datasul (menu interno, Portal Empresa, Auditoria Médica, etc). Isso pode caracterizar a necessidade de criação de uma instância do Tomcat dedicada apenas para as customizações do cliente. | TOTVS Broker Escalável |
| 403 | Avaliar as triggers customizadas | É importante validar se existem triggers customizadas em tabelas de alto volume de utilização, pois podem comprometer o desempenho geral do sistema, tanto em tempo de processamento como gerando locks desnecessários. | Para consultar as triggers do GPS: output to c:\temp\dztriggers.txt. Para consultar as triggers do ERP: output to c:\temp\tab_dic_dtsul.txt. Mais detalhes sobre o procedimento de configuração e ativação de triggers: Instruções_de_Atualização_Versão_GPS |
| 404 | Análise de Logs mais relevantes | O Tomcat gera diversos logs, cada um com objetivos diferentes. A nível de regra de negócio do Datasul, destaca-se o catalina.AAAA-MM-DD.log. Deploy Este log mostra se cada arquivo.war (pasta webapps) foi corretamente carregado na memória do sevidor (deploy) ou se ocorreram erros que impediram o deploy. Os erros mais comuns são:
Negócio Neste mesmo log pode-se identificar as requisições realizadas pela camada de tela (Frontend) ao Appserver/PASOE (backend). Ex: 14-Apr-2023 17:11:16.225 INFO [datasul-exec-404] com.totvs.framework.rest.connector.APIDatasulConnector.processRequest TOTVS-REST API-DATASUL: Conectando appserver Appserver/PASOE No log do Appserver/PASOE é possível cruzar o trecho de log acima (frontend) com o backend que foi chamado: 2023-04-14T17:11:16.288-0300 020972 050324 2 AS-27 ?:?:? 4GLTRACE Run utp/ut-logexecapi.p "hpr/api/v1/modalities api" [registerLogExec - fwk/rest/authProgressApp.p @ 998] | |
| 405 | Reduzir timeout default para locks do banco de dados | Por default um Client/Agent Progress aguarda 30 minutos (1800 segundos) quando tenta acessar um registro que já está em lock. Para o caso de uma tela Client em que o usuário está interagindo isso não é um grande problema, visto que é apresentada uma mensagem perguntando se o usuário deseja aguardar ou cancelar a operação. Essa tela cancela a operação automaticamente se os 30 minutos se passarem sem interação do usuário. Já para um Agent do Appserver isso pode ser um transtorno, visto que o processo fica em lock mas não há feedback ao usuário, que fica com sensação de "tela lenta/travada" quando na verdade o agent está aguardando a liberação de um registro preso por outra transação. Isso pode induzir o usuário a abrir nova tela e tentar novamente, e isso sucessivamente vai prendendo mais agentes, correndo o risco de todos ficarem presos até que o timeout seja atingido em cada sessão. E neste período, todos os usuários ficam com sensação de "sistema caiu/indisponível". Para este cenário, pode ser útil reduzir este timeout para algo entre 1 e 5 minutos. Importante: caso haja alguma aplicação gerando um lock indevido, esta configuração não resolve o problema. Ela apenas ameniza o impacto aos demais usuários e processos enquanto o lock é investigado, reduzindo a chance de todos os agentes ficarem presos e o sistema completamente indisponível. | Parâmetro no arquivo.pf de conexão: -lkwtmo https://community.progress.com/s/article/16073 |
| 406 | Processos com Importação Parcial | O sistema possui alguns processos de importação de dados que podem ser pesados e executarem por várias horas. É importante alinhar com a área de negócio sobre a possibilidade de estes processos serem executados à noite via RPW, e também para utilizar processo de Importação Parcial (quando disponível). Com isso, o processo utilizará muitas transações pequenas ao invés de uma única transação grande, reduzindo consideravelmente o tempo de processamento e efeitos colaterais em outros processos, devido aos locks no banco de dados. Um exemplo deste tipo de processo é a Importação de A500 XML. | Alinhar cada caso com suporte / consultor de negócio. |
| 407 | Configuração inicial do PASOE | Documentação com maiores informações sobre a configuração inicial do PASOE | 8. Configurando o Progress Application Server OpenEdge (PASOE) |
| 408 | Configurar variáveis de ambiente para o Tomcat do Datasul | Existem dúvidas comuns ao tratar variáveis de ambiente para o produto. Criamos o artigo ao lado com esclarecimentos. | Como criar variaveis de ambiente visiveis ao Datasul no Tomcat |
Virada Progress 11 (AppServer clássico) para Progress 12 (PASOE)
Este link contém a documentação oficial da Progress, com recomendações, boas práticas e descrição detalhada dos parâmetros do PASOE: https://docs.progress.com/pt-BR/bundle/pas-for-openedge-management/page/Configure-OpenEdge-properties.html
Os itens abaixo adicionam informações úteis que identificamos em testes internos e atendimento a clientes.
| ID | O que | Por que | Como | ||
|---|---|---|---|---|---|
| 501 | Atenção com o dimensionamento das Licenças Progress | A mudança do AppServer clássico para o PASOE não é trivial, especialmente no novo comportamento dos Agentes, que passam a ser multi-thread. | No AppServer clássico cada agente consome 1 licença Progress, executando as requisições de modo single-thread (fila). Logo, se você tem 10 licenças, vai usar 10 agentes. No PASOE o agente passa a ser um controlador de múltiplas sessões. Cada sessão por sua vez passa a consumir uma licença, e podem ser executadas de forma paralela (multi-thread). Logo, se você tem 10 licenças, vai usar 1 agente com 10 sessões; ou 2 agentes com 5 sessões; etc. Pode parecer lógico o seguinte raciocínio: se eu tinha 10 agentes no AppServer, terei 10 agentes no PASOE. Mas essa não é a melhor abordagem. O melhor desempenho (e consumo mais otimizado de hardware) é observado utilizando apenas 1 agente com o máximo de sessões (licenças) disponíveis. | ||
| 502 | Escalonamento automático de agentes | Este ponto pode gerar dúvidas comuns. A tela de configuração do PASOE não impede o usuário de preencher com parâmetros conflitantes, que irão gerar mau funcionamento. | Se, apesar da recomendação de usar apenas um agente com muitas sessões, o seu cenário prevê o uso de mais agentes de forma escalonada, a serem inicializados automaticamente sob demanda, tenha atenção especial a estes parâmetros:
É fundamental ter em mente que se Connection wait timeout for muito alto, vai gerar sensação de lentidão ao usuário final. E se for maior que Request wait timeout, é o pior cenário, pois nunca vai solicitar a adição automática de um novo Agente, ficando travado.
| ||
| 503 | Relação entre Sessões e Conexões | Este é um novo controle criado no PASOE, e pode gerar dúvidas. |
| ||
| 504 | Proteteção contra loops infinitos | Em caso de falha de um processo, é preferível que a sessão encerre automaticamente e volte a ficar disponível no pool, ao invés de ficar presa, sob risco de esgotamento de recursos e parada total do sistema. | SessionExecutionTimeLimit: este é um parâmetro avançado, que não aparece na tela de gerenciamento do PASOE. Seu valor default é zero, o que indica que o controle não está ativo. Para alterá-lo, deve ser editado o arquivo conf/openedge.properties do seu PASOE. Quando informado, indica o número de segundos em que uma requisição deve abortar automaticamente, devolvendo a sessão para o pool. Exemplos de uso:
Quando este timeout exceder, será disparado o evento STOP. O log apresentará mensagens neste formato. Se ocorrer, deve-se avaliar se o parâmetro está muito baixo e deve ser recalculado, ou se deve ser acionado o suporte para avaliação do desempenho dos programas:
| ||
| 505 | Desativar monitoramento de alterações de dicionário | À partir do Progress 12 o monitoramento de alterações de dicionário é ligado por default (roda a cada 30 segundos), enquanto era desligado no Progress 11. Com isso, percebe-se um certo delay nas conexões. Visto que o produto Datasul não sofre alterações de dicionário com o produto no ar, apenas em janelas de atualização programadas, faz sentido desativar este monitoramento para incrementar performance e reduzir mensagens nos logs. | O referido delay está descrito neste artigo: https://community.progress.com/s/article/OE-12-2-performance-is-worse-than-OE-11-7-when-receiving-a-Temp-Table Neste outro artigo a Progress confirma que há um bug que não permite a desativação do parâmetro pela tela de configuração do PASOE: https://community.progress.com/s/article/usernotifytime-and-dbnotifytime-parameters-not-setting-to-0-under-oem Para contornar, os parâmetros "-usernotifytime 0 -dbnotifytime 0" devem ser adicionados no campo "Other arguments" de cada banco de dados:  Ao desativar este monitoramento, o log do PASOE deixará de listar este tipo de mensagem a cada 30 segundos: 2024-06-17T07:26:53.768-0300 024104 024140 4 AS-ResourceMgr mtapsv:-:? CONN Setting attention flag for database 'srcadger', interval '30' | ||
| 506 | Desligamento automático de Sessões e Agentes ociosos | Por default, os timeouts ficam desativados, e com isso as Sessões e Agentes ociosos não são derrubados automaticamente. Ficam consumindo recursos sem necessidade. |
Artigo da Progress: https://community.progress.com/s/article/How-to-configure-PASOE-to-clean-up-idle-resources-automatically | ||
| 507 | Derrubar uma sessão do agente multi-thread do PASOE sem afetar as demais sessões em andamento | No AppServer clássico (1 agente por sessão) o PID de um processo travado pode ser derrubado pelo sistema operacional sem afetar as demais sessões. já no PASOE, por ser multi-thread, se o PID de um agente for derrubado, todas as sessões que ele administra serão afetadas, tornando inviável este procedimento. | Para derrubar apenas uma sessão de um agente multi-tread sem afetar as demais sessões:
|
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas