Comando transform trava e fecha o terminal

[fatorius]

Baixei os dados da receita federal e quando fui executar o comando transform, ele completou a atividade Processing base CNPJ, partners and taxes em mais ou menos uma hora. Após isso, ao criar os dados JSON para cada CNPJ (Creating JSON data for each CNPJ), ele rodou uns 5% da atividade em torno de 10 minutos e então os valores do terminal pararam de ser atualizados. Todos os valores permaneciam estáticos, o it/s era de uns 18000, mas o tempo decorrido, a porcentagem e a quantidade de dados convertidos não aumentavam. Com isso, o sistema operacional inteiro travou por um minuto, e quando voltou a funcionar, a janela do terminal foi fechada. Durante todo o processo de transform eu estava com o System monitor aberto em outra janela, e estava acompanhando o consumo de RAM e CPU o tempo todo. O computador estava usando uns 95% da CPU e 50% da memória RAM, e um pouco antes desse travamento acontecer, os valores de CPU e RAM despencaram para quase 0.

Você por acaso tem alguma ideia do que pode ter acontecido? Ou será que teria alguma forma de obter algum log do processo para saber o que causou esse crash? Já procurei no /var/log/syslog mas não havia nada do minha-receita. Teria algum outro lugar onde posso encontrar informações sobre o que levou o programa a crashar o terminal? Ou alguma forma de executar ele para dar display nas mensagens de erro... Talvez isso poderia dar uma luz a esse problema.

Informações que podem ser úteis:

Sistema operacional: Ubuntu 22.04.2 Versão do POSTGRESQL: 14.7 Versão do GO: 1.20.3 linux/amd64 Modo de execução do Minha-Receita: Compilado a partir do código fonte Modo de execução do banco de dados Postgresql: Nativo no sistema operacional Memória RAM disponível no computador: 16GB (Nada estava sendo executado na máquina além do Minha-Receita e o monitor do sistema) Processador: Intel i5 6600K 3.5 Ghz HD ou SSD: HD de 1TB, com 450GB disponíveis para o Ubuntu Comando executado: minha-receita transform -u postgresql://user:senha123@localhost:5432/db --no-privacy

[cuducos]

Ou será que teria alguma forma de obter algum log do processo para saber o que causou esse crash?

Não que eu saiba. Vez ou outra estou debugando coisa e sinto essa necessidade — e, por enquanto só vou adicionando logs temporários para debug no código fonte. Tosco, eu sei. É um assunto que preciso aprender mais…

O que eu recomendaria era variar um pouco os parâmetros que mais impactam uso de memória e processamento (--batch-size e --max-parallel-db-queries) e ver se tem alguma diferença.

Qual o data dos dados que está usando? Acabei de importar (hoje) os dados de produção sem problemas (localmente e em produção), já com o Badger mais novo (fe1b4e3).

[fatorius]

O que eu recomendaria era variar um pouco os parâmetros que mais impactam uso de memória e processamento (--batch-size e --max-parallel-db-queries) e ver se tem alguma diferença.

Certo! Vou testar com outros valores e te aviso do resultado

Qual o data dos dados que está usando? Acabei de importar (hoje) os dados de produção sem problemas (localmente e em produção), já com o Badger mais novo (fe1b4e3).

Os dados eram do dia 10 de abril, mesmo dia em que eu baixei e compilei o código-fonte, então eles não estão com a nova versão do Badger. Irei compilar novamente o programa agora com os pacotes novos do Go.

[fatorius]

Compilei novamente com o código atualizado, testei com 4 queries paralelos e batch de 4096, mas aconteceu o mesmo erro de antes. Reduzi mais uma vez para 2 queries e batch de 1024, dessa vez deu certo e demorou umas 7 a 8 horas para processar todos os dados.

Obrigado pela ajuda viuu!!

[jonathands]

@fatorius @cuducos comentando aqui para futura referenica...

percebi que tem uns meses o arquivo Estabelecimentos0.zip esta dando uma aumentada, ja esta em 1.1gb zipado, pode ser que esteja usando memoria demais na hora de processar ele