Skip navigation
zeejayy
zeejayy Calculating status...
Currently Being Moderated

Memory Leak issue "macromedia.util.UtilPagedTempBuffer"

Nov 2, 2011 2:11 PM

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.

572 Views   2 Replies   Latest reply: zeejayy, May 2, 2012 10:11 PM
 
Replies
  • steinshouerj
    Currently Being Moderated
    1. steinshouerj,
    May 1, 2012 7:25 AM   in reply to zeejayy
    Report

    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

     
    |
    Mark as:
  • zeejayy
    Currently Being Moderated
    2. zeejayy,
    May 2, 2012 10:11 PM   in reply to steinshouerj
    Report

    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.

     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points