Clipper On Line • Ver Tópico - Alto Consumo de Memoria

Alto Consumo de Memoria

Discussão sobre a biblioteca Fivewin - O Clipper para Windows.

Moderador: Moderadores

 

Alto Consumo de Memoria

Mensagempor nicanor » 28 Out 2019 08:35

Ola,

Estamos com o problema na nossa aplicação referente a aumento excessivo de consumo de memoria, durante a utilização a aplicação em si aumente de forma quase irrelevante seu consumo, porem o consumo total do windows aumenta entre 30 e 40%.
Ex; Após determinado período de utilização o consumo de memoria do processo da aplicação vai de 9 MB para 16 MB e em contra partida o consumo do windows que tinha iniciado em 40% vai para 75%, e assim que a aplicação é finalizada o consumo total do windows volta para o patamar inicial, ou seja, é realmente a aplicação que de alguma forma esta elevando esse consumo mesmo que o consumo da aplicação não tenha se elevado na mesma proporção, e não consegui identificar a causa do problema, alguém já passou por uma situação semelhante que possa me dar um direcionamento? Desde já agradeço

Atualmente estamos utilizando a seguinte versão xHarbour Builder Enterprise-February-2015-Build219, FWHX 15.01 e fizemos recentemente um upgrade para a 2018-Bld663.
nicanor
Usuário Nível 1

Usuário Nível 1
 
Mensagens: 1
Data de registro: 28 Out 2019 08:22
Cidade/Estado: Paracatu
Curtiu: 0 vez
Mens.Curtidas: 0 vez

Alto Consumo de Memoria

Mensagempor sygecom » 29 Out 2019 11:50

Tenho feito assim:

Tenho um SET TIMER da Hwgui ( mas pode ser em console ou outras gui usando Hb_IdleAdd() ) chamando a FUNCTION MemoryFlush a cada 5 minutos.

#include "dll.ch"
FUNCTION MemoryFlush
    SetProcess( -1, -1, -1)
RETURN NIL

DLL32 Function SetProcess( ;
   hWnd As LONG, nMinWorkingSpace As LONG, nMaxWorkingSpace As LONG ) ;
   As LONG PASCAL From "SetProcessWorkingSetSize" Lib "Kernel32.dll"
Leonardo Machado
xHarbour.org + Hwgui + PostgreSql
leonardodemachado@hotmail.com

Faça você também sua doação esse fórum é uma lenda viva: http://www.pctoledo.com.br/doacao
Avatar de usuário

sygecom
Usuário Nível 7

Usuário Nível 7
 
Mensagens: 7006
Data de registro: 21 Jul 2006 10:12
Cidade/Estado: Alvorada-RS
Curtiu: 1 vez
Mens.Curtidas: 130 vezes

Alto Consumo de Memoria

Mensagempor janio » 01 Nov 2019 07:10

tentei usar a função acima mas da erro na compilação na linha DLL32 Function...

O codigo so funciona para Xharbour e/ou FiveWin?? Teria algo semelhante para harbour?
fui...
e-mail:janioaguiar@yahoo.com.br
msn: janio_aguiar@hotmail.com
xHarbour1.2.1/Harbour3.2 + wvg + hwgui + Mediator + MySql
Avatar de usuário

janio
Colaborador

Colaborador
 
Mensagens: 1835
Data de registro: 06 Jul 2004 07:43
Cidade/Estado: UBAJARA - CE
Curtiu: 8 vezes
Mens.Curtidas: 68 vezes

Alto Consumo de Memoria

Mensagempor sygecom » 01 Nov 2019 07:22

Jânio,
Funciona com Harbour.

Vc add o include?
Leonardo Machado
xHarbour.org + Hwgui + PostgreSql
leonardodemachado@hotmail.com

Faça você também sua doação esse fórum é uma lenda viva: http://www.pctoledo.com.br/doacao
Avatar de usuário

sygecom
Usuário Nível 7

Usuário Nível 7
 
Mensagens: 7006
Data de registro: 21 Jul 2006 10:12
Cidade/Estado: Alvorada-RS
Curtiu: 1 vez
Mens.Curtidas: 130 vezes

