-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
memory leak? #82
Comments
Qual a configuração da maquina? |
Ubuntu Trusty 64 bits. A memoria ta mais do que suficent (8Go mas tem outras coisas rodando), o lance e que a gente ve que transmissao apos transmissao ele nao libera a memoria. Geralmente o Gunicorn ja supervisa os workers do Odoo e um worker nao consegue matar o processo pai. Nesse caso especifico porem, e o processo global que morre. Alem de observar a memoria engordar, eu nao sei o que mata o processo no final. Nesse caso nao temos supervisao entao fica misterioso mesmo. Ele morre com uns 80% da memoria ocupada apenas com a messagem:
no log. Talvez o Gunicorn nao consegue mais reservar a memoria que ele precisa e morre. Eu nao tenho a minima ideia. So tenho a impressao que algo da transmissao nao libera a memoria como deveria. Tambem como e um processo repititivo de cadastrar e transmitir notas, eu realmente acho que o processo para por causa do memory leak e nao algum outro problema pontual. Mas enfim relato o problema aqui. Isso vai ficar chato de debugar mesmo e aqui nao e prioridade. Quis apenas saber se alguem ja encontrou esse problema. Senao fica registrado para que o proximo se toca que pode ter um problema nisso. |
O limite de memoria do worker ta em quanto? |
@mileo nesse caso:
Porem nao e o Gunircorn que mata um worker, porque quando isso acontece, ele escreve no log e alem disso so o um worker morre e nao o processo pai. Eu nao acho que o problema tenha a ver com a supervisao do Gunicorn nesse caso. |
@rvalyi Tivemos alguns problemas no começo, mas eu não consegui diagnosticar se é um problema do PySPED ou algo relacionado. Mas depois de vários ajustes na nossa infraestrutura tenho rodado instancias com 512 ram emitindo nf-e tranquilamente. |
@mileo no caso nao estamos usando mas de 512Mo nesse servico. O unico problema que eu vejo e que a cada nota transmitida a memoria aumenta. Com uma supervisao por cima isso funciona com certeza. Agora nao deixa de ser um probleminha. Imagine que vc use o Odoo como CMS/ecommerce, vc vai ter seus workers consumindo rapidamente mais RAM do que vc deveria. Ai vc pode ter a supervisao que mata os workers ou o processo global (talvez). Mas ai restartando workers novos vc perde performance porque perde o cache por examplo. Nao acho que seja nehnum problema prioritario e nao acho que seja simples de resolver. So queria deixar arquivado algum lugar para ver se temos relatorios convergentes disso ate alguem achar algo para resolver. |
Filename: /home/mileo/Projects/odoo/odoo8-oca/parts/l10n_br/odoo-brazil-eletronic-documents/nfe/sped/nfe/processing/processor.py Line # Mem usage Increment Line Contents
Filename: /home/mileo/Projects/odoo/odoo8-oca/parts/l10n_br/odoo-brazil-eletronic-documents/nfe/sped/nfe/processing/xml.py Line # Mem usage Increment Line Contents
Filename: /home/mileo/Projects/odoo/odoo8-oca/parts/l10n_br/odoo-brazil-eletronic-documents/nfe/sped/nfe/processing/xml.py Line # Mem usage Increment Line Contents
Filename: /home/mileo/Projects/odoo/odoo8-oca/parts/l10n_br/odoo-brazil-eletronic-documents/nfe/models/account_invoice.py Line # Mem usage Increment Line Contents
Filename: /home/mileo/Projects/odoo/odoo8-oca/parts/l10n_br/odoo-brazil-eletronic-documents/nfe/sped/nfe/processing/processor.py Line # Mem usage Increment Line Contents
Filename: /home/mileo/Projects/odoo/odoo8-oca/parts/l10n_br/odoo-brazil-eletronic-documents/nfe/sped/nfe/processing/xml.py Line # Mem usage Increment Line Contents
Filename: /home/mileo/Projects/odoo/odoo8-oca/parts/l10n_br/odoo-brazil-eletronic-documents/nfe/sped/nfe/processing/xml.py Line # Mem usage Increment Line Contents
Filename: /home/mileo/Projects/odoo/odoo8-oca/parts/l10n_br/odoo-brazil-eletronic-documents/nfe/models/account_invoice.py Line # Mem usage Increment Line Contents
|
@rvalyi Não sou especialista nessas analises mas com um teste rápido aqui não vi o PySPED alocando muita memoria não. Inclusive removendo a geração do Danfe apos a transmissão e a opção de salvar aquivos |
E essa linha aqui: 143 165.0 MiB 0.7 MiB nfe.append(nfe_obj.set_xml(arquivo)) A segunda coluna me parece ser o incremento de memória né? |
Sim, incremento de memoria |
143 134.5 MiB 8.6 MiB nfe.append(nfe_obj.set_xml(arquivo)) Realizei vários testes, mas não esta me parecendo algo exato |
Que profiler é esse, pycharm? |
na verdade nao falei que ele usaria muita memoria, so me parece que ele nao estaria liberando tudo o que aloca e a cada nota ele usaria mais. Eu precisaria gastar um tempo com o profiler na instancia onde eu observei isso (ate esgotar a RAM varias vezes no caso), infelizmente tou ocupado com algumas outras coisas no momento... Mas enfim certeza que esse levantamento do uso da memoria servira o dia que mergulhar nisso de novo. |
@rvalyi Pior q era isso mesmo! Tava com tanto sono hoje a tarde q nem me liguei. Vou continuar com o profile ativo nos testes da NT003 e verificar se a memoria sobe ao longo do tempo. []s |
Ola pessoal
Temos um cliente que esta lancando centenas de notas hoje ele usa so a parte de criar NFe's e transmitir elas nesse tempo. A cada duas horas ou algo assim, o servidor cai, parece que ele esta aumentando o consumo da memoria RAM sempre. Provavelemte o processo ultrapassa o que ele pode alcancar.
Tou perguntando aqui se alguem ja viu algo assim porque e o unico projeto que temos onde acontece isso e acontece que o ERP so esta usando o pysped massivamente hoje.
A gente vai resolver o problema la com supervisao, mas seria interessante saber:
alguem ja observou algum memory leak nessa parte da transmissao das notas com o pysped?
Como esta usando algumas bibliotecas com extencoes em C por tras esse tipo de problema nao seria impossivel...
The text was updated successfully, but these errors were encountered: