index searcher leading to system freeze ?

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

index searcher leading to system freeze ?

yangyangyyy
I'm running 8 index searchers  java processes on a 8-core node.
They all read from the  same lucene index on local hard drive.


the index contains about 20million docs, each doc is a small record with
about 200 bytes.
total size is about 5GB.

it worked fine before, but recently (I don't know what changed) I found
that once the index searchers
are started, kswapd and kjournald take up 100% cpu (but this is not such a
bad thing, cuz the 8 cores
offer 800% cpu), and quickly the system comes to a freeze.

I do NOT have swap on the system, so I don't understand why kswapd and
kjournald should be so busy.
But even if these 2 kernel processes are busy, that's no reason for the
system to freeze either.
Does this sound like a kernel bug?


the system is a EC2 instance:
Linux blahblah.mycompany.com 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28
EST 2008 x86_64 x86_64 x86_64 GNU/Linux


Thanks a lot
yang
Reply | Threaded
Open this post in threaded view
|

Re: index searcher leading to system freeze ?

Simon Willnauer-4
are you closing your underlying IndexReaders properly?

simon

On Wed, Jul 11, 2012 at 5:04 AM, Yang <[hidden email]> wrote:

> I'm running 8 index searchers  java processes on a 8-core node.
> They all read from the  same lucene index on local hard drive.
>
>
> the index contains about 20million docs, each doc is a small record with
> about 200 bytes.
> total size is about 5GB.
>
> it worked fine before, but recently (I don't know what changed) I found
> that once the index searchers
> are started, kswapd and kjournald take up 100% cpu (but this is not such a
> bad thing, cuz the 8 cores
> offer 800% cpu), and quickly the system comes to a freeze.
>
> I do NOT have swap on the system, so I don't understand why kswapd and
> kjournald should be so busy.
> But even if these 2 kernel processes are busy, that's no reason for the
> system to freeze either.
> Does this sound like a kernel bug?
>
>
> the system is a EC2 instance:
> Linux blahblah.mycompany.com 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28
> EST 2008 x86_64 x86_64 x86_64 GNU/Linux
>
>
> Thanks a lot
> yang

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

Reply | Threaded
Open this post in threaded view
|

Re: index searcher leading to system freeze ?

Israel Tsadok
I'm not sure this is at all related, but we've had high cpu loads on our
servers due to the leap second kernel bug -
http://serverfault.com/questions/403732/<http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-during-a-leap-second>
.

On Wed, Jul 11, 2012 at 4:00 PM, Simon Willnauer
<[hidden email]>wrote:

> are you closing your underlying IndexReaders properly?
>
> simon
>
> On Wed, Jul 11, 2012 at 5:04 AM, Yang <[hidden email]> wrote:
> > I'm running 8 index searchers  java processes on a 8-core node.
> > They all read from the  same lucene index on local hard drive.
> >
> >
> > the index contains about 20million docs, each doc is a small record with
> > about 200 bytes.
> > total size is about 5GB.
> >
> > it worked fine before, but recently (I don't know what changed) I found
> > that once the index searchers
> > are started, kswapd and kjournald take up 100% cpu (but this is not such
> a
> > bad thing, cuz the 8 cores
> > offer 800% cpu), and quickly the system comes to a freeze.
> >
> > I do NOT have swap on the system, so I don't understand why kswapd and
> > kjournald should be so busy.
> > But even if these 2 kernel processes are busy, that's no reason for the
> > system to freeze either.
> > Does this sound like a kernel bug?
> >
> >
> > the system is a EC2 instance:
> > Linux blahblah.mycompany.com 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15
> 12:34:28
> > EST 2008 x86_64 x86_64 x86_64 GNU/Linux
> >
> >
> > Thanks a lot
> > yang
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>