Python em Linux 64 bits e o maldito memory leak

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Python em Linux 64 bits e o maldito memory leak

Thiago F. Pappacena
Senhores,

desculpe voltar a este assunto, mas algum dos senhores utiliza Python
em Linux 64 bits?

Explico: como já expliquei em [1], tenho problemas com consumo de
memória em umas aplicações. Mas uns testes mais recentes me
preocuparam um pouco: compilando o python-2.6.5 com um "./configure &&
make" normal, tenho memory leak. Entretanto, se eu compilar o mesmo
python com as flags -m32 (ou seja, compilar o Python em modo de
compatibilidade 32 bits), não só deixo de ter o leak, como minhas
aplicações passam a consumir bem menos memória. Ou seja, não há nada
mais de diferente na máquina. Apenas a compilação do próprio python.

O código testado está em [2]. O resultado do teste é o seguinte:

Compilado em 64 bits:
Memória residente total antes do "del": 427MB
Memória residente total depois do "del": 420MB

Compilado em 32 bits:
Memória residente total antes do "del": 225MB (quase metade!!)
Memória residente total depois do "del": 14MB (tudo que eu queria na vida...)


Alguém mais da lista tem esse tipo de problema?

[1] http://old.nabble.com/Strings-e-consumo-eterno-de-mem%C3%B3ria-td26500252.html
[2] http://pastebin.com/bfJts4jW


[]'s,
Thiago F. Pappacena

Good things come for those who wait...
... and for the efficient people who doesn't wait too, but faster:
Open source, XP, OO, Python, VIM, Bash and Gentoo.
Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Rodrigo Lira
Qual versão de Linux você usa?

Rodrigo Lira

Embora ninguém possa voltar atrás e fazer um novo começo, qualquer um pode
começar agora e fazer um novo fim. (Chico Xavier)
   _
|  °v°
| /(S)\    SLACKWARE
|  ^ ^           Linux
_____________________




Em 11 de junho de 2010 16:37, Thiago F. Pappacena <[hidden email]>escreveu:

>
>
> Senhores,
>
> desculpe voltar a este assunto, mas algum dos senhores utiliza Python
> em Linux 64 bits?
>
> Explico: como já expliquei em [1], tenho problemas com consumo de
> memória em umas aplicações. Mas uns testes mais recentes me
> preocuparam um pouco: compilando o python-2.6.5 com um "./configure &&
> make" normal, tenho memory leak. Entretanto, se eu compilar o mesmo
> python com as flags -m32 (ou seja, compilar o Python em modo de
> compatibilidade 32 bits), não só deixo de ter o leak, como minhas
> aplicações passam a consumir bem menos memória. Ou seja, não há nada
> mais de diferente na máquina. Apenas a compilação do próprio python.
>
> O código testado está em [2]. O resultado do teste é o seguinte:
>
> Compilado em 64 bits:
> Memória residente total antes do "del": 427MB
> Memória residente total depois do "del": 420MB
>
> Compilado em 32 bits:
> Memória residente total antes do "del": 225MB (quase metade!!)
> Memória residente total depois do "del": 14MB (tudo que eu queria na
> vida...)
>
> Alguém mais da lista tem esse tipo de problema?
>
> [1]
> http://old.nabble.com/Strings-e-consumo-eterno-de-mem%C3%B3ria-td26500252.html
> [2] http://pastebin.com/bfJts4jW
>
> []'s,
> Thiago F. Pappacena
>
> Good things come for those who wait...
> ... and for the efficient people who doesn't wait too, but faster:
> Open source, XP, OO, Python, VIM, Bash and Gentoo.
>
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

,-----------------------------------------------------------.
| Antes de enviar um e-mail para o grupo leia:              |
| http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
| E se você é usuário do BOL lembre-se de cadastrar o       |
| e-mail do grupo na lista branca do seu sistema anti-spam. |
`-----------------------------------------------------------´Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Luciano Ramalho
In reply to this post by Thiago F. Pappacena
Thiago, porque você compila o Python? Repetindo a pergunda do Rodrigo
Lira, qual versão de Linux você usa? A distribuição Linux que vc usa
não tem um pacote com uma versão de Python que rode a sua aplicação?

2010/6/11 Thiago F. Pappacena <[hidden email]>:

> Senhores,
>
> desculpe voltar a este assunto, mas algum dos senhores utiliza Python
> em Linux 64 bits?
>
> Explico: como já expliquei em [1], tenho problemas com consumo de
> memória em umas aplicações. Mas uns testes mais recentes me
> preocuparam um pouco: compilando o python-2.6.5 com um "./configure &&
> make" normal, tenho memory leak. Entretanto, se eu compilar o mesmo
> python com as flags -m32 (ou seja, compilar o Python em modo de
> compatibilidade 32 bits), não só deixo de ter o leak, como minhas
> aplicações passam a consumir bem menos memória. Ou seja, não há nada
> mais de diferente na máquina. Apenas a compilação do próprio python.
>
> O código testado está em [2]. O resultado do teste é o seguinte:
>
> Compilado em 64 bits:
> Memória residente total antes do "del": 427MB
> Memória residente total depois do "del": 420MB
>
> Compilado em 32 bits:
> Memória residente total antes do "del": 225MB (quase metade!!)
> Memória residente total depois do "del": 14MB (tudo que eu queria na vida...)
>
>
> Alguém mais da lista tem esse tipo de problema?
>
> [1] http://old.nabble.com/Strings-e-consumo-eterno-de-mem%C3%B3ria-td26500252.html
> [2] http://pastebin.com/bfJts4jW
>
>
> []'s,
> Thiago F. Pappacena
>
> Good things come for those who wait...
> ... and for the efficient people who doesn't wait too, but faster:
> Open source, XP, OO, Python, VIM, Bash and Gentoo.
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | Antes de enviar um e-mail para o grupo leia:              |
> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> | E se você é usuário do BOL lembre-se de cadastrar o       |
> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> `-----------------------------------------------------------´Links do Yahoo! Grupos
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Danilo Cabello
In reply to this post by Thiago F. Pappacena
Thiago,

2010/6/11 Thiago F. Pappacena <[hidden email]>:
> Compilado em 64 bits:
> Memória residente total antes do "del": 427MB
>
> Compilado em 32 bits:
> Memória residente total antes do "del": 225MB (quase metade!!)

Não sei se estou certo, mas a questão de ser praticamente o dobro tem
relação com o uso de números do código, não? 32 bits suporta 2^32
valores inteiros já 64 bits suporta 2^64, mas esses bits são guardados
na memória.

Não está diretamente o dobro, pois existe a string também na sua classe Foo.

--
Danilo Cabello
Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Luciano Ramalho
2010/6/12 Danilo Cabello <[hidden email]>:
> Não sei se estou certo, mas a questão de ser praticamente o dobro tem
> relação com o uso de números do código, não? 32 bits suporta 2^32
> valores inteiros já 64 bits suporta 2^64, mas esses bits são guardados
> na memória.

Sim, você está certíssimo, Danilo. Isso explica porque o programa
ocupa praticamente o dobro de memória quando o interpretador Python é
compilado para rodar em 64 bits.

Falta só entender porque as referências apagadas com del não estão
ocasionando a liberaçãode memória na mesma razão que o Thiago
demonstrou em 32 bits.

Thiago, você pode colocar no pastebin os comandos que usou para
verificar a memória em uso, para facilitar que outros reproduzam o
problema?

[ ]s
Luciano
Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Thiago F. Pappacena
Pessoal,

eu utilizo Gentoo Linux, e costumo utilizar o pacote da distribuição
para isso. Só compilei o Python original para me certificar de que não
era um problema da compilação da minha distribuição (o que eu já havia
constatado, já que o Python no Ubuntu 64 parece ter o mesmo problema).
E para que o benchmark fosse mais justo (o Gentoo pode colocar algumas
flags diferentes no configure).

Notem que o numero é armazenado na classe Foo, e não em cada instância
(ou eu confundi o comportamento?). Deveria haver apenas 1 número
inteiro na memória, certo? A memória ocupada realmente deveria ser tão
maior por conta disso? Por que não percebo discrepância tão grande
assim no consumo de memória em outros programas de 32 para 64 bits
(lembre-se que meu Gentoo inteiro é 64 bits em uma máquina, e
totalmente 32 bits em outra!)?

Luciano, o comando que utilizei foi um simples "top", observando a
memória residente (RES) ocupada pelo programa. Mas observar o total de
memória ocupada sem buffer/cache no "free -m" também demonstra o
problema.

Alguma luz? Ou um bugreport faria sentido?

[]'s,
Thiago F. Pappacena

Good things come for those who wait...
... and for the efficient people who doesn't wait too, but faster:
Open source, XP, OO, Python, VIM, Bash and Gentoo.


2010/6/13 Luciano Ramalho <[hidden email]>

>
>
>
> 2010/6/12 Danilo Cabello <[hidden email]>:
>
> > Não sei se estou certo, mas a questão de ser praticamente o dobro tem
> > relação com o uso de números do código, não? 32 bits suporta 2^32
> > valores inteiros já 64 bits suporta 2^64, mas esses bits são guardados
> > na memória.
>
> Sim, você está certíssimo, Danilo. Isso explica porque o programa
> ocupa praticamente o dobro de memória quando o interpretador Python é
> compilado para rodar em 64 bits.
>
> Falta só entender porque as referências apagadas com del não estão
> ocasionando a liberaçãode memória na mesma razão que o Thiago
> demonstrou em 32 bits.
>
> Thiago, você pode colocar no pastebin os comandos que usou para
> verificar a memória em uso, para facilitar que outros reproduzam o
> problema?
>
> [ ]s
> Luciano
>
>


------------------------------------

