You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Greg Pendlebury <gr...@gmail.com> on 2014/03/17 05:36:44 UTC
Re: Solr metrics in Codahale metrics and Graphite?
In the codahale metrics library there are 1, 5 and 15 minute moving
averages just like you would see in a tool like 'top'. However in Solr I
can only see 5 and 15 minute values, plus 'avgRequestsPerSecond'. I assumed
this was the 1 minute value initially, but it seems to be something like
the average since startup. I haven't looked thoroughly, but it is around 1%
of the other two in a normally idle test cluster after load tests have been
running for long enough that the 5 and 15 minute numbers match the load
testing throughput.
Is this difference deliberate? or an accident? or am I wrong entirely? I
can compute the overall average anyway, given that the stats also include
the start time of the search handler and the total search count, so I
thought it might be an accident.
Ta,
Greg
On 4 May 2013 01:19, Furkan KAMACI <fu...@gmail.com> wrote:
> Does anybody tested Ganglia with JMXTrans at production environment for
> SolrCloud?
>
> 2013/4/26 Dmitry Kan <so...@gmail.com>
>
> > Alan, Shawn,
> >
> > If backporting to 3.x is hard, no worries, we don't necessarily require
> the
> > patch as we are heading to 4.x eventually. It is just much easier within
> > our organization to test on the existing solr 3.4 as there are a few of
> > internal dependencies and custom code on top of solr. Also solr upgrades
> on
> > production systems are usually pushed forward by a month or so starting
> the
> > upgrade on development systems (requires lots of testing and
> > verifications).
> >
> > Nevertheless, it is good effort to make #solr #graphite friendly, so keep
> > it up! :)
> >
> > Dmitry
> >
> >
> >
> >
> > On Thu, Apr 25, 2013 at 9:29 PM, Shawn Heisey <so...@elyograg.org> wrote:
> >
> > > On 4/25/2013 6:30 AM, Dmitry Kan wrote:
> > > > We are very much interested in 3.4.
> > > >
> > > > On Thu, Apr 25, 2013 at 12:55 PM, Alan Woodward <al...@flax.co.uk>
> > wrote:
> > > >> This is on top of trunk at the moment, but would be back ported to
> 4.4
> > > if
> > > >> there was interest.
> > >
> > > This will be bad news, I'm sorry:
> > >
> > > All remaining work on 3.x versions happens in the 3.6 branch. This
> > > branch is in maintenance mode. It will only get fixes for serious bugs
> > > with no workaround. Improvements and new features won't be considered
> > > at all.
> > >
> > > You're welcome to try backporting patches from newer issues. Due to
> the
> > > major differences in the 3x and 4x codebases, the best case scenario is
> > > that you'll be facing a very manual task. Some changes can't be
> > > backported because they rely on other features only found in 4.x code.
> > >
> > > Thanks,
> > > Shawn
> > >
> > >
> >
>
Re: Solr metrics in Codahale metrics and Graphite?
Posted by Greg Pendlebury <gr...@gmail.com>.
Oh my bad. I thought it was already in. Thanks for the correction.
Ta,
Greg
On 17 March 2014 15:55, Shalin Shekhar Mangar <sh...@gmail.com>wrote:
> Greg, SOLR-4735 (using the codahale metrics lib) hasn't been committed
> yet. It is still work in progress.
>
> Actually the internal Solr Metrics class has a method to return 1
> minute stats but it is not used.
>
> On Mon, Mar 17, 2014 at 10:06 AM, Greg Pendlebury
> <gr...@gmail.com> wrote:
> > In the codahale metrics library there are 1, 5 and 15 minute moving
> > averages just like you would see in a tool like 'top'. However in Solr I
> > can only see 5 and 15 minute values, plus 'avgRequestsPerSecond'. I
> assumed
> > this was the 1 minute value initially, but it seems to be something like
> > the average since startup. I haven't looked thoroughly, but it is around
> 1%
> > of the other two in a normally idle test cluster after load tests have
> been
> > running for long enough that the 5 and 15 minute numbers match the load
> > testing throughput.
> >
> > Is this difference deliberate? or an accident? or am I wrong entirely? I
> > can compute the overall average anyway, given that the stats also include
> > the start time of the search handler and the total search count, so I
> > thought it might be an accident.
> >
> > Ta,
> > Greg
> >
> >
> >
> >
> >
> > On 4 May 2013 01:19, Furkan KAMACI <fu...@gmail.com> wrote:
> >
> >> Does anybody tested Ganglia with JMXTrans at production environment for
> >> SolrCloud?
> >>
> >> 2013/4/26 Dmitry Kan <so...@gmail.com>
> >>
> >> > Alan, Shawn,
> >> >
> >> > If backporting to 3.x is hard, no worries, we don't necessarily
> require
> >> the
> >> > patch as we are heading to 4.x eventually. It is just much easier
> within
> >> > our organization to test on the existing solr 3.4 as there are a few
> of
> >> > internal dependencies and custom code on top of solr. Also solr
> upgrades
> >> on
> >> > production systems are usually pushed forward by a month or so
> starting
> >> the
> >> > upgrade on development systems (requires lots of testing and
> >> > verifications).
> >> >
> >> > Nevertheless, it is good effort to make #solr #graphite friendly, so
> keep
> >> > it up! :)
> >> >
> >> > Dmitry
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Apr 25, 2013 at 9:29 PM, Shawn Heisey <so...@elyograg.org>
> wrote:
> >> >
> >> > > On 4/25/2013 6:30 AM, Dmitry Kan wrote:
> >> > > > We are very much interested in 3.4.
> >> > > >
> >> > > > On Thu, Apr 25, 2013 at 12:55 PM, Alan Woodward <al...@flax.co.uk>
> >> > wrote:
> >> > > >> This is on top of trunk at the moment, but would be back ported
> to
> >> 4.4
> >> > > if
> >> > > >> there was interest.
> >> > >
> >> > > This will be bad news, I'm sorry:
> >> > >
> >> > > All remaining work on 3.x versions happens in the 3.6 branch. This
> >> > > branch is in maintenance mode. It will only get fixes for serious
> bugs
> >> > > with no workaround. Improvements and new features won't be
> considered
> >> > > at all.
> >> > >
> >> > > You're welcome to try backporting patches from newer issues. Due to
> >> the
> >> > > major differences in the 3x and 4x codebases, the best case
> scenario is
> >> > > that you'll be facing a very manual task. Some changes can't be
> >> > > backported because they rely on other features only found in 4.x
> code.
> >> > >
> >> > > Thanks,
> >> > > Shawn
> >> > >
> >> > >
> >> >
> >>
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
Re: Solr metrics in Codahale metrics and Graphite?
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
Greg, SOLR-4735 (using the codahale metrics lib) hasn't been committed
yet. It is still work in progress.
Actually the internal Solr Metrics class has a method to return 1
minute stats but it is not used.
On Mon, Mar 17, 2014 at 10:06 AM, Greg Pendlebury
<gr...@gmail.com> wrote:
> In the codahale metrics library there are 1, 5 and 15 minute moving
> averages just like you would see in a tool like 'top'. However in Solr I
> can only see 5 and 15 minute values, plus 'avgRequestsPerSecond'. I assumed
> this was the 1 minute value initially, but it seems to be something like
> the average since startup. I haven't looked thoroughly, but it is around 1%
> of the other two in a normally idle test cluster after load tests have been
> running for long enough that the 5 and 15 minute numbers match the load
> testing throughput.
>
> Is this difference deliberate? or an accident? or am I wrong entirely? I
> can compute the overall average anyway, given that the stats also include
> the start time of the search handler and the total search count, so I
> thought it might be an accident.
>
> Ta,
> Greg
>
>
>
>
>
> On 4 May 2013 01:19, Furkan KAMACI <fu...@gmail.com> wrote:
>
>> Does anybody tested Ganglia with JMXTrans at production environment for
>> SolrCloud?
>>
>> 2013/4/26 Dmitry Kan <so...@gmail.com>
>>
>> > Alan, Shawn,
>> >
>> > If backporting to 3.x is hard, no worries, we don't necessarily require
>> the
>> > patch as we are heading to 4.x eventually. It is just much easier within
>> > our organization to test on the existing solr 3.4 as there are a few of
>> > internal dependencies and custom code on top of solr. Also solr upgrades
>> on
>> > production systems are usually pushed forward by a month or so starting
>> the
>> > upgrade on development systems (requires lots of testing and
>> > verifications).
>> >
>> > Nevertheless, it is good effort to make #solr #graphite friendly, so keep
>> > it up! :)
>> >
>> > Dmitry
>> >
>> >
>> >
>> >
>> > On Thu, Apr 25, 2013 at 9:29 PM, Shawn Heisey <so...@elyograg.org> wrote:
>> >
>> > > On 4/25/2013 6:30 AM, Dmitry Kan wrote:
>> > > > We are very much interested in 3.4.
>> > > >
>> > > > On Thu, Apr 25, 2013 at 12:55 PM, Alan Woodward <al...@flax.co.uk>
>> > wrote:
>> > > >> This is on top of trunk at the moment, but would be back ported to
>> 4.4
>> > > if
>> > > >> there was interest.
>> > >
>> > > This will be bad news, I'm sorry:
>> > >
>> > > All remaining work on 3.x versions happens in the 3.6 branch. This
>> > > branch is in maintenance mode. It will only get fixes for serious bugs
>> > > with no workaround. Improvements and new features won't be considered
>> > > at all.
>> > >
>> > > You're welcome to try backporting patches from newer issues. Due to
>> the
>> > > major differences in the 3x and 4x codebases, the best case scenario is
>> > > that you'll be facing a very manual task. Some changes can't be
>> > > backported because they rely on other features only found in 4.x code.
>> > >
>> > > Thanks,
>> > > Shawn
>> > >
>> > >
>> >
>>
--
Regards,
Shalin Shekhar Mangar.