Hi Gil, Thanks for the heads up and price references! I was certainly wary of the license aspect even though the project I am planning is for open source development.
Would there be anything of similar capability in openjdk? Looking at the openjdk src repo, it seems that there has been some more JEP 167 (http://openjdk.java.net/jeps/167) oriented changes introduced recently into jdk9. The event tracing logic in the jdk8 tracing code seems to already cover the core feature set of native (as opposed to BCI) JFR: stacktrace samples, monitor waits, alloc/gc events, compiler events. Judging by the small volume of changes between 2013 and 2015, I am guessing the tracing feature is not used much in openjdk7/8 and might be of uncertain reliability however (e.g. see this: https://bugs.openjdk.java.net/browse/JDK-8145788). Maybe I should look more into using those openjdk tracing capabilities instead of JFR for jdk9. The runtime configurability and resource management (like JFR's buffer/chunk/checkpoint) isn't quite there yet and I might need to write some hacks to enable output destination that is not stdout/stderr. As for commercial APM out there, not doubt they will have lots of custom BCI to cover app server use cases. I wonder how well (low overhead and high accuracy) they do on the jvm native instrumentation side (stack sample, alloc events, monitor wait). Same goes for profilers like Yourkit/JProfiler. Zee On Thursday, December 1, 2016 at 4:06:59 PM UTC-8, Gil Tene wrote: > > Virtually all the benefits of monitoring come in production environments > (by definition, I think), and that's probably why you don't see this > scenario (as) commonly used with JFR. > > Basically, using JFR for production [currently at least] requires a > commercial Java SE Advanced license. How/if this is enforced technically is > irrelevant, the click-thropiugh license that allows you to use it for free > is specifically restricted to non-production use. This is spelled out in > the Oracle Binary Code License Agreement for the Java SE Platform Products > and JavaFX ( > http://www.oracle.com/technetwork/java/javase/terms/license/index.html), > under SUPPLEMENTAL LICENSE TERMS... A. COMMERCIAL FEATURES. and B. SOFTWARE > INTERNAL USE FOR DEVELOPMENT LICENSE GRANT. And since JFR is clearly marked > as a "Commercial Feature" (you literally have to use the > -XX:+UnlockCommercialFeatures -XX:+FlightRecorder to use it) it's > impossible to claim ignorance of this fact. See e.g. > https://www.infoq.com/news/2013/10/misson-control-flight-recorder, > http://www.adam-bien.com/roller/abien/entry/java_mission_control_development_pricing, > > and > https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-guide/run.htm#JFRUH164 > > for some discussion and mentions around it. > > So while JFR can and may do some cool (and even semi-unique) things for > production monitoring, you'd have to clear the commercial pricing terms > first, and those seem pretty steep, as in a list price of $5000 per 2 x86 > cores according to the Oracle price list ( > http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf), > which would equate to e.g. $40K per instance for EC2 m3.2xlarge instances, > and $80K-160K per server for modern 2 socket servers (those with "only" > 16-32 cores). While I'm sure the actual production pricing could end up > much lower once purchasing departments finish hand-wrestling with Oracle's > sales folks, it would probably still be way more than other commercial > monitoring and JVM-knowledgable APM solutions that are much more feature > rich and focused would cost (e.g. Dynatrace, AppDynamics, NewRelic, etc.), > all of which list at a tiny fraction of the Oracle Java SE Advanced list > price levels (and are massively used in production systems). > > On Thursday, December 1, 2016 at 12:18:18 PM UTC-8, zeo...@gmail.com > wrote: >> >> Hi all, >> >> Does anyone know a good way to do continuous performance monitoring using >> JFR (JDK8)? I am interested in using this on some apache data pipeline >> projects (Spark, Flink etc). I have used JFR for perf profiling with fixed >> duration before. Continuous monitoring would be quite different. >> >> The ideal scenario is to set up JFR to write to UDP <ip:port> >> destinations with configurable update frequencies. Obviously that is not >> supported by JFR as it stands today. So I tried setting up continuous JFR >> with maxage=30s and running JFR.dump every 30s, to my surprise the time >> range covered by the dumped jfr files does NOT correspond to the maxage >> parameter I gave. Instead the time ranges >> (FlightRecordingLoader.loadFile(new >> File("xyz.jfr")).timeRange) from successive JFR.dump can be overlapping >> and much bigger than maxage. >> >> So couple of questions for those experienced users of JFR: >> >> -- What exactly is the semantics of maxage? >> I imagined that maxage has 2 effects: discarding events older than maxage >> and aggregating certain metrics (like stacktrace sample counts) over the >> time interval. It appears my understanding was way off. >> >> -- How does the event pool/buffer under consideration for next JFR.dump >> get reset? >> I was hoping every JFR.dump would reset the pool and allow the next >> JFR.dump to output non-overlapping time range. I was also wrong here. >> >> -- Is there any way to do continuous perf monitoring with JFR with a >> configured aggregation and output interval? >> One thing I did notice is that JFR would periodically (default seems 60s) >> flush to chunk files and then rotate chunk files according to maxchunksize >> param. I could use that mechanism to inotify-watch the repository dir and >> just read and parse the chunk files. However there are a few things missing >> if I wanted to go down this route: there is no way to set "maxchunkage" >> (would like to be able to set one as low as 10s), I will need to write some >> custom chunk file parser, not sure if chunk files have all the symbols to >> resolve the typeids. >> >> Thanks! >> >> -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
