【Java】jprofiler工具初上手

为了分析系统中的性能瓶颈，申请装了JProfile8(...公司可提供的最新版本...)，来了解学习一下监控原理和实操运用。

https://www.ej-technologies.com/products/jprofiler/overview.html

https://www.ej-technologies.com/resources/jprofiler/help/doc/main/introduction.html

https://www.ej-technologies.com/resources/jprofiler/help/doc/JProfiler.pdf

 

https://www.cnblogs.com/andashu/p/6273964.html

https://blog.csdn.net/qq_38025219/article/details/85046791

https://blog.csdn.net/Keith003/article/details/81742663

https://www.jianshu.com/p/0a2440dc49db

https://blog.csdn.net/u013613428/article/details/53926825

https://my.oschina.net/u/2487314/blog/798416

 

 

数据采集原理

JProfiler GUI在一个单独的JVM里启动，他与被监视的目标jvm之间通过socket通讯，目的为了不干扰目标JVM。所以监视本地Tomcat与监视远程的Tomcat的配置方法基本是一样的。

 

A1. 分析的数据主要来自于下面俩部分
1. 一部分来自于jvm的分析接口**JVMTI**(JVM Tool Interface) , JDK必须>=1.6

JVMTI is an event-based system. The profiling agent library can register handler functions for different events. It can then enable or disable selected events

例如: 对象的生命周期，thread的生命周期等信息
2. 一部分来自于instruments classes(可理解为class的重写,增加JProfiler相关统计功能)
例如：方法执行时间，次数，方法栈等信息

A2. 数据收集的原理如图2
1. 用户在JProfiler GUI中下达监控的指令(一般就是点击某个按钮)
2. JProfiler GUI JVM 通过socket(默认端口8849)，发送指令给被分析的jvm中的JProfile Agent。
3. JProfiler Agent(如果不清楚Agent请看文章第三部分"启动模式") 收到指令后，将该指令转换成相关需要监听的事件或者指令,来注册到JVMTI上或者直接让JVMTI去执行某功能(例如dump jvm内存)
4. JVMTI 根据注册的事件，来收集当前jvm的相关信息。 例如: 线程的生命周期; jvm的生命周期;classes的生命周期;对象实例的生命周期;堆内存的实时信息等等
5. JProfiler Agent将采集好的信息保存到**内存**中，按照一定规则统计好(如果发送所有数据JProfiler GUI，会对被分析的应用网络产生比较大的影响)
6. 返回给JProfiler GUI Socket.
7. JProfiler GUI Socket 将收到的信息返回 JProfiler GUI Render
8. JProfiler GUI Render 渲染成最终的展示效果

 

 

数据采集模式

设置sampling或instrument采集模式：

•      jprofiler客户端连接时，可以设置监控方式，其中在Method clall recording中有      定制监控方法分为，instrumentation方式和sampling方式

• instrumentation（注入）方式，是指在方法中注入字节码，记录监控信息，优点，结果更准确真实，监控的数据更多，包含调用次数等，缺点：性能开销大。所以一般JRE class和framework的class是在Filter中通常会过滤掉。

• sampling（采样）方式，是指，通过额外的线程，周期性的采集其他线程的执行信息，jprofiler8中默认的采集间隔为5ms（visualVM中默认的采样时间为100ms），优点：开销小；缺点：无法采集调用次数等信息，且对于执行时间短且调用频率高的接口存在采集遗漏的情况 

注: JProfiler本身没有指出数据的采集类型，这里的采集类型是针对方法调用的采集类型 。因为JProfiler的绝大多数核心功能都依赖方法调用采集的数据, 所以可以直接认为是JProfiler的数据采集类型。

 

 

采集启动模式

• Attach mode
  可直接将本机正在运行的jvm加载JProfiler Agent。优点是很方便，缺点是一些特性不能支持。如果选择Instrumentation数据采集方式，那么需要花一些额外时间来重写需要分析的class。

• Profile at startup 在被分析的jvm启动时，将指定的JProfiler Agent手动加载到该jvm。JProfiler GUI 将收集信息类型和策略等配置信息通过socket发送给JProfiler Agent，收到这些信息后该jvm才会启动。在被分析的jvm 的启动参数增加下面内容：语法: -agentpath:[path to jprofilerti library]

 

 

Overview of Features

---

 

• JProfiler's features are ordered into view sections. A view section can be made visible by selecting in JProfiler's sidebar. JProfiler offers the following view sections:
  • Memory profiling
    Keep track of your objects and find out where the problem spots are.
  • The heap walker
    Use the drill down capabilities of JProfiler's unique heap walker to find memory leaks.
  • CPU profiling
    Find out where your CPU time is going and zero in on performance bottlenecks.
  • Thread profiling
    Check the activity of your threads, resolve deadlocks and get detailed information on your application's monitor usage.
  • VM telemetry information
    Unfold the statistical history of your application with JProfiler's virtual machine telemetry monitors.
  • JEE & probes
    Measure higher-level subsystems of the JVM, like JDBC calls or file I/O, as well as own subsystems with custom probes.

