YourKit Operations: Difference between revisions
| Line 43: | Line 43: | ||
<br> | <br> | ||
7. Employ heuristics to identify the most likely source of leaks (there could be more than one independent leaks). Pick a class whose instances are most likely to cause the leak. | |||
8. Go to the new snapshot (t1) | |||
9. Select "Strong reachable" in the header. | |||
10. Go to Generations and select generation G0 -> Object Explorer in the lower window -> Filter by the suspect class name. The query will return instances of the class that survived on the heap since the first snapshot, and they are most likely to cause the leak. | |||
Revision as of 19:22, 12 June 2018
Internal
Logging
The log files are created in ~/.yjp/log.
Diagnosing a Memory Leak
A memory leak represents an unwanted accumulation of object instances on the heap. Memory leak diagnosis consists of:
- determining there is a memory leak
- identifying the object instances that leak
- identifying the reason the leaked object instances are held in memory
For concepts used in memory leak diagnosis, see Java Memory Concepts and YourKit Concepts for Memory Profiling.
Memory Leak Symptoms
The most obvious symptom of a memory leak is the continuous increase in the old generation footprint, after successive full garbage collections. This behavior can be determined by analyzing the garbage collection logs, and it is visible in the form of a monotonously increasing occupancy level. Full garbage collections can be forced from the profiler UI. Most OutOfMemoryErrors (but not all of them) are also an indication of memory leak.
Identifying Object Instances that Leak
The essence of the procedure is to capture two memory snapshots at two different moments in time, t0 and t1, sufficiently far apart so the state of the heap captured at the moment t1 includes object instances that are part of the leak. If HPROF memory snapshots are captured, the differential analysis may offer hints on what object instances may be included in the leak. However, if YourKit memory snapshot format is used, object generation information included in these snapshots may help identifying the leaked objects with more precision.
1. Take a memory snapshot at time t0. If the memory snapshot is taken while the target JVM is instrumented with the YourKit profiler agent, the object generation information is automatically incremented right before the snapshot to G0, so all the object instances included by the snapshot will belong to generation G0.
2. Let the application perform the task suspected of generating memory leak, or leave the application to run for a sufficiently long time to generate leaked instances.
3. Take a memory snapshot at time t1. For YourKit memory snapshots, the object generation information will be automatically incremented to G1.
4. Use the YourKit Profiler UI to load the t0 and t1 snapshots: File -> Open Snapshot.
5. Right click on t1 snapshot tab and "Compare Snapshot with ... " -> t0.
6. Select only "Strong reachable" reachability scope.
"Objects (+/-)" displays the difference in object count for instances of the specified class. A positive value means that snapshot t1 (the later memory state) has more objects than t0. "Size (+/-)" displays the difference in shallow size associated with the specified class instances. A positive value means that the corresponding instances in t1 snapshot (the later memory state) have a larger shallow memory footprint. The percentage associated with the change in size is calculated relative to the total size of all objects in the old snapshot: 100% of size corresponds to the total size of all objects in the old snapshot.
7. Employ heuristics to identify the most likely source of leaks (there could be more than one independent leaks). Pick a class whose instances are most likely to cause the leak.
8. Go to the new snapshot (t1)
9. Select "Strong reachable" in the header.
10. Go to Generations and select generation G0 -> Object Explorer in the lower window -> Filter by the suspect class name. The query will return instances of the class that survived on the heap since the first snapshot, and they are most likely to cause the leak.
TODO:
- http://localhost:9627/personal/Wiki.jsp?page=YourKitProcedures
- https://www.yourkit.com/docs/java/help/compare_snapshots.jsp
TODO - factor in dominators.
Diagnosing Elevated Steady State Memory Level
This procedure can be used in diagnosing elevated steady state memory level.
TODO
Diagnosing Excessive Garbage Collection
For concepts used in diagnosing excessive garbage collection, see YourKit Concepts for Memory Profiling.
Procedure:
Manually Configure Target JVM for Remote Profiling
Connect to a Remote Instrumented JVM via SSH
Before attempting to connect, the remote JVM should be instrumented as described in Manually Configure Target JVM for Remote Profiling.
Profile remote Java EE server or application ... -> Main Tab
Connection name: usually named after the host name.
Host IP or address: Address of the machine where Java processes run.
Application discovery method -> Advanced -> SSH user.
For "Authentication settings" the password or the private key can be used.
The connection can then be tested with "Test Connection".
Connect to a Remote Instrumented JVM via an SSH Tunnel
TODO.
Maven and YourKit
TODO: http://localhost:9627/personal/Wiki.jsp?page=MavenAndYourKit