,-----------------------------------------------------------.
| Antes de enviar um e-mail para o grupo leia:              |
| http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
| E se você é usuário do BOL lembre-se de cadastrar o       |
| e-mail do grupo na lista branca do seu sistema anti-spam. |
`-----------------------------------------------------------´Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Vitor Iha
In reply to this post by Luciano Ramalho
2010/6/13 Luciano Ramalho <[hidden email]>

>
> Falta só entender porque as referências apagadas com del não estão
> ocasionando a liberaçãode memória na mesma razão que o Thiago
> demonstrou em 32 bits.
>
> Thiago, você pode colocar no pastebin os comandos que usou para
> verificar a memória em uso, para facilitar que outros reproduzam o
> problema?
>

Isso já foi explicado e ele mesmo indicou a thread. Experimenta fazer o
seguinte: após o del crie outro conjunto de objetos e observe que o seu
programa consome praticamente a mesma coisa. Se consumir bem mais é
realmente um memory leak.
--
iha


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Gabriel Morrison Lima Dantas-2
In reply to this post by Thiago F. Pappacena
Em 13 de junho de 2010 10:54, Thiago F. Pappacena escreveu:

> Pessoal,
>
> eu utilizo Gentoo Linux, e costumo utilizar o pacote da distribuição
> para isso. Só compilei o Python original para me certificar de que não
> era um problema da compilação da minha distribuição (o que eu já havia
> constatado, já que o Python no Ubuntu 64 parece ter o mesmo problema).
> E para que o benchmark fosse mais justo (o Gentoo pode colocar algumas
> flags diferentes no configure).
>
> Notem que o numero é armazenado na classe Foo, e não em cada instância
> (ou eu confundi o comportamento?). Deveria haver apenas 1 número
> inteiro na memória, certo? A memória ocupada realmente deveria ser tão
> maior por conta disso? Por que não percebo discrepância tão grande
> assim no consumo de memória em outros programas de 32 para 64 bits
> (lembre-se que meu Gentoo inteiro é 64 bits em uma máquina, e
> totalmente 32 bits em outra!)?
>
> Luciano, o comando que utilizei foi um simples "top", observando a
> memória residente (RES) ocupada pelo programa. Mas observar o total de
> memória ocupada sem buffer/cache no "free -m" também demonstra o
> problema.
>
> Alguma luz? Ou um bugreport faria sentido?
>
> []'s,
> Thiago F. Pappacena
>
> Good things come for those who wait...
> ... and for the efficient people who doesn't wait too, but faster:
> Open source, XP, OO, Python, VIM, Bash and Gentoo.
>
>
> 2010/6/13 Luciano Ramalho
> >
> >
> >
> > 2010/6/12 Danilo Cabello
> >
> > > Não sei se estou certo, mas a questão de ser praticamente o dobro tem
> > > relação com o uso de números do código, não? 32 bits suporta 2^32
> > > valores inteiros já 64 bits suporta 2^64, mas esses bits são guardados
> > > na memória.
> >
> > Sim, você está certíssimo, Danilo. Isso explica porque o programa
> > ocupa praticamente o dobro de memória quando o interpretador Python é
> > compilado para rodar em 64 bits.
> >
> > Falta só entender porque as referências apagadas com del não estão
> > ocasionando a liberaçãode memória na mesma razão que o Thiago
> > demonstrou em 32 bits.
> >
> > Thiago, você pode colocar no pastebin os comandos que usou para
> > verificar a memória em uso, para facilitar que outros reproduzam o
> > problema?
> >
> > [ ]s
> > Luciano
> >
> >
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | Antes de enviar um e-mail para o grupo leia:              |
> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> | E se você é usuário do BOL lembre-se de cadastrar o       |
> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> `-----------------------------------------------------------´Links do
> Yahoo! Grupos
>
>
>

Thiago, também testei esse seu script no Arch Linux 64 bits, com o Python
padrão da distribuição, e obtive resultados próximos aos seus, apesar de que
após o del, o python estava consumindo 300 MB. Testei o script no Kubuntu 32
bits, e os resultados foram iguais aos seus. Também fiz testes no Windows 7
64 bits: com o Python 32 bits, os resultados são iguais aos seus, mas com o
Python 64 bits, o consumo de memória com os objetos alocados é igual ao seu,
mas após o del caiu para 40 MB. Muito estranho isso.

Eu li em algum lugar que 64 bits não consome o dobro da memória, apenas um
pouco mais. Se fosse o dobro, seria inviável utilizar 64 bits em máquinas
com 1 ou 2 GB de RAM, por exemplo.

Caso ninguém aqui saiba explicar melhor isso, acho que você poderia
perguntar na python-list e ver se alguém responde se é alguma característica
de arquitetura, sei lá, antes de postar bugreport.

Abraços.
--
Gabriel Morrison Lima Dantas
"Any sufficiently advanced technology is indistinguishable from magic."
- Arthur C. Clarke


Atenção!!!
Proteja meu endereço como estou protegendo o seu.
Ao enviar cópias, apague no corpo do email o endereço de quem lhe enviou e
para quem enviou. Não use o campo "Cc:", use sempre o campo "Cco:" (cópia
oculta) ou "Bc" (Blind copy), assim o e-mail de todos estará preservado.
Obrigado.


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Felipe Zorzo
In reply to this post by Thiago F. Pappacena
Em 11 de junho de 2010 16:37, Thiago F. Pappacena <[hidden email]>escreveu:

>
>
> Senhores,
>
> desculpe voltar a este assunto, mas algum dos senhores utiliza Python
> em Linux 64 bits?
>
> Explico: como já expliquei em [1], tenho problemas com consumo de
> memória em umas aplicações. Mas uns testes mais recentes me
> preocuparam um pouco: compilando o python-2.6.5 com um "./configure &&
> make" normal, tenho memory leak. Entretanto, se eu compilar o mesmo
> python com as flags -m32 (ou seja, compilar o Python em modo de
> compatibilidade 32 bits), não só deixo de ter o leak, como minhas
> aplicações passam a consumir bem menos memória. Ou seja, não há nada
> mais de diferente na máquina. Apenas a compilação do próprio python.
>
> O código testado está em [2]. O resultado do teste é o seguinte:
>
> Compilado em 64 bits:
> Memória residente total antes do "del": 427MB
> Memória residente total depois do "del": 420MB
>
> Compilado em 32 bits:
> Memória residente total antes do "del": 225MB (quase metade!!)
> Memória residente total depois do "del": 14MB (tudo que eu queria na
> vida...)
>
> Alguém mais da lista tem esse tipo de problema?
>
> [1]
> http://old.nabble.com/Strings-e-consumo-eterno-de-mem%C3%B3ria-td26500252.html
> [2] http://pastebin.com/bfJts4jW
>
> []'s,
> Thiago F. Pappacena
>
> Good things come for those who wait...
> ... and for the efficient people who doesn't wait too, but faster:
> Open source, XP, OO, Python, VIM, Bash and Gentoo.
>

