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

    Memory Leak issue "macromedia.util.UtilPagedTempBuffer"


      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.




      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.



      coldfusion.bootstrap.BootstrapClassLoader @ 0x10b56120



      Problem Suspect 3

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

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




      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"

          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.





          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.





          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.