Re: Pooled searcher (was: Solid State Drives vs. RAMDirectory)

2008-04-18 Thread Otis Gospodnetic
From: Karl Wettin <[EMAIL PROTECTED]> To: java-user@lucene.apache.org Sent: Wednesday, April 16, 2008 1:28:44 PM Subject: Pooled searcher (was: Solid State Drives vs. RAMDirectory) Toke Eskildsen skrev: > In the log names, t2 signifies 2 threads with a shared > searcher, t2u signifi

Re: Pooled searcher

2008-04-17 Thread Karl Wettin
It would be great if you did. Please reply in LUCENE-1265. Jake Mannix skrev: We started doing the same thing (pooling 1 searcher per core) at my work when profiling showed a lot of time hitting synchonized blocks deep inside the SegmentTermReader (? Might be messing the class up) under high lo

Re: Pooled searcher (was: Solid State Drives vs. RAMDirectory)

2008-04-16 Thread Jake Mannix
We started doing the same thing (pooling 1 searcher per core) at my work when profiling showed a lot of time hitting synchonized blocks deep inside the SegmentTermReader (? Might be messing the class up) under high load, due to file read()'s using instance variables for seeking. I could dig up the

Pooled searcher (was: Solid State Drives vs. RAMDirectory)

2008-04-16 Thread Karl Wettin
Toke Eskildsen skrev: In the log names, t2 signifies 2 threads with a shared searcher, t2u signifies 2 threads with separate searchers. metis_RAM_24GB_i14_v23_t1_l23.log 530.0 q/sec metis_RAM_24GB_i14_v23_t2_l23.log 888.2 q/sec Did someone end up investigating this thing with pool