Mailing List Archive: Lucene: Java-User

Throughput doesn't increase when using more concurrent threads

1 2 3

View All

Index | Next | Previous | View Threaded

peterlkeegan at gmail

Jan 26, 2006, 1:20 PM

Post #26 of 62 (3732 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm now
getting 250 queries/sec and excellent cpu utilization (equal concurrency on
all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I wasn't aware
of it.

Thanks all very much.
Peter

On 1/26/06, Doug Cutting <cutting [at] apache> wrote:
>
> Doug Cutting wrote:
> > A 64-bit JVM with NioDirectory would really be optimal for this.
>
> Oops. I meant MMapDirectory, not NioDirectory.
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

peterlkeegan at gmail

Jan 26, 2006, 1:32 PM

Post #27 of 62 (3735 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Correction: make that 285 qps :)

On 1/26/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
>
> I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm now
> getting 250 queries/sec and excellent cpu utilization (equal concurrency on
> all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I wasn't aware
> of it.
>
> Thanks all very much.
> Peter
>
>
> On 1/26/06, Doug Cutting <cutting [at] apache> wrote:
> >
> > Doug Cutting wrote:
> > > A 64-bit JVM with NioDirectory would really be optimal for this.
> >
> > Oops. I meant MMapDirectory, not NioDirectory.
> >
> > Doug
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > For additional commands, e-mail: java-user-help [at] lucene
> >
> >
>

yseeley at gmail

Jan 26, 2006, 1:42 PM

Post #28 of 62 (3742 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Nice speedup! The extra registers in 64 bit mode hay have helped a little too.

-Yonik

On 1/26/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> Correction: make that 285 qps :)

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

peterlkeegan at gmail

Jan 26, 2006, 4:19 PM

Post #29 of 62 (3733 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Dumb question: does the 64-bit compiler (javac) generate different code than
the 32-bit version, or is it just the jvm that matters? My reported speedups
were soley from using the 64-bit jvm with jar files from the 32-bit
compiler.

Peter

On 1/26/06, Yonik Seeley <yseeley [at] gmail> wrote:
>
> Nice speedup! The extra registers in 64 bit mode hay have helped a little
> too.
>
> -Yonik
>
> On 1/26/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > Correction: make that 285 qps :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

yseeley at gmail

Jan 26, 2006, 4:34 PM

Post #30 of 62 (3737 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

There is no difference in bytecode... the whole difference is just in
the underlying JVM.

-Yonik

On 1/26/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> Dumb question: does the 64-bit compiler (javac) generate different code than
> the 32-bit version, or is it just the jvm that matters? My reported speedups
> were soley from using the 64-bit jvm with jar files from the 32-bit
> compiler.
>
> Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

saturnism at gmail

Jan 26, 2006, 5:15 PM

Post #31 of 62 (3742 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Peter,

Wow, the speed up in impressive! But may I ask what did you do to
achieve 135 queries/sec prior to the JVM swich?

ray,

On 1/27/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> Correction: make that 285 qps :)
>
> On 1/26/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> >
> > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm now
> > getting 250 queries/sec and excellent cpu utilization (equal concurrency on
> > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I wasn't aware
> > of it.
> >
> > Thanks all very much.
> > Peter
> >
> >
> > On 1/26/06, Doug Cutting <cutting [at] apache> wrote:
> > >
> > > Doug Cutting wrote:
> > > > A 64-bit JVM with NioDirectory would really be optimal for this.
> > >
> > > Oops. I meant MMapDirectory, not NioDirectory.
> > >
> > > Doug
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > For additional commands, e-mail: java-user-help [at] lucene
> > >
> > >
> >
>
>

peterlkeegan at gmail

Jan 26, 2006, 6:44 PM

Post #32 of 62 (3730 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Ray,

The short answer is that you can make Lucene blazingly fast by using advice
and design principles mentioned in this forum and of course reading 'Lucene
in Action'. For example, use a 'content' field for searching all fields (vs
mutli-field search), put all your stored data in one field, understand the
cost of numeric search and sorting. On the platform side, go multi-CPU and
of course 64-bit if possible :)

Also, I would venture to guess that a lot of search bottlenecks have nothing
to do with Lucene, but rather in the infrastructure around it. For example,
how does your client interface to the search engine? My results use a plain
socket interface between client and server (one connection for queries,
another for results), using a simple query/results data format. Introducing
other web infrastructures invites degradation in performance, too.

I've a bit of experience with search engines, but I'm obviously still
learning thanks to this group.

Peter

