FAQ
I have a server running Python 2.6x64 which after running for about a
month decides to lock up and become unresponsive to all threads for
several minutes at a time. While it is locked up Python proceeds to
consume large amounts of continually increasing memory.

The basic function of the server is to serve a large dictionary -
somewhat like a database. I have a couple theories as to why it locks
up, but I'm not sure how to test them.

Theories:
Python is resizing the large dictionary
Python is garbage collecting

How would you suggest to figure out what is the problem?

--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer (Digital Overlord)
Zindagi Games

Search Discussions

  • MRAB at Sep 9, 2009 at 8:43 pm

    Zac Burns wrote:
    I have a server running Python 2.6x64 which after running for about a
    month decides to lock up and become unresponsive to all threads for
    several minutes at a time. While it is locked up Python proceeds to
    consume large amounts of continually increasing memory.

    The basic function of the server is to serve a large dictionary -
    somewhat like a database. I have a couple theories as to why it locks
    up, but I'm not sure how to test them.

    Theories:
    Python is resizing the large dictionary
    Python is garbage collecting

    How would you suggest to figure out what is the problem?
    If it has been running continuously all that time then it might be that
    the dictionary has grown too big (is that possible?) or that it's a
    memory fragmentation problem. In the latter case it might be an idea to
    restart Python every so often; perhaps it could do that automatically
    during a "quiet time", eg at midnight every Sunday.
  • Zac Burns at Sep 10, 2009 at 12:08 am

    If it has been running continuously all that time then it might be that
    the dictionary has grown too big (is that possible?) or that it's a
    memory fragmentation problem. In the latter case it might be an idea to
    restart Python every so often; perhaps it could do that automatically
    during a "quiet time", eg at midnight every Sunday.
    --
    http://mail.python.org/mailman/listinfo/python-list
    I did some testing with the dictionary size and ruled that out. Memory
    fragmentation is an interesting idea. Is there a way to check python's
    fragmentation or run a defragment periodically?

    My first thought there would be that a defragment would invalidate ids... err...

    --
    Zachary Burns
    (407)590-4814
    Aim - Zac256FL
    Production Engineer (Digital Overlord)
    Zindagi Games
  • David Stanek at Sep 10, 2009 at 1:52 am
    On Wed, Sep 9, 2009 at 4:28 PM, Zac Burnswrote:
    How would you suggest to figure out what is the problem?
    I don't think you said your OS so I'll assume Linux.

    Sometimes it is more noise than value, but stracing the process may
    shed light on what system calls are being made. This in turn may help
    you narrow your focus. I find strace helps me a ton in some really
    tough problems.

    Are you watching for swapping, CPU usage, etc.?
  • Zac Burns at Sep 11, 2009 at 12:57 am

    On Wed, Sep 9, 2009 at 6:52 PM, David Stanek wrote:
    On Wed, Sep 9, 2009 at 4:28 PM, Zac Burnswrote:
    How would you suggest to figure out what is the problem?
    I don't think you said your OS so I'll assume Linux.

    Sometimes it is more noise than value, but stracing the process may
    shed light on what system calls are being made. This in turn may help
    you narrow your focus. I find strace helps me a ton in some really
    tough problems.

    Are you watching for swapping, CPU usage, etc.?

    --
    David
    blog: http://www.traceback.org
    twitter: http://twitter.com/dstanek
    The OS is Windows Server 2003 x64.

    CPU ranges from 0% to 1%, there is no disk IO, and it eats ram at ~1MB/2sec.

    --
    Zachary Burns
    (407)590-4814
    Aim - Zac256FL
    Production Engineer (Digital Overlord)
    Zindagi Games
  • Sturlamolden at Sep 11, 2009 at 9:12 am

    On 9 Sep, 22:28, Zac Burns wrote:

    Theories:
    ? ?Python is resizing the large dictionary
    ? ?Python is garbage collecting
    Python uses reference counting, not a generational GC like Java. A
    Python object is destroyed when the refcount drops to 0. The GC only
    collects cyclic references. If you create none, there are no GC delays
    (you can in fact safely turn the GC off). Python does not share Java's
    nasty habit of having long GC delays.
  • Terry Reedy at Sep 11, 2009 at 6:02 pm

    sturlamolden wrote:
    On 9 Sep, 22:28, Zac Burns wrote:

    Theories:
    Python is resizing the large dictionary
    Python is garbage collecting
    Python uses reference counting, not a generational GC like Java.
    The CPython implementation, that is. Jython, built on top of Java, uses
    Java's GC. Ditto for IronPython implementation. PyPY may allow some choice.

    A
    Python object is destroyed when the refcount drops to 0. The GC only
    collects cyclic references. If you create none, there are no GC delays
    (you can in fact safely turn the GC off). Python does not share Java's
    nasty habit of having long GC delays.
  • Dave Angel at Sep 11, 2009 at 9:47 pm

    Paul Rubin wrote:
    sturlamolden <sturlamolden at yahoo.no> writes:
    Python uses reference counting, not a generational GC like Java. A
    Python object is destroyed when the refcount drops to 0. The GC only
    collects cyclic references. If you create none, there are no GC delays
    (you can in fact safely turn the GC off). Python does not share Java's
    nasty habit of having long GC delays.
    If you drop the last reference to a large object (say a billion item
    dictionary), then Python can pause for quite a long time freeing
    all the constituents of that object.
    (Both of these messages refer to an implementation, CPython, not the
    language Python.)

    The key difference is that CPython "pauses" at a deterministic point in
    the code, because of something the program has specified, rather than at
    a point when some system measurement decides that now would be a good
    time for gc.
  • M.-A. Lemburg at Sep 14, 2009 at 1:10 pm

    Zac Burns wrote:
    I have a server running Python 2.6x64 which after running for about a
    month decides to lock up and become unresponsive to all threads for
    several minutes at a time. While it is locked up Python proceeds to
    consume large amounts of continually increasing memory.

    The basic function of the server is to serve a large dictionary -
    somewhat like a database. I have a couple theories as to why it locks
    up, but I'm not sure how to test them.

    Theories:
    Python is resizing the large dictionary
    Python is garbage collecting

    How would you suggest to figure out what is the problem?
    Enable process core dumps and then kill the process.

    Using a debugger you should be able to find out what caused the hang.

    If you're serving a dictionary, I'd suggest using a different
    approach: keep the dictionary on disk instead of in memory.

    mxBeeBase will let you do that quite easily and is fast at
    it as well:

    http://www.egenix.com/products/python/mxBase/mxBeeBase/

    It includes a tunable caching mechanism to keep the most often
    requested data in memory.

    --
    Marc-Andre Lemburg
    eGenix.com

    Professional Python Services directly from the Source (#1, Sep 14 2009)
    Python/Zope Consulting and Support ... http://www.egenix.com/
    mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
    mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
    ________________________________________________________________________

    ::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


    eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
    Registered at Amtsgericht Duesseldorf: HRB 46611
    http://www.egenix.com/company/contact/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedSep 9, '09 at 8:28p
activeSep 14, '09 at 1:10p
posts9
users7
websitepython.org

People

Translate

site design / logo © 2022 Grokbase