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.
Garbage collector ??????
Moderador: Moderadores
-
Hasse
- Usuário Nível 4

- Mensagens: 820
- Registrado em: 19 Out 2004 10:30
- Localização: Jaraguá do Sul - SC
Garbage collector ??????
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)
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)
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.
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!
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!
- sygecom
- Administrador

- Mensagens: 7131
- Registrado em: 21 Jul 2006 10:12
- Localização: Alvorada-RS
- Contato:
Hasse, tenho sistema com base grandes e tenha a seguinte função que alias uso em outras determinadas parte do meu sistema.
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
Código: Selecionar todos
Func Limpa() // limpa a memoria
HB_GCALL()
return nil
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
xHarbour.org + Hwgui + PostgreSql
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.Eu aqui abro o banco,crio o indice e fecho o banco ...nos banco maiores...antes e depois de ndexar eu uso o limpa().
[]'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!
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

- Mensagens: 820
- Registrado em: 19 Out 2004 10:30
- Localização: Jaraguá do Sul - SC
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:Então foi como o Maligno disse, nem sempre o problema é memoria...
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:Uma pergunta isso começou do nd ou sempre aconteceu ?
O Sistema todo é parado. Os executáveis de todos os terminais são fechados. Os terminais não são desligados.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 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.
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.Maligno escreveu:Você consegue perceber se o sistema, enquanto indexando, vai se tornando mais lento, conforme passa o tempo?
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)
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)
Eu não me referia à um problema de hardware, mas a um possível problema de gerenciamento de memória por parte do XHarbour.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.
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!
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

- Mensagens: 820
- Registrado em: 19 Out 2004 10:30
- Localização: Jaraguá do Sul - SC
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.
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.
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.
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:33Ao 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.
Acredito que podemos descartar a tua suposição inicial.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.
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)
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)