• In order to help you find JProfiler's features which are most important to you, we present a situational overview. There are two types of uses for a profiler which arise from different motivations:
  • Problem solving
    If you turn to a profiler with a problem in your application, it most likely falls into one of the following three categories:
    • Performance problem
      To find performance related problem spots in your application, turn to JProfiler's CPU section. Often, performance problems are caused by excessive creation of temporary objects. For that case, the recorded objects views with its view mode set to "garbage collected objects" will show you where efforts to reduce allocations make sense.

      For I/O or any other subsystem that is measured by a probe, the probe views show you higher-level information on what operations take a lot of time.

    • Excessive memory consumption
      If your application consumes too much memory, the memory views will show you where the memory consumption comes from. With the reference views in the heap walker you can find out which objects are unnecessarily kept alive in the heap.
    • Memory leak
      If your application's memory consumption goes up linearly with time, you likely have a memory leak which is show stopper especially for application servers. The "mark current values and show differences" feature in the memory section and the heap walker will help you to find the cause.
    • Deadlock
      If you experience a deadlock, JProfiler's current monitor graph will help you to find the cause even for complex locking situations.
    • Hard to find bug
      A often overlooked but highly profitable use of a profiler is that of debugging. Many kinds of bugs are exceptionally hard to find by hand or by using a traditional debugger. Some bugs revolve around complex call stack scenarios (have a look at the CPU section), others around entangled object reference graphs (have a look at the heap walker section), both of which are not easy to keep track of.
      Particularly JProfiler's thread views are of great help in multi-threaded situations, where race-conditions and deadlocks are hard to track down.
  • Quality assurance
    During a development process, it's a good idea to regularly run a profiler on your application to assess potential problem spots. Even though an application may prove to be "good enough" in test cases, an awareness for performance and memory bottlenecks enables you adapt your design decisions as the project evolves. In this way you avoid costly re-engineering when real-world needs are not met. Use the information presented in JProfiler's telemetry section to keep an eye on the evolution of your application. The ability to save profiling snapshots enables you to keep track of your project's evolution. The offline profiling capability allows you to perform automated profiling runs on your application.

 

Sessions Overview

---

 

• The information required to start a profiling run is called a session. Sessions are saved in the file {User home directory}/.jprofiler8/config.xml and can be easily migrated to a different computer by importing this file in the setup wizard. When upgrading JProfiler, your settings of older installations are imported automatically.

• Sessions are created
  • on the "New Session" tab of JProfiler's start center.
  • by selecting Session->New Session from JProfiler's main menu.
  • automatically by JProfiler's application server integration wizard.
  • by importing them. from an external config file.
  • closing a session that was created by invoking quick attach with Session->Quick Attach. In that case, you will be asked whether to save a new session or not.
  Sessions are edited, deleted and opened
  • in JProfiler's start center.
  • through the open session dialog which is accessible from JProfiler's main menu via Session->Open Session.

• The session settings dialog can be invoked from
  • the open session dialog or the start center.
  • the the session startup dialog that is displayed just before a session is started.
  • JProfiler's main menu and the toolbar. The  toolbar button and the menu item Session->Session Settings open the session settings dialog.

• The session settings dialog is divided into 5 sections:
  • Application settings
    The application settings section collects all information that is required to start your application with profiling enabled or to connect to a running JVM. If you use an IDE integration, this information will be provided by the IDE.

    This section also includes the code editor & compilation settings which are important for code completion and compilation of scripts.

  • Filter settings
    In the filter settings section, you define which classes should be considered when recording call-stack information. Defining appropriate filters will help you to reduce data overload and minimizing CPU profiling overhead. By default, JProfiler adds an exclusion list
  • Profiling settings
    In the profiling settings section you can configure the way your application is profiled and change the focus of a profiling run toward performance or accuracy, CPU or memory profiling.
  • Trigger settings
    In the trigger settings section you can optionally define a list of triggers. With triggers, you can tell the profiling agent to execute specific actions when certain events occur in the JVM. The actions are also executed during offline profiling.
  • Databases
    In the Databases settings section you can configure the built-in database probes such as JDBC or MongoDB.
  • JEE & probes
    In the JEE & probes section you can configure built-in probes and optionally define a list of custom probes. Probes capture higher-level information on specific subsystems such as servlet requests, file I/O or launcher processes.

• If you change filter, profiling, trigger or probe settings for an active session, the new settings can be applied immediately if you profile a 1.6+ JRE. Apart from telemetry data, all recorded data including the heap dump in the heap walker will be discarded in that case. When profiling settings are updated, a bookmark will be added to views with a time-line, such as the telemetry views. The application of the new profiling settings may take some time, especially if filter settings are changed and the method call recording type is set to dynamic instrumentation. In this case, changes in the instrumentation requires that classes have to be retransformed to reflect the new filter settings.

  If you profile a pre-1.6 JRE, you have to restart the session.

  View settings on the other hand, are always adjustable during a running session and are saved separately for each session.

 

实操案例：

 https://www.cnblogs.com/onmyway20xx/p/3963735.html

https://www.cnblogs.com/langtianya/p/3172180.html