Sync Time in Java
Why am I getting so much of sync time in my java application?
Regards,
Anoh Brou
actually, the auto-sensor information (that's where the sync information comes from) should normally already give you a good hint about the sync point.
could you share the PurePath above as a dynatrace session?
of course, the thread dump gives you then the full visibility into which other thread(s) were involved in that sync issue. you could also run thread dumps scheduled, let's say in a minute interval. as thread dumps are pretty light-weight that should not have too much impact on your application.
eJacket Acceptance 03222013.dts
Hello Christian,
Please find attached a session. Would you please show me what other process is in contention with "addStmtUsageData(weblogic.jdbc.wrapper.Statement, java.lang.String, long)"?
well, here's what i did:
i took a look at the Method Hotspots Dashlet to figure that the method mentioned by you really consumes most of the sync time:
weblogic.jdbc.common.internal.ConnectionPoolProfiler.addStmtUsageData(Statement, String, long)
and this seems to be called by prepared statements all the time.
so if i drill-down from this method to the PurePaths, i see which transactions are influenced by this method and that it's mostly around 10s for each transaction:
? 
so to really tell you, what's going on inside this method there would be 2 options:
- decompile this method and look at the code. you could do this on your system by right-clicking this method -> source lookup -> decompile source code
- taking thread dumps or CPU sampling when this is happening. however, this may be a little difficult with the timing.
however, what i'm really wondering about is the class that is consuming all this sync time: weblogic.jdbc.common.internal.ConnectionPoolProfiler!
sounds too me like there is some kind of connection pool profiling enabled on this system that consumes this sync time!
a short google search brought up some links with some potentially useful information (search for 'profil'):
- http://docs.oracle.com/cd/E13222_01/wls/docs81/ConsoleHelp/domain_jdbcconnectionpool_config_connections.html
- http://docs.oracle.com/cd/E15051_01/wls/docs103/jdbc_admin/monitor.html
maybe one of these options is turned on?! the description also clearly states something like 'This feature uses extra resources and will likely slow down connection pool operations, so it is not recommended for production use.'. so this could explain the sync time.
i think this connection pool profiling is worth taking a look at!
hope this helps,
Christian
A thread dump is a dump of what's happening "now". There is no historical info stored in the JVM regarding threads.
So for this to be useful, you would need to see when you are getting PPs with sync contention, and do a thread dump then. It will become very clear to you who is blocked and who is not.
The "sync" is not just informational. As Roman mentioned, the app is blocking/restricting access to either code or an object, making sure that one thread only is accessing this resource. So when a method is showing "sync" that means it's waiting for someone else to give up control of that shared resource.
If you need to know who is holding/blocking and who is waiting, you can use the thread dump feature of dynaTrace to show that.
Rob
Best guess - because somewhere in or under (the tree in the screenshot is not fully expanded) the getAwardInfoDocuments method you have a synchronized method or block and the PP could not enter it straight away.
Best, Roman
Here is the expanded getAwardInfoDocuments method. Are you saying that PP could enter getDADAward(gov.nsf.components.proposal.model.Proposal proposal, gov.nsf.components.dynAwdDoc.DADAwardVersion dadAwdVer) method straight away?
Does the sync have
a direct impact on the performace of the applicaqtion itself or just informational?
Regards,
Anoh Brou
Aehm, yes - this has direct impact. It means this method call took 14s and 90% of that are due to synchronization. Somewhere in the getDADAward there seems to be a synchronized block - I would try getting a developer for that app and ask him to take a look at this. Maybe they can shorten the part of the method that needs to be synchronized, but since we don't have visibilty below the method level this is nothing we can show...
Best, Roman