On 1/26/06, Ray Tsang <saturnism [at] gmail> wrote:
>
> Peter,
>
> Wow, the speed up in impressive! But may I ask what did you do to
> achieve 135 queries/sec prior to the JVM swich?
>
> ray,
>
> On 1/27/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > Correction: make that 285 qps :)
> >
> > On 1/26/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > >
> > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm now
> > > getting 250 queries/sec and excellent cpu utilization (equal
> concurrency on
> > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I wasn't
> aware
> > > of it.
> > >
> > > Thanks all very much.
> > > Peter
> > >
> > >
> > > On 1/26/06, Doug Cutting <cutting [at] apache> wrote:
> > > >
> > > > Doug Cutting wrote:
> > > > > A 64-bit JVM with NioDirectory would really be optimal for this.
> > > >
> > > > Oops. I meant MMapDirectory, not NioDirectory.
> > > >
> > > > Doug
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > > For additional commands, e-mail: java-user-help [at] lucene
> > > >
> > > >
> > >
> >
> >
>

saturnism at gmail

Jan 26, 2006, 7:14 PM

Post #33 of 62 (3731 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Paul,

Thanks for the advice! But for the 100+queries/sec on a 32-bit
platfrom, did you end up applying other patches? or use different
FSDirectory implementations?

Thanks!

ray,

On 1/27/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> Ray,
>
> The short answer is that you can make Lucene blazingly fast by using advice
> and design principles mentioned in this forum and of course reading 'Lucene
> in Action'. For example, use a 'content' field for searching all fields (vs
> mutli-field search), put all your stored data in one field, understand the
> cost of numeric search and sorting. On the platform side, go multi-CPU and
> of course 64-bit if possible :)
>
> Also, I would venture to guess that a lot of search bottlenecks have nothing
> to do with Lucene, but rather in the infrastructure around it. For example,
> how does your client interface to the search engine? My results use a plain
> socket interface between client and server (one connection for queries,
> another for results), using a simple query/results data format. Introducing
> other web infrastructures invites degradation in performance, too.
>
> I've a bit of experience with search engines, but I'm obviously still
> learning thanks to this group.
>
> Peter
>
> On 1/26/06, Ray Tsang <saturnism [at] gmail> wrote:
> >
> > Peter,
> >
> > Wow, the speed up in impressive! But may I ask what did you do to
> > achieve 135 queries/sec prior to the JVM swich?
> >
> > ray,
> >
> > On 1/27/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > Correction: make that 285 qps :)
> > >
> > > On 1/26/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > >
> > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm now
> > > > getting 250 queries/sec and excellent cpu utilization (equal
> > concurrency on
> > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I wasn't
> > aware
> > > > of it.
> > > >
> > > > Thanks all very much.
> > > > Peter
> > > >
> > > >
> > > > On 1/26/06, Doug Cutting <cutting [at] apache> wrote:
> > > > >
> > > > > Doug Cutting wrote:
> > > > > > A 64-bit JVM with NioDirectory would really be optimal for this.
> > > > >
> > > > > Oops. I meant MMapDirectory, not NioDirectory.
> > > > >
> > > > > Doug
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > > > For additional commands, e-mail: java-user-help [at] lucene
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

peterlkeegan at gmail

Jan 26, 2006, 7:55 PM

Post #34 of 62 (3731 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Ray,

The 135 qps rate was using the standard FSDirectory in 1.9.

Peter

On 1/26/06, Ray Tsang <saturnism [at] gmail> wrote:
>
> Paul,
>
> Thanks for the advice! But for the 100+queries/sec on a 32-bit
> platfrom, did you end up applying other patches? or use different
> FSDirectory implementations?
>
> Thanks!
>
> ray,
>
> On 1/27/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > Ray,
> >
> > The short answer is that you can make Lucene blazingly fast by using
> advice
> > and design principles mentioned in this forum and of course reading
> 'Lucene
> > in Action'. For example, use a 'content' field for searching all fields
> (vs
> > mutli-field search), put all your stored data in one field, understand
> the
> > cost of numeric search and sorting. On the platform side, go multi-CPU
> and
> > of course 64-bit if possible :)
> >
> > Also, I would venture to guess that a lot of search bottlenecks have
> nothing
> > to do with Lucene, but rather in the infrastructure around it. For
> example,
> > how does your client interface to the search engine? My results use a
> plain
> > socket interface between client and server (one connection for queries,
> > another for results), using a simple query/results data format.
> Introducing
> > other web infrastructures invites degradation in performance, too.
> >
> > I've a bit of experience with search engines, but I'm obviously still
> > learning thanks to this group.
> >
> > Peter
> >
> > On 1/26/06, Ray Tsang <saturnism [at] gmail> wrote:
> > >
> > > Peter,
> > >
> > > Wow, the speed up in impressive! But may I ask what did you do to
> > > achieve 135 queries/sec prior to the JVM swich?
> > >
> > > ray,
> > >
> > > On 1/27/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > > Correction: make that 285 qps :)
> > > >
> > > > On 1/26/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > > >
> > > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm
> now
> > > > > getting 250 queries/sec and excellent cpu utilization (equal
> > > concurrency on
> > > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I
> wasn't
> > > aware
> > > > > of it.
> > > > >
> > > > > Thanks all very much.
> > > > > Peter
> > > > >
> > > > >
> > > > > On 1/26/06, Doug Cutting <cutting [at] apache> wrote:
> > > > > >
> > > > > > Doug Cutting wrote:
> > > > > > > A 64-bit JVM with NioDirectory would really be optimal for
> this.
> > > > > >
> > > > > > Oops. I meant MMapDirectory, not NioDirectory.
> > > > > >
> > > > > > Doug
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > > > > For additional commands, e-mail:
> java-user-help [at] lucene
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>

yseeley at gmail

Jan 29, 2006, 5:08 PM

Post #35 of 62 (3725 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> Peter Keegan wrote:
> > I'd love to try this, but I'm not aware of any 64-bit jvms for Windows on
> > Intel. If you know of any, please let me know. Linux may be an option, too.
> >
> Is this true about the 64-bit JVM not working on Intel?

Go back and look at my response to the message you quoted :-)
The short answer is yes, it will work on Intel.

> I was under the
> impression that it supported the AMD64 instruction set, and that Intel's
> 64-bit processors basically cloned AMD's instruction set.

Pretty much, but it's never that simple (and wasn't for 32 bit mode either)
http://en.wikipedia.org/wiki/EM64T#Differences_between_AMD64_and_EM64T

Now that they have both been out a while, compilers generally produce
code that work on both. Tricky things like JVMs and esp kernels needed
explicit support.

> I really hope this isn't the case, because it's going to be one hell of
> a caveat if we end up telling customers "yes, we support 64-bit AMD, but
> not 64-bit Intel."

Support is a different issue. It may work, but it may or may not be a
"supported" platform of the JVM vendor.

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

daniel at nuix

Jan 29, 2006, 5:08 PM

Post #36 of 62 (3734 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Peter Keegan wrote:
> I'd love to try this, but I'm not aware of any 64-bit jvms for Windows on
> Intel. If you know of any, please let me know. Linux may be an option, too.
>
Is this true about the 64-bit JVM not working on Intel? I was under the
impression that it supported the AMD64 instruction set, and that Intel's
64-bit processors basically cloned AMD's instruction set.

I really hope this isn't the case, because it's going to be one hell of
a caveat if we end up telling customers "yes, we support 64-bit AMD, but
not 64-bit Intel."

Daniel

--
Daniel Noll

Nuix Australia Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
Phone: (02) 9280 0699
Fax: (02) 9212 6902

This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

daniel at nuix

Jan 29, 2006, 5:13 PM

Post #37 of 62 (3735 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Peter Keegan wrote:
> I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm now
> getting 250 queries/sec and excellent cpu utilization (equal concurrency on
> all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I wasn't aware
> of it.
>
Wow. That's fast.

Out of interest, does indexing time speed up much on 64-bit hardware?
I'm particularly interested in this side of things because for our own
application, any query response under half a second is good enough, but
the indexing side could always be faster. :-)

Daniel

--
Daniel Noll

Nuix Australia Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
Phone: (02) 9280 0699
Fax: (02) 9212 6902

This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

daniel at nuix

Jan 29, 2006, 5:27 PM