Alto Consumo de Memoria

Mensagempor JoséQuintas » 01 Nov 2019 10:19

Só não entendo pra que usar isso em Harbour, mas...
seguindo o estilo da classe pra RMChart, pra montar uma pequena LIB, poderia ser assim:

Rotina genérica pra qualquer DLL
#include "hbdyn.ch"

FUNCTION CallDllStd( cDll, cName, ... )

   LOCAL nHandle, xValue

   nHandle := hb_LibLoad( cDll )
   xValue   := hb_DynCall( { cName, nHandle, HB_DYN_CALLCONV_STDCALL }, ... )
   hb_libFree( nHandle )

   RETURN xValue


Funções de API, exatamente iguais à API, sem restrição de uso
Poderia ser incluso tratamento extra para os parâmetros

FUNCTION wapi_SetProcessWorkingSetSize( ... )

   RETURN CallDllStd( "Kernel32.dll", "SetProcessWorkingSetSize", ... )


Opcional, ou chamada direta, ou rotina intermediária
FUNCTION LiberarMemoria()
   wapi_SetProcessWorkingSetSize(  -1, -1, -1 )
   RETURN NIL
José M. C. Quintas
Harbour 3.2, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"

https://github.com/JoseQuintas/
Avatar de usuário

JoséQuintas
Membro Master

Membro Master
 
Mensagens: 18013
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 15 vezes
Mens.Curtidas: 1206 vezes

Alto Consumo de Memoria

Mensagempor Itamar M. Lins Jr. » 01 Nov 2019 13:53

Ola!
Funciona com Harbour.

Pra quê ? Isso é a famosa "memory leaks" do xHB.
Alguma classe, etc que vai acumulando lixo na memória... da biblioteca FW.

Assunto bem antigo por sinal.

### OBJECT DESTRUCTORS ###
================================
Both Harbour and xHarbour support object destructors and both
compilers uses reference counters and garbage collector to
execute destructors. Anyhow the low level implementation is
different in the two compilers. In Harbour HVM is reentrant safe
so the implementation of destructors is much simpler. It also
keeps full control about reference counters and detects user
code errors bound with complex items in .prg and C code what
greatly helps to detect problems in user code or 3-rd party
libraries and gives protection against internal HVM memory
corruption. In the last years it also helped to located few
very hard to exploit bugs in core code.

In xHarbour there is some basic protection but it was never
fully functional. Sometimes it may cause that internal error
message is generated but in most of cases internal HVM memory
is silently corrupted. A good example which illustrates what
may happen is in Harbour source repository in harbour/tests/destruct.prg
This code can be compiled and executed by Harbour and xHarbour.
But only Harbour version detects user errors generating RTE
and is necessary in all cases to keep internal memory cleaned
protecting against corruption. The xHarbour version behavior
is random because this .prg code corrupts internal HVM memory.
It's possible that it will be executed without any visible
errors or it will generate GPF or internal error. But in all
cases it can be well seen using tools like valgrind or CodeGuard
that it corrupts internal memory so the results are unpredictable.
I.e. this is part of valgrind log generated during execution
of above destruct.prg compiled by xHarbour:

