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.

Reply via email to