OOME due to large numbers of dirty BlockIos in RecordFile

Help
2014-01-22
2014-03-12
  • Dan Gravell
    Dan Gravell
    2014-01-22

    So.... I'm getting an OOME when using JDBM. According to Eclipse MemoryAnalyzer this is mostly caused by a lot of BlockIo objects.

    The BlockIo objects are owned by RecordFile but are stored in different members - I've noticed dirty and inTxn cases.

    What causes this large number to be retained? I am only committing once every five modifications to my data structures. Could it also be the size of data I am adding (although this shouldn't be too large)?

     
  • Dan Gravell
    Dan Gravell
    2014-01-23

    Darn... I rebooted and the heap dump was in /tmp...

    The heap size was 128MB. From memory, the RecordFile was consuming about 70MB. There were several thousand BlockIo objects, with the largest about 8KB and going down from there...

    Sorry, I can re-run the test to recreate the heap dump if you need more accurate figures. It just takes several hours...

     
    • Bryan Thompson
      Bryan Thompson
      2014-01-23

      The main question is whether there is a leak, whether you do not have enough RAM allocated, or whether you are not flushing out the connection. There are no known memory leaks as of my last involvement with jdbm. You can use a profiler to figure out the root objects that are causing those objects to be pinned and then figure out whether the transactions are not being properly committed or whether there is a real leak. Remember that any hard references you might hold to jdbm objects could cause them to be maintained beyond their intended life cycle.

      Just to be clear, are you working on the JDBM v1.0 code [1], or on the fork labeled JDBM3 at [1]?

      Thanks,
      Bryan

      [1] http://jdbm.sourceforge.net/

      From: Dan Gravell gravelld2@users.sf.net<mailto:gravelld2@users.sf.net>
      Reply-To: "[jdbm:discussion]" 12570@discussion.jdbm.p.re.sf.net<mailto:12570@discussion.jdbm.p.re.sf.net>
      Date: Thursday, January 23, 2014 6:22 AM
      To: "[jdbm:discussion]" 12570@discussion.jdbm.p.re.sf.net<mailto:12570@discussion.jdbm.p.re.sf.net>
      Subject: [jdbm:discussion] OOME due to large numbers of dirty BlockIos in RecordFile

      Darn... I rebooted and the heap dump was in /tmp...

      The heap size was 128MB. From memory, the RecordFile was consuming about 70MB. There were several thousand BlockIo objects, with the largest about 8KB and going down from there...

      Sorry, I can re-run the test to recreate the heap dump if you need more accurate figures. It just takes several hours...


      OOME due to large numbers of dirty BlockIos in RecordFilehttps://sourceforge.net/p/jdbm/discussion/12570/thread/a3af7438/?limit=25#d51d


      Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jdbm/discussion/12570/

      To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

       
      Attachments
      • Cees de Groot
        Cees de Groot
        2014-01-27

        I’d be interested in a dump. One of my hobbies is puzzling through memory dumps and I have to agree with Bryan that to my best knowledge, JDBM doesn’t leak (when used properly). So quite interested to learn what can cause this behaviour :)

        On 23Jan, 2014, at 6:30, Bryan Thompson thompsonbry@users.sf.net wrote:

        The main question is whether there is a leak, whether you do not have enough RAM allocated, or whether you are not flushing out the connection. There are no known memory leaks as of my last involvement with jdbm. You can use a profiler to figure out the root objects that are causing those objects to be pinned and then figure out whether the transactions are not being properly committed or whether there is a real leak. Remember that any hard references you might hold to jdbm objects could cause them to be maintained beyond their intended life cycle.

        Just to be clear, are you working on the JDBM v1.0 code [1], or on the fork labeled JDBM3 at [1]?

        Thanks,
        Bryan

        [1] http://jdbm.sourceforge.net/

        From: Dan Gravell gravelld2@users.sf.netgravelld2@users.sf.net
        Reply-To: "[jdbm:discussion]" 12570@discussion.jdbm.p.re.sf.net12570@discussion.jdbm.p.re.sf.net
        Date: Thursday, January 23, 2014 6:22 AM
        To: "[jdbm:discussion]" 12570@discussion.jdbm.p.re.sf.net12570@discussion.jdbm.p.re.sf.net
        Subject: [jdbm:discussion] OOME due to large numbers of dirty BlockIos in RecordFile

        Darn... I rebooted and the heap dump was in /tmp...

        The heap size was 128MB. From memory, the RecordFile was consuming about 70MB. There were several thousand BlockIo objects, with the largest about 8KB and going down from there...

        Sorry, I can re-run the test to recreate the heap dump if you need more accurate figures. It just takes several hours...

        OOME due to large numbers of dirty BlockIos in RecordFilehttps://sourceforge.net/p/jdbm/discussion/12570/thread/a3af7438/?limit=25#d51d

        Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jdbm/discussion/12570/

        To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

        OOME due to large numbers of dirty BlockIos in RecordFile

        Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jdbm/discussion/12570/

        To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

         
        • Dan Gravell
          Dan Gravell
          2014-01-28

          Here's the dump: https://drive.google.com/file/d/0Bwa_nIHUOJ9gUHBEZjVlVXhSRFE/edit?usp=sharing

          I probably am using it incorrectly! A few notes:

          • There are multiple RecordManagers because JDBM is used in different places in my app. I could consolidate but would only save me about 20MB I guess.

          • The BlockIos are listed as being retained by the RecordFile. I'm not sure why this is because they look to only have one path to a GC root... normally "dirty".

          • It's running in an OSGi environment, hence the classloaders

          • It's embedding a Jetty web server, hence the web stuff.

           
      • Dan Gravell
        Dan Gravell
        2014-01-28

        Cheers Bryan. It's JDBM v1.0. See the dump in the reply to Cees.

         
      • Cees de Groot
        Cees de Groot
        2014-01-30

        And a second question - what JVM are you using? I am working in a fairly
        new setup and only have JDK7, and notice some tests are failing. I'm
        quite sure this wasn't the case when v1.0 was released ;-)

        On 14-01-23 06:30 AM, Bryan Thompson wrote:

        The main question is whether there is a leak, whether you do not have
        enough RAM allocated, or whether you are not flushing out the
        connection. There are no known memory leaks as of my last involvement
        with jdbm. You can use a profiler to figure out the root objects that
        are causing those objects to be pinned and then figure out whether the
        transactions are not being properly committed or whether there is a
        real leak. Remember that any hard references you might hold to jdbm
        objects could cause them to be maintained beyond their intended life
        cycle.

        Just to be clear, are you working on the JDBM v1.0 code [1], or on the
        fork labeled JDBM3 at [1]?

        Thanks,
        Bryan

        [1] http://jdbm.sourceforge.net/

        From: Dan Gravell gravelld2@users.sf.net<mailto:gravelld2@users.sf.net <a="" href="mailto:gravelld2@users.sf.net%3Cmailto:gravelld2@users.sf.net">gravelld2@users.sf.net%3Cmailto:gravelld2@users.sf.net>
        Reply-To: "[jdbm:discussion]"
        12570@discussion.jdbm.p.re.sf.net<mailto:12570@discussion.jdbm.p.re.sf.net <a="" href="mailto:12570@discussion.jdbm.p.re.sf.net%3Cmailto:12570@discussion.jdbm.p.re.sf.net">12570@discussion.jdbm.p.re.sf.net%3Cmailto:12570@discussion.jdbm.p.re.sf.net>
        Date: Thursday, January 23, 2014 6:22 AM
        To: "[jdbm:discussion]"
        12570@discussion.jdbm.p.re.sf.net<mailto:12570@discussion.jdbm.p.re.sf.net <a="" href="mailto:12570@discussion.jdbm.p.re.sf.net%3Cmailto:12570@discussion.jdbm.p.re.sf.net">12570@discussion.jdbm.p.re.sf.net%3Cmailto:12570@discussion.jdbm.p.re.sf.net>
        Subject: [jdbm:discussion] OOME due to large numbers of dirty BlockIos
        in RecordFile

        Darn... I rebooted and the heap dump was in /tmp...

        The heap size was 128MB. From memory, the RecordFile was consuming
        about 70MB. There were several thousand BlockIo objects, with the
        largest about 8KB and going down from there...

        Sorry, I can re-run the test to recreate the heap dump if you need
        more accurate figures. It just takes several hours...


        OOME due to large numbers of dirty BlockIos in
        RecordFilehttps://sourceforge.net/p/jdbm/discussion/12570/thread/a3af7438/?limit=25#d51d


        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/jdbm/discussion/12570/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/


        OOME due to large numbers of dirty BlockIos in RecordFile
        http://sourceforge.net/p/jdbm/discussion/12570/thread/a3af7438/?limit=25#d51d/0655


        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/jdbm/discussion/12570/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

         
        Attachments
        • Dan Gravell
          Dan Gravell
          2014-01-30

          For this test I'm using OpenJDK 1.6.0_27. I'm not specifying a headless mode.

           
          • Cees de Groot
            Cees de Groot
            2014-01-30

            I’ll try to hunt one of the same version then. I don’t want to go on a wild goose chase here but when I grab the code and tests don’t even run, I’m getting uneasy…

            On 30Jan, 2014, at 6:11, Dan Gravell gravelld2@users.sf.net wrote:

            For this test I'm using OpenJDK 1.6.0_27. I'm not specifying a headless mode.

            OOME due to large numbers of dirty BlockIos in RecordFile

            Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jdbm/discussion/12570/

            To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

             
            • Dan Gravell
              Dan Gravell
              2014-03-12

              Don't suppose you ever found anything...? :)