==22709== Invalid read of size 2
==22709== at 0x426E235: hb_gcItemRef (garbage.c:646)
==22709== by 0x425EDE5: hb_memvarsIsMemvarRef (memvars.c:2396)
==22709== by 0x426E674: hb_gcCollectAll (garbage.c:847)
==22709== by 0x426E899: HB_FUN_HB_GCALL (garbage.c:1179)
==22709== Address 0x485b096 is 22 bytes inside a block of size 56 free'd
==22709== at 0x4023B7A: free ()
==22709== by 0x42837A9: hb_arrayReleaseBase (arrays.c:1588)
==22709== by 0x428381A: hb_arrayRelease (arrays.c:1602)
==22709== by 0x4256B94: hb_itemClear (fastitem.c:248)
[...]
==22709== Invalid write of size 2
==22709== at 0x426E4C6: hb_gcItemRef (garbage.c:652)
==22709== by 0x425EDE5: hb_memvarsIsMemvarRef (memvars.c:2396)
==22709== by 0x426E674: hb_gcCollectAll (garbage.c:847)
==22709== by 0x426E899: HB_FUN_HB_GCALL (garbage.c:1179)
==22709== Address 0x485b096 is 22 bytes inside a block of size 56 free'd
==22709== at 0x4023B7A: free ()
==22709== by 0x42837A9: hb_arrayReleaseBase (arrays.c:1588)
==22709== by 0x428381A: hb_arrayRelease (arrays.c:1602)
==22709== by 0x4256B94: hb_itemClear (fastitem.c:248)
[...]
==22709== Invalid read of size 4
==22709== at 0x426E223: hb_gcItemRef (garbage.c:603)
==22709== by 0x425EDE5: hb_memvarsIsMemvarRef (memvars.c:2396)
==22709== by 0x426E674: hb_gcCollectAll (garbage.c:847)
==22709== by 0x426E899: HB_FUN_HB_GCALL (garbage.c:1179)
==22709== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==22709== Process terminating with default action of signal 11 (SIGSEGV)
==22709== Access not within mapped region at address 0x0

Harbour executes above code cleanly without any errors:

==28376== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1)
==28376== malloc/free: in use at exit: 0 bytes in 0 blocks.
==28376== malloc/free: 6,164 allocs, 6,164 frees, 10,323,064 bytes allocated.
==28376== All heap blocks were freed -- no leaks are possible.

Missing protection and error detection is not only problem for programmers.
It also causes that in xHarbour core code few bad bugs have not been fixed
so far though they exist for years. It also extremely time consuming problem
for core developers when users or 3-rd party developers reports problems with
some memory corruption and it's necessary to locate the reason.
I remember how much time I lost for such things working on xHarbour
in the past so later when I moved to Harbour it was one of the main goal
for me to resolve the problem.

In xHarbour there is disabled code which was designed to detect such
problems and it can be enabled by setting HB_ARRAY_USE_COUNTER_OFF macro
but it causes horrible runtime overhead and was never finished to be ready
as production extension. Such solution seems to be dummy way so I do not
believe that it will be ever finished.


Saudações,
Itamar M. Lins Jr.
Avatar de usuário

Itamar M. Lins Jr.
Colaborador

Colaborador
 
Mensagens: 6927
Data de registro: 30 Mai 2007 11:31
Cidade/Estado: Ilheus Bahia
Curtiu: 309 vezes
Mens.Curtidas: 503 vezes

Alto Consumo de Memoria

Mensagempor JoséQuintas » 01 Nov 2019 14:18

Talvez isso explique as mensagens de alerta ao usar HBMK2 pra compilar usando XHarbour.
Parece que até no compilador XHarbour acontece isso de não limpar memória direito.

Até isso o HBMK2 verifica !!!

xharbour.png


Nota:
Foi só coincidência...
Me passaram esta semana isso, e até achei ser normal.
José M. C. Quintas
Harbour 3.2, mingw, gtwvg, multithread, dbfcdx, ADO+MySql, PNotepad
"The world is full of kings and queens, who blind our eyes and steal our dreams Its Heaven and Hell"

https://github.com/JoseQuintas/
Avatar de usuário

JoséQuintas
Membro Master

Membro Master
 
Mensagens: 18013
Data de registro: 26 Fev 2007 11:59
Cidade/Estado: São Paulo-SP
Curtiu: 15 vezes
Mens.Curtidas: 1206 vezes

Alto Consumo de Memoria

Mensagempor rochinha » 14 Dez 2019 19:54

Amiguinhos,

[b]nicanor[/]b tem certeza que seja sua aplicação?

O spool do windows as vezes provoca isto.

Desativar o serviço Windows Update resolve usos excessivos.
Desativar o serviço MDM(machine debug manager) resolve usos excessivos.
Derrubar o aplicativo do windows DWM(fica na pasta system32) resolve usos excessivos.

