Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

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



Datasul

O quePor queComo
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).

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.
FOR EACH prog_dtsul no-lock:
    IF prog_dtsul.log_gera_log_exec THEN do:
         export prog_dtsul.
    end.
END.
output close.


Para desativar:

FOR EACH prog_dtsul exclusive-lock:
    IF prog_dtsul.log_gera_log_exec THEN do:
         assign prog_dtsul.log_gera_log_exec = false.
    end.
END.

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
Configurar utp/ut-sessionclear.r nos eventos do AppseverEste 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.

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:

image.png


PASOE (Progress 12)

No arquivo conf/openedge.properties (na instância do PASOE) configurar estes parâmetros:

    sessionDisconnProc=utp/ut-apsv-sessionclear.r
    sessionShutdownProc=utp/ut-apsv-sessionclear.r

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

Se o cliente possui aplicações próprias que consomem o Datasul via REST, usar BROKER ESCALÁVELavaliar utilização do recurso de Broker Escalável

Por exemplo:

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.

TOTVS Broker Escalável
Garantir que a variável de ambiente JAVA_HOME esteja corretamente setada no servidor onde é executado o Appserver/PASOEO 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"

Configurações de performance no script.pf de conexão aos bancos de dadosDiversos 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
-mmax 50000
-s 20000
-Bt 32000
-tmpbsize 8
-q


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

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.

ATENÇÃO

Ao utilizar esse recurso, tenha ciência que, caso precise atualizar um binário (.r Progress), o ambiente precisará ser reiniciado (Appserver, RPW, Sessão Progress) para que a nova versão seja considerada.

Recomenda-se seu uso em ambientes de Produção

Logs do Appserver

Muitas vezes o log do Appserver está muito grande (Gigabites), causando alto consumo de I-O, e deteriorando a performance.

Recomenda-se limitar o tamanho máximo de um log de Appserver em 15MB.

https://knowledgebase.progress.com/articles/Article/000051593

Essa mesma técnica pode ser aplicada para o clientlog de sessões Progress e RPW.

Atenção também para não apontar a geração do arquivo para caminhos de rede, o que pode comprometer o desempenho.

Timeout da sessão

Conf do Tomcat (xml)

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.

Para consultar as triggers do GPS:

output to c:\temp\dztriggers.txt.
FOR EACH dztriggers no-lock:
         export dztriggers.
END.
output close.


Para consultar as triggers do ERP:

output to c:\temp\tab_dic_dtsul.txt.
FOR EACH tab_dic_dtsul no-lock:
         export tab_dic_dtsul.
END.
output close.


Mais detalhes sobre o procedimento de configuração e ativação de triggers: Instruções_de_Atualização_Versão_GPS

Verificar 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:

  • eventualmente eliminar arquivos temporários (por exemplo, durante a aplicação de um patch, aproveitando o momento em que o serviço está desligado):
    • Datasul
      • instancia-tomcat/logs
      • instancia-tomcat/temp
      • instancia-tomcat/work
    • Autorizador Web e Foundation Saúde
      • instancia-jboss/log
      • instancia-jboss/data
      • instancia-jboss/tmp
      • instancia-jboss/work


Datasul com banco de dados Oracle (Schema Holder)

O queComoPor que
Checar open_cursors

Executar em uma sessão conectada ao banco de dados Oracle, com privilégios de administrador:


select * from v$parameter p where p.name in ('open_cursors','processes','sessions')


Se o resultado for inferior a:

open_cursors: 30000
processes: 4000
sessions: 6024

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='*';
alter system set processes=4000 scope=spfile;
alter system set sessions=6024 scope=spfile;

Obs: o listener do Oracle deve ser reiniciado para que as  alterações tenham efeito.



Detalhes no item 28 do guia de instalação: Tutorial_de_Instalação_do_TOTVS_12_Oracle

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:

  • Se o Datasul está configurado com 10 bancos e tivermos 10 usuários conectados, isso se reflete em 100 sessões.
  • Se somarmos à configuração acima mais 10 agentes de Appserver, chegaremos a 200 sessões.
  • Se um usuário já tem uma sessão em aberto, e ele abrir mais uma sem fechar a anterior, chegaremos a 210 sessões.

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.

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


Exemplo da linha completa:

-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



Autorizador Web e Foundation Saúde

O queComoPor que
Pool Appserver x Jboss

Checar se as parametrizações do pool de agentes do Appserver estão compatíveis com as configurações do Jboss.


Appserver - entrar no Progress OpenEdge Explorer (http://<seu_servidor>:9090):

Checar nas propriedades do Broker qual é o Operating Mode que está configurado. O recomendado é State-reset:


Checar nas propriedades do Agent o valor do campo Maximum servers:  




Jboss - editar o arquivo .../<pasta_instalacao_jboss>/server/<instance>/conf/datasul/datasul_framework.properties:

Verificar os seguintes campos:

progress.server.mode=2 

2 equivale a State-reset (conforme recomendado acima para o Appserver). Se o Appserver for Stateless, então trocar para 1.



progress.server.maxconnections=15

o número aqui deve ser igual ao Maximum servers do Appserver (conforme visto acima).


Obs: Tanto Appserver como Jboss devem ser reiniciados, caso alguns dos parâmetros for alterado.

Referência: Documentação "datasul_framework.properties" 



Geral

O queComoPor que
Checar quantidade de processadores

Verificar o número de processadores virtuais da máquina.

Se for Windows, pode ser verificado pelo Task Manager: 


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.


Recomenda-se que um servidor de Produção tenha ao menos 16 processadores.