Post #38 of 62 (3733 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Yonik Seeley wrote:
> On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
>
>> Peter Keegan wrote:
>>
>>> I'd love to try this, but I'm not aware of any 64-bit jvms for Windows on
>>> Intel. If you know of any, please let me know. Linux may be an option, too.
>>>
>>>
>> Is this true about the 64-bit JVM not working on Intel?
>>
>
> Go back and look at my response to the message you quoted :-)
> The short answer is yes, it will work on Intel.
>
Ah. Okay, sorry about that. The only response I saw was the one about
JRockit supporting it.
> Support is a different issue. It may work, but it may or may not be a
> "supported" platform of the JVM vendor.
>
True enough. At the moment our most likely move is to support Sun's
64-bit JVM on Windows, but not other vendors' JVMs (i.e., we'll support
whatever JVMs we redistribute with our own app.) Of course, this will
only come once we claim to support 64-bit hardware... I'm sure there are
many things still yet to be done there, such as making sure all our JNI
libraries will compile properly for 64-bit Windows.

Daniel

--
Daniel Noll

Nuix Australia Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
Phone: (02) 9280 0699
Fax: (02) 9212 6902

This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

peterlkeegan at gmail

Jan 30, 2006, 6:15 AM

Post #39 of 62 (3742 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

I cranked up the dial on my query tester and was able to get the rate up to
325 qps. Unfortunately, the machine died shortly thereafter (memory errors
:-( ) Hopefully, it was just a coincidence. I haven't measured 64-bit
indexing speed, yet.

Peter

On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
>
> Peter Keegan wrote:
> > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm now
> > getting 250 queries/sec and excellent cpu utilization (equal concurrency
> on
> > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I wasn't
> aware
> > of it.
> >
> Wow. That's fast.
>
> Out of interest, does indexing time speed up much on 64-bit hardware?
> I'm particularly interested in this side of things because for our own
> application, any query response under half a second is good enough, but
> the indexing side could always be faster. :-)
>
> Daniel
>
> --
> Daniel Noll
>
> Nuix Australia Pty Ltd
> Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> Phone: (02) 9280 0699
> Fax: (02) 9212 6902
>
> This message is intended only for the named recipient. If you are not
> the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> message or attachment is strictly prohibited.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

peterlkeegan at gmail

Feb 22, 2006, 11:52 AM

Post #40 of 62 (3705 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

I am doing a performance comparison of Lucene on Linux vs Windows.

I have 2 identically configured servers (8-CPUs (real) x 3GHz Xeon
processors, 64GB RAM). One is running CentOS 4 Linux, the other is running
Windows server 2003 Enterprise Edition x64. Both have 64-bit JVMs from Sun.
The Lucene server is using MMapDirectory. I'm running the jvm with
-Xmx16000M. Peak memory usage of the jvm on Linux is about 6GB and 7.8GB on
windows.

I'm observing query rates of 330 queries/sec on the Wintel server, but only
200 qps on the Linux box. At first, I suspected a network bottleneck, but
when I 'short-circuited' Lucene, the query rates were identical.

I suspect that there are some things to be tuned in Linux, but I'm not sure
what. Any advice would be appreciated.

Peter

On 1/30/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
>
> I cranked up the dial on my query tester and was able to get the rate up
> to 325 qps. Unfortunately, the machine died shortly thereafter (memory
> errors :-( ) Hopefully, it was just a coincidence. I haven't measured 64-bit
> indexing speed, yet.
>
> Peter
>
> On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> >
> > Peter Keegan wrote:
> > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm now
> > > getting 250 queries/sec and excellent cpu utilization (equal
> > concurrency on
> > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I wasn't
> > aware
> > > of it.
> > >
> > Wow. That's fast.
> >
> > Out of interest, does indexing time speed up much on 64-bit hardware?
> > I'm particularly interested in this side of things because for our own
> > application, any query response under half a second is good enough, but
> > the indexing side could always be faster. :-)
> >
> > Daniel
> >
> > --
> > Daniel Noll
> >
> > Nuix Australia Pty Ltd
> > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> > Phone: (02) 9280 0699
> > Fax: (02) 9212 6902
> >
> > This message is intended only for the named recipient. If you are not
> > the intended recipient you are notified that disclosing, copying,
> > distributing or taking any action in reliance on the contents of this
> > message or attachment is strictly prohibited.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > For additional commands, e-mail: java-user-help [at] lucene
> >
> >
>

yseeley at gmail

Feb 22, 2006, 12:18 PM

Post #41 of 62 (3703 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Hmmm, not sure what that could be.
You could try using the default FSDir instead of MMapDir to see if the
differences are there.

Some things that could be different:
- thread scheduling (shouldn't make too much of a difference though)
- synchronization workings
- page replacement policy... how to figure out what pages to swap in
and which to swap out, esp of the memory mapped files.

You could also try a profiler on both platforms to try and see where
the difference is.

-Yonik

On 2/22/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> I am doing a performance comparison of Lucene on Linux vs Windows.
>
> I have 2 identically configured servers (8-CPUs (real) x 3GHz Xeon
> processors, 64GB RAM). One is running CentOS 4 Linux, the other is running
> Windows server 2003 Enterprise Edition x64. Both have 64-bit JVMs from Sun.
> The Lucene server is using MMapDirectory. I'm running the jvm with
> -Xmx16000M. Peak memory usage of the jvm on Linux is about 6GB and 7.8GB on
> windows.
>
> I'm observing query rates of 330 queries/sec on the Wintel server, but only
> 200 qps on the Linux box. At first, I suspected a network bottleneck, but
> when I 'short-circuited' Lucene, the query rates were identical.
>
> I suspect that there are some things to be tuned in Linux, but I'm not sure
> what. Any advice would be appreciated.
>
> Peter
>
>
>
> On 1/30/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> >
> > I cranked up the dial on my query tester and was able to get the rate up
> > to 325 qps. Unfortunately, the machine died shortly thereafter (memory
> > errors :-( ) Hopefully, it was just a coincidence. I haven't measured 64-bit
> > indexing speed, yet.
> >
> > Peter
> >
> > On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> > >
> > > Peter Keegan wrote:
> > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm now
> > > > getting 250 queries/sec and excellent cpu utilization (equal
> > > concurrency on
> > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I wasn't
> > > aware
> > > > of it.
> > > >
> > > Wow. That's fast.
> > >
> > > Out of interest, does indexing time speed up much on 64-bit hardware?
> > > I'm particularly interested in this side of things because for our own
> > > application, any query response under half a second is good enough, but
> > > the indexing side could always be faster. :-)
> > >
> > > Daniel
> > >
> > > --
> > > Daniel Noll
> > >
> > > Nuix Australia Pty Ltd
> > > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> > > Phone: (02) 9280 0699
> > > Fax: (02) 9212 6902
> > >
> > > This message is intended only for the named recipient. If you are not
> > > the intended recipient you are notified that disclosing, copying,
> > > distributing or taking any action in reliance on the contents of this
> > > message or attachment is strictly prohibited.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > For additional commands, e-mail: java-user-help [at] lucene
> > >
> > >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

otis_gospodnetic at yahoo

Feb 22, 2006, 1:46 PM

Post #42 of 62 (3716 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Hi,

Some things that could be different:
- thread scheduling (shouldn't make too much of a difference though)

--- I would also play with disk IO schedulers, if you can. CentOS is based on RedHat, I believe, and RedHat (ext3, really) now has about 4 different IO schedulers that, according to articles I recently read, can have an impact on disk read/write performance. These schedules can be specified at mount time, I believe, and maybe at boot time (kernel line in Grub/LILO).

Otis

On 2/22/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> I am doing a performance comparison of Lucene on Linux vs Windows.
>
> I have 2 identically configured servers (8-CPUs (real) x 3GHz Xeon
> processors, 64GB RAM). One is running CentOS 4 Linux, the other is running
> Windows server 2003 Enterprise Edition x64. Both have 64-bit JVMs from Sun.
> The Lucene server is using MMapDirectory. I'm running the jvm with
> -Xmx16000M. Peak memory usage of the jvm on Linux is about 6GB and 7.8GB on
> windows.
>
> I'm observing query rates of 330 queries/sec on the Wintel server, but only
> 200 qps on the Linux box. At first, I suspected a network bottleneck, but
> when I 'short-circuited' Lucene, the query rates were identical.
>
> I suspect that there are some things to be tuned in Linux, but I'm not sure
> what. Any advice would be appreciated.
>
> Peter
>
>
>
> On 1/30/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> >
> > I cranked up the dial on my query tester and was able to get the rate up
> > to 325 qps. Unfortunately, the machine died shortly thereafter (memory
> > errors :-( ) Hopefully, it was just a coincidence. I haven't measured 64-bit
> > indexing speed, yet.
> >
> > Peter
> >
> > On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> > >
> > > Peter Keegan wrote:
> > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm now
> > > > getting 250 queries/sec and excellent cpu utilization (equal
> > > concurrency on
> > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I wasn't
> > > aware
> > > > of it.
> > > >
> > > Wow. That's fast.
> > >
> > > Out of interest, does indexing time speed up much on 64-bit hardware?
> > > I'm particularly interested in this side of things because for our own
> > > application, any query response under half a second is good enough, but
> > > the indexing side could always be faster. :-)
> > >
> > > Daniel
> > >
> > > --
> > > Daniel Noll
> > >
> > > Nuix Australia Pty Ltd
> > > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> > > Phone: (02) 9280 0699
> > > Fax: (02) 9212 6902
> > >
> > > This message is intended only for the named recipient. If you are not
> > > the intended recipient you are notified that disclosing, copying,
> > > distributing or taking any action in reliance on the contents of this
> > > message or attachment is strictly prohibited.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > For additional commands, e-mail: java-user-help [at] lucene
> > >
> > >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

peterlkeegan at gmail

Feb 23, 2006, 8:00 AM

Post #43 of 62 (3704 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Hi Otis,

The Lucene server is actually CPU and network bound, as the index gets
memory mapped pretty quickly. There is little disk activity observed.

I was also able to run the server on a Sun box last night with 4 dual core
opterons (same Linux and JVM) and I'm observing query rates of 400 qps! Has
Linux been optimized to run on this hardware? I imagine that Sun's JVM has
been.

Peter

On 2/22/06, Otis Gospodnetic <otis_gospodnetic [at] yahoo> wrote:
>
> Hi,
>
> Some things that could be different:
> - thread scheduling (shouldn't make too much of a difference though)
>
> --- I would also play with disk IO schedulers, if you can. CentOS is
> based on RedHat, I believe, and RedHat (ext3, really) now has about 4
> different IO schedulers that, according to articles I recently read, can
> have an impact on disk read/write performance. These schedules can be
> specified at mount time, I believe, and maybe at boot time (kernel line in
> Grub/LILO).
>
> Otis
>
>
> On 2/22/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > I am doing a performance comparison of Lucene on Linux vs Windows.
> >
> > I have 2 identically configured servers (8-CPUs (real) x 3GHz Xeon
> > processors, 64GB RAM). One is running CentOS 4 Linux, the other is
> running
> > Windows server 2003 Enterprise Edition x64. Both have 64-bit JVMs from
> Sun.
> > The Lucene server is using MMapDirectory. I'm running the jvm with
> > -Xmx16000M. Peak memory usage of the jvm on Linux is about 6GB and 7.8GBon
> > windows.
> >
> > I'm observing query rates of 330 queries/sec on the Wintel server, but
> only
> > 200 qps on the Linux box. At first, I suspected a network bottleneck,
> but
> > when I 'short-circuited' Lucene, the query rates were identical.
> >
> > I suspect that there are some things to be tuned in Linux, but I'm not
> sure
> > what. Any advice would be appreciated.
> >
> > Peter
> >
> >
> >
> > On 1/30/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > >
> > > I cranked up the dial on my query tester and was able to get the rate
> up
> > > to 325 qps. Unfortunately, the machine died shortly thereafter (memory
> > > errors :-( ) Hopefully, it was just a coincidence. I haven't measured
> 64-bit
> > > indexing speed, yet.
> > >
> > > Peter
> > >
> > > On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> > > >
> > > > Peter Keegan wrote:
> > > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm
> now
> > > > > getting 250 queries/sec and excellent cpu utilization (equal
> > > > concurrency on
> > > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I
> wasn't
> > > > aware
> > > > > of it.
> > > > >
> > > > Wow. That's fast.
> > > >
> > > > Out of interest, does indexing time speed up much on 64-bit
> hardware?
> > > > I'm particularly interested in this side of things because for our
> own
> > > > application, any query response under half a second is good enough,
> but
> > > > the indexing side could always be faster. :-)
> > > >
> > > > Daniel
> > > >
> > > > --
> > > > Daniel Noll
> > > >
> > > > Nuix Australia Pty Ltd
> > > > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> > > > Phone: (02) 9280 0699
> > > > Fax: (02) 9212 6902
> > > >
> > > > This message is intended only for the named recipient. If you are
> not
> > > > the intended recipient you are notified that disclosing, copying,
> > > > distributing or taking any action in reliance on the contents of
> this
> > > > message or attachment is strictly prohibited.
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > > For additional commands, e-mail: java-user-help [at] lucene
> > > >
> > > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

rrprabhu at gmail

Feb 23, 2006, 8:10 AM

Post #44 of 62 (3698 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Can nutch be made to use lucene query parser?

Rgds
Prabhu

On 2/23/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
>
> Hi Otis,
>
> The Lucene server is actually CPU and network bound, as the index gets
> memory mapped pretty quickly. There is little disk activity observed.
>
> I was also able to run the server on a Sun box last night with 4 dual core
> opterons (same Linux and JVM) and I'm observing query rates of 400 qps!
> Has
> Linux been optimized to run on this hardware? I imagine that Sun's JVM has
> been.
>
> Peter
>
> On 2/22/06, Otis Gospodnetic <otis_gospodnetic [at] yahoo> wrote:
> >
> > Hi,
> >
> > Some things that could be different:
> > - thread scheduling (shouldn't make too much of a difference though)
> >
> > --- I would also play with disk IO schedulers, if you can. CentOS is
> > based on RedHat, I believe, and RedHat (ext3, really) now has about 4
> > different IO schedulers that, according to articles I recently read, can
> > have an impact on disk read/write performance. These schedules can be
> > specified at mount time, I believe, and maybe at boot time (kernel line
> in
> > Grub/LILO).
> >
> > Otis
> >
> >
> > On 2/22/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > I am doing a performance comparison of Lucene on Linux vs Windows.
> > >
> > > I have 2 identically configured servers (8-CPUs (real) x 3GHz Xeon
> > > processors, 64GB RAM). One is running CentOS 4 Linux, the other is
> > running
> > > Windows server 2003 Enterprise Edition x64. Both have 64-bit JVMs from
> > Sun.
> > > The Lucene server is using MMapDirectory. I'm running the jvm with
> > > -Xmx16000M. Peak memory usage of the jvm on Linux is about 6GB and
> 7.8GBon
> > > windows.
> > >
> > > I'm observing query rates of 330 queries/sec on the Wintel server, but
> > only
> > > 200 qps on the Linux box. At first, I suspected a network bottleneck,
> > but
> > > when I 'short-circuited' Lucene, the query rates were identical.
> > >
> > > I suspect that there are some things to be tuned in Linux, but I'm not
> > sure
> > > what. Any advice would be appreciated.
> > >
> > > Peter
> > >
> > >
> > >
> > > On 1/30/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > >
> > > > I cranked up the dial on my query tester and was able to get the
> rate
> > up
> > > > to 325 qps. Unfortunately, the machine died shortly thereafter
> (memory
> > > > errors :-( ) Hopefully, it was just a coincidence. I haven't
> measured
> > 64-bit
> > > > indexing speed, yet.
> > > >
> > > > Peter
> > > >
> > > > On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> > > > >
> > > > > Peter Keegan wrote:
> > > > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and
> I'm
> > now
> > > > > > getting 250 queries/sec and excellent cpu utilization (equal
> > > > > concurrency on
> > > > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I
> > wasn't
> > > > > aware
> > > > > > of it.
> > > > > >
> > > > > Wow. That's fast.
> > > > >
> > > > > Out of interest, does indexing time speed up much on 64-bit
> > hardware?
> > > > > I'm particularly interested in this side of things because for our
> > own
> > > > > application, any query response under half a second is good
> enough,
> > but
> > > > > the indexing side could always be faster. :-)
> > > > >
> > > > > Daniel
> > > > >
> > > > > --
> > > > > Daniel Noll
> > > > >
> > > > > Nuix Australia Pty Ltd
> > > > > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> > > > > Phone: (02) 9280 0699
> > > > > Fax: (02) 9212 6902
> > > > >
> > > > > This message is intended only for the named recipient. If you are
> > not
> > > > > the intended recipient you are notified that disclosing, copying,
> > > > > distributing or taking any action in reliance on the contents of
> > this
> > > > > message or attachment is strictly prohibited.
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > > > For additional commands, e-mail: java-user-help [at] lucene
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > For additional commands, e-mail: java-user-help [at] lucene
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > For additional commands, e-mail: java-user-help [at] lucene
> >
> >
>
>

daniel.armbrust.list at gmail

Feb 23, 2006, 8:10 AM

Post #45 of 62 (3700 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

I would give the IBM or blackdown JVM a try on linux - I've seen pretty
wide variance in their speed on different operations.

Sometimes better than Sun, sometimes worse - it depended on the task (I
did some adhoc tests at one point that showed sun was faster for
indexing, but IBM was faster for querying - but that was quite a while ago.

Dan

--
****************************
Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester
daniel.armbrust(at)mayo.edu
http://informatics.mayo.edu/

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

otis_gospodnetic at yahoo

Feb 23, 2006, 9:56 AM

Post #46 of 62 (3706 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Hi,

Please ask on the Nutch mailing list (I answered your question in general@ already).
Also, please don't steal other people's threads - it's considered inpolite for obvious reasons.

Otis

----- Original Message ----
From: Raghavendra Prabhu <rrprabhu [at] gmail>
To: java-user [at] lucene
Sent: Thursday, February 23, 2006 11:10:11 AM
Subject: Re: Throughput doesn't increase when using more concurrent threads

Can nutch be made to use lucene query parser?

Rgds
Prabhu

On 2/23/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
>
> Hi Otis,
>
> The Lucene server is actually CPU and network bound, as the index gets
> memory mapped pretty quickly. There is little disk activity observed.
>
> I was also able to run the server on a Sun box last night with 4 dual core
> opterons (same Linux and JVM) and I'm observing query rates of 400 qps!
> Has
> Linux been optimized to run on this hardware? I imagine that Sun's JVM has
> been.
>
> Peter
>
> On 2/22/06, Otis Gospodnetic <otis_gospodnetic [at] yahoo> wrote:
> >
> > Hi,
> >
> > Some things that could be different:
> > - thread scheduling (shouldn't make too much of a difference though)
> >
> > --- I would also play with disk IO schedulers, if you can. CentOS is
> > based on RedHat, I believe, and RedHat (ext3, really) now has about 4
> > different IO schedulers that, according to articles I recently read, can
> > have an impact on disk read/write performance. These schedules can be
> > specified at mount time, I believe, and maybe at boot time (kernel line
> in
> > Grub/LILO).
> >
> > Otis
> >
> >
> > On 2/22/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > I am doing a performance comparison of Lucene on Linux vs Windows.
> > >
> > > I have 2 identically configured servers (8-CPUs (real) x 3GHz Xeon
> > > processors, 64GB RAM). One is running CentOS 4 Linux, the other is
> > running
> > > Windows server 2003 Enterprise Edition x64. Both have 64-bit JVMs from
> > Sun.
> > > The Lucene server is using MMapDirectory. I'm running the jvm with
> > > -Xmx16000M. Peak memory usage of the jvm on Linux is about 6GB and
> 7.8GBon
> > > windows.
> > >
> > > I'm observing query rates of 330 queries/sec on the Wintel server, but
> > only
> > > 200 qps on the Linux box. At first, I suspected a network bottleneck,
> > but
> > > when I 'short-circuited' Lucene, the query rates were identical.
> > >
> > > I suspect that there are some things to be tuned in Linux, but I'm not
> > sure
> > > what. Any advice would be appreciated.
> > >
> > > Peter
> > >
> > >
> > >
> > > On 1/30/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > >
> > > > I cranked up the dial on my query tester and was able to get the
> rate
> > up
> > > > to 325 qps. Unfortunately, the machine died shortly thereafter
> (memory
> > > > errors :-( ) Hopefully, it was just a coincidence. I haven't
> measured
> > 64-bit
> > > > indexing speed, yet.
> > > >
> > > > Peter
> > > >
> > > > On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> > > > >
> > > > > Peter Keegan wrote:
> > > > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and
> I'm
> > now
> > > > > > getting 250 queries/sec and excellent cpu utilization (equal
> > > > > concurrency on
> > > > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I
> > wasn't
> > > > > aware
> > > > > > of it.
> > > > > >
> > > > > Wow. That's fast.
> > > > >
> > > > > Out of interest, does indexing time speed up much on 64-bit
> > hardware?
> > > > > I'm particularly interested in this side of things because for our
> > own
> > > > > application, any query response under half a second is good
> enough,
> > but
> > > > > the indexing side could always be faster. :-)
> > > > >
> > > > > Daniel
> > > > >
> > > > > --
> > > > > Daniel Noll
> > > > >
> > > > > Nuix Australia Pty Ltd
> > > > > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> > > > > Phone: (02) 9280 0699
> > > > > Fax: (02) 9212 6902
> > > > >
> > > > > This message is intended only for the named recipient. If you are
> > not
> > > > > the intended recipient you are notified that disclosing, copying,
> > > > > distributing or taking any action in reliance on the contents of
> > this
> > > > > message or attachment is strictly prohibited.
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > > > For additional commands, e-mail: java-user-help [at] lucene
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > For additional commands, e-mail: java-user-help [at] lucene
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > For additional commands, e-mail: java-user-help [at] lucene
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

rrprabhu at gmail

Feb 23, 2006, 9:59 AM

Post #47 of 62 (3699 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Hi

Sorry for the trouble

I was sending my first mail to the group

and replied to this thread and then later on sent a direct mail.

I would like to apologise for the inconvenience caused.

Rgds
Prabhu

On 2/23/06, Otis Gospodnetic <otis_gospodnetic [at] yahoo> wrote:
>
> Hi,
>
> Please ask on the Nutch mailing list (I answered your question in general@
> already).
> Also, please don't steal other people's threads - it's considered inpolite
> for obvious reasons.
>
> Otis
>
>
> ----- Original Message ----
> From: Raghavendra Prabhu <rrprabhu [at] gmail>
> To: java-user [at] lucene
> Sent: Thursday, February 23, 2006 11:10:11 AM
> Subject: Re: Throughput doesn't increase when using more concurrent
> threads
>
> Can nutch be made to use lucene query parser?
>
> Rgds
> Prabhu
>
>
> On 2/23/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> >
> > Hi Otis,
> >
> > The Lucene server is actually CPU and network bound, as the index gets
> > memory mapped pretty quickly. There is little disk activity observed.
> >
> > I was also able to run the server on a Sun box last night with 4 dual
> core
> > opterons (same Linux and JVM) and I'm observing query rates of 400 qps!
> > Has
> > Linux been optimized to run on this hardware? I imagine that Sun's JVM
> has
> > been.
> >
> > Peter
> >
> > On 2/22/06, Otis Gospodnetic <otis_gospodnetic [at] yahoo> wrote:
> > >
> > > Hi,
> > >
> > > Some things that could be different:
> > > - thread scheduling (shouldn't make too much of a difference though)
> > >
> > > --- I would also play with disk IO schedulers, if you can. CentOS is
> > > based on RedHat, I believe, and RedHat (ext3, really) now has about 4
> > > different IO schedulers that, according to articles I recently read,
> can
> > > have an impact on disk read/write performance. These schedules can be
> > > specified at mount time, I believe, and maybe at boot time (kernel
> line
> > in
> > > Grub/LILO).
> > >
> > > Otis
> > >
> > >
> > > On 2/22/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > > I am doing a performance comparison of Lucene on Linux vs Windows.
> > > >
> > > > I have 2 identically configured servers (8-CPUs (real) x 3GHz Xeon
> > > > processors, 64GB RAM). One is running CentOS 4 Linux, the other is
> > > running
> > > > Windows server 2003 Enterprise Edition x64. Both have 64-bit JVMs
> from
> > > Sun.
> > > > The Lucene server is using MMapDirectory. I'm running the jvm with
> > > > -Xmx16000M. Peak memory usage of the jvm on Linux is about 6GB and
> > 7.8GBon
> > > > windows.
> > > >
> > > > I'm observing query rates of 330 queries/sec on the Wintel server,
> but
> > > only
> > > > 200 qps on the Linux box. At first, I suspected a network
> bottleneck,
> > > but
> > > > when I 'short-circuited' Lucene, the query rates were identical.
> > > >
> > > > I suspect that there are some things to be tuned in Linux, but I'm
> not
> > > sure
> > > > what. Any advice would be appreciated.
> > > >
> > > > Peter
> > > >
> > > >
> > > >
> > > > On 1/30/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > > >
> > > > > I cranked up the dial on my query tester and was able to get the
> > rate
> > > up
> > > > > to 325 qps. Unfortunately, the machine died shortly thereafter
> > (memory
> > > > > errors :-( ) Hopefully, it was just a coincidence. I haven't
> > measured
> > > 64-bit
> > > > > indexing speed, yet.
> > > > >
> > > > > Peter
> > > > >
> > > > > On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> > > > > >
> > > > > > Peter Keegan wrote:
> > > > > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and
> > I'm
> > > now
> > > > > > > getting 250 queries/sec and excellent cpu utilization (equal
> > > > > > concurrency on
> > > > > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I
> > > wasn't
> > > > > > aware
> > > > > > > of it.
> > > > > > >
> > > > > > Wow. That's fast.
> > > > > >
> > > > > > Out of interest, does indexing time speed up much on 64-bit
> > > hardware?
> > > > > > I'm particularly interested in this side of things because for
> our
> > > own
> > > > > > application, any query response under half a second is good
> > enough,
> > > but
> > > > > > the indexing side could always be faster. :-)
> > > > > >
> > > > > > Daniel
> > > > > >
> > > > > > --
> > > > > > Daniel Noll
> > > > > >
> > > > > > Nuix Australia Pty Ltd
> > > > > > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> > > > > > Phone: (02) 9280 0699
> > > > > > Fax: (02) 9212 6902
> > > > > >
> > > > > > This message is intended only for the named recipient. If you
> are
> > > not
> > > > > > the intended recipient you are notified that disclosing,
> copying,
> > > > > > distributing or taking any action in reliance on the contents of
> > > this
> > > > > > message or attachment is strictly prohibited.
> > > > > >
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > > > > For additional commands, e-mail:
> java-user-help [at] lucene
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > For additional commands, e-mail: java-user-help [at] lucene
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > For additional commands, e-mail: java-user-help [at] lucene
> > >
> > >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

peterlkeegan at gmail

Feb 23, 2006, 11:00 AM

Post #48 of 62 (3691 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

We discovered that the kernel was only using 8 CPUs. After recompiling for
16 (8+hyperthreads), it looks like the query rate will settle in around
280-300 qps. Much better, although still quite a bit slower than the
opteron.

Peter

On 2/22/06, Yonik Seeley <yseeley [at] gmail> wrote:
>
> Hmmm, not sure what that could be.
> You could try using the default FSDir instead of MMapDir to see if the
> differences are there.
>
> Some things that could be different:
> - thread scheduling (shouldn't make too much of a difference though)
> - synchronization workings
> - page replacement policy... how to figure out what pages to swap in
> and which to swap out, esp of the memory mapped files.
>
> You could also try a profiler on both platforms to try and see where
> the difference is.
>
> -Yonik
>
> On 2/22/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > I am doing a performance comparison of Lucene on Linux vs Windows.
> >
> > I have 2 identically configured servers (8-CPUs (real) x 3GHz Xeon
> > processors, 64GB RAM). One is running CentOS 4 Linux, the other is
> running
> > Windows server 2003 Enterprise Edition x64. Both have 64-bit JVMs from
> Sun.
> > The Lucene server is using MMapDirectory. I'm running the jvm with
> > -Xmx16000M. Peak memory usage of the jvm on Linux is about 6GB and 7.8GBon
> > windows.
> >
> > I'm observing query rates of 330 queries/sec on the Wintel server, but
> only
> > 200 qps on the Linux box. At first, I suspected a network bottleneck,
> but
> > when I 'short-circuited' Lucene, the query rates were identical.
> >
> > I suspect that there are some things to be tuned in Linux, but I'm not
> sure
> > what. Any advice would be appreciated.
> >
> > Peter
> >
> >
> >
> > On 1/30/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > >
> > > I cranked up the dial on my query tester and was able to get the rate
> up
> > > to 325 qps. Unfortunately, the machine died shortly thereafter (memory
> > > errors :-( ) Hopefully, it was just a coincidence. I haven't measured
> 64-bit
> > > indexing speed, yet.
> > >
> > > Peter
> > >
> > > On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> > > >
> > > > Peter Keegan wrote:
> > > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm
> now
> > > > > getting 250 queries/sec and excellent cpu utilization (equal
> > > > concurrency on
> > > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I
> wasn't
> > > > aware
> > > > > of it.
> > > > >
> > > > Wow. That's fast.
> > > >
> > > > Out of interest, does indexing time speed up much on 64-bit
> hardware?
> > > > I'm particularly interested in this side of things because for our
> own
> > > > application, any query response under half a second is good enough,
> but
> > > > the indexing side could always be faster. :-)
> > > >
> > > > Daniel
> > > >
> > > > --
> > > > Daniel Noll
> > > >
> > > > Nuix Australia Pty Ltd
> > > > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> > > > Phone: (02) 9280 0699
> > > > Fax: (02) 9212 6902
> > > >
> > > > This message is intended only for the named recipient. If you are
> not
> > > > the intended recipient you are notified that disclosing, copying,
> > > > distributing or taking any action in reliance on the contents of
> this
> > > > message or attachment is strictly prohibited.
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > > For additional commands, e-mail: java-user-help [at] lucene
> > > >
> > > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

clamprecht at gmail

Feb 23, 2006, 11:48 AM

Post #49 of 62 (3699 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Peter,
Have you given JRockit JVM a try? I've seen it help throughput
compared to Sun's JVM on a dual xeon/linux machine, especially with
concurrency (up to 6 concurrent searches happening). I'm curious to
see if it makes a difference for you.

-chris

On 2/23/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> We discovered that the kernel was only using 8 CPUs. After recompiling for
> 16 (8+hyperthreads), it looks like the query rate will settle in around
> 280-300 qps. Much better, although still quite a bit slower than the
> opteron.
>
> Peter
>
>
>
>
> On 2/22/06, Yonik Seeley <yseeley [at] gmail> wrote:
> >
> > Hmmm, not sure what that could be.
> > You could try using the default FSDir instead of MMapDir to see if the
> > differences are there.
> >
> > Some things that could be different:
> > - thread scheduling (shouldn't make too much of a difference though)
> > - synchronization workings
> > - page replacement policy... how to figure out what pages to swap in
> > and which to swap out, esp of the memory mapped files.
> >
> > You could also try a profiler on both platforms to try and see where
> > the difference is.
> >
> > -Yonik
> >
> > On 2/22/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > I am doing a performance comparison of Lucene on Linux vs Windows.
> > >
> > > I have 2 identically configured servers (8-CPUs (real) x 3GHz Xeon
> > > processors, 64GB RAM). One is running CentOS 4 Linux, the other is
> > running
> > > Windows server 2003 Enterprise Edition x64. Both have 64-bit JVMs from
> > Sun.
> > > The Lucene server is using MMapDirectory. I'm running the jvm with
> > > -Xmx16000M. Peak memory usage of the jvm on Linux is about 6GB and 7.8GBon
> > > windows.
> > >
> > > I'm observing query rates of 330 queries/sec on the Wintel server, but
> > only
> > > 200 qps on the Linux box. At first, I suspected a network bottleneck,
> > but
> > > when I 'short-circuited' Lucene, the query rates were identical.
> > >
> > > I suspect that there are some things to be tuned in Linux, but I'm not
> > sure
> > > what. Any advice would be appreciated.
> > >
> > > Peter
> > >
> > >
> > >
> > > On 1/30/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > >
> > > > I cranked up the dial on my query tester and was able to get the rate
> > up
> > > > to 325 qps. Unfortunately, the machine died shortly thereafter (memory
> > > > errors :-( ) Hopefully, it was just a coincidence. I haven't measured
> > 64-bit
> > > > indexing speed, yet.
> > > >
> > > > Peter
> > > >
> > > > On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> > > > >
> > > > > Peter Keegan wrote:
> > > > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and I'm
> > now
> > > > > > getting 250 queries/sec and excellent cpu utilization (equal
> > > > > concurrency on
> > > > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I
> > wasn't
> > > > > aware
> > > > > > of it.
> > > > > >
> > > > > Wow. That's fast.
> > > > >
> > > > > Out of interest, does indexing time speed up much on 64-bit
> > hardware?
> > > > > I'm particularly interested in this side of things because for our
> > own
> > > > > application, any query response under half a second is good enough,
> > but
> > > > > the indexing side could always be faster. :-)
> > > > >
> > > > > Daniel
> > > > >
> > > > > --
> > > > > Daniel Noll
> > > > >
> > > > > Nuix Australia Pty Ltd
> > > > > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> > > > > Phone: (02) 9280 0699
> > > > > Fax: (02) 9212 6902
> > > > >
> > > > > This message is intended only for the named recipient. If you are
> > not
> > > > > the intended recipient you are notified that disclosing, copying,
> > > > > distributing or taking any action in reliance on the contents of
> > this
> > > > > message or attachment is strictly prohibited.
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > > > For additional commands, e-mail: java-user-help [at] lucene
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > For additional commands, e-mail: java-user-help [at] lucene
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

peterlkeegan at gmail

Feb 23, 2006, 1:14 PM

Post #50 of 62 (3708 views)
Permalink

Re: Throughput doesn't increase when using more concurrent threads [In reply to]

Chris,

I tried JRockit a while back on 8-cpu/windows and it was slower than Sun's.
Since I seem to be cpu-bound right now, I'll be trying a 16-cpu system next
(32 with hyperthreading), on LinTel. I may give JRockit another go around
then.

Thanks,
Peter

On 2/23/06, Chris Lamprecht <clamprecht [at] gmail> wrote:
>
> Peter,
> Have you given JRockit JVM a try? I've seen it help throughput
> compared to Sun's JVM on a dual xeon/linux machine, especially with
> concurrency (up to 6 concurrent searches happening). I'm curious to
> see if it makes a difference for you.
>
> -chris
>
> On 2/23/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > We discovered that the kernel was only using 8 CPUs. After recompiling
> for
> > 16 (8+hyperthreads), it looks like the query rate will settle in around
> > 280-300 qps. Much better, although still quite a bit slower than the
> > opteron.
> >
> > Peter
> >
> >
> >
> >
> > On 2/22/06, Yonik Seeley <yseeley [at] gmail> wrote:
> > >
> > > Hmmm, not sure what that could be.
> > > You could try using the default FSDir instead of MMapDir to see if the
> > > differences are there.
> > >
> > > Some things that could be different:
> > > - thread scheduling (shouldn't make too much of a difference though)
> > > - synchronization workings
> > > - page replacement policy... how to figure out what pages to swap in
> > > and which to swap out, esp of the memory mapped files.
> > >
> > > You could also try a profiler on both platforms to try and see where
> > > the difference is.
> > >
> > > -Yonik
> > >
> > > On 2/22/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > > I am doing a performance comparison of Lucene on Linux vs Windows.
> > > >
> > > > I have 2 identically configured servers (8-CPUs (real) x 3GHz Xeon
> > > > processors, 64GB RAM). One is running CentOS 4 Linux, the other is
> > > running
> > > > Windows server 2003 Enterprise Edition x64. Both have 64-bit JVMs
> from
> > > Sun.
> > > > The Lucene server is using MMapDirectory. I'm running the jvm with
> > > > -Xmx16000M. Peak memory usage of the jvm on Linux is about 6GB and
> 7.8GBon
> > > > windows.
> > > >
> > > > I'm observing query rates of 330 queries/sec on the Wintel server,
> but
> > > only
> > > > 200 qps on the Linux box. At first, I suspected a network
> bottleneck,
> > > but
> > > > when I 'short-circuited' Lucene, the query rates were identical.
> > > >
> > > > I suspect that there are some things to be tuned in Linux, but I'm
> not
> > > sure
> > > > what. Any advice would be appreciated.
> > > >
> > > > Peter
> > > >
> > > >
> > > >
> > > > On 1/30/06, Peter Keegan <peterlkeegan [at] gmail> wrote:
> > > > >
> > > > > I cranked up the dial on my query tester and was able to get the
> rate
> > > up
> > > > > to 325 qps. Unfortunately, the machine died shortly thereafter
> (memory
> > > > > errors :-( ) Hopefully, it was just a coincidence. I haven't
> measured
> > > 64-bit
> > > > > indexing speed, yet.
> > > > >
> > > > > Peter
> > > > >
> > > > > On 1/29/06, Daniel Noll <daniel [at] nuix> wrote:
> > > > > >
> > > > > > Peter Keegan wrote:
> > > > > > > I tried the AMD64-bit JVM from Sun and with MMapDirectory and
> I'm
> > > now
> > > > > > > getting 250 queries/sec and excellent cpu utilization (equal
> > > > > > concurrency on
> > > > > > > all cpus)!! Yonik, thanks for the pointer to the 64-bit jvm. I
> > > wasn't
> > > > > > aware
> > > > > > > of it.
> > > > > > >
> > > > > > Wow. That's fast.
> > > > > >
> > > > > > Out of interest, does indexing time speed up much on 64-bit
> > > hardware?
> > > > > > I'm particularly interested in this side of things because for
> our
> > > own
> > > > > > application, any query response under half a second is good
> enough,
> > > but
> > > > > > the indexing side could always be faster. :-)
> > > > > >
> > > > > > Daniel
> > > > > >
> > > > > > --
> > > > > > Daniel Noll
> > > > > >
> > > > > > Nuix Australia Pty Ltd
> > > > > > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia
> > > > > > Phone: (02) 9280 0699
> > > > > > Fax: (02) 9212 6902
> > > > > >
> > > > > > This message is intended only for the named recipient. If you
> are
> > > not
> > > > > > the intended recipient you are notified that disclosing,
> copying,
> > > > > > distributing or taking any action in reliance on the contents of
> > > this
> > > > > > message or attachment is strictly prohibited.
> > > > > >
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > > > > For additional commands, e-mail:
> java-user-help [at] lucene
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > > For additional commands, e-mail: java-user-help [at] lucene
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads