2 Replies Latest reply: May 2, 2012 10:11 PM by zeejayy RSS

    Memory Leak issue "macromedia.util.UtilPagedTempBuffer"

    zeejayy

      For the past couple of weeks, I've been working on a memory leak on one of our servers.

      The application runs a lot of heavy querys and ajax stuff. After about 12 hours or so, the

      heap grows up to the max size, then the server starts to grind to a halt with GC overhead

      limit exceeded errors and it has to be restarted.

       

      The server is running win 2003, cf 8.01 with the latest hotfixes and and MS SQL Server 2005.

       

      I've run a heap dump through Eclipse MAT and it came up with the following leak suspects.

       

      Problem Suspect 1

      7,500 instances of "macromedia.util.UtilPagedTempBuffer", loaded by

      "coldfusion.bootstrap.BootstrapClassLoader @ 0x10b56120" occupy 351,566,904 (42.45%) bytes.

       

      Keywords

      macromedia.util.UtilPagedTempBuffer

      coldfusion.bootstrap.BootstrapClassLoader @ 0x10b56120

       

      Problem Suspect 2

      14 instances of "macromedia.jdbc.base.BaseWarnings", loaded by

      "coldfusion.bootstrap.BootstrapClassLoader @ 0x10b56120" occupy 294,957,568 (35.61%) bytes.

       

      Biggest instances:

       

      macromedia.jdbc.base.BaseWarnings @ 0x1d785958 - 80,087,248 (9.67%) bytes.

      macromedia.jdbc.base.BaseWarnings @ 0x11fa03b8 - 63,612,424 (7.68%) bytes.

      macromedia.jdbc.base.BaseWarnings @ 0x110df0f8 - 63,214,312 (7.63%) bytes.

      macromedia.jdbc.base.BaseWarnings @ 0x2da73540 - 40,891,344 (4.94%) bytes.

      macromedia.jdbc.base.BaseWarnings @ 0x11095ca0 - 17,197,352 (2.08%) bytes.

      macromedia.jdbc.base.BaseWarnings @ 0x2a40aba8 - 12,229,040 (1.48%) bytes.

       

      Keywords

      coldfusion.bootstrap.BootstrapClassLoader @ 0x10b56120

      macromedia.jdbc.base.BaseWarnings

       

      Problem Suspect 3

      1,050 instances of "macromedia.jdbc.base.BasePreparedStatement", loaded by

      "coldfusion.bootstrap.BootstrapClassLoader @ 0x10b56120" occupy 121,908,464 (14.72%) bytes.

       

      Keywords

      macromedia.jdbc.base.BasePreparedStatement

      coldfusion.bootstrap.BootstrapClassLoader @ 0x10b56120

       

      I think these have something to do with querys and SQL but i can't pinpoint

      the cause as of yet. If anybody has some insight on what my next step would

      be then it would be much appreciated.

        • 1. Re: Memory Leak issue "macromedia.util.UtilPagedTempBuffer"
          steinshouerj

          Did you ever find a resolution to this? I am running into this and am not sure what may be causing it. I have CF 9.0.1 on win 2008 64bit with SQL Server 2008. Here is my report.

           

          Problem Suspect 1

          9,935 instances of "macromedia.util.UtilPagedTempBuffer", loaded by "sun.misc.Launcher$AppClassLoader @ 0x780000cf8" occupy 645,586,384 (35.28%) bytes.

           

           

          Keywords

          macromedia.util.UtilPagedTempBuffer

          sun.misc.Launcher$AppClassLoader @ 0x780000cf8

           

           

           

           

          Problem Suspect 2

          12,919 instances of "macromedia.jdbc.base.BasePreparedStatement", loaded by "sun.misc.Launcher$AppClassLoader @ 0x780000cf8" occupy 538,577,736 (29.43%) bytes.

           

           

          Keywords

          macromedia.jdbc.base.BasePreparedStatement

          sun.misc.Launcher$AppClassLoader @ 0x780000cf8

          • 2. Re: Memory Leak issue "macromedia.util.UtilPagedTempBuffer"
            zeejayy Community Member

            Actualy i did find a resolution for this issue.

             

            I suspected for a while that it was database related because looking through some of the values in heap

            dumps showed bits and pieces of SQL and DB messages.

             

            After about a month of pulling out my hair trying to figure out what was going on, i ended up doing two things

            that fixed the problem. It's not really a perfect fix but it's plenty good enough for my needs.

             

            First i changed the select method on the CF datasource from direct to cursor. The cursor method uses less

            memory because the entire record set isn't returned right away and instead is somewhat spooled out on demand.

             

            Second, and this is what really made the difference, i changed the connection pooling settings.

             

            The default is 1000 max pooled statements with a timeout of 20 min and an interval of 7 min to close expired connections.

             

            Those settings have never really been a problem in the past, but this app has some really heavy querys and seems to have a

            real problem with pooling. I've set the max statements to 100, the timeout to 5 min, and the interval to 1 min.

             

            I don't know if I actualy needed to set the pooling so much lower to get it all working, but I went somewhat overkill

            because I wanted to really be able to notice a difference.

             

            No doubt the app could also be better designed to avoid this issue, but at least now it can run 24/7 instead of grinding to a halt after

            a day or so. I haven't really noticed any drop in performance with the new settings.