Thiago, eu também uso o Python no Linux 64-bit. Fiz esse teste e o resultado
foi o seguinte:

Memória residente total antes do "del": 435MB
Memória residente total depois do "del": 320MB

Só pra informação, utilizo o Arch Linux 64-bit e o Python 2.6.5, disponível
no repositório.

E, por curiosidade, resolvi fazer o mesmo teste no Python 2.6.5 64-bit no
Windows, e, olha só:

Memória residente total antes do "del": 433MB
Memória residente total depois do "del": 37MB (é isso mesmo, não digitei
errado, são 37MB)

--
Felipe Bernardo Zorzo


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Robson Silva-2
On Sun, 13 Jun 2010, Felipe Zorzo wrote:
> Em 11 de junho de 2010 16:37, Thiago F. Pappacena <[hidden email]>escreveu:
>
> > Senhores,
> >
> > desculpe voltar a este assunto, mas algum dos senhores utiliza Python
> > em Linux 64 bits?
> > [cut]

Saudações a todos!

Uma maneira interessante de saber o que está acontecendo é olhando o mapa
da memória utilizada por esse processo:

pmap -d PID_DO_PROCESSO > arquivo_saida

Fazendo isso antes e depois do "del" pode ajudar a descobrir o problema.

Abraços,
Robson

