|
1 | | -# Async Profiler |
| 1 | +# Java App Profiling |
| 2 | + |
| 3 | +Java App Profiling uses the AsyncProfiler for sampling |
2 | 4 |
|
3 | 5 | Async Profiler is bound within the auto-instrument agent and corresponds to [In-Process Profiling](../../concepts-and-designs/profiling.md#in-process-profiling). |
4 | 6 |
|
5 | | -It is passed to the proxy in the form of a task, allowing it to be enabled or disabled dynamically. |
6 | | -When service encounters performance issues (cpu usage, memory allocation, locks), async-profiler task can be created. |
7 | | -When the proxy receives a task, it enables Async Profiler for sampling. |
8 | | -After sampling is completed, a flame graph will be generated for performance analysis to determine the specific business code line that caused the performance problem. |
| 7 | +It is delivered to the agent in the form of a task, allowing it to be enabled or disabled dynamically. |
| 8 | +When service encounters performance issues (cpu usage, memory allocation, locks), Async Profiler task can be created. |
| 9 | +When the agent receives a task, it enables Async Profiler for sampling. |
| 10 | +After sampling is completed, the sampling results are analyzed by requesting the server to render a flame graph for performance |
| 11 | +analysis to determine the specific business code lines that cause performance problems. |
9 | 12 |
|
10 | | -## Activate async profiler in the OAP |
| 13 | +## Activate Async Profiler in the OAP |
11 | 14 | OAP and the agent use a brand-new protocol to exchange Async Profiler data, so it is necessary to start OAP with the following configuration: |
12 | 15 |
|
13 | 16 | ```yaml |
14 | 17 | receiver-async-profiler: |
15 | | - selector: ${SW_RECEIVER_ASYNC_PROFILER:default} |
16 | | - default: |
| 18 | + selector: ${SW_RECEIVER_ASYNC_PROFILER:default} |
| 19 | + default: |
| 20 | + # Used to manage the maximum size of the jfr file that can be received, the unit is Byte, default is 30M |
| 21 | + jfrMaxSize: ${SW_RECEIVER_ASYNC_PROFILER_JFR_MAX_SIZE:31457280} |
| 22 | + # Used to determine whether to receive jfr in memory file or physical file mode |
| 23 | + # |
| 24 | + # The memory file mode have fewer local file system limitations, so they are by default. But it costs more memory. |
| 25 | + # |
| 26 | + # The physical file mode will use less memory when parsing and is more friendly to parsing large files. |
| 27 | + # However, if the storage of the tmp directory in the container is insufficient, the oap server instance may crash. |
| 28 | + # It is recommended to use physical file mode when volume mounting is used or the tmp directory has sufficient storage. |
| 29 | + memoryParserEnabled: ${SW_RECEIVER_ASYNC_PROFILER_MEMORY_PARSER_ENABLED:true} |
17 | 30 | ``` |
18 | 31 |
|
19 | 32 | ## Async Profiler Task with Analysis |
@@ -45,18 +58,18 @@ When the Agent receives a Async Profiler task from OAP, it automatically generat |
45 | 58 |
|
46 | 59 | ### Wait the agent to collect data and upload |
47 | 60 |
|
48 | | -At this point, async-profiler will trace the following kinds of events: |
| 61 | +At this point, Async Profiler will trace the events you selected when you created the task: |
49 | 62 |
|
50 | | -1. CPU cycles |
51 | | -2. Hardware and Software performance counters like cache misses, branch misses, page faults, context switches etc. |
52 | | -3. Allocations in Java Heap |
53 | | -4. Contented lock attempts, including both Java object monitors and ReentrantLocks |
| 63 | +1. CPU,WALL,ITIMER,CTIMER: CPU cycles |
| 64 | +2. ALLOC: Allocations in Java Heap |
| 65 | +3. LOCK: Contented lock attempts, including both Java object monitors and ReentrantLocks |
54 | 66 |
|
55 | | -Finally, java agent will upload the jfr file produced by async-profiler to the oap server for online performance analysis. |
| 67 | +Finally, the agent will upload the jfr file produced by Async Profiler to the oap server for online performance analysis. |
56 | 68 |
|
57 | 69 | ### Query the profiling task progresses |
58 | 70 |
|
59 | | -Wait for async-profiler to complete data collection and upload successfully,We can query the execution log of the async-profiler task and the successful and failed instances,which includes the following information: |
| 71 | +Wait for Async Profiler to complete data collection and upload successfully. |
| 72 | +We can query the execution logs of the Async Profiler task and the task status, which includes the following information: |
60 | 73 |
|
61 | 74 | 1. **successInstanceIds**: SuccessInstanceIds gives instances that have executed the task successfully. |
62 | 75 | 2. **errorInstanceIds**: ErrorInstanceIds gives instances that failed to execute the task. |
|
0 commit comments