Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.mixmin.net!eweka.nl!hq-usenetpeers.eweka.nl!xlned.com!feeder1.xlned.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <78E1273CA6E76A43BB8830A194FF709B0B157FC9@039-SN2MPN1-013.039d.mgd.msft.net>
References: <390f0dc5-5750-4849-9433-a19d90cc8566@googlegroups.com> <87zjyhhret.fsf@nautilus.nautilus> <mailman.2934.1362564689.2939.python-list@python.org> <5137d292$0$30001$c3e8da3$5496439d@news.astraweb.com> <78E1273CA6E76A43BB8830A194FF709B0B14D68C@039-SN2MPN1-013.039d.mgd.msft.net> <CAPTjJmp1qV7vFuT0fB50yHSzbyQagU55MONLbe5W+as6TZ0Csg@mail.gmail.com> <78E1273CA6E76A43BB8830A194FF709B0B153A71@039-SN2MPN1-013.039d.mgd.msft.net> <h41lj8loiudccrragebcrlf05iqtkmnp9f@invalid.netcom.com> <78E1273CA6E76A43BB8830A194FF709B0B157FC9@039-SN2MPN1-013.039d.mgd.msft.net>
Date: Sat, 9 Mar 2013 23:02:17 +0800
Subject: Re: Set x to to None and del x doesn't release memory in python 2.7.1 (HPUX 11.23, ia64)
From: Isaac To <isaac.to@gmail.com>
To: "python-list@python.org" <python-list@python.org>
Content-Type: multipart/alternative; boundary=20cf3005dc38ca18e504d77f39a8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3129.1362841346.2939.python-list@python.org>
Lines: 92
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:40948

--20cf3005dc38ca18e504d77f39a8
Content-Type: text/plain; charset=ISO-8859-1

In general, it is hard for any process to return the memory the OS allocate
to it back to the OS, short of exiting the whole process.  The only case
that this works reliably is when the process allocates a chunk of memory by
mmap (which is chosen by libc if it malloc or calloc a large chunk of
memory), and that whole chunk is not needed any more.  In that case the
process can munmap it.  Evidently you are not see that in your program.
What you allocate might be too small (so libc choose to allocate it using
another system call "sbrk"), or that the allocated memory also hold other
objects not freed.

If you want to reduce the footprint of a long running program that
periodically allocates a large chunk of memory, the "easiest" solution is
to fork a different process to achieve the computations that needs the
memory.  That way, you can exit the process after you complete the
computation, and at that point all memory allocated to it is guaranteed to
be freed to the OS.

Modules like multiprocessing probably make the idea sufficiently easy to
implement.


On Sat, Mar 9, 2013 at 4:07 PM, Wong Wah Meng-R32813
<r32813@freescale.com>wrote:

>
>
>         If the memory usage is continually growing, you have something
> else that is a problem -- something is holding onto objects. Even if Python
> is not returning memory to the OS, it should be reusing the memory it has
> if objects are being freed.
> --
> [] Yes I have verified my python application is reusing the memory (just
> that it doesn't reduce once it has grown) and my python process doesn't
> have any issue to run even though it is seen taking up more than 2G in
> footprint. My problem is capacity planning on the server whereby since my
> python process doesn't release memory back to the OS, the OS wasn't able to
> allocate memory when a new process is spawn off.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

--20cf3005dc38ca18e504d77f39a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>In general, it is hard for any process to return=
 the memory the OS allocate to it back to the OS, short of exiting the whol=
e process.=A0 The only case that this works reliably is when the process al=
locates a chunk of memory by mmap (which is chosen by libc if it malloc or =
calloc a large chunk of memory), and that whole chunk is not needed any mor=
e.=A0 In that case the process can munmap it.=A0 Evidently you are not see =
that in your program.=A0 What you allocate might be too small (so libc choo=
se to allocate it using another system call &quot;sbrk&quot;), or that the =
allocated memory also hold other objects not freed.<br>
<br></div>If you want to reduce the footprint of a long running program tha=
t periodically allocates a large chunk of memory, the &quot;easiest&quot; s=
olution is to fork a different process to achieve the computations that nee=
ds the memory.=A0 That way, you can exit the process after you complete the=
 computation, and at that point all memory allocated to it is guaranteed to=
 be freed to the OS.<br>
<br></div>Modules like multiprocessing probably make the idea sufficiently =
easy to implement.<br></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Sat, Mar 9, 2013 at 4:07 PM, Wong Wah Meng-R32813 <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:r32813@freescale.com" target=3D"_blank">=
r32813@freescale.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br>
<br>
=A0 =A0 =A0 =A0 If the memory usage is continually growing, you have someth=
ing else that is a problem -- something is holding onto objects. Even if Py=
thon is not returning memory to the OS, it should be reusing the memory it =
has if objects are being freed.<br>

--<br>
</div>[] Yes I have verified my python application is reusing the memory (j=
ust that it doesn&#39;t reduce once it has grown) and my python process doe=
sn&#39;t have any issue to run even though it is seen taking up more than 2=
G in footprint. My problem is capacity planning on the server whereby since=
 my python process doesn&#39;t release memory back to the OS, the OS wasn&#=
39;t able to allocate memory when a new process is spawn off.<br>

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<a href=3D"http://mail.python.org/mailman/listinfo/python-list" target=3D"_=
blank">http://mail.python.org/mailman/listinfo/python-list</a><br>
</font></span></blockquote></div><br></div>

--20cf3005dc38ca18e504d77f39a8--