[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Thiago F. Pappacena
In reply to this post by Felipe Zorzo
É, Felipe. Eu também percebi que o problema de não limpar as
referências não utilizadas era apenas no Linux 64. Nem no Windows, nem
em Linux 32 esse problema acontece. Alguém com Mac OS poderia ver como
esse teste se sai?

Acho que vou mesmo abrir um bug report no Python. Não acho que a
não-liberação seja um problema só comigo.


[]'s,
Thiago F. Pappacena

Good things come for those who wait...
... and for the efficient people who doesn't wait too, but faster:
Open source, XP, OO, Python, VIM, Bash and Gentoo.


2010/6/13 Felipe Zorzo <[hidden email]>

>
>
>
> Em 11 de junho de 2010 16:37, Thiago F. Pappacena <[hidden email]>escreveu:
>
> >
> >
> > Senhores,
> >
> > desculpe voltar a este assunto, mas algum dos senhores utiliza Python
> > em Linux 64 bits?
> >
> > Explico: como já expliquei em [1], tenho problemas com consumo de
> > memória em umas aplicações. Mas uns testes mais recentes me
> > preocuparam um pouco: compilando o python-2.6.5 com um "./configure &&
> > make" normal, tenho memory leak. Entretanto, se eu compilar o mesmo
> > python com as flags -m32 (ou seja, compilar o Python em modo de
> > compatibilidade 32 bits), não só deixo de ter o leak, como minhas
> > aplicações passam a consumir bem menos memória. Ou seja, não há nada
> > mais de diferente na máquina. Apenas a compilação do próprio python.
> >
> > O código testado está em [2]. O resultado do teste é o seguinte:
> >
> > Compilado em 64 bits:
> > Memória residente total antes do "del": 427MB
> > Memória residente total depois do "del": 420MB
> >
> > Compilado em 32 bits:
> > Memória residente total antes do "del": 225MB (quase metade!!)
> > Memória residente total depois do "del": 14MB (tudo que eu queria na
> > vida...)
> >
> > Alguém mais da lista tem esse tipo de problema?
> >
> > [1]
> > http://old.nabble.com/Strings-e-consumo-eterno-de-mem%C3%B3ria-td26500252.html
> > [2] http://pastebin.com/bfJts4jW
> >
> > []'s,
> > Thiago F. Pappacena
> >
> > Good things come for those who wait...
> > ... and for the efficient people who doesn't wait too, but faster:
> > Open source, XP, OO, Python, VIM, Bash and Gentoo.
> >
>
> Thiago, eu também uso o Python no Linux 64-bit. Fiz esse teste e o resultado
> foi o seguinte:
>
> Memória residente total antes do "del": 435MB
> Memória residente total depois do "del": 320MB
>
> Só pra informação, utilizo o Arch Linux 64-bit e o Python 2.6.5, disponível
> no repositório.
>
> E, por curiosidade, resolvi fazer o mesmo teste no Python 2.6.5 64-bit no
> Windows, e, olha só:
>
> Memória residente total antes do "del": 433MB
> Memória residente total depois do "del": 37MB (é isso mesmo, não digitei
> errado, são 37MB)
>
> --
> Felipe Bernardo Zorzo
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>


------------------------------------

,-----------------------------------------------------------.
| Antes de enviar um e-mail para o grupo leia:              |
| http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
| E se você é usuário do BOL lembre-se de cadastrar o       |
| e-mail do grupo na lista branca do seu sistema anti-spam. |
`-----------------------------------------------------------´Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Luciano Ramalho
Thiago, ė recomendável que você (1) pesquise no histórico das listas em inglês e (2) envie sua questão para python-users e aguarde respostas antes de cadastrar um bug.

[ ]s
Luciano

Sent from my iPad

On Jun 13, 2010, at 2:12 PM, "Thiago F. Pappacena" <[hidden email]> wrote:

> É, Felipe. Eu também percebi que o problema de não limpar as
> referências não utilizadas era apenas no Linux 64. Nem no Windows, nem
> em Linux 32 esse problema acontece. Alguém com Mac OS poderia ver como
> esse teste se sai?
>
> Acho que vou mesmo abrir um bug report no Python. Não acho que a
> não-liberação seja um problema só comigo.
>
>
> []'s,
> Thiago F. Pappacena
>
> Good things come for those who wait...
> ... and for the efficient people who doesn't wait too, but faster:
> Open source, XP, OO, Python, VIM, Bash and Gentoo.
>
>
> 2010/6/13 Felipe Zorzo <[hidden email]>
>>
>>
>>
>> Em 11 de junho de 2010 16:37, Thiago F. Pappacena <[hidden email]>escreveu:
>>
>>>
>>>
>>> Senhores,
>>>
>>> desculpe voltar a este assunto, mas algum dos senhores utiliza Python
>>> em Linux 64 bits?
>>>
>>> Explico: como já expliquei em [1], tenho problemas com consumo de
>>> memória em umas aplicações. Mas uns testes mais recentes me
>>> preocuparam um pouco: compilando o python-2.6.5 com um "./configure &&
>>> make" normal, tenho memory leak. Entretanto, se eu compilar o mesmo
>>> python com as flags -m32 (ou seja, compilar o Python em modo de
>>> compatibilidade 32 bits), não só deixo de ter o leak, como minhas
>>> aplicações passam a consumir bem menos memória. Ou seja, não há nada
>>> mais de diferente na máquina. Apenas a compilação do próprio python.
>>>
>>> O código testado está em [2]. O resultado do teste é o seguinte:
>>>
>>> Compilado em 64 bits:
>>> Memória residente total antes do "del": 427MB
>>> Memória residente total depois do "del": 420MB
>>>
>>> Compilado em 32 bits:
>>> Memória residente total antes do "del": 225MB (quase metade!!)
>>> Memória residente total depois do "del": 14MB (tudo que eu queria na
>>> vida...)
>>>
>>> Alguém mais da lista tem esse tipo de problema?
>>>
>>> [1]
>>> http://old.nabble.com/Strings-e-consumo-eterno-de-mem%C3%B3ria-td26500252.html
>>> [2] http://pastebin.com/bfJts4jW
>>>
>>> []'s,
>>> Thiago F. Pappacena
>>>
>>> Good things come for those who wait...
>>> ... and for the efficient people who doesn't wait too, but faster:
>>> Open source, XP, OO, Python, VIM, Bash and Gentoo.
>>>
>>
>> Thiago, eu também uso o Python no Linux 64-bit. Fiz esse teste e o resultado
>> foi o seguinte:
>>
>> Memória residente total antes do "del": 435MB
>> Memória residente total depois do "del": 320MB
>>
>> Só pra informação, utilizo o Arch Linux 64-bit e o Python 2.6.5, disponível
>> no repositório.
>>
>> E, por curiosidade, resolvi fazer o mesmo teste no Python 2.6.5 64-bit no
>> Windows, e, olha só:
>>
>> Memória residente total antes do "del": 433MB
>> Memória residente total depois do "del": 37MB (é isso mesmo, não digitei
>> errado, são 37MB)
>>
>> --
>> Felipe Bernardo Zorzo
>>
>> [As partes desta mensagem que não continham texto foram removidas]
>>
>>
>
>
> ------------------------------------
>
> ,-----------------------------------------------------------.
> | Antes de enviar um e-mail para o grupo leia:              |
> | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
> | E se você é usuário do BOL lembre-se de cadastrar o       |
> | e-mail do grupo na lista branca do seu sistema anti-spam. |
> `-----------------------------------------------------------´Links do Yahoo! Grupos
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Luciano Ramalho
In reply to this post by Gabriel Morrison Lima Dantas-2
2010/6/13 Gabriel Morrison Lima Dantas <[hidden email]>:
> Eu li em algum lugar que 64 bits não consome o dobro da memória, apenas um
> pouco mais. Se fosse o dobro, seria inviável utilizar 64 bits em máquinas
> com 1 ou 2 GB de RAM, por exemplo.

Gabriel, é claro que de uma forma geral um SO ou um aplicativo
complexo como o OpenOffice rodando em 64 bits não vai consumir o dobro
de memória, até porque são programas que usam uma variedade de
estruturas de dados.

Agora se estamos falando de um script Python que basicamente a única
coisa que faz é alocar ints, então sim, ele vai ocupar praticamente o
dobro da memória porque um int de 64 bits ocupa 8 bytes e um int de 32
bits ocupa 4 bytes.

> Caso ninguém aqui saiba explicar melhor isso, acho que você poderia
> perguntar na python-list e ver se alguém responde se é alguma característica
> de arquitetura, sei lá, antes de postar bugreport.

Concordo. Em 12 anos usando Python eu nunca vi ser reportado aqui na
lista um bug real de Python. Quase sempre existe uma outra explicação.
Infelizmente neste caso eu não sei qual é.

Pode até ser que o Thiago tenha encontrado um bug no Python 2.6, mas o
procedimento correto de qualquer forma é pesquisar e perguntar na
python-list [1]. Depois vasculhar o bug tracker [2] para ver se o
problema não foi reportado antes e, se foi, se é possível complementar
as informações do relato anterior.

[1] http://mail.python.org/mailman/listinfo/python-list
[2] http://bugs.python.org/

A gente não pode deixar de ter em mente que Python é uma linguagem
madura e desenvolvida com muito rigor técnico, e usada literalmente em
milhões de computadores ao redor do mundo, então a chance de encontrar
um bug novo que pode ser reproduzido com um pequeno e singelo script
de 10 linhas é remota. Por outro lado, a linguagem tem comportamentos
indesejáveis que não são bugs porque são limitações conhecidas,
resultantes de decisões técnicas feitas conscientemente.

[ ]s
Luciano
Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Thiago F. Pappacena
2010/6/13 Luciano Ramalho <[hidden email]>
> Agora se estamos falando de um script Python que basicamente a única
> coisa que faz é alocar ints, então sim, ele vai ocupar praticamente o
> dobro da memória porque um int de 64 bits ocupa 8 bytes e um int de 32
> bits ocupa 4 bytes.

Sim, Luciano. Mas, como eu disse, o script de teste alocava apenas 1
inteiro, uma variável de classe. Posso estar enganado com o
comportamento disso no Python, mas havia apenas um inteiro na variável
de classe e uma lista de inteiros no list comprehention. O resto era
string. Não sei se realmente deveria consumir quase o dobro do tamanho
em RAM.


> Concordo. Em 12 anos usando Python eu nunca vi ser reportado aqui na
> lista um bug real de Python. Quase sempre existe uma outra explicação.
> Infelizmente neste caso eu não sei qual é.
>
> Pode até ser que o Thiago tenha encontrado um bug no Python 2.6, mas o
> procedimento correto de qualquer forma é pesquisar e perguntar na
> python-list [1]. Depois vasculhar o bug tracker [2] para ver se o
> problema não foi reportado antes e, se foi, se é possível complementar
> as informações do relato anterior.

+1. Quando falei em fazer um bug report, pensei em perguntar na
python-list primeiro, em busca de explicação. No bug tracker eu já
andei procurando e não achei nada muito parecido, de qualquer maneira.


> A gente não pode deixar de ter em mente que Python é uma linguagem
> madura e desenvolvida com muito rigor técnico, e usada literalmente em
> milhões de computadores ao redor do mundo, então a chance de encontrar
> um bug novo que pode ser reproduzido com um pequeno e singelo script
> de 10 linhas é remota. Por outro lado, a linguagem tem comportamentos
> indesejáveis que não são bugs porque são limitações conhecidas,
> resultantes de decisões técnicas feitas conscientemente.

+10. Não é porque threads não rodam em processadores distintos que
vamos abrir um bugreport por semana reclamando do GIL, certo? ;-)

