Stellar analysis of memory leaks: Finding a memory leak can be impossible without the right tool. In addition to the Java EE subsystems like JDBC, JPA/Hibernate, JSP/Servlets, JMS, web services and JNDI, JProfiler also presents high level information about RMI calls, files, sockets and processes. 
Higher level profiling data: JProfiler has a number of probes that show you higher level data from interesting subsystems in the JRE.
#Jprofiler memory leak code
With its JEE support, JProfiler bridges the gap between a code profiler and a high-level JEE monitoring tool. Also, JProfiler adds a semantic layer on top of the low-level profiling data, like JDBC, JPA/Hibernate, JMS and JNDI calls that are presented in the CPU profiling views.
Support for Java Enterprise Edition: Dedicated support for JEE is present in most views in JProfiler. Database profiling for JDBC, JPA and NoSQL: JProfiler's JDBC and JPA/Hibernate probes as well as the NoSQL probes for MongoDB, Cassandra and HBase show the reasons for slow database access and how slow statements are called by your code. On all levels, JProfiler has been carefully designed to help you get started with solving your problems. Configuring sessions is straight-forward, third party integrations make getting started a breeze and profiling data is presented in a natural way. Ease of use: JProfiler is just that: simple and powerful at the same time. JProfiler's intuitive UI helps to resolve performance bottlenecks, pin down memory leaks and understand threading issues. Then jcmd or jvisualvm can be performed on the production server.JProfiler's intuitive UI helps you resolve performance bottlenecks, pin down memory leaks and understand threading issues. Make anything that CAN grow in memory JMX monitorable. Similarly your pools (http client pools or JDBC pools, etc). Generally never use fields to store things use explicitly named caches (with JMX metric capabilities, so you can diagnose without using a debugger). For fresh code that's never been vetted you'll likely need to perform static analysis (am I caching or pooling anything?), or leverage the full-blown leak-detector kits (as in the article). If you already had a stable system, and you're just now seeing the memory leak, it's often something introduced, which makes the problem much easier to track down (diff the two released versions to identify class names to search for in the jcmd class-heap dump). Simple ps counts can be useful: ps -ef | grep $(pidof java) is a cheesy way to find all processes started by your java process. If, say you're launching imageMagic to do imager filtering, maybe you're launching too many. (in linux you have that default 1024 file handle limit too but you'd see explicit errors of that type)Īnother component is system-ram due to co-processes. Presumably each of which has lots of native and java buffers. You might be creating lots of temp files (should be easy to trace down) or just opening too many data-files. If see connection counts growing, there's the problem. I'll typically break out the ports based (DB/resource connections, vs inbound connections). 
I'll also use netstat -ntp | grep $(pidof java). Generally a mem leak has a couple companion objects, so seeing something as innocent as a Map.Key increasing lets me know I've got some unfreed' map growing. I've not found it possible to use profilers in production (not to mention it makes the system unusably slow). This helps me pinpoint my problem (in production) in a matter of minutes.
If I see a particular class increase by K (for k requests) I know i've got a winner. I'll often use the jcmd $(pidof java) GC.class_histogram to identify classes with trouble. If not, maybe it's cache related need to produce a diversified parameter-set. If the memory grows proportionately to the number of requests, then this should be fixable.
So I'll create a unit test or use apache-benchmark that initiate an expensive operation with deterministic memory pressure. My typical work-loads are such that it's pretty reproducible what causes a mem-leak. I'll also use jvisualVM, but it's mostly the same type of information. 90% of the time, I just inspect the java-gc logs (which I always have turned on).
0 kommentar(er)
