cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Excessive DB Transaction Commit

bilal.ahmed
Wanderer

Hi, 

 

We are using Java Agent for AppDynamics. Our application is Spring + Hibernate with MySQL running at back ground. 

We have instrumented couple of business transactions (POJO) to monitor and troubleshoot slow performance. 

When we are examining slow transaction snapshots, we usually encounter "DB Transaction Commit" line under DB and Remote Service calls. 

 

This  "DB Transaction Commit" line always seems to show incorrect information in Count and Total time, please see the attached snapshot with this message. 

For instance, the total transaction time is 26 seconds, but as per these 2 columns, only "DB Transaction Commit" took 82 second, which doe snot make sense. 

 

Can you please clarify what is "DB Transaction Commit" line represent, and why the information collected for this line does not fit with overall transaction infromation. 

 

Thanks

 

 

 

 

4 REPLIES 4

Arun.Dasetty
AppDynamics Team

Hi Bilal Ahmed,

 

  Apologies for issue you are seeing, We see similar issue(CORE-66761) already fixed in 4.2.x later version (4.2.6) , refer link https://docs.appdynamics.com/display/PRO42/Release+Notes "Incorrect data under Transaction snapshot SQL calls" )  Hope that information helps, Can you please confirm if this SaaS trial UI account or onPremise UI, if SaaS share url and snapshot deeplink, if onPremise, please confirm both contorller UI and agent version?

 

If this onPremise and you planned for upgrade, make sure you take cold backup for sure before starting upgrade process.

 

If you are seeing this for recent UI versions and onPremise Controller, please share below details as well:
- Is the sql calls are part of "synchronous" calls or async chronous calls, as we see time spent in exit other sub calls part of async thread will not add to BT ARTs in UI. 

-  attach exported snapshot PDF and also below query output issued at controller db: (GUID in your case starts wit e9fbxx refer screenshot you shared)

select * from requestdata_exitcall where id in select id from requestdata_summary where guid = 'REPLACE_GUID_HERE' and exitpoint_type = 'JDBC'

 

Regards.

Arun



Found something helpful? Click the Accept as Solution button to help others find answers faster.
Liked something? Click the Thumbs Up button.

- Issue is happeing on on-premisis account. 
- Controller Version : 4.2.2.1, build 59
- Server agent Version : 3.8.3.0 GA
- The database calls are synchronous
- Transaction snapshot is attached
- Query result is also posted (see attachment Query.out)


Other Queries :
- What is the latest version of controller and Java agents, that you will recommend us to upgrade.
- I don't see the option to export transaction snapshot as PDF, I remember it was availble in the proevious controller version.

 

Hi Bilal Ahmed,

 

Find our reply:

- We suggest to go for latest 4.2.x (4.2.15.4) Or 4.3.x(4.3.0.4), Please make sure you take cold backup of controller instllation for sure before upgrade process (refer cold backup steps)

- Upgrade controller and upgrade agent on one of the node, Hope that answers.

 

Regarding "export snapshot" option you can change old call graph view from Settings -> My Preferences screen "select checkbox" old call graph view and revisit snapshot on UI reload, Hope that answers, for now snapshot pdf not required.

 

Regards,

Arun



Found something helpful? Click the Accept as Solution button to help others find answers faster.
Liked something? Click the Thumbs Up button.

Hi

This issue is still occuring with the latest versions of controller and app agents. We are executing realtime SQL queries through the App to Oracle DB 11g

We are currently running controller - AppDynamics Version 4.4.1.0, build 111

App Agents - ver4.4.0.6

See below screen shots

 

On-Demand Webinar
Discover new Splunk integrations and AI innovations for Cisco AppDynamics.


Register Now!

Observe and Explore
Dive into our Community Blog for the Latest Insights and Updates!


Read the blog here