Python sempre resolveu meus problemas, até que precisei manter alguns
serviços rodando por tempo indeterminado, com uso massivo concorrente
e sobre grandes massas de dados. Aí, a memória não sendo devolvida pro
SO me custava algumas ligações durante a madrugada, e frequentes
"cannot allocate memory" no syslog. Tudo isso sem solução ainda... e,
em 5 ou 6 anos, eu nunca tive um problema em Python que não tivesse
solução na primeira página do Google. ;)


[]'s,
Thiago F. Pappacena

Good things come for those who wait...
... and for the efficient people who doesn't wait too, but faster:
Open source, XP, OO, Python, VIM, Bash and Gentoo.
Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Iuri
Uma explicação possível é uma diferença no comportamento do garbage
collector. Dar del não garante que o garbage collector vai liberar a memória
imediatamente.

*SE* isso é um memory leak de fato, repita o mesmo procedimento várias
vezes, e veja se o GC realmente não libera memória. Se não liberar, o Python
em algum momento vai consumir toda a memória destinada a ele, causando erro.

[]s
iuri

2010/6/13 Thiago F. Pappacena <[hidden email]>

>
>
> 2010/6/13 Luciano Ramalho <[hidden email] <ramalho%40gmail.com>>
>
> > Agora se estamos falando de um script Python que basicamente a única
> > coisa que faz é alocar ints, então sim, ele vai ocupar praticamente o
> > dobro da memória porque um int de 64 bits ocupa 8 bytes e um int de 32
> > bits ocupa 4 bytes.
>
> Sim, Luciano. Mas, como eu disse, o script de teste alocava apenas 1
> inteiro, uma variável de classe. Posso estar enganado com o
> comportamento disso no Python, mas havia apenas um inteiro na variável
> de classe e uma lista de inteiros no list comprehention. O resto era
> string. Não sei se realmente deveria consumir quase o dobro do tamanho
> em RAM.
>
>
> > Concordo. Em 12 anos usando Python eu nunca vi ser reportado aqui na
> > lista um bug real de Python. Quase sempre existe uma outra explicação.
> > Infelizmente neste caso eu não sei qual é.
> >
> > Pode até ser que o Thiago tenha encontrado um bug no Python 2.6, mas o
> > procedimento correto de qualquer forma é pesquisar e perguntar na
> > python-list [1]. Depois vasculhar o bug tracker [2] para ver se o
> > problema não foi reportado antes e, se foi, se é possível complementar
> > as informações do relato anterior.
>
> +1. Quando falei em fazer um bug report, pensei em perguntar na
> python-list primeiro, em busca de explicação. No bug tracker eu já
> andei procurando e não achei nada muito parecido, de qualquer maneira.
>
>
> > A gente não pode deixar de ter em mente que Python é uma linguagem
> > madura e desenvolvida com muito rigor técnico, e usada literalmente em
> > milhões de computadores ao redor do mundo, então a chance de encontrar
> > um bug novo que pode ser reproduzido com um pequeno e singelo script
> > de 10 linhas é remota. Por outro lado, a linguagem tem comportamentos
> > indesejáveis que não são bugs porque são limitações conhecidas,
> > resultantes de decisões técnicas feitas conscientemente.
>
> +10. Não é porque threads não rodam em processadores distintos que
> vamos abrir um bugreport por semana reclamando do GIL, certo? ;-)
>
> Python sempre resolveu meus problemas, até que precisei manter alguns
> serviços rodando por tempo indeterminado, com uso massivo concorrente
> e sobre grandes massas de dados. Aí, a memória não sendo devolvida pro
> SO me custava algumas ligações durante a madrugada, e frequentes
> "cannot allocate memory" no syslog. Tudo isso sem solução ainda... e,
> em 5 ou 6 anos, eu nunca tive um problema em Python que não tivesse
> solução na primeira página do Google. ;)
>
>
> []'s,
> Thiago F. Pappacena
>
> Good things come for those who wait...
> ... and for the efficient people who doesn't wait too, but faster:
> Open source, XP, OO, Python, VIM, Bash and Gentoo.
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

