PC Toledo

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.

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.

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

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.

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 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.

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.

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.