Garbage collector ??????

Projeto [x]Harbour - Compilador de código aberto compatível com o Clipper.

Moderador: Moderadores

Hasse
Usuário Nível 4
Usuário Nível 4
Mensagens: 820
Registrado em: 19 Out 2004 10:30
Localização: Jaraguá do Sul - SC

Garbage collector ??????

Mensagem por Hasse »

Boa tarde colegas.

Estou com um problema.

Tenho um executável para indexar todos os arquivos de um determinado sistema.

Neste sistema há arquivos pequenos e grandes. Os grandes com 1.500.000, 2.500.000 e 4.500.000 de registros.

Sempre nos grandes, acontece de simplesmente abortar o executável no meio da indexação. Reiniciando o executável, e pulando os arquivos anteriores e indexando somente aquele arquivo onde abortou anteriormente, ele passa normalmente. No seguinte já dá pau novamente.

Não há qualquer mensagem de erro.

Dá a impressão de que a memória vai "enchendo", e de repente algo funciona mal e aborta o executável. Antigamente havia vários problemas deste tipo, e havia um recurso para esvaziar a memória com um recurso chamado "Garbage Collector" (tipo enviar para o lixo ou coletar o lixo). Me parece que no xHarbour isto não existe.

Qual ou quais as soluções para isto ?

Mais memória ? Trata-se de um Servidor com 1gB. Estou "rodando" o indexador no servidor para um serviço mais rápido.
Hasse
CP200 / CP500 / Basic / dBase III / dBase IV / Clipper Summer / RTlink / Exospace.
Clipper 5.3b / Blinker 7.0 / CDX com TAG
xHarbour 1.2.1-6604 / Borland C++ (5.5.1) 32 bit / HBmake.
Harbour 3.2.0dev (r1412121623) / MINGW / HBM2 / MiniGui HMG 3.1.4 / IDE (Roberto Lopez).
"Conheça todas as teorias, domine todas as técnicas, mas, quando tocares uma alma humana, seja apenas outra alma humana." (C.G.Jung)
Avatar do usuário
Maligno
Membro Master
Membro Master
Mensagens: 6398
Registrado em: 06 Jul 2004 01:40
Localização: Londrina/PR

Mensagem por Maligno »

Você consegue perceber se o sistema, enquanto indexando, vai se tornando mais lento, conforme passa o tempo?

O XHarbour tem a função HB_GCAll([<lForce>]) que, conforme o help diz, faz o trabalho de desfragmentação. Se o argumento for TRUE, isso é feito forçosamente, havendo ou não blocos de memória fragmentados ou mesmo se houver apenas uma pequena fragmentação. Se FALSE, só fará se for necessário.
Agora, também conforme o manual, esse tipo de serviço já é (ou deveria ser) realizado automaticamente nos tempos de ociosidade do sistema, em background.

Mas também é possível que o seu problema esteja relacionado a algum outro fator que não a memória.
[]'s
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.

---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Avatar do usuário
sygecom
Administrador
Administrador
Mensagens: 7131
Registrado em: 21 Jul 2006 10:12
Localização: Alvorada-RS
Contato:

Mensagem por sygecom »

Hasse, tenho sistema com base grandes e tenha a seguinte função que alias uso em outras determinadas parte do meu sistema.

Código: Selecionar todos

Func Limpa()  // limpa a memoria
HB_GCALL()
return nil
Então foi como o Maligno disse, nem sempre o problema é memoria...uma pergunta isso começou do nd ou sempre aconteceu ?
Como vc faz para criar seus indice ?
Eu aqui abro o banco,crio o indice e fecho o banco ...nos banco maiores...antes e depois de ndexar eu uso o limpa().

Abraços
Leonardo Machado
Leonardo Machado
xHarbour.org + Hwgui + PostgreSql
Avatar do usuário
Maligno
Membro Master
Membro Master
Mensagens: 6398
Registrado em: 06 Jul 2004 01:40
Localização: Londrina/PR

Mensagem por Maligno »

Eu aqui abro o banco,crio o indice e fecho o banco ...nos banco maiores...antes e depois de ndexar eu uso o limpa().
Como é (ou deveria ser) feito no próprio Clipper. Agora se isso não é feito de forma apropriada nos tempos de ociosidade do sistema, é certo pensar que o Xharbour padece do mesmo bug que se vê no Clipper, onde o GC em background não funciona como deveria.
[]'s
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.

---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Hasse
Usuário Nível 4
Usuário Nível 4
Mensagens: 820
Registrado em: 19 Out 2004 10:30
Localização: Jaraguá do Sul - SC

Mensagem por Hasse »

sygecom escreveu:Então foi como o Maligno disse, nem sempre o problema é memoria...
Que o problema podia ser de memória eu já aventei no passado, porém, já trocamos todos os bancos de memória, e o problema continua. Então imagino que não seja de memória.
sygecom escreveu:Uma pergunta isso começou do nd ou sempre aconteceu ?
O problema já vem acontecendo faz tempo, só que agora a coisa está se tornando meio desconfortável. Provavelmente pelo crescimento dos DBF's.
sygecom escreveu:Como vc faz para criar seus indice ?
Eu aqui abro o banco,crio o indice e fecho o banco ...nos banco maiores...antes e depois de ndexar eu uso o limpa().
O Sistema todo é parado. Os executáveis de todos os terminais são fechados. Os terminais não são desligados.

