Problema memória do LabVIEW

[DBernardes]

[DBernardes]

Levantar uma flag de erro quando atingir 80% da memoria RAM. Logar esta mensagem junto dos parâmetros da aquisição.

ACS2 travou com 40% (6.5 GB) de RAM, mesmo utilizando HIGH priority. 2.8 GB são do OS

LV 32bit trabalha com até 4 GB.

[DBernardes]

Teste com LV64 bits

• Instalei o LabVIEW com sucesso. Nem pediu licença
• Com segui lotar a RAM em até 99%
• Após isso, ficou travado em 99%. Parei a aquisição, o ACS ainda permaneceu salvando imagem por um longo período de tempo (~20min). O HD da máquina lotou e o ACS travou. Precisei parar a aplicação.
• Além disso, notei que não faz diferença no tempo de o python demora para salvar uma imagem, caso sejam utilizadas as extensões U16 ou U32.

[DBernardes]

20250710

Testes com o LV64 no canal 2

• ACS no modo simulado
• A máquina possui 16 GB de RAM
• Parece que ficaram 2 GB na RAM, mesmo após o S4ACS terminar de salvar todas as imagens. Talvez tem alguma coisa ocupando memória no software?
• Consegui chegar em 99% da RAM
• Precisei de 9.700 imagens (19 GB). Quando terminei o teste, a máquina ainda estava salvando as imagens 5500.
• CPU em 30%.
• Foram 16 minutos para terminar de salvar todas as imagens. Contudo, após o teste, a RAM ainda ficou em 97%. Mesmo soltando uma imagem única, a RAM não liberou. Isto foi diferente de minha máquina local. Parei o ACS e a RAM caiu para 17%.

Segundo teste

• Utilizando um texp de 40 ms (simular a câmera)
• RAM inicial de 17%
• Após o término da aquisição, o índice da imagem salva estava em 4800.
• Cheguei a 96% da RAM
• Foram geradas 9800 imagens.
• Foram necessários 14 min para salvar tudo. A memória da máquina fixou em 88% após isso. Parei o ACS e caiu para 17%

[DBernardes]

20250711

• Fiz um teste utilizando o profiling de memória do LabVIEW. Fiz uma aquisição de 1400 imagens e esperei terminar da salvar. Parando o profiling, o maior uso de memória aconteceu para o Save_Image.vi, com um total de 6 MB
• Link:
  • When a top-level VI calls a subVI, LabVIEW allocates a data space of memory in which that subVI runs. When the subVI finishes running, LabVIEW usually does not deallocate the data space until the top-level VI finishes running or until the entire application stops, which can result in out-of-memory conditions and degradation of performance. Use this function to deallocate the data space immediately after the VI completes execution
  • Contudo, fiz um teste utilizando este funcionalidade e não resolveu nada.

Teste

• RAM inicial 10.2 GB.
• Aquisição de uma série de 4 ciclos de 1400 imagens. RAM final de 15 GB (47%).
• Caiu para 14.7 GB depois de um tempo
• Mandei uma nova série e a RAM começou a aumentar. Acabou em 17.3 GB

[DBernardes]

20250829

Olá, pessoal

Acredito que encontrei uma informação importante à respeito dos testes de alta cadência.

Lendo à respeito sobre o uso de memória, encontrei que o acúmulo de memória RAM utilizada pelo ACS pode estar relacionado com o próprio OS estar reservando esta memória para uso da aplicação.

Seria como uma reserva para uso futuro, dada a alta demanda da primeira série de imagens.

Além disso, utilizando uma ferramenta da própria National, pude novamente constatar que o máximo de memória utilizada pelo ACS numa única iteração é de 14 MB.

Logo, não existem variáveis no código ocupando grandes espaços de memória.

Dessa forma, fiz um teste para verificar a hipótese da reserva de RAM alocada pelo OS.

Na minha máquina local, rodei o mesmo teste do email anterior para uma série de imagens que, ao final, ocupou 40% da RAM.

Após o término da escrita de todas as imagens em disco, soltei novamente a mesma série.

Como resultado, constatei que a memória RAM ocupada pelo ACS permaneceu em 40% durante todo o experimento.

Logo, acredito que a hipótese da reserva de RAM seja válida e, "desde que caiba na RAM", não existe risco da versão 64bits do ACS quebrar por falta de memória.

O que falta agora  para resolver este problema é o caso do tempo após a aquisição para o término da escrita de todas as imagens em disco.

Estarei pesquisando sobre formas de liberar mais processamento da CPU para o labview

Atenciosamente

Denis

[DBernardes]

Agora sobre aumentar o processamento

• Links úteis:
  • How-to-make-labview-program-run-faster
• os 20% que o task manager apresentar é a frequência do processador. Aumentar isso irá causar calor excessivo
• O labview já faz uma boa divisão da tarefas de modo a igualar a carga de trabalho por todos os núcleos. Sera?
• Outra solução seria paralelizar o loop. Mas não tem como fazer isso em loops while.
• Tentei mudar a prioridade em Task Manager > Details > LabVIEW.exe, mas não adiantou.
• Tenho a impressão de que o OS vai alterando os CPUs trabalhando. Deve ser por causa de aquecimento. Com isso, a RAM para de subir. Mas daí, eles precisam ser desligados para resfriar. Com isso, a RAM volta a subir.
• task-manager-set-priority → Utilizei este link que explica como alterar a prioridade de uma tarefa executada pelo windows. Coloquei a prioridade para real-time. Também encontrei que tem como definir em quais núcleos o sistema vai rodar. Percebi que já estava configurado para todos os sistemas. Nas configurações, alterei também o power mode do computador para melhor performance. Fiz um teste de alta cadência com esta configuração, mas nada mudou, ainda assim as imagens geradas estavam sendo acumuladas na memoria RAM.
• Talvez valha a pena mudar o power mode dos ACSs