Monitoramento de memoria por arquivo CSV

É importante para um administrador do sistema acompanhar o crescimento de memória do Appserver, observar os períodos do dia mais críticos de utilização dos usuários e saber assim os momentos mais oportunos para troca de rpo ou reinicialização de serviços, ou até para saber quando é o momento de crescer o ambiente (na horizontal) com a disponibilização de novos slaves no balanceamento de carga.

Os recursos do S.O. disponíveis não são flexíveis a ponto de conseguir logar momentos específicos com "pontos personalizados", ou logar em que programas especificamente do ERP o Appserver estava rodando. Pensando nessa necessidade foi desenvolvido uma nova funcionalidade interna no Appserver que permite logar em um arquivo essas informações de variação de memória, assim como a chave ServerMemoryInfo, porem em um formato que seja facilmente exportado para um aplicativo de planilha eletrônica e conseguir criar um gráfico dessas informações, tornando mais fácil sua leitura.

Uma outra forma de usar esse recurso é junto com a função ShowInfMem, fazendo com que cada chamada especifica no seu programa possa ser logado no arquivo, podendo realizar facilmente o diagnostico dos pontos a serem logados.

Modo de utilização e casos de uso

É necessário que as seguintes chaves de ini sejam ativadas no arquivo appserver.ini:

[GENERAL]
...
DebugThreadUsedMemory=1
EnableMemInfoCSV=1
;A chave abaixo é para indicar um local especifico para geração do relatório, opcional
MemInfoCSVFile=c:\logcsv\server01.csv
;O valor da chave abaixo, por padrão, é 1, porem se desativada o recurso do relatório em CSV não terá o efeito desejado
MemPoolShrink=1
; ------------------------
 

No caso acima, será criado o arquivo server01.csv, e caso esse já exista, será criado o arquivo AAAAMMDDserver01.csv (A - ano, M - mês, D - dia), com o intuito de manter registrado o dia em que o server foi iniciado e seu registro desde então (para cada reinicialização, em dias diferentes, um novo arquivo será criado). Em caso de não indicar um nome, o arquivo será registrado na pasta do Appserver com o nome AAAAMMDDdefault.csv. O arquivo, ao ser aberto por uma planilha eletrônica, poderá ser visualizado como abaixo:

As linhas em A indicam momentos específicos de coletas de dados dos pools de memórias, as colunas em seguida indicam o tipo de memória e o número de objetos alocados na memória. A partir desse dados, é possível extrair um gráfico do consumo de memória como o exemplo a seguir:

Na execução desse exemplo, foi utilizado as chamadas da função ShowinfMem em um programa teste, indicando momentos específicos de inicio e fim, a caráter de debug e analise de código e consumo. Pode-se observar a realização de diversas execuções que se mostraram estáveis no consumo de memória. Para esses casos de debug, a fim de evitar falsos positivos, segue as mesmas recomendações da função ShowInfMem: deve-se realizar o uso apenas de uma thread entre as comparações dos valores retornados pela função evitando processos concorrentes.

Além disso, o mecanismo de monitoramento, graças a chave do MemPoolShrink ativa, registrará nos momentos de compactação da memória do pool, um novo registro no arquivo csv a fim de que o recurso de log não seja utilizado somente em debug de sua aplicação, mas ser logado também na utilização do Appserver como um serviço ou na execução do ERP. Observe por exemplo o casos abaixo:

O gráfico mostra metade de um dia em uma operação em um programa que após um alto processamento (também a ser analisado no console.log), o Appserver voltou a alocar o mesmo número de objetos na memória, para então o operador finalizar o ambiente as 18:30. O Appserver, quando realmente não tem mais nenhum usuário no sistema, deve estar com a maioria dos seus pools zerados, ou pode caracterizar algum erro de programação ou sistema. Nesses casos, procure cercar os programas executados nesse ambiente, e isole-os para ter uma noção melhor de onde está ocorrendo o problema.

Observe o gráfico abaixo:

Nesse caso real extraído em um cliente, onde o Appserver estava com uma alocação ao final do dia em quase 4GB, foi cercado a rotina de processamento (um JOB de processamento de entrada e saída de estoque) com a função ShowInfMem, e o que foi possível observar era o Appserver após a 7 rodada do JOB passou a ficar muito instável e com altas variações de alocação de objetos entre cada rotina. Com essa informação, houve o trabalho de identificar nos arquivos de console.log o que houve de diferente nesse ponto, sendo possível diagnosticar mais facilmente a partir de que momento começou a ocorrer o problema.

Veja também

DebugThreadUsedMemory, ShowInfMem - ADVPL, ShowInfMem, EnableMemInfoCSV