If you’ve been looking for deeper insight into your JVM and application server, we’ve got some good news for you. The latest release of the New Relic Java agent includes an increase in the amount of data we collect on your Java applications and these new metrics can be used to solve a multitude of performance problems.
The new metrics are located under the JVM tab and include the following:
* Loaded and unloaded class count for the JVM
* Active thread count for the JVM
* Active and idle thread count for each thread pool
* The ratio of active to maximum thread count for each thread pool
* Active, expired and rejected HTTP session counts per application
* Active, finished and created transaction counts per application server
Now let’s take a closer look at each of them:
Loaded & Unloaded Class Count
Location: Under the Memory tab in the bottom-right corner of the screen.
Supported Application Servers: All application servers that have JMX enabled.
Use Cases: The loaded and unloaded class count can be used for a variety of purposes. For example, if the loaded class count is constantly going up, then the app server or a class loader may have a bug. Or if you perform upgrades without bringing down the JVM, you can use it to verify that classes were unloaded and then reloaded.
Active Thread Count
Location: Under the Threads tab.
Supported Application Servers: All application servers that have JMX enabled.
Use Cases: You can use the thread count to determine how many active threads are running in your application. This is useful for determining usage trends. For example, it can show the time of day and the day of the week in which you usually reach peak thread count. In addition, the creation of too many threads can result in out of memory errors or thrashing. By watching this metric, you can reduce excessive memory consumption before it’s too late.
Thread Pool Metrics
Location: Under the Threads tab.
Supported Application Servers: Tomcat, JBoss 5 and 6, Resin, Jetty, WebLogic, TomEE, Glassfish, and WebSphere
Use Cases: Thread pools are typically used to service multiple requests simultaneously. However, to get the best throughput, thread pools must be configured appropriately. For example, if the maximum thread count is set too high, the app will slow down from excessive memory usage. But if the maximum thread count is too low, it will cause requests to block or timeout.
You can use these metrics to see if you are reaching the maximum thread count in a pool. In addition, they can be used to tune other properties – such as the amount of time before an idle thread is destroyed and the frequency of when new threads are created.
This graph displays information on the http-bio-8080 thread pool on a Tomcat 7.0 application server. It shows that the thread pool starts with 10 idle threads and never handles more than five active requests at a time. The 0.23% capacity indicates that the number of active threads is well under the limit.
Session Metrics
Location: Under the HTTP Sessions tab.
Supported Application Servers: Tomcat, JBoss 5 and 6, Resin, TomEE, Glassfish, and WebSphere
Use Cases: HTTP session information is used to determine usage trends such as the time of day when an application is getting the most amount of traffic. It can also be used to tune configuration properties such as the maximum number of active sessions allowed at one time and the amount of time a session remains active. For example, a high rejected session count usually indicates that the maximum active session count should be increased. Meanwhile, a high expired session count can suggest that the session timeout is too low.
The graphs below show session information for two applications. The first indicates that a maximum of two sessions have been created for the application ‘examples’, but the sessions are constantly expiring. After increasing the timeout, the number of expired sessions reduces to zero. From the second graph, we see that zero sessions have been created for the application ‘host-manager’.
Transaction Metrics
Location: Under the App Server Transaction tab.
Supported Application Servers: JBoss 7, Resin, and Glassfish
Use Cases: These metrics show info on transactions that go through the application server's transaction manager. They are used to show transaction traffic patterns and help to configure the transaction manager.
Get Started Today
New Relic uses Java Management Extensions (JMX) to gather data on these new metrics. Before you get started using these new metrics, you must update to our latest Java agent and enable JMX on your application server.
You can also set up New Relic to show custom JMX metrics. To see how to display custom metrics, watch this video.
이 블로그에 표현된 견해는 저자의 견해이며 반드시 New Relic의 견해를 반영하는 것은 아닙니다. 저자가 제공하는 모든 솔루션은 환경에 따라 다르며 New Relic에서 제공하는 상용 솔루션이나 지원의 일부가 아닙니다. 이 블로그 게시물과 관련된 질문 및 지원이 필요한 경우 Explorers Hub(discuss.newrelic.com)에서만 참여하십시오. 이 블로그에는 타사 사이트의 콘텐츠에 대한 링크가 포함될 수 있습니다. 이러한 링크를 제공함으로써 New Relic은 해당 사이트에서 사용할 수 있는 정보, 보기 또는 제품을 채택, 보증, 승인 또는 보증하지 않습니다.