Não são essenciais.
OPS! LINK QUEBRADO? Veja ESTE TOPICO antes e caso não encontre ENVIE seu email com link do tópico para fivolution@hotmail.com. Agradecido.

@braços : ? )

A justiça divina tarda mas não falha, enquanto que a justiça dos homens falha porque tarda.
Avatar de usuário

rochinha
Membro Master

Membro Master
 
Mensagens: 4538
Data de registro: 18 Ago 2003 20:43
Cidade/Estado: São Paulo - Brasil
Curtiu: 800 vezes
Mens.Curtidas: 242 vezes

Alto Consumo de Memoria

Mensagempor Kapiaba » 16 Dez 2019 10:52

Ola, se usa FIVEWIN, veja este exemplo para saida do programa.
Se for em uma FUNCTION, poste-a para ver-mos onde pode estar o problema.
As vezes, um WHILE... ENDDO, pode causar grandes problemas, ou algo dentro do
DEFINE DIALOG... ACTIVATE DIALOG... Pegue o habito de usar o SYSREFRESH() dentro
dos WHILE... ENDDO.

   DEFINE BUTTON oSaida RESOURCE "FECHAR", "FECHAR2" OF oBar                 ;
          NOBORDER GROUP PROMPT "Saida"                                      ;
          MESSAGE "Sair do Programa"                                         ;
          ACTION( oSaida:Toggle(), ENCERRA( oWnd ), oSaida:GoUp() )          ;
          TOOLTIP { "Encerrar WinOrcam - Finalizar",                         ;
                    "Encerrar o Programa Agora?   ", 1, CLR_WHITE, CLR_HBLUE }

   oSaida:oCursor := oHand

//-> Encerra o Programa
FUNCTION ENCERRA( oWnd  )

   LOCAL lRet, nKey := VK_RETURN, oMsgInter, oQuestao
   LOCAL oDlg, oFontSay, IDCor, oSaida, oCancela, oGroup, aGrad

   PUBLIC aArray, aResolucaoAtual

   aGrad := { { 0.30, CLR_WHITE, CLR_WHITE },{ 0.50, CLR_WHITE, CLR_WHITE } }

   DEFINE FONT oFontSay NAME "Ms Sans Serif" SIZE 0, -14 BOLD

   DEFINE DIALOG oDlg RESOURCE "DLG_TERMINAR" GRADIENT aGrad

   oDlg:lHelpIcon := .F.

   REDEFINE BITMAP oQuestao ID 121 RESOURCE "F_QUESTAO2" OF oDlg TRANSPARENT

   REDEFINE GROUP oGroup ID 501 OF oDlg FONT oFontSay COLOR CLR_HRED TRANSPARENT

   REDEFINE SAY ID 401 OF oDlg COLORS CLR_BLACK, CLR_WHITE UPDATE FONT oFontSay TRANSPARENT
   REDEFINE SAY ID 402 OF oDlg COLORS CLR_BLACK, CLR_WHITE UPDATE FONT oFontSay TRANSPARENT
   REDEFINE SAY ID 403 OF oDlg COLORS CLR_HRED,  CLR_WHITE UPDATE FONT oFontSay TRANSPARENT

   REDEFINE BUTTON oSaida ID 301 OF oDlg                                     ;
            ACTION( lPermissao := .T., oDlg:End() ) CANCEL

   oSaida:cTooltip :={ "Click no Botão Para Sair",                           ;
                       "Sair do Programa Agora? ", 1, CLR_WHITE, CLR_HBLUE }

   REDEFINE BUTTON oCancela ID 302 OF oDlg                                   ;
            ACTION( lPermissao := .F., oDlg:End() ) CANCEL

   oCancela:cTooltip :={ "Click no Botão Para Cancelar a Saida",             ;
                         "Cancelar a Saida do Programa?       ", 1, CLR_WHITE, CLR_HBLUE }

   SET FONT OF oSaida   TO oFontSay
   SET FONT OF oCancela TO oFontSay

   ACTIVATE DIALOG oDlg CENTERED

   //-> PermissÆo Para Sair do Menu Principal
   IF lPermissao  //-> Se for o Botao de Saida... Pimba!

      SETKEY( VK_F9,  { | nKey | NIL   } )
      SETKEY( VK_F11, { | nKey | NIL } )

      // LIBERA_TUDO()  // FECHA O PROGRAMA NA MEMORIA DEFINITIVAMENTE
      MsgRun( "FECHANDO O PROGRAMA E BANCOS DE DADOS.", ;
              "Por Favor, Espere! Vou Desligar.       ", ;
              { || WinExec( LIBERA_TUDO() ), 3 } )

      RETURN NIL

   ELSE

      // oFontSay:End()
      DeleteObject( oFontSay )

      lRet := .F.  //-> Volta ao Menu Principal

   ENDIF

