Thermostat is Red Hat’s Monitoring and management tool for Java Deployments, allowing users to measure and monitor a host of different performance aspects of their Java applications. Available metrics range from raw CPU and memory usage to operation of the Garbage Collector and Compiler through to thread activity and method call/heap profiles. Thermostat provides a GUI view of activity of local and distributed JVMs in real time and it also backs up all the metrics it obtains to a persistent store so they can be reviewed offline.
What Thermostat cannot do on its own is track events and record statistics that are specific to a given Java application, at least not unless the application co-operates with it, for example by publishing JMX statistics that Thermostat can read, persist and display in its GUI. However, that’s about to change thanks to work Red Hat’s OpenJDK team has been doing to integrate Byteman into Thermostat.
Byteman is a tool which can be used to modify the behaviour of Java programs by injecting extra Java code almost anywhere in the program. You don’t need to recompile your program or even prepare it in advance in order for this to work. You can specify changes to the program on the command line but, what is more amazing, you can actually use Byteman to change the way a program runs after startup while it is still running.
Continue reading “Video: Monitoring application events in Thermostat, using Byteman”
OpenJDK is the premier open source Java implementation. The OpenJDK project provides the code used to build Red Hat’s Java releases for Fedora and RHEL and the Java releases used on most other Linux distributions. It also forms the basis of Oracle’s proprietary Java binary releases.
The Red Hat OpenJDK team has been working for some time now, along with organizations like the London Java Community (LJC) and some of our academic partners (e.g. Glasgow & Manchester) to encourage researchers and developers to dive into the innards of OpenJDK’s Java Virtual Machine (JVM) and see how it actually works. One reason is the entirely selfish one that we would like to enlarge the community of potential contributors to the OpenJDK project. Another is that we think it is no bad thing for Java developers, as indeed for any developers, to understand the tools they are using at a deeper level and appreciate how a well designed tool shields them from having to manage some of the more complex aspects of the runtime environment in which their programs execute.
Continue reading “What Lies Beneath: A tour of the dark gritty underbelly of OpenJDK”
The test web service implements a simple file cache storing up to 10 copies of any given named file. Uploading copies beyond the 10th one causes the oldest version to be discarded. The server supports a variety of requests allowing
a new version of a file to be uploaded
an existing file version to be downloaded
listing of the name and version counts of all files in the cache
deletion of all copies of a named file
deletion of the whole cache
Continue reading “Dude, where’s my PaaS memory? Tuning Java’s footprint in OpenShift (Part 2)”
Java is often blamed for being an over-hungry consumer of physical memory. Indeed, until recently our OpenShift team were tempted to draw this same conclusion. OpenShift is Red Hat’s open source Platform as a Service (PaaS) product. You can access it via public Cloud infrastructure managed by Red Hat (OpenShift Online) or even deploy it to your own data centre/private cloud (OpenShift Enterprise). OpenShift Online provides simple and manageable scalability to anyone developing and deploying web services. One of the OpenShift team’s goals is to maximize the number of guest Java EE deployments on any underlying physical host. However, in the first release of OpenShift meeting this goal was challenged by the high physical memory use observed in many of the deployed JVMs. With only so much memory available on any given physical host the more memory each JVM uses the lower the density of guest deployments.
Continue reading “Dude, where's my PaaS memory? Tuning Java's footprint in OpenShift (Part 1)”