Loading ...
Sorry, an error occurred while loading the content.

How to get rid of Memory leak

Expand Messages
  • Till Crueger
    Hi again, So I am still trying to optimize my programm. After a few more tests I noticed, that it is actually pretty fast at the beginning and then the speed
    Message 1 of 6 , Dec 1, 2007
    • 0 Attachment
      Hi again,

      So I am still trying to optimize my programm. After a few more tests I
      noticed, that it is actually pretty fast at the beginning and then the
      speed decays very fast. So the Problem should not be the math/loop/etc
      part anymore but rather the loss of speed. Letting my programm run for a
      while I also noticed, that my computer will start swapping quite a lot
      after a while.

      I looked at the output of Gc.print_stat to see what is happening here and
      noticed, that between two succesive calls to the same function the minor
      Heap keeps growing with each call. So after several calls it has gotten so
      big that it can't run efficiently anymore. In the call all I am using are
      local variables and some object fields, that should not grow in size.

      Is there any way to figure out where this memory leak occurs and how to
      stop it?

      Thanks once more for your help,
      Till

      --
      There is nothing noble in being superior to your fellow men, true nobility
      lies in being superior to your former self.
      --Radiohead
    • Richard Jones
      ... You re looking in the wrong place. The minor heap always grows until it hits some maximum size (32 K words IIRC, but you can adjust it) at which point the
      Message 2 of 6 , Dec 1, 2007
      • 0 Attachment
        On Sat, Dec 01, 2007 at 02:03:27PM +0100, Till Crueger wrote:
        > So I am still trying to optimize my programm. After a few more tests I
        > noticed, that it is actually pretty fast at the beginning and then the
        > speed decays very fast. So the Problem should not be the math/loop/etc
        > part anymore but rather the loss of speed. Letting my programm run for a
        > while I also noticed, that my computer will start swapping quite a lot
        > after a while.
        >
        > I looked at the output of Gc.print_stat to see what is happening here and
        > noticed, that between two succesive calls to the same function the minor
        > Heap keeps growing with each call. So after several calls it has gotten so
        > big that it can't run efficiently anymore. In the call all I am using are
        > local variables and some object fields, that should not grow in size.
        >
        > Is there any way to figure out where this memory leak occurs and how to
        > stop it?

        You're looking in the wrong place. The minor heap always grows until
        it hits some maximum size (32 K words IIRC, but you can adjust it) at
        which point the whole minor heap is collected and a slice of major GC
        is done.

        Is the real memory consumption of your program increasing over longer
        periods of time? Look at /proc/<pid>/maps and the live_words field
        returned by the Gc. Is the compactor running? (Certain libraries
        unfortunately turn it off, eg. lablgtk).

        Rich.

        --
        Richard Jones
        Red Hat
      • Jon Harrop
        ... We wrote a memory profiler with the intent of releasing it as a commercial product but never got around to it. You most likely have a cache somewhere that
        Message 3 of 6 , Dec 1, 2007
        • 0 Attachment
          On Saturday 01 December 2007 13:03, Till Crueger wrote:
          > Hi again,
          >
          > So I am still trying to optimize my programm. After a few more tests I
          > noticed, that it is actually pretty fast at the beginning and then the
          > speed decays very fast. So the Problem should not be the math/loop/etc
          > part anymore but rather the loss of speed. Letting my programm run for a
          > while I also noticed, that my computer will start swapping quite a lot
          > after a while.
          >
          > I looked at the output of Gc.print_stat to see what is happening here and
          > noticed, that between two succesive calls to the same function the minor
          > Heap keeps growing with each call. So after several calls it has gotten so
          > big that it can't run efficiently anymore. In the call all I am using are
          > local variables and some object fields, that should not grow in size.
          >
          > Is there any way to figure out where this memory leak occurs and how to
          > stop it?

          We wrote a memory profiler with the intent of releasing it as a commercial
          product but never got around to it.

          You most likely have a cache somewhere that is growing unbounded. That is
          basically the only way to get a memory leak in a GC'd language (assuming you
          aren't using broken unsafe code).

          --
          Dr Jon D Harrop, Flying Frog Consultancy Ltd.
          http://www.ffconsultancy.com/products/?e
        • Till Crueger
          ... I am not sure I really understand the information in the maps file. I had a look at it, as well as the smaps file on my system. I also made two snapshots
          Message 4 of 6 , Dec 1, 2007
          • 0 Attachment
            On Sat, 01 Dec 2007 16:20:36 +0100, Richard Jones <rich@...> wrote:

            > You're looking in the wrong place. The minor heap always grows until
            > it hits some maximum size (32 K words IIRC, but you can adjust it) at
            > which point the whole minor heap is collected and a slice of major GC
            > is done.
            >
            > Is the real memory consumption of your program increasing over longer
            > periods of time? Look at /proc/<pid>/maps and the live_words field
            > returned by the Gc. Is the compactor running? (Certain libraries
            > unfortunately turn it off, eg. lablgtk).

            I am not sure I really understand the information in the maps file. I had
            a look at it, as well as the smaps file on my system. I also made two
            snapshots during the execution, but both of them were rather at the
            beginning of the test run. At the end my System was so busy, that all I
            could do was to kill the process.

            I also recorded the data from the Gc.print_stat call during execution.

            At the beginning it was like this:
            minor_words: 1933383
            promoted_words: 16645
            major_words: 138632414
            minor_collections: 64
            major_collections: 2
            heap_words: 138651648
            heap_chunks: 15
            top_heap_words: 138651648
            live_words: 138632249
            live_blocks: 14828939
            free_words: 19399
            free_blocks: 22
            largest_free: 12254
            fragments: 0
            compactions: 0

            When I killed it, the output was along the lines of this:
            minor_words: 1453402707
            promoted_words: 151557
            major_words: 1097565922
            minor_collections: 47945
            major_collections: 14
            heap_words: 331858944
            heap_chunks: 2001
            top_heap_words: 331858944
            live_words: 254902017
            live_blocks: 14838058
            free_words: 76956926
            free_blocks: 2030
            largest_free: 97280
            fragments: 1
            compactions: 0

            As far as I can interpret this, the minor word count is far beyond the 32k
            you mentioned. And the number of live words also keeps growing steadily.
            When I ran another program yesterday, that has many .cmos and libraries in
            common with this one, it ended with a Out of Memory Exception while trying
            to dump it's data to a file.

            Bye,

            Till

            --
            It can't rain all the time.
            --The Crow
          • Remi Vanicat
            ... No, to is not what is meant : minor_words : Number of words allocated in the minor heap since the program was started. This number is accurate in byte-code
            Message 5 of 6 , Dec 1, 2007
            • 0 Attachment
              "Till Crueger" <crueger@...-bonn.de> writes:

              > When I killed it, the output was along the lines of this:
              > minor_words: 1453402707
              > promoted_words: 151557
              > major_words: 1097565922
              > minor_collections: 47945
              > major_collections: 14
              > heap_words: 331858944
              > heap_chunks: 2001
              > top_heap_words: 331858944
              > live_words: 254902017
              > live_blocks: 14838058
              > free_words: 76956926
              > free_blocks: 2030
              > largest_free: 97280
              > fragments: 1
              > compactions: 0
              >
              > As far as I can interpret this, the minor word count is far beyond the 32k
              > you mentioned.

              No, to is not what is meant :
              minor_words : Number of words allocated in the minor heap since the
              program was started. This number is accurate in byte-code programs,
              but only an approximation in programs compiled to native code.

              So it is not the number of lived words in the minor heap, but the
              number of words that have been allocated (and for most of them freed or
              promoted).

              What is of interest is the heap_words which is the current size of the
              heap and the live_words which is the number of those words that are in
              some ocaml value.

              Note that there may be also thing that are not into the heap,
              particularly if you are using some C library (say lablgtk, lablgl, or
              other). Here in C library there is a HUGE potential for memory leak.




              --
              RĂ©mi Vanicat
            • Richard Jones
              ... This Perl script might help you to interpret /proc/pid/maps: http://annexia.org/tmp/maps.pl ... [...] ... Remi covered this already, but I ll add that this
              Message 6 of 6 , Dec 1, 2007
              • 0 Attachment
                On Sat, Dec 01, 2007 at 06:09:07PM +0100, Till Crueger wrote:
                > I am not sure I really understand the information in the maps file. I had
                > a look at it, as well as the smaps file on my system. I also made two
                > snapshots during the execution, but both of them were rather at the
                > beginning of the test run. At the end my System was so busy, that all I
                > could do was to kill the process.

                This Perl script might help you to interpret /proc/pid/maps:
                http://annexia.org/tmp/maps.pl

                > I also recorded the data from the Gc.print_stat call during execution.
                > live_words: 138632249
                [...]
                > live_words: 254902017

                Remi covered this already, but I'll add that this is the only GC stat
                which I really look at. And only after first running 'Gc.compact ()'
                which runs a complete major cycle of the GC and compacts all memory.

                Rich.


                --
                Richard Jones
                Red Hat
              Your message has been successfully submitted and would be delivered to recipients shortly.