But are you sure you're not just masking the problem? That is, your limit
may now be 90,000 queries...
I always assume this kind of thing is a memory leak somewhere, have you
any tools to monitor your memory consumption and see if that's ever-rising?
Best
Erick
On Mon, Jun 2, 2008 at 10:38 AM, Bram de Jong <[EMAIL PROTECTED]> wrote:
> Ai! That was exactly it. I increased the VM mem, and all is running
> fine (34K queries and rising!)!
>
> Thanks a lot,
>
> - Bram
>
> On Mon, Jun 2, 2008 at 3:32 PM, Chris <[EMAIL PROTECTED]> wrote:
> > Maybe you jetty need to turning....
> > how many memory in your system ?
> > Can you show the processes information with the java processes ?
> >
> > above
> > Chris
> >
> > 2008/6/2 Bram de Jong <[EMAIL PROTECTED]>:
> >
> >> Hello all,
> >>
> >>
> >> Still running tests on solr using the example jetty container. I've
> >> been getting nice performance. However, suddenly between 15400 and
> >> 15600 queries, I get a very serious drop in performance, and this
> >> every time I run my test, independent of what I'm searching for. The
> >> performance STAYS low and doesn't come up again until I restart
> >> Jerry/Solr.
> >>
> >> This what I'm getting. The number between parentheses is the nr of
> >> queries done until "now".
> >>
> >> <snip>
> >> average query time this batch ( 2798 ) : 21.7171502113
> >> average query time this batch ( 2998 ) : 21.556429863
> >> average query time this batch ( 3197 ) : 20.7244367456
> >> average query time this batch ( 3397 ) : 20.9529149532
> >> average query time this batch ( 3597 ) : 21.7199647427
> >> <snip>
> >>
> >> Then sudenly around 14K my average time goes up 3 fold:
> >>
> >> <snip>
> >> average query time this batch ( 15183 ) : 22.5312757732
> >> average query time this batch ( 15383 ) : 27.6089298725 <-
> >> average query time this batch ( 15583 ) : 66.8137800694 <-
> >> average query time this batch ( 15783 ) : 67.5224089622 <-
> >> average query time this batch ( 15983 ) : 68.210555315 <-
> >> </snip>
> >>
> >> I tried taking another set of searches (I'm replaying searches done on
> >> our website), but exactly the same pattern occurs. The cumulative
> >> evictions for all caches is 0 before and after the slowdown, so my
> >> initial thought (i.e. full cache) was not it. I did some further
> >> investigating, and it looks like only once every few searches becomes
> >> slow. This is the batch of searches for block nr 15583. Every search
> >> string is mentioned and then the query_time as reported by Solr:
> >>
> >> ('electricity', 19), ('killed', 16), ('radio static', 179), ('monster
> >> killed', 15), ('heavy machinery', 16), ('killed', 179), ('chimes',
> >> 17), ('video games', 17), ('sword', 16), ('construction machine', 17),
> >> ('graveyard', 15), ('people', 16), ('yard', 179), ('horn', 15),
> >> ('bugle', 14), ('trumpet', 17), ('grass walking', 177), ('walking',
> >> 17), ('horn', 15), ('clunk', 14), ('hydraulic', 178), ('jet landing',
> >> 16), ('o fortuna', 14), ('large crowd', 180), ('dj', 15), ('hallway',
> >> 15), ('scrach', 13), ('jet tires screeching', 177), ('tires
> >> screeching', 14), ('ambient', 16), ('electricity', 180), ('tires',
> >> 15), ('hospital', 15), ('chimes', 17), ('win chimes', 178), ('wind
> >> chimes', 15), ('sex', 15), ('SPACE', 17), ('river', 180), ('thunder
> >> storms', 16), ('crash', 15), ('boss', 16), ('thunder', 16), ('car
> >> braking', 16), ('vocal', 17), ('vocal dance', 182), ('vocal', 16),
> >> ('stream', 16), ('whale', 14), ('space ambient', 183), ('animal', 16),
> >> ('pad', 15), ('body', 16), ('crickets', 180), ('fall', 16), ('camera
> >> flash bulb', 15), ('arctic', 178), ('flash bulb', 13), ('camera', 15),
> >> ('drawn', 16), ('next level', 180), ('timbale', 14), ('navigation',
> >> 14), ('bass', 14), ('blips', 179), <snip>
> >>
> >>
> >> Any hints of things I can try would be superb. Having to wait 15000 *
> >> 25ms every time I want to try something else to fix this is becoming a
> >> bit annoying :)
> >>
> >>
> >> - Bram
> >>
> >> PS: if you are curious: the things people search for are sounds :)
> >> hence the very varied set of search strings.
> >>
> >> --
> >> http://freesound.iua.upf.edu
> >> http://www.smartelectronix.com
> >> http://www.musicdsp.org
> >>
> >
> >
> >
> > --
> > Chris Lin
> > [EMAIL PROTECTED]
> > Taipei , Taiwan.
> > -----------------------------------------------------------
> >
>
>
>
> --
> http://freesound.iua.upf.edu
> http://www.smartelectronix.com
> http://www.musicdsp.org
>
