Re: enable-time-statistics
David, I would say remove the caveat.Thanks for offering. Charlie On Fri, Jan 10, 2020 at 1:55 PM Dave Barnes wrote: > Sounds like the caveat could be dropped from the user guide. If we have > consensus on that (am I understanding correctly?), I'll initiate a JIRA > ticket. > > On Fri, Jan 10, 2020 at 1:47 PM Jacob Barrett wrote: > > > The biggest impact was in recording all the additional stats in the old > > blocking stats implementation. As of 9.8 the stats internals are mostly > > non-blocking. Enabling time stats has very little of any impact now. > > > > > On Jan 10, 2020, at 12:45 PM, Dan Smith wrote: > > > > > > I personally wouldn't be too worried about enabling time based > > statistics > > > in production. I think we segregated the time statistics because they > do > > > have to call System.nanoTime to measure the elapsed time. At one point > in > > > the history with old JDKs they called System.currentTimeMillis, which > was > > > really expensive. But now I'm not sure the nanoTime calls really have > > that > > > much of an impact compared to the rest of the processing time. > > > > > > -Dan > > > > > > > > >> On Fri, Jan 10, 2020 at 11:25 AM Mario Kevo > > wrote: > > >> > > >> Hi geode-dev, > > >> > > >> We have executed some traffic against Geode servers with time-based > > >> statistics enabled and disabled and we didn't see any performance > > >> difference. > > >> The documentation says: > > >> > > >> > > >> If you need time-based statistics, enable that. Time-based statistics > > >> require statistics sampling and archival. Example: > > >> > > >> statistic-sampling-enabled=true > > >> statistic-archive-file=myStatisticsArchiveFile.gfs > > >> enable-time-statistics=true > > >> > > >> > > >> Note: Time-based statistics can impact system performance and is not > > >> recommended for production environments. > > >> > > >> > > >> Do you know on which part this note referring to? > > >> > > >> > > >> Also we tried to enable time statistics on geode native but without > > >> success. > > >> > > >> We change in geode.properties file this parameter to true but didn't > get > > >> any additional statistics in statistics archive file. > > >> > > >> Do we need also to change something else to enable it or this is not > > >> working for geode-native? > > >> > > >> > > >> BR, > > >> > > >> Mario > > >> > > >> > > > -- Charlie Black | cbl...@pivotal.io
Re: enable-time-statistics
Read that as “As of geode 1.9.0 …”. Anthony > On Jan 10, 2020, at 1:19 PM, Jacob Barrett wrote: > > The biggest impact was in recording all the additional stats in the old > blocking stats implementation. As of 9.8 the stats internals are mostly > non-blocking. Enabling time stats has very little of any impact now.
Re: enable-time-statistics
Sounds like the caveat could be dropped from the user guide. If we have consensus on that (am I understanding correctly?), I'll initiate a JIRA ticket. On Fri, Jan 10, 2020 at 1:47 PM Jacob Barrett wrote: > The biggest impact was in recording all the additional stats in the old > blocking stats implementation. As of 9.8 the stats internals are mostly > non-blocking. Enabling time stats has very little of any impact now. > > > On Jan 10, 2020, at 12:45 PM, Dan Smith wrote: > > > > I personally wouldn't be too worried about enabling time based > statistics > > in production. I think we segregated the time statistics because they do > > have to call System.nanoTime to measure the elapsed time. At one point in > > the history with old JDKs they called System.currentTimeMillis, which was > > really expensive. But now I'm not sure the nanoTime calls really have > that > > much of an impact compared to the rest of the processing time. > > > > -Dan > > > > > >> On Fri, Jan 10, 2020 at 11:25 AM Mario Kevo > wrote: > >> > >> Hi geode-dev, > >> > >> We have executed some traffic against Geode servers with time-based > >> statistics enabled and disabled and we didn't see any performance > >> difference. > >> The documentation says: > >> > >> > >> If you need time-based statistics, enable that. Time-based statistics > >> require statistics sampling and archival. Example: > >> > >> statistic-sampling-enabled=true > >> statistic-archive-file=myStatisticsArchiveFile.gfs > >> enable-time-statistics=true > >> > >> > >> Note: Time-based statistics can impact system performance and is not > >> recommended for production environments. > >> > >> > >> Do you know on which part this note referring to? > >> > >> > >> Also we tried to enable time statistics on geode native but without > >> success. > >> > >> We change in geode.properties file this parameter to true but didn't get > >> any additional statistics in statistics archive file. > >> > >> Do we need also to change something else to enable it or this is not > >> working for geode-native? > >> > >> > >> BR, > >> > >> Mario > >> > >> >
Re: enable-time-statistics
The biggest impact was in recording all the additional stats in the old blocking stats implementation. As of 9.8 the stats internals are mostly non-blocking. Enabling time stats has very little of any impact now. > On Jan 10, 2020, at 12:45 PM, Dan Smith wrote: > > I personally wouldn't be too worried about enabling time based statistics > in production. I think we segregated the time statistics because they do > have to call System.nanoTime to measure the elapsed time. At one point in > the history with old JDKs they called System.currentTimeMillis, which was > really expensive. But now I'm not sure the nanoTime calls really have that > much of an impact compared to the rest of the processing time. > > -Dan > > >> On Fri, Jan 10, 2020 at 11:25 AM Mario Kevo wrote: >> >> Hi geode-dev, >> >> We have executed some traffic against Geode servers with time-based >> statistics enabled and disabled and we didn't see any performance >> difference. >> The documentation says: >> >> >> If you need time-based statistics, enable that. Time-based statistics >> require statistics sampling and archival. Example: >> >> statistic-sampling-enabled=true >> statistic-archive-file=myStatisticsArchiveFile.gfs >> enable-time-statistics=true >> >> >> Note: Time-based statistics can impact system performance and is not >> recommended for production environments. >> >> >> Do you know on which part this note referring to? >> >> >> Also we tried to enable time statistics on geode native but without >> success. >> >> We change in geode.properties file this parameter to true but didn't get >> any additional statistics in statistics archive file. >> >> Do we need also to change something else to enable it or this is not >> working for geode-native? >> >> >> BR, >> >> Mario >> >>
Re: enable-time-statistics
When we were doing Micrometer work we confirmed that enable-time-statistics doesn't change performance. We'd like to deprecate this property and turn it on always. On Fri, Jan 10, 2020 at 12:45 PM Dan Smith wrote: > I personally wouldn't be too worried about enabling time based statistics > in production. I think we segregated the time statistics because they do > have to call System.nanoTime to measure the elapsed time. At one point in > the history with old JDKs they called System.currentTimeMillis, which was > really expensive. But now I'm not sure the nanoTime calls really have that > much of an impact compared to the rest of the processing time. > > -Dan > > > On Fri, Jan 10, 2020 at 11:25 AM Mario Kevo wrote: > > > Hi geode-dev, > > > > We have executed some traffic against Geode servers with time-based > > statistics enabled and disabled and we didn't see any performance > > difference. > > The documentation says: > > > > > > If you need time-based statistics, enable that. Time-based statistics > > require statistics sampling and archival. Example: > > > > statistic-sampling-enabled=true > > statistic-archive-file=myStatisticsArchiveFile.gfs > > enable-time-statistics=true > > > > > > Note: Time-based statistics can impact system performance and is not > > recommended for production environments. > > > > > > Do you know on which part this note referring to? > > > > > > Also we tried to enable time statistics on geode native but without > > success. > > > > We change in geode.properties file this parameter to true but didn't get > > any additional statistics in statistics archive file. > > > > Do we need also to change something else to enable it or this is not > > working for geode-native? > > > > > > BR, > > > > Mario > > > > >
Re: enable-time-statistics
I personally wouldn't be too worried about enabling time based statistics in production. I think we segregated the time statistics because they do have to call System.nanoTime to measure the elapsed time. At one point in the history with old JDKs they called System.currentTimeMillis, which was really expensive. But now I'm not sure the nanoTime calls really have that much of an impact compared to the rest of the processing time. -Dan On Fri, Jan 10, 2020 at 11:25 AM Mario Kevo wrote: > Hi geode-dev, > > We have executed some traffic against Geode servers with time-based > statistics enabled and disabled and we didn't see any performance > difference. > The documentation says: > > > If you need time-based statistics, enable that. Time-based statistics > require statistics sampling and archival. Example: > > statistic-sampling-enabled=true > statistic-archive-file=myStatisticsArchiveFile.gfs > enable-time-statistics=true > > > Note: Time-based statistics can impact system performance and is not > recommended for production environments. > > > Do you know on which part this note referring to? > > > Also we tried to enable time statistics on geode native but without > success. > > We change in geode.properties file this parameter to true but didn't get > any additional statistics in statistics archive file. > > Do we need also to change something else to enable it or this is not > working for geode-native? > > > BR, > > Mario > >
enable-time-statistics
Hi geode-dev, We have executed some traffic against Geode servers with time-based statistics enabled and disabled and we didn't see any performance difference. The documentation says: If you need time-based statistics, enable that. Time-based statistics require statistics sampling and archival. Example: statistic-sampling-enabled=true statistic-archive-file=myStatisticsArchiveFile.gfs enable-time-statistics=true Note: Time-based statistics can impact system performance and is not recommended for production environments. Do you know on which part this note referring to? Also we tried to enable time statistics on geode native but without success. We change in geode.properties file this parameter to true but didn't get any additional statistics in statistics archive file. Do we need also to change something else to enable it or this is not working for geode-native? BR, Mario
Re: startClusterManagementService throws NPE
Is there a specific test that would cause this NPE? I will try to take a look at it. On Fri, Jan 10, 2020 at 9:08 AM Kirk Lund wrote: > I think this may only occur in tests that perform a reconnect of the > Locator. > > On Fri, Jan 10, 2020 at 9:06 AM Kirk Lund wrote: > > > Anyone know why we keep intermittently dealing with this suspect string > in > > dunit tests? > > > > I think we need all valid ways of starting up a Locator to be in a state > > that NEVER produces this NPE. But I'm not sure how to fix it because I'm > > not familiar with startClusterManagementService. Some pointers on how to > > fix, please? > > > > [fatal 2020/01/09 23:37:49.594 GMT > > tid=182] Uncaught exception in thread Thread[Location services restart > > thread,5,RMI Runtime] > > java.lang.NullPointerException > > at > > > org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:779) > > at > > > org.apache.geode.distributed.internal.InternalLocator.restartWithSystem(InternalLocator.java:1215) > > at > > > org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1142) > > at > > > org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1052) > > at java.base/java.lang.Thread.run(Thread.java:834) > > > -- Cheers Jinmei
Re: startClusterManagementService throws NPE
I think this may only occur in tests that perform a reconnect of the Locator. On Fri, Jan 10, 2020 at 9:06 AM Kirk Lund wrote: > Anyone know why we keep intermittently dealing with this suspect string in > dunit tests? > > I think we need all valid ways of starting up a Locator to be in a state > that NEVER produces this NPE. But I'm not sure how to fix it because I'm > not familiar with startClusterManagementService. Some pointers on how to > fix, please? > > [fatal 2020/01/09 23:37:49.594 GMT > tid=182] Uncaught exception in thread Thread[Location services restart > thread,5,RMI Runtime] > java.lang.NullPointerException > at > org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:779) > at > org.apache.geode.distributed.internal.InternalLocator.restartWithSystem(InternalLocator.java:1215) > at > org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1142) > at > org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1052) > at java.base/java.lang.Thread.run(Thread.java:834) >
startClusterManagementService throws NPE
Anyone know why we keep intermittently dealing with this suspect string in dunit tests? I think we need all valid ways of starting up a Locator to be in a state that NEVER produces this NPE. But I'm not sure how to fix it because I'm not familiar with startClusterManagementService. Some pointers on how to fix, please? [fatal 2020/01/09 23:37:49.594 GMT tid=182] Uncaught exception in thread Thread[Location services restart thread,5,RMI Runtime] java.lang.NullPointerException at org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:779) at org.apache.geode.distributed.internal.InternalLocator.restartWithSystem(InternalLocator.java:1215) at org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1142) at org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1052) at java.base/java.lang.Thread.run(Thread.java:834)