,-----------------------------------------------------------.
| Antes de enviar um e-mail para o grupo leia:              |
| http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
| E se você é usuário do BOL lembre-se de cadastrar o       |
| e-mail do grupo na lista branca do seu sistema anti-spam. |
`-----------------------------------------------------------´Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Luciano Ramalho
In reply to this post by Thiago F. Pappacena
2010/6/13 Thiago F. Pappacena <[hidden email]>:
> Sim, Luciano. Mas, como eu disse, o script de teste alocava apenas 1
> inteiro, uma variável de classe. Posso estar enganado com o
> comportamento disso no Python, mas havia apenas um inteiro na variável
> de classe e uma lista de inteiros no list comprehention. O resto era
> string. Não sei se realmente deveria consumir quase o dobro do tamanho
> em RAM.

Thiago, eu não tinha olhado com atenção o seu script antes. Quando
você declara a variável count na classe, e tenta incrementá-la fazendo
self.count += 1 você está na verdade criando uma variável count na
instância.

Isso porque não existe alteração "in-place" de valores imutáveis em
Python. Ou seja, self.count += 1 é exatamente igual a fazer o
seguinte:

self.count = self.count + 1

O que acontece é que em Python é o mesmo que acontece em qualquer
linguagem que segue esta semântica de atribuição, tal como Java, C,
PHP, Ruby, etc): o que é executado primeiro é a expressão á direita do
igual. Ou seja, self.count + 1. Isto produz um novo objeto int, cujo
valor é 0 + 1, já que a expressão self.count acaba acessando o valor
definido na classe, pela semântica de acesso a atributos do Python,
explicada no Tutorial Python do Guido. Em seguida, o valor resultante,
1, é atribuído a uma variável da instância, chamada count. Em nenhum
momento o valor da variável de classe é alterado no seu script. TODAS
as instâncias criadas terão o valor de self.count == 1. Porém, seráo
instãncias diferentes, com suas respectivas cópias da variável de
instância count.

Isso explica pelo menos uma parte do mistério.

[ ]s
Luciano
Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Luciano Ramalho
Coloquei no pastebin uma versão do scripto do Thiago com apenas dois
prints a mais para demostrar o que eu escrevi há pouco:

http://pastebin.com/JMERq7WU

[ ]s
Luciano

PS. O script original postado pelo Thiago estava com erro de indentação

2010/6/13 Luciano Ramalho <[hidden email]>:

> 2010/6/13 Thiago F. Pappacena <[hidden email]>:
>> Sim, Luciano. Mas, como eu disse, o script de teste alocava apenas 1
>> inteiro, uma variável de classe. Posso estar enganado com o
>> comportamento disso no Python, mas havia apenas um inteiro na variável
>> de classe e uma lista de inteiros no list comprehention. O resto era
>> string. Não sei se realmente deveria consumir quase o dobro do tamanho
>> em RAM.
>
> Thiago, eu não tinha olhado com atenção o seu script antes. Quando
> você declara a variável count na classe, e tenta incrementá-la fazendo
> self.count += 1 você está na verdade criando uma variável count na
> instância.
>
> Isso porque não existe alteração "in-place" de valores imutáveis em
> Python. Ou seja, self.count += 1 é exatamente igual a fazer o
> seguinte:
>
> self.count = self.count + 1
>
> O que acontece é que em Python é o mesmo que acontece em qualquer
> linguagem que segue esta semântica de atribuição, tal como Java, C,
> PHP, Ruby, etc): o que é executado primeiro é a expressão á direita do
> igual. Ou seja, self.count + 1. Isto produz um novo objeto int, cujo
> valor é 0 + 1, já que a expressão self.count acaba acessando o valor
> definido na classe, pela semântica de acesso a atributos do Python,
> explicada no Tutorial Python do Guido. Em seguida, o valor resultante,
> 1, é atribuído a uma variável da instância, chamada count. Em nenhum
> momento o valor da variável de classe é alterado no seu script. TODAS
> as instâncias criadas terão o valor de self.count == 1. Porém, seráo
> instãncias diferentes, com suas respectivas cópias da variável de
> instância count.
>
> Isso explica pelo menos uma parte do mistério.
>
> [ ]s
> Luciano
>
Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Vitor Iha
Isso foi reportado na python-dev [1], e não é exclusivo de programas
compilados para 64 bits, aqui ele não liberou muita coisa (Arch32).

[1] http://mail.python.org/pipermail/python-dev/2004-October/049480.html


[As partes desta mensagem que não continham texto foram removidas]

Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Gabriel Morrison Lima Dantas-2
In reply to this post by Luciano Ramalho
Em 13 de junho de 2010 18:02, Luciano Ramalho escreveu:

>
>
> Coloquei no pastebin uma versão do scripto do Thiago com apenas dois
> prints a mais para demostrar o que eu escrevi há pouco:
>
> http://pastebin.com/JMERq7WU
>
> [ ]s
> Luciano
>
> PS. O script original postado pelo Thiago estava com erro de indentação
>
> 2010/6/13 Luciano Ramalho:
>
> > 2010/6/13 Thiago F. Pappacena:
> >> Sim, Luciano. Mas, como eu disse, o script de teste alocava apenas 1
> >> inteiro, uma variável de classe. Posso estar enganado com o
> >> comportamento disso no Python, mas havia apenas um inteiro na variável
> >> de classe e uma lista de inteiros no list comprehention. O resto era
> >> string. Não sei se realmente deveria consumir quase o dobro do tamanho
> >> em RAM.
> >
> > Thiago, eu não tinha olhado com atenção o seu script antes. Quando
> > você declara a variável count na classe, e tenta incrementá-la fazendo
> > self.count += 1 você está na verdade criando uma variável count na
> > instância.
> >
> > Isso porque não existe alteração "in-place" de valores imutáveis em
> > Python. Ou seja, self.count += 1 é exatamente igual a fazer o
> > seguinte:
> >
> > self.count = self.count + 1
> >
> > O que acontece é que em Python é o mesmo que acontece em qualquer
> > linguagem que segue esta semântica de atribuição, tal como Java, C,
> > PHP, Ruby, etc): o que é executado primeiro é a expressão á direita do
> > igual. Ou seja, self.count + 1. Isto produz um novo objeto int, cujo
> > valor é 0 + 1, já que a expressão self.count acaba acessando o valor
> > definido na classe, pela semântica de acesso a atributos do Python,
> > explicada no Tutorial Python do Guido. Em seguida, o valor resultante,
> > 1, é atribuído a uma variável da instância, chamada count. Em nenhum
> > momento o valor da variável de classe é alterado no seu script. TODAS
> > as instâncias criadas terão o valor de self.count == 1. Porém, seráo
> > instãncias diferentes, com suas respectivas cópias da variável de
> > instância count.
> >
> > Isso explica pelo menos uma parte do mistério.
> >
> > [ ]s
> > Luciano
> >
>  
>


Opa, obrigado pelo clareamento quanto aos bits :)
Uma coisa que andei pensando aqui é sobre o gerenciamento de memória do
Linux. Um dia li que ele faz cache o máximo possível, tanto que um free -m
mostra que a memória usada + cache é quase a memória toda que o computador
tem disponível. Eu acho que o que acontece é que quando você chama o del, o
kernel não desaloca a memória instantaneamente, já que vc tem bastante
memória livre ainda, mas mantém em cache, para o caso de eventualmente vc
precisar daquilo tudo de novo =). Imagino que se de repente seu sistema
necessitasse de muita memória, o kernel trataria de desfazer aquela cache
para liberar memória pra esse hipotético processo comilão (um jogo, por
exemplo) =].
Acho que pode ser isso. Depois vou testar :)

Abraços

--
Gabriel Morrison Lima Dantas
"Any sufficiently advanced technology is indistinguishable from magic."
- Arthur C. Clarke


Atenção!!!
Proteja meu endereço como estou protegendo o seu.
Ao enviar cópias, apague no corpo do email o endereço de quem lhe enviou e
para quem enviou. Não use o campo "Cc:", use sempre o campo "Cco:" (cópia
oculta) ou "Bc" (Blind copy), assim o e-mail de todos estará preservado.
Obrigado.


[As partes desta mensagem que não continham texto foram removidas]



------------------------------------

,-----------------------------------------------------------.
| Antes de enviar um e-mail para o grupo leia:              |
| http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar  |
| E se você é usuário do BOL lembre-se de cadastrar o       |
| e-mail do grupo na lista branca do seu sistema anti-spam. |
`-----------------------------------------------------------´Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/python-brasil/

