Query Timings increase after system is idle

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Query Timings increase after system is idle

ST ST-2
Folks,

We have a problem in our environment where after a system is idle the query time goes up from a few 100ms to 4+ seconds after 9 hours of idle time on the system.

System Details:
 - Solr 1.4 with Lucene 2.9
 - 10 Million Index.
 - Use MMAP for mapping the index files in memory

Test Details:
-  8 hour performance run with ingestion (@ 8 docs/sec) , query rate - 3 Queries per sec.
-  Commit is per hour.

Issue:
- After 9 hours of idle time (ie no queries, no ingestion ) every query takes 4+ seconds, subsequent queries are fast.

I have a few specific questions:
A. Does Lucene/Solr have internal caches which may be flushed out of memory when the system is idle ?
B. What operations are done on a per term basis (example: build doc lists ) for first time queries.
C. Any pointers to what else may be an issue here.

Really appreciate any help you can provide.

ST






Reply | Threaded
Open this post in threaded view
|

Re: Query Timings increase after system is idle

Mike Klaas
Solr and Lucene rely on the OS disk cache for speedy queries.  If they
are left idle for hours while the disk is used for other purposes, the
OS will page out some of the lucene index (and it will have to be
paged back in the next time a query is received).

The best way to prevent this from occurring is to set up a periodic
automatic query using crontab that keeps the system warm.

cheers,
-Mike

On Wed, May 19, 2010 at 2:19 PM, ST ST <[hidden email]> wrote:

> Folks,
>
> We have a problem in our environment where after a system is idle the query
> time goes up from a few 100ms to 4+ seconds after 9 hours of idle time on
> the system.
>
> System Details:
>  - Solr 1.4 with Lucene 2.9
>  - 10 Million Index.
>  - Use MMAP for mapping the index files in memory
>
> Test Details:
> -  8 hour performance run with ingestion (@ 8 docs/sec) , query rate - 3
> Queries per sec.
> -  Commit is per hour.
>
> Issue:
> - After 9 hours of idle time (ie no queries, no ingestion ) every query
> takes 4+ seconds, subsequent queries are fast.
>
> I have a few specific questions:
> A. Does Lucene/Solr have internal caches which may be flushed out of memory
> when the system is idle ?
> B. What operations are done on a per term basis (example: build doc lists )
> for first time queries.
> C. Any pointers to what else may be an issue here.
>
> Really appreciate any help you can provide.
>
> ST
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Query Timings increase after system is idle

Otis Gospodnetic-2
In reply to this post by ST ST-2
Hi,

You are most likely seeing the effects of your previously cached (by the OS) index data getting paged out of the cache by other disk and process data.  The OS is doing the right thing - if nobody is using index data, why keep it in memory when that memory could be used for other things.

Is this happening under Linux?  If so, this "swappiness" can be controlled: http://kerneltrap.org/node/3000
 
Otis
----
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Lucene ecosystem search :: http://search-lucene.com/


From: ST ST <[hidden email]>
To: [hidden email]
Sent: Wed, May 19, 2010 5:19:09 PM
Subject: Query Timings increase after system is idle

Folks,

We have a problem in our environment where after a system is idle the query time goes up from a few 100ms to 4+ seconds after 9 hours of idle time on the system.

System Details:
 - Solr 1.4 with Lucene 2.9
 - 10 Million Index.
 - Use MMAP for mapping the index files in memory

Test Details:
-  8 hour performance run with ingestion (@ 8 docs/sec) , query rate - 3 Queries per sec.
-  Commit is per hour.

Issue:
- After 9 hours of idle time (ie no queries, no ingestion ) every query takes 4+ seconds, subsequent queries are fast.

I have a few specific questions:
A. Does Lucene/Solr have internal caches which may be flushed out of memory when the system is idle ?
B. What operations are done on a per term basis (example: build doc lists ) for first time queries.
C. Any pointers to what else may be an issue here.

Really appreciate any help you can provide.

ST






Reply | Threaded
Open this post in threaded view
|

Re: Query Timings increase after system is idle

ST ST-2
In reply to this post by Mike Klaas

Thanks for the response, Mike.

In our solution, the entire index is memory mapped.


On Thu, May 20, 2010 at 2:05 PM, Mike Klaas <[hidden email]> wrote:
Solr and Lucene rely on the OS disk cache for speedy queries.  If they
are left idle for hours while the disk is used for other purposes, the
OS will page out some of the lucene index (and it will have to be
paged back in the next time a query is received).

The best way to prevent this from occurring is to set up a periodic
automatic query using crontab that keeps the system warm.

cheers,
-Mike

On Wed, May 19, 2010 at 2:19 PM, ST ST <[hidden email]> wrote:
> Folks,
>
> We have a problem in our environment where after a system is idle the query
> time goes up from a few 100ms to 4+ seconds after 9 hours of idle time on
> the system.
>
> System Details:
>  - Solr 1.4 with Lucene 2.9
>  - 10 Million Index.
>  - Use MMAP for mapping the index files in memory
>
> Test Details:
> -  8 hour performance run with ingestion (@ 8 docs/sec) , query rate - 3
> Queries per sec.
> -  Commit is per hour.
>
> Issue:
> - After 9 hours of idle time (ie no queries, no ingestion ) every query
> takes 4+ seconds, subsequent queries are fast.
>
> I have a few specific questions:
> A. Does Lucene/Solr have internal caches which may be flushed out of memory
> when the system is idle ?
> B. What operations are done on a per term basis (example: build doc lists )
> for first time queries.
> C. Any pointers to what else may be an issue here.
>
> Really appreciate any help you can provide.
>
> ST
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]