PC Toledo

Atualizando o tópico...

carlaoonline escreveu:Roda normal, sem precisar inicializar a máquina e, a princípio, roda em qualquer desktop remoto.

Decidi mudar o servidor para outra máquina, então não cheguei a usar o aplicativo no momento. Mas agradeço a indicação do CrystalDiskInfo

Itamar M. Lins Jr. escreveu:Lembre-se que MAPEAMENTO vc está TRANSFERINDO um arquivo de 1Gib para TODAS as maquinas da REDE, dependendo do processo.

Pois é, fiz um programinha de teste e instalei em 5 PCs do cliente (1 servidor e 4 pontos) além de deixar o sistema aberto em cada uma delas. Este programa faz um loop de 1 em 1 segundo abrindo o DBF e seus INDICES com mais de 1GB, ele faz uma busca e um REPLACE DE DADOS simulando uma interação, abri o gerenciador de recursos do Windows e acompanhei as transferências de rede. Não subiu quase nada em nenhum dos PCs, nem o servidor servindo os pontos e nem os pontos recebendo do servidor. Acompanhei a memória de cada PC ao fechar o processo em cada PC a memoria local teve diminuição em torno de 50mb. Eu imaginava que cada PC recebesse esses 1GB constantemente, mas não foi o observado.
Concordo que o uso do LetoDBf seja o mais indicado.

O sistema esta em testes por 2 dias e não ocasionou o erro ainda. Veja o que fiz:

1) Como disse o DBF estava com caracteres estranhos mas invisiveis. Fiz o metodo de criar um novo DBF para fazer o Append From, fiz o metodo do PACK e RECALL ALL e permanecia sempre acusando tais caracteres. Como tinha um DBF perfeito até a data 03/11/2022 usei estes dados e no arquivo atual do cliente DELETEI todos os registros inferiores a 04/11/2022, o que sobrou fiz um APPEND no DBF de 03/11/2022, assim fiz o teste e não acusou mais os caracteres estranhos.

2) Aproveitei e fiz uma limpeza deixando vendas do ano de 2021 ate a data atual. Tinha vendas de 2011...

Então não sei dizer com certeza se foi algum dos procedimentos acima que fez parar o problema, ou se não ocorreu por que o movimento nestes 2 dias foi muito abaixo do normal, sendo assim não exigindo muito do sistema.

Se tivesse que optar entre esses dois procedimentos creio que tenha sido a limpeza do DBF (diminuição de tamanho) que possa ter surtido uma melhora.

Itamar M. Lins Jr. escreveu:Eu sei o que passa na sua cabeça. Eu já passei por isso. "MAS FUNCIONAVA TUDO MUITO BEM", "EM OUTROS CLIENTES NÃO DÁ ESSE ERRO" e por ai vai.

Exatamente isso Itamar, sei das limitações desta topologia de rede e já passei por muitas coisas malucas. Mas sempre intriga quando estes erros começam acontecer do nada, mesmo sabendo que não são do sistema em si. Como disse neste cliente específico, ele teve queima de roteador (caiu água diretamente no aparelho), teve queima da rede elétrica (queimou diversos PCs pq o eletricista ligou rede 220 no 110), ele usa também uns 3 programas web em cada PC que ficam se comunicando a cada segundo com os servidores (consumindo recurso dos PCs e da rede), enfim, temos que tentar saber pelo menos o motivo desses erros malucos.
Outro detalhe, todos os Windows lá instalados não dão acesso a algumas configurações, sendo assim não consigo nem acessar o Windows Defender para incluir uma exceção da pasta, e creio, que também pode ser este o motivo, pois analisando o log de erro embora apareça DBFNTX/1010 Read Error, o erro do DOS acusa 5 (Lock falhou).


Vou acompanhar por esta semana e vou atualizando aqui as novidades.

ANDRIL escreveu:1) Como disse o DBF estava com caracteres estranhos mas invisiveis

Isso já indica algum problema provável até de disco.
Se entrar um caractere CTRL-Z, no DOS indicaria fim de arquivo, sem que seja fim de arquivo.

