It is really difficult to distinguish between leaks and bad memory usage
using hprof. I'm used to use JProfiler, enable object allocation time
recording and keep 2 snapshots: 1 after few hours, 1 after few days
(after a GC) and search for long running objects allocated after the
first snapshot and still in memory.
I did this for the default file based distribution and under the
"standard" release postage load and I didn't find old objects.
Noel J. Bergman wrote:
Traces 34780, 5954, 5960 and 24996 require explanation
1 9.69% 9.69% 4821600 294 139416400 8501 34780 [B
TRACE 34780:
org.gjt.mm.mysql.Buffer.<init>(<Unknown>:Unknown line)
org.gjt.mm.mysql.PreparedStatement.executeQuery(<Unknown>:Unknown line)
org.apache.james.mailrepository.JDBCSpoolRepository.loadPendingMessages(:2
76)
Ok, this is bothersome. There does not appear to be any reason for there to
be 294 outstanding buffers taking up 4.8MB of heap.
IIRC connector/j caches in memory for each connection the whole expanded
configuration as chars. This uses a lot of memory. I think I already
said that when using jdbc over mysql I reserve 2-3 additional MB in the
maximum heap for each connection I configure in config.xml because of this.
3 3.28% 21.42% 1631296 15245 31949344 298592 5954 [C
5 3.09% 27.66% 1539240 9525 30157792 186620 5960 [B
TRACE 5954:
java.lang.StringBuffer.expandCapacity(StringBuffer.java:202)
java.lang.StringBuffer.append(StringBuffer.java:401)
java.io.UnixFileSystem.resolve(UnixFileSystem.java:93)
java.io.File.<init>(File.java:227)
java.io.File.listFiles(File.java:998)
org.apache.avalon.excalibur.monitor.DirectoryResource.testModifiedAfter(Dir
ectoryResource.java:84)
org.apache.avalon.excalibur.monitor.impl.AbstractMonitor.scanAllResources(A
bstractMonitor.java:132)
org.apache.avalon.excalibur.monitor.impl.ActiveMonitor.run(ActiveMonitor.ja
va:102)
java.lang.Thread.run(Thread.java:534)
TRACE 5960:
java.lang.StringCoding$CharsetSE.encode(StringCoding.java:336)
java.lang.StringCoding.encode(StringCoding.java:380)
java.lang.StringCoding.encode(StringCoding.java:386)
java.lang.String.getBytes(String.java:590)
java.io.UnixFileSystem.getLastModifiedTime(UnixFileSystem.java:Native
method)
java.io.File.lastModified(File.java:773)
org.apache.avalon.excalibur.monitor.DirectoryResource.testModifiedAfter(Dir
ectoryResource.java:93)
org.apache.avalon.excalibur.monitor.impl.AbstractMonitor.scanAllResources(A
bstractMonitor.java:132)
org.apache.avalon.excalibur.monitor.impl.ActiveMonitor.run(ActiveMonitor.ja
va:102)
I'm going to increase the stack depth for the next test to see where these
are coming from. 3MB for what? And it isn't in our code as far as I can
see, so it must be some Avalon artifact.
Excalibur-monitor should not be used by james code but only by phoenix.
Did you changed anything on the phoenix side?
Btw if phoenix needs 3MB to keep references/hashes or anything else for
deployed classes I would not be so surprised.
I guess the leak is not here, I would investigate on the others spot first.
8 2.52% 35.46% 1253616 882 36346336 25572 24996 [B
TRACE 24996:
org.gjt.mm.mysql.PreparedStatement.<init>(<Unknown>:Unknown line)
org.gjt.mm.mysql.jdbc2.PreparedStatement.<init>(<Unknown>:Unknown line)
org.gjt.mm.mysql.jdbc2.Connection.prepareStatement(<Unknown>:Unknown line)
org.gjt.mm.mysql.jdbc2.Connection.prepareStatement(<Unknown>:Unknown line)
org.apache.james.util.mordred.PoolConnEntry.prepareStatement(PoolConnEntry.
java:257)
org.apache.james.mailrepository.JDBCSpoolRepository.loadPendingMessages(JDB
CSpoolRepository.java:272)
org.apache.james.mailrepository.JDBCSpoolRepository.getNextPendingMessage(J
DBCSpoolRepository.java:248)
org.apache.james.mailrepository.JDBCSpoolRepository.accept(JDBCSpoolReposit
ory.java:192)
org.apache.james.mailrepository.JDBCSpoolRepository.accept(JDBCSpoolReposit
ory.java:122)
Disturbing on two accounts. First, why are there 882 outstanding
PreparedStatement objects left in memory, and secondly, why didn't I switch
to DBCP from Mordred? :-)
Is there anyone supporting mordred here? If not we should remove any
mordred reference from the config.xml. And I would like to remove
mordred folder from our trunk.
So there are two incidents of MySQL apparently leaking, but not on every
opportunity. And we do have explicit close calls for that allocation spot.
This is not enough to say they are leaks, they could simply be memory
correctly allocated for the current usage, btw between all the spots you
reported I would start looking in this one.
You should make a further report later so we can compare the numbers of
live objects vs allocated and see wether they increased proportionally
or they are almost equals for each spot.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
