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

Valor correto (ubroker.properties / Progress Admin Services):

    operatingMode=State-reset

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.

No arquivo.pf de conexão aos bancos de dados, garantir que exista esta linha:

-q

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

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.

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

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"

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

No arquivo.pf de conexão aos bancos de dados, garantir que exista esta linha:

-q

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

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.

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

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

Alguns ofensores conhecidos que podem gerar volume considerável de arquivos na pasta temp:

• Geração de boletos
• Geração de relatórios
• Arquivos que ficam disponíveis para download dos usuários

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.

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

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.

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:

• O arquivo.war pode fazer chamadas ao backend com parâmetros pré-definidos. Se algum parâmetro estiver diferente, causará falha de comunicação.
• O arquivo.war pode conter diversas aplicações. Logo, ao enviar o arquivo para contorno de um problema em específico, outras aplicações podem ser afetadas como efeito colateral.
  • Nestes casos, ao invés de realizar o build do .war e enviá-lo ao cliente, pode ser mais prudente baixar o .war que o cliente já possui (patch), editá-lo apenas com a alteração necessária, zipar novamente e enviar este resultado, para minimizar impactos.

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:

• O arquivo.war pode fazer chamadas ao backend com parâmetros pré-definidos. Se algum parâmetro estiver diferente, causará falha de comunicação.
• O arquivo.war pode conter diversas aplicações. Logo, ao enviar o arquivo para contorno de um problema em específico, outras aplicações podem ser afetadas como efeito colateral.
  • Nestes casos, ao invés de realizar o build do .war e enviá-lo ao cliente, pode ser mais prudente baixar o .war que o cliente já possui (patch), editá-lo apenas com a alteração necessária, zipar novamente e enviar este resultado, para minimizar impactos.

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.

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

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

progress.server.mode=1 

progress.server.maxconnections=10 

Obs: Tanto Appserver como Jboss devem ser reiniciados caso algum dos parâmetros seja alterado.

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

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.