ANDRIL escreveu:Se tivesse que optar entre esses dois procedimentos creio que tenha sido a limpeza do DBF (diminuição de tamanho) que possa ter surtido uma melhora.

Acho que foi eliminar os caracteres estranhos, porque tudo pode acontecer.
Como eu mencionei, pode considerar fim de arquivo sem ser fim de arquivo.
Ou caracteres nos campos numéricos, ou datas inválidas.

Quando mencionou READ ERROR, não mencionou se veio algo adicional, como por exemplo DOS ERROR.
DOS ERROR indicaria erro detectado pelo sistema operacional.

Olá!

Este programa faz um loop de 1 em 1 segundo abrindo o DBF e seus INDICES com mais de 1GB, ele faz uma busca e um REPLACE DE DADOS simulando uma interação, abri o gerenciador de recursos do Windows e acompanhei as transferências de rede. Não subiu quase nada em nenhum dos PCs, nem o servidor servindo os pontos e nem os pontos recebendo do servidor.

Assim não dá para perceber.
Abre um arquivo de 1 Gib, faz um DO WHILE .NOT. EOF() por exemplo nas 5 maquinas sem INKEY(.5). abrindo mais outros arquivos de contas a receber por exemplo... Enfim, sucesso ai, quando os arquivos aumentarem irá ocorrer o problema, ou a rede ou as maquinas. Se usar WIFI meu caso vai perceber outro gargalo.
Usando LETODBf, eu preciso de além do inkey(.5) de mais outro recurso da HWGUI(DoEvents/ProcessMessage), para liberar os outros processos que ficam esperando o DO WHILE terminar. O WINDOWS manda a MSG -> ESSE SISTEMA/PROGRAMA NÃO ESTÁ RESPONDENDO.

Eu uso muito o INDEX TEMPORARY para relatórios.

Saudações,
Itamar M. Lins Jr.

atualizando o tópico...

Mais de uma semana rodando e não deu mais o erro depois que diminui o tamanho do arquivo, passou para 700Mb. Era o tamanho do arquivo o problema neste caso. Como sei?

Eu chequei a deixar o arquivo sem o(s) caratere(s) que acusavam "estranhos", ou seja, normal. Na verdade era 1 byte, dava para ver que o arquivo com problema (nem sei se isso realmente é um problema) tinha um byte a mais do que o que foi corrigido com o processo relatado no meu último post. Após a retirada deste 1 byte, instalei o arquivo no cliente, fiz a redução de registros e deixei funcionando. Três dias depois, como não deu mais o erro, puxei o arquivo do cliente e notei que veio com 1byte a mais novamente. Mas mesmo assim, o sistema não deu mais problema até hoje (09/01/23).

Vou acompanhar por uns 30 dias e se algo surgir posto aqui.

Depois desta descoberta sobre o tamanho do arquivo fiquei preocupado com os limites do Windows e também da rede. Sempre ouvia que sistemas feitos em Clipper tinham DBFs gigantescos com pelo menos 3GB sem usar recursos como LetoDBf ou outros. Talvez esses 3GB ou mais seja em ambiente monousuário.

Obrigado a todos pela ajuda!

ANDRIL escreveu:Sempre ouvia que sistemas feitos em Clipper tinham DBFs gigantescos com pelo menos 3GB sem usar recursos como LetoDBf ou outros. Talvez esses 3GB ou mais seja em ambiente monousuário.

3GB com certeza não é aceito nem em Clipper 16 bits, nem em Windows 32 bits, nem em Harbour 32 bits.

Sinceramente....
Acho que o problema foi resolvido com a troca do HD do servidor.

Como não prestou atenção na mensagem de erro, atribuiu tudo a limites.

READ ERROR pode vir acompanhado de:

DOS ERROR 5

DOS ERROR 32

DOS ERROR 64

e outros

Cada um representa um tipo de erro CAPTURADO PELO SISTEMA OPERACIONAL

JoséQuintas escreveu:3GB com certeza não é aceito nem em Clipper 16 bits, nem em Windows 32 bits, nem em Harbour 32 bits.

Então, como faziam antes? Não chegava a esses valores nos antigos sistemas?