<*> Para sair deste grupo, envie um e-mail para:
    [hidden email]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html


Reply | Threaded
Open this post in threaded view
|

Re: Python em Linux 64 bits e o maldito memory leak

Rodrigo Corrêa
In reply to this post by Luciano Ramalho
>  Thiago, eu não tinha olhado com atenção o seu script antes. Quando
>  você declara a variável count na classe, e tenta incrementá-la fazendo
> self.count += 1 você está na verdade criando uma variável count na
> instância.
>
> Isso porque não existe alteração "in-place" de valores imutáveis em
> Python. Ou seja, self.count += 1 é exatamente igual a fazer o
> seguinte:
>
> self.count = self.count + 1
>
> O que acontece é que em Python é o mesmo que acontece em qualquer
> linguagem que segue esta semântica de atribuição, tal como Java, C,
> PHP, Ruby, etc): o que é executado primeiro é a expressão á direita do
> igual. Ou seja, self.count + 1. Isto produz um novo objeto int, cujo
> valor é 0 + 1, já que a expressão self.count acaba acessando o valor
> definido na classe, pela semântica de acesso a atributos do Python,
> explicada no Tutorial Python do Guido. Em seguida, o valor resultante,
> 1, é atribuído a uma variável da instância, chamada count. Em nenhum
> momento o valor da variável de classe é alterado no seu script. TODAS
> as instâncias criadas terão o valor de self.count == 1. Porém, seráo
> instãncias diferentes, com suas respectivas cópias da variável de
> instância count.
>
> Isso explica pelo menos uma parte do mistério.
>
Independente disso, até onde eu vi não é o inteiro que está ocupando mais
memória nesse script (se quiser testar, o que eu sempre aconselho, é só
tira-lo do script). Sem o inteiro, mas mantendo uma string com um
tamanho compatível, eu pude observar que o consumo até caiu (cerca de 20%)
mas não é a parcela que difere de uma versão para a outra (no caso, 64 para
32).

Testei esses scripts em ambiente gentoo linux, archlinux, e ubuntu. O
comportamento foi sempre muito semelhante.



Rodrigo Corrêa Alves


[As partes desta mensagem que não continham texto foram removidas]

12