Changes for SAP HANA dump analyzer
This blog will track the changes for SAP HANA dump analyzer.
You can get the latest SAP HANA dump analyzer here. The latest HANA dump analyzer is on version 1.0.201910151100, You can query your SAP HANA dump analyzer version via the following command
java -jar HANADumpAnalyzer.jar -version
Version change info:
|Version||Updated Date||Major Changes|
1. Starting from SAP HANA 2.0 SPS 03, a new workload auto-tuning feature is introduced: in case of high load to the system, MAX_CONCURRRENCY parameter is automatically adjusted to shrink the capacity for OLAP load. As a result, the system will distribute more capacity to the OLTP transactions and the OLTP load are more preferred to be processed. If the above situation happens and MAX_CONCURRENCY is reduced to a rather small value, the previous version can provide wrong conclusion that HANA is overloaded because wrong configuration of MAX_CONCURRENCY. This version fixed this wrong conclusion and enhanced the workload analyzer to analyze HANA workload even if the workload auto-tuning feature is triggered.
2. Fixed bugs for indexhandle state graph, dotGraph, blocked transactions graph are not working correctly if they are big.
3. Starting with SAP HANA 2.0 SPS 04, there is a format change for the system views on [STATISTICS] section in the HANA runtime dump. Due to this change, earlier version of SAP HANA dump analyzer are not working correctly with error message “There is a problem to analyze this dump”. This new version fixed this issue and supports HANA runtime dumps from HANA version lower than HANA 2.0 SPS 04 and above.
1. Auto analyzing composite OOM is supported.
2. Improved the analysis if no fatal issue is auto-detected from the provided HANA runtime dump.
3. Added Runtime Dump Mini Check feature.In case the issue is not auto-analyzed, the runtime dump mini check report will be directly provided to end user to have an overview how the HANA system is behaving when the runtime dump is captured.If the issue is analyzed, the mini check report won’t be provided in the analysis report. It can still be triggered in the expert tab explicitly or with -hc option in command line mode.
4. Starting from SAP HANA 2.00.043, the configured value of max_concurrency is available in system view M_JOBEXECUTORS (MAX_CONCURRENCY_CONFIG). In case of a system hang issue with the small value of max_concurrency recorded in the system view M_JOBEXECUTORS_ on the runtime dump, SAP HANA dump analyzer should be able to tell if it’s caused by a wrong configuration or MAX_CONCURRENCY auto-adjusting feature is triggered.
5. Improved error handling when runtime dumps is incomplete.
6. Fixed bugs on flamgraph zoom in/zoom out etc.
|HANADumpAnalyzer 1.0.201911261800||2019-11-26||1. Fixed the HANA workload analyzer bug. Fixed wrong conclusion for max_concurrency configuration in some cases when HANA has lower version than lower than HANA 2.0 SP03 or above HANA 2.0 SP04.|
1. The admission control feature is available starting with SAP HANA 2.0 in order to restrict the execution of SAP HANA database requests at times of a high system utilization. This new version added HANA admission control queue analyzer to detect and analyze if there is a queue waiting issue.
2. Fixed a bug that the HANA composite OOM dump is not analyzed with error popup message “For input string:”XXgb(XXXXXXb)””.
3. Fixed an issue to allow space in the trace file name.
1. Fixed a hang issue when there is a loop in the parent relationship.
2. Fixed OOM analyzer issues e.g. when no SQL memory consumption is recorded on M_ACTIVE_STATEMENTS; when IPMM short info is not recorded on OOM dump on higher HANA revisions.
1. Added exception handling if the files to be analyzed are invalid
2. Added timeout handling if SAP HANA dump analyzer runs for long time. You can specify the timeout setting using -t option when executing via command line
3. Fixed a warning when running Waitgraph analysis on Linux environment
Frequent Seen Problems of using SAP HANA dump analyzer
1. In case you are uploading a large HANA runtime dump, the HANA dump analyzer can run into problems like “GC overhead limit exceeded” or error “Java heap space”. You can increase Java heap (e.g. to 1GB) by starting HANA dump analyzer via command:
java -Xmx1G -jar HANADumpAnalyzer.jar
HANA dump analyzer is not able to analyze the dump in HANA 2.0 SP4. Please find the attached image. Looking for your guidance.
Dump analyzer version..
D:\Users\SAP_HANA_dump_analyzer>java -jar HANADumpAnalyzer.jar -version
HANADumpAnalyzer Version 1.0.201906061800
Appreciated Nina. I will check and configure the HANASitter and try. Please let me know any further release of HANA Dump Analyzer.
while running dump analyzer i got below error. please suggest what to do?
Hello Prabhat, As Lin mentioned in the note above you need to increase the JAVA Heap memory overhead by using the following command
java -Xmx1G -jar HANADumpAnalyzer.jar
This will increase the to 1Gib.
Sorry for replying you late. the latest version HANADumpAnalyzer 1.0.202004281800 fixed the bug that the HANA composite OOM dump is not analyzed with error popup message “For input string:”XXgb(XXXXXXb)”
I was following your blogs and indeed it help me to find the crash and OOM Analysis.One thing I was looking was how to get the hold of user which would be responsible of causing the dumps.Suppose some application or query was executed and that has caused the dumps>I have gone through flame graph, concurrency graph ,OOM stack graph but couldn't get the details of user.I checked auto plus expert mode both .Can you help me on this.
In terms of OOM analysis. if a top consumer is the cause, the Top Memory Consumer part will provides details e.g. connection id, SQL user name. If you find the query on the Concurrency Memory Flame, tooltip on the corresponding sql executor thread (the bottom box in the query column) will show more details of the query. Try if this can help.
I couldn't find this way but I have found one another method that is more easier.
We can note down the thread ID from the dump Analyzer and go to expert mode ->Concurrency and choose the option as csv for Thread concurrency .An excel would open with all the thread details,we just have to find(ctrl+F)for our thread id noted earlier.
I found it more easy way to analysis.
getting this how to fix this?
stack_short or statistics is missing from the runtime dump