JoséQuintas escreveu:Acho que o problema foi resolvido com a troca do HD do servidor.

Não foi. Embora troquei de PC com outro HD os erros continuaram igual no SERVIDOR anterior.

ANDRIL escreveu:pois analisando o log de erro embora apareça DBFNTX/1010 Read Error, o erro do DOS acusa 5 (Lock falhou).

Aqui mencionei sobre o DOS ERROR 5. Acesso Negado. Estanho por que o arquivo é aberto em modo SHARED e fica aberto o tempo todo e aleatoriamente dava o erro. Quem estava usando o arquivo fora a minha aplicação?? Pensei no Windows Defender talvez por ser um arquivo grande ele atacasse a ele. Porem, não consigui acessar as opções de desativa-lo ou colocar a pasta do sistema como exceção, então não pude testar esta parte.
Outra hipótese, é o arquivo muito grande e o sistema de bloqueio de arquivo falhe em algum momento deixando o arquivo inacessivel, enfim, são muitas hipóteses. Como não ocorreu mais o erro após diminuição do arquivo ficamos sem saber o real motivo. Quando o arquivo chegar novamente perto de 1GB talvez volte aqui para relatar o reinicio do problema.

ANDRIL escreveu:Então, como faziam antes? Não chegava a esses valores nos antigos sistemas?

A resposta é óbvia: NÃO
O ADS se tornou famoso justamente por dar mais limite e agilidade ao Clipper, mesmo assim, também tem limite conforme OS.

ANDRIL escreveu:Aqui mencionei sobre o DOS ERROR 5. Acesso Negado. Estanho por que o arquivo é aberto em modo SHARED e fica aberto o tempo todo e aleatoriamente dava o erro. Quem estava usando o arquivo fora a minha aplicação??

DOS ERROR 5 é acesso bloqueado/negado, isso não tem nada a ver com uso compartilhado, ou não poder bloquear registro.

Falou muito em Clipper, sua assinatura menciona Clipper, fico na dúvida se o erro foi com Harbour ou com Clipper.

Se for Clipper, aposto no NTX, e falta de liberação de CPU.

Se for Harbour.... pessoalmente não tive problema porque já tinha deixado de usar NTX, mas já houve relatos por aqui sobre o NTX.

Curiosidade, fico na dúvida se faria diferença:
O servidor antigo tinha somente um núcleo, e o atual tem mais núcleos?
Já olhou o consumo de CPU, por núcleo, se algum deles chega a 100% ou perto disso?

JoséQuintas escreveu:Se for Clipper, aposto no NTX, e falta de liberação de CPU.

O mesmo pra Harbour, em certas situações.

Vamos considerar também um erro comum:
Isso acaba com toda rede.

JoséQuintas escreveu:Falou muito em Clipper, sua assinatura menciona Clipper, fico na dúvida se o erro foi com Harbour ou com Clipper.

Uso Harbour 3.2 e atualmente NTX do Harbour. Tive também problemas com o CDX/IDX (dando erros estranhos registrados no hb_log).

JoséQuintas escreveu:O servidor antigo tinha somente um núcleo, e o atual tem mais núcleos?

Tudo I3 e todas as máquinas são de mesma configuração, foi comprado um lote.

JoséQuintas escreveu:Já olhou o consumo de CPU, por núcleo, se algum deles chega a 100% ou perto disso?

Não chequei a ver 1 a 1, mas a CPU no geral não estava alta o bastante para causar algum dano.

JoséQuintas escreveu:Vamos considerar também um erro comum:

Concordo, mas no código não tenho este erro. Sempre uso INKEY(1) dentro do loop.

Saliento que não havia modificado o sistema em nada e começou de repente o problema, em outros clientes nada do erro. Então, era algo extra sistema a ser resolvido neste cliente. Só não sabia o motivo, neste caso o tamanho do arquivo, embora eu suspeitasse, não conseguia estabelecer algo concreto perante isso.

Atualmente só uso Harbour 3.2, vou ajustar minha assinatura.

Fica este tópico aqui registrados para consultas e ajuda futura.