RETURN( lRet )

//--Fecha o Programa Definitivamente
FUNCTION LIBERA_TUDO()

   DeleteObject( oFont )
   DeleteObject( oBrush )

   DbCommitAll()
   DbUnLockAll()
   DbCloseAll()

   FreeResources()
   Release All
   SysRefresh()

   HB_GCALL( .T. )  // limpar o lixo na memoria .F. so se tiver lixo
   CLEAR MEMORY

   IF FILE( "checkres.txt" )
      FErase( "checkres.txt" )
   ENDIF

   CheckRes()

   PostQuitMessage( 0 )
   QUIT

RETURN NIL


Abs.
Kapiaba
Colaborador

Colaborador
 
Mensagens: 1765
Data de registro: 07 Dez 2012 15:14
Cidade/Estado: São Paulo
Curtiu: 310 vezes
Mens.Curtidas: 119 vezes

Alto Consumo de Memoria

Mensagempor Kapiaba » 16 Dez 2019 10:56

Master Leornardo, MemoryFlush(), não é mais usado nas versões mais modernas do FIVEWIN the best, isto era para a versão VELHA do BCC55, hoy, no más. Saludos mi caro amigo.

Abs.
Kapiaba
Colaborador

Colaborador
 
Mensagens: 1765
Data de registro: 07 Dez 2012 15:14
Cidade/Estado: São Paulo
Curtiu: 310 vezes
Mens.Curtidas: 119 vezes

Alto Consumo de Memoria

Mensagempor Kapiaba » 16 Dez 2019 11:50

Em tempo, veja:

   SetResDebug( .T. )


http://forums.fivetechsupport.com/viewtopic.php?f=6&t=23502&p=126336&hilit=consumo+de+memoria#p126336

Se não entender, vá perguntado.

Abs.
Kapiaba
Colaborador

Colaborador
 
Mensagens: 1765
Data de registro: 07 Dez 2012 15:14
Cidade/Estado: São Paulo
Curtiu: 310 vezes
Mens.Curtidas: 119 vezes

Alto Consumo de Memoria

Mensagempor Wanderlei » 08 Set 2021 14:23

Leonardo essa função SetProcessWorkingSetSize salvo meu projeto.
Wanderlei Cardoso
Analista / Programador
XHarbour + GtWvW + FiveWin + HwGui + Firebird
Skype: cwanderlei
cwanderlei@yahoo.com.br
(62)98171-3059 - whatsapp

Imagem
Avatar de usuário

Wanderlei
Usuário Nível 3

Usuário Nível 3
 
Mensagens: 183
Data de registro: 25 Jan 2008 12:19
Cidade/Estado: Goiânia - GO
Curtiu: 13 vezes
Mens.Curtidas: 5 vezes




Retornar para FiveWin

Quem está online

Usuários vendo este fórum: Nenhum usuário registrado online e 8 visitantes


Ola Amigo, espero que meu site e forum tem lhe beneficiado, com exemplos e dicas de programacao.
Entao divulgue o link da Doacao abaixo para seus amigos e redes sociais ou faça uma doacao para o site forum...
MUITO OBRIGADO PELA SUA DOACAO!
Faça uma doação para o forum
cron
v
Olá visitante, seja bem-vindo ao Fórum Clipper On Line!
Efetue o seu login ou faça o seu Registro