binjr
Replies: 3 comments 5 replies
-
|
That's a very high quality teaser — I had to come back and read it a second time! 😄 The charts already look like a very nice complement to JRDS and having them available right next to each other is an easy sell for me compared to alternatives like JMC or VisualVM. Now, I've found myself using the HTML flamegraph output of async-profiler rather that both of these tools lately and that's great to get an overally picture of where CPU / memory is used, but the time component is missing. If having a flamegraph in binjr means being able to take the JFR output of async-profiler and navigate the flamegraph in sync with other worksheets (and maybe filter on threads at the same time)… well, that would be a killer feature in itself. |
Beta Was this translation helpful? Give feedback.
-
This is very much the idea, yeah. As a matter of fact, this is something that the Firefox profiler does already pretty well, and what convinced me it would be a very useful feature. There are no doubt other tools that do it as well, but with binjr not being tied to any source or environment by design, I believe it could open up a lot of very interesting possibilities. The main hurdle, so far, is that I could not find a flame-graph component written for JavaFX (nor any other Java UI toolkit, for that matter), so it looks like if I want one, I'll have to write it myself... which sounds like a lot of work! 😅 |
Beta Was this translation helpful? Give feedback.
-
|
It looks like Qt didn't have a flamegraph widget either: there's one in Hotspot (no, not that Hotspot) and another one in QtCreator. With everybody using them these days, that's surprising. |
Beta Was this translation helpful? Give feedback.
-
|
It seems what most apps do these days is to embed a browser frame and use a JS lib to do the rendering. This is what JDK Mission Control does. From a strictly pragmatic angle, it probably works well enough, but this is something I would really prefer to avoid, for many reasons. |
Beta Was this translation helpful? Give feedback.
-
|
Is processing a flow of JFR events in real time something possible ? WIth something working like |
Beta Was this translation helpful? Give feedback.
-
|
Not at the moment, no. In the past, I have toyed with the idea of adding features in binjr to facilitate real-time monitoring of live sources, like a periodic fetch from data sources and auto-refreshing timelines. In this particular case, a good way to go about it would be to use an agent to stream JFR events directly from the JVM and push them to binjr, bypassing the creation of the jfr file altogether. But in the end, I came to the conclusion that monitoring use cases (as opposed to postmortem investigations/profiling) are generally better served by solutions that are both centralized and offer predefined dashboards, which are both properties that are orthogonal to binjr's existing feature set. Also, this is a very crowed market, and so far I've been inclined to think it would not be worth the effort. |
Beta Was this translation helpful? Give feedback.
-
|
Here's an illustration of how including the wall-clock time component for method profiling can help gain deeper insights out of a JFR profile, from a recent Real Life™ investigation. In this example, we are faced with an application that saw its startup time increase dramatically following a migration of some pieces of its software stack, to the point of becoming hardly usable. We first plot the standard metrics from a JFR capture, and we can clearly see a pattern in CPU usage, heap statistics and GC during the startup sequence that singles out a long period where the application seems to be stuck into what looks like a single threaded, repetitive operation in the critical path, preventing any further progress until it is completed:
(NB: the highlight was "added in post"; I didn't mean to mislead anyone into rejoicing that this has finally been implemented. But it will be. One day. Probably.) How can we tell the workload in that interval is single threaded? The CPU usage flat-lining at ~8% on a 12 cores machine is the main tell. And the same operation repeated in a loop? Well, at this stage is it only a hunch, but the regularity in both CPU and mem/GC activity strongly supports it: let's call that "duck profiling" - if it consumes CPU like a duck and allocates memory like a duck, then it is probably a duck (albeit an odd one). Then, we can very easily filter out the application's log on the that specific period of time, only to realize the application didn't log anything during that period; lots of events before or after but nothing during (not pictured: nothing to see). This strongly suggests all processing is taking place in either the underlying framework (Spring) or the in JVM itself. Meanwhile, a flame graph (courtesy of JMC) for the complete startup sequence shows it is literally dominated by a single kind of action: the computation of cryptographic hash triggered by jar signature verification:
The flame graph very clearly indicate that this is where most of the CPU time is being spent, but it doesn't really tell us anything about the relationship between the jar verification it highlights and the pattern we see in the plotted metrics. Once the ability to zoom in on a time interval and produce a flame graph out of those events only is added, we will be able to figure out whether or not there is indeed a link between the two immediately. But until then, what we can do it to filter out the method profiling data on the method that we care about in binjr's JFR event view and have a look at the distribution density for these events via the histogram view. And in this case, it is indeed quite telling: these events occur predominantly during the time interval we previously identified:
As it turns out, the root cause for all this is a bad interaction between Spring component scanning and signed jars, a pretty old issue but one that can still bite today, apparently (and, in case you're curious, this is how you work around it. Don't ask me more, I know close to nothing about Spring). |
Beta Was this translation helpful? Give feedback.
-
Already reading my mind before I even read the message! |
Beta Was this translation helpful? Give feedback.
-
Hi!
We're currently building support for files produced by JDK Flight Recorder (JFR) as a data source for binjr, and we would love to hear from anyone interested in the topic, sharing ideas, requests, feedback, etc...
What is JFR? To quote Wikipedia:
Each and every one of the events recorded by JFR naturally contain a timestamp, making it a pretty straight-forward source of data for binjr.
Binjr Is Not a Jmc Replacement
At least not for the time being. The initial plan is to play on the strength of the app and bring what it does well (browsing trough time series) to JFR recordings, not to try and achieve feature parity with JMC, nor make binjr a fully-fledged profiler.
Later down the line, we will probably consider adding some new visualization type, more specifically oriented to data types contained in JFR recordings, when those make sense and mix well with the other existing one, and more generally speaking, work well within the time-based navigation paradigm in binjr.
For example, the idea of a flame-graph representation for method profiling data that can be refined on selecting the events in specific period on a time line sounds quite promising and would be a naturally fit for binjr's navigation's style (and AFAIK, not something that is easily done in JMC at the moment).
What's in the box?
But this is The Future™ (maybe...), not what we have right-now. So what do we have, then?
We've added a single Data Adapter which add a new source type, aptly named "JFR". After opening a
.jfrfile using this adapter, two distinct sources are added to the workspace; both offer a hierarchical view of the various types of events recorded in the file, but allow for a different visualization type for the items they expose.The
JFR:EventssourceWhen dragging items for the source named
[JFR: Events] my_recording.jfronto the worksheet area, a view similar to that used for log files is created and a textual representation of the selected events are shown.Like for log files, you can keep on adding more items onto the same page, and use the filtering field to refine the event view based on their textual content and the event density histogram to filter out on their timestamps.
In essence, the core experience is fundamentally that of using the
jfrcommand line tool and grep/sed/awk'ing the results in a terminal emulator, while offering all the refinements of the binjr UI: dynamic coloring for event types, fast index-based filtering, facets computation, visual representation of the events occurrence on a timeline and the ability to persist the entire state of a session at anytime, to re-open later or share.But the most useful feature might possibly be that you can seamlessly merge on a single view events coming from different JFR recording files or, for that matter, any other source compatible with the event visualization (now handily identified by a small icon next to a source pane or worksheet tab's title).
This makes it remarkably easy to produced a unified and dynamically filterable view of a series of events that don't have the same point of origin, like getting the full picture from the exchange between a client and its server by mixing events from 4 different sources; a jfr recording for both the client and server processes, as well as the log files produced by each application.
The
JFR:ChartssourceThe JFR Charts source is very reminiscent of the core binjr experience: it allows for every types of event in a JFR recording that contain fields typed as numbers to be plotted as time series on various types of charts.
Plotting values over time makes perfect and immediate sense for a majority of all the available numeric field in JFR, like in the case of CPU usage or heap statistics, while for some others... well... not so much!
For thing like memory addresses or identifiers, well, let's just say that it makes for some "interesting" charts...
For now, the majority of event fields are presented in their raw form, but as the adapter matures, more and more specialization will be added, to prune out the fields that make no sense in plotting (like the aforementioned memory addresses or thread ids, etc...) and limit the amount of noise in the UI.
An other kind of special treatment that needs to be added at the source level is when the value of a field determines a category that is worth distinguishing as a distinct sources, like in the case of the Reference type counts in the GC category, where the kind of reference (final, soft, weak, phantom) is conveyed by a field's value rather than an event type.
Again, like for the JFR:Events source, there's nothing stopping you from mixing in any given charts metrics from a JFR recording with some others coming from different sources, like your Netdata or JRDS monitoring system, or from ad-hoc data gathered in CSV or RRD files.
Visualizing events and charts in sync
Although it is not possible to mix events and charts in a same worksheet, it is nonetheless possible to link the timelines of several worksheets, so that changes applied to one apply to the other ones, keeping them in sync.
Used together with the ability to detach worksheets from the main window, you can then compose dynamic rich views, that allow for peeking into events and charts simultaneously:
New.data.adapter.-.JDK.Flight.Recorder.mp4
What's next?
The new adapter is currently quite usable, but it is by no means "finished"; it's therefore the perfect time to give it a try and share your feedback in this discussion!You will find snapshot builds for all supported environments that contain the latest changes for this new adapter here:Keep in mind these builds are snapshots: they are regularly updated as the development branch becomes stable enough to deserve generating a new build for testing out the latest features.Meanwhile, the development branch for this new version is https://github.com/binjr/binjr/tree/v3.13.0-dev, so alternatively you can clone and build from source from there (NB: please be aware that there is even less guaranties that for this branch to be stable at any given point than for snapshot builds, though).binjr v3.13.0 has now been released!
You can download it from https://github.com/binjr/binjr/releases/tag/v3.13.0
Beta Was this translation helpful? Give feedback.
All reactions