Hi, I agree, this could be very useful…
— Kirk > On Nov 14, 2018, at 10:29 AM, Simon Roberts <si...@dancingcloudservices.com> > wrote: > > I would say this could be pretty useful. It's almost like a > platform-independent, process specific vmstat, with JVM extras. Given the > existence of jps, this seems to fit in that ecosystem well. I find myself > having to work with windows just rarely enough that I'd have to look up how > to get this info on that host every time. > $0.02 > > > On Wed, Nov 14, 2018 at 7:57 AM Thomas Stüfe <thomas.stu...@gmail.com > <mailto:thomas.stu...@gmail.com>> wrote: > Hi all, > > We have that feature in our port which we would like to contribute, > and I would like to gauge opinions. > > First off, I am not sure which list is correct. This is more of a > serviceability issue, but implementation wise it fit hs-runtime > better. I'll start with serviceability, but feel free crosspost if > needed. > > Second, I am aware that this may require a JEP. If necessary and the > feedback is positive, I will draft one. > > ---- > > In our port we have something called "Statistics History". Basically > this is a rolling history, spanning up to 10 days, of a number of key > values. Key values range from JVM specifics like heap size, metaspace > size, number of threads etc, to platform specifics like memory > footprint, cpu load, io- and swapping activity etc. > > A periodic tasks collects those values, in - by default - 15 second > intervals. They are then fed into a FIFO. FIFO spans 10 days. To save > memory that FIFO is downsampled in two steps, so we have the last n > hours in high resolution and the last n days in low resolution (of > course all these parameters are configurable). > > The history report can be triggered via jcmd, and also could get > printed in the hs.err file (open for debate). > > --- > > Here some examples of how the whole thing looks like: > > http://cr.openjdk.java.net/~stuefe/webrevs/stathist/examples/stathist-volker.txt > > <http://cr.openjdk.java.net/~stuefe/webrevs/stathist/examples/stathist-volker.txt> > > http://cr.openjdk.java.net/~stuefe/webrevs/stathist/examples/stathist-s390x.txt > > <http://cr.openjdk.java.net/~stuefe/webrevs/stathist/examples/stathist-s390x.txt> > > --- > > This feature has been really popular with our support folk over the > years. Be it that the VM is starved for resources by the OS, that we > have some slow- or fast developing leak situation etc: these values > are a first and easy way to get a first stab at a situation, before we > start more expensive analysis. > > The explicit design goal of this history was to be very cheap - cheap > enough to be *always on* and getting forgotten. It is, in our port, > enabled by default. That way, if a problem occurs at a customer site, > we immediately see developments spanning the last 10 days, without > having to reproduce the issue. > > It is also robust enough to be usable during error reporting without > endangering the error reporting process or falsifying the picture. > > I am aware that this crosses over into JFR territory. But this feature > does not attempt to replace JFR, it is intended instead a cheap always > on first stop historical overview. > > -- > > I have a patch which can be applied atop of jdk12: > > http://cr.openjdk.java.net/~stuefe/webrevs/stathist/stathist.patch > <http://cr.openjdk.java.net/~stuefe/webrevs/stathist/stathist.patch> > > It works, passes our nightlies and no regressions are shown in dapapo > benchmarks. > > Please tell me what you think. Given enough interest, I will attempt > to contribute (drafting a JEP if necessary.) > > Thanks and Kind Regards, > > Thomas > > > -- > Simon Roberts > (303) 249 3613 >