O executável indexador é "rodado" no Servidor, e somente ele, sem qualquer outro executável aberto.

Os arquivos são abertos um a um e indexados, e fechados em seguida.
Maligno escreveu:Você consegue perceber se o sistema, enquanto indexando, vai se tornando mais lento, conforme passa o tempo?
Aparentemente o computador não reduz o seu desempenho. Com o Gerenciador de Tarefas aberto a CPU fica na faixa dos 45 a 55% do início ao fim da operação.

Eu vou tentar usar a Função HB_GCALL(). Eu já havia lido a respeito, porém no texto entendi que ele somente é útil quando usado em conjunto com uma determinada ferramenta ou função que não me lembro mais qual.
Hasse
CP200 / CP500 / Basic / dBase III / dBase IV / Clipper Summer / RTlink / Exospace.
Clipper 5.3b / Blinker 7.0 / CDX com TAG
xHarbour 1.2.1-6604 / Borland C++ (5.5.1) 32 bit / HBmake.
Harbour 3.2.0dev (r1412121623) / MINGW / HBM2 / MiniGui HMG 3.1.4 / IDE (Roberto Lopez).
"Conheça todas as teorias, domine todas as técnicas, mas, quando tocares uma alma humana, seja apenas outra alma humana." (C.G.Jung)
Avatar do usuário
Maligno
Membro Master
Membro Master
Mensagens: 6398
Registrado em: 06 Jul 2004 01:40
Localização: Londrina/PR

Mensagem por Maligno »

Hasse escreveu:Que o problema podia ser de memória eu já aventei no passado, porém, já trocamos todos os bancos de memória, e o problema continua. Então imagino que não seja de memória.
Eu não me referia à um problema de hardware, mas a um possível problema de gerenciamento de memória por parte do XHarbour.
Mas teste a função. Não custa tentar. De repente, resolve o problema. :)
[]'s
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.

---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Hasse
Usuário Nível 4
Usuário Nível 4
Mensagens: 820
Registrado em: 19 Out 2004 10:30
Localização: Jaraguá do Sul - SC

Mensagem por Hasse »

Boa tarde colegas.

Fiz vários testes com a Função HB_GCALL(). Abaixo seguem os resultados com os diversos tamanhos de arquivos e os tempos resultantes.

Código: Selecionar todos

         ------ Número de Registros dos arquivos ------

Arq1       352.000    704.000    1.408.000    2.464.000

Arq2     1.265.000  2.527.000    5.054.000    8.845.000

Arq3     2.440.000  4.880.000    9.761.000   17.083.000


         ------------ Tempos em min:seg ---------------

sem GC     00:53      02:00        05:42        15:00

com GC     00:54      02:03        04:37        15:33
Todos os arquivos foram indexados num "tiro" só, com CDX, sem TAG.

Ao todo foram gerados 28 CDX partindo destes arquivos acima.

Algo muito interessante que notei é que a indexação COM O HB_GCALL() é mais lenta (muito pouco), mas nem sempre, como podem observar acima.

Outro ponto que me chamou a atenção foi na observação do desempenho no Gerenciador de Tarefas do Windows. Não houve coerência em % da CPU ocupada com relação ao tamanho do arquivo.

No caso da arq1 que é menor que o arq2, o primeiro ocupava a CPU em torno de 45%, o segundo em torno de 13%. o Último oscilou entre 15% e 22%, osculação esta que outros não apresentaram.

CONCLUSÃO: Fiz os testes no meu NoteBook, em nenhum caso houve aborto do indexador e com arquivo MUITO maiores. Devo ter rodado o indexador mais de 20 vezes. Desta forma sou forçado a crer que o problema está no Servidor do meu cliente.
Maligon escreveu:Eu não me referia à um problema de hardware, mas a um possível problema de gerenciamento de memória por parte do XHarbour.
Mas teste a função. Não custa tentar. De repente, resolve o problema.
Acredito que podemos descartar a tua suposição inicial.

Também vejo que preciso concentrar a minha atenção sobre o Servidor.

De qualquer forma vou testar o Indexador com o HB_GCALL() na próxima semana, no Servidor do cliente.

Assim que eu tiver resultados, posto aqui.

FINALMENTE: Só por curiosidade tentei rodar o mesmo indexador compilado com o Clipper e linkado com Blinker nestes aquivos grandes e NÃO conseguiu passar uma só vez. Sempre abortou. Só não me lembro se na época ele foi linkado para trabalhar em modo protegido ou não.
Hasse
CP200 / CP500 / Basic / dBase III / dBase IV / Clipper Summer / RTlink / Exospace.
Clipper 5.3b / Blinker 7.0 / CDX com TAG
xHarbour 1.2.1-6604 / Borland C++ (5.5.1) 32 bit / HBmake.
Harbour 3.2.0dev (r1412121623) / MINGW / HBM2 / MiniGui HMG 3.1.4 / IDE (Roberto Lopez).
"Conheça todas as teorias, domine todas as técnicas, mas, quando tocares uma alma humana, seja apenas outra alma humana." (C.G.Jung)
Responder