Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Lucene: Java-Dev

[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput

 

 

Lucene java-dev RSS feed   Index | Next | Previous | View Threaded


jira at apache

Jun 30, 2008, 5:57 AM

Post #1 of 13 (509 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609226#action_12609226 ]

Jason Rutherglen commented on LUCENE-753:
-----------------------------------------

Interesting results. The question would be, what would the algorithm for allocating RandomAccessFiles to which file look like? When would a new file open, when would a file be closed? If it is based on usage would it be based on the rate of calls to readInternal? This seems like an OS filesystem topic that maybe there is some standard algorithm for. How would the pool avoid the same synchronization issue given the default small buffer size of 1024? If there are 30 threads executing searches, there will not be 30 RandomAccessFiles per file so there is still contention over the limited number of RandomAccessFiles allocated.

> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jun 30, 2008, 11:37 AM

Post #2 of 13 (484 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609327#action_12609327 ]

Michael McCandless commented on LUCENE-753:
-------------------------------------------

I think you have a small bug -- minCount is initialized to 0 but should be something effectively infinite instead?

> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jun 30, 2008, 3:14 PM

Post #3 of 13 (479 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609383#action_12609383 ]

Michael McCandless commented on LUCENE-753:
-------------------------------------------

OK I re-ran only PooledPread, SeparateFile and ChannelPread since they
are the "leading contenders" on all platforms.

Also, I changed to serial=false.

Now the results are very close on all but windows, but on windows I'm
seeing the opposite of what Yonik saw: PooledPread is slowest, and
SeparateFile is fastest. But this is a laptop (Win XP Pro), and it is
JRE 1.4. Also I ran with pool size == number of threads == 4.


Mac OS X 10.5.3, single WD Velociraptor hard drive, Sun JRE 1.6.0_05

{code}
config: impl=PooledPread serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=67108864
answer=-23830370, ms=120807, MB/sec=222.20190551871994

config: impl=SeparateFile serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=67108864
answer=-23830326, ms=119641, MB/sec=224.36744594244448

config: impl=ChannelPread serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=67108864
answer=-23830370, ms=119217, MB/sec=225.1654176837196
{code}


Linux 2.6.22.1, 6-drive RAID 5 array, Sun JRE 1.6.0_06

{code}
config: impl=PooledPread serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=67108864
answer=-23830370, ms=52613, MB/sec=510.2074696367818

config: impl=SeparateFile serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=67108864
answer=-23830370, ms=52715, MB/sec=509.22025230010433

config: impl=ChannelPread serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=67108864
answer=-23830370, ms=53792, MB/sec=499.0248661511005
{code}


WIN XP PRO, laptop, Sun JRE 1.4.2_15:

{code}
config: impl=PooledPread serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=67108864
answer=-23830370, ms=209956, MB/sec=127.85319590771401

config: impl=SeparateFile serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=67108864
answer=-23830370, ms=89101, MB/sec=301.27098012367986

config: impl=ChannelPread serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=67108864
answer=-23830370, ms=184087, MB/sec=145.81988733587923
{code}

> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jun 30, 2008, 4:30 PM

Post #4 of 13 (475 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609401#action_12609401 ]

Brian Pinkerton commented on LUCENE-753:
----------------------------------------

I was curious about the discrepancy between the ChannelPread implementation and the SeparateFile implementation that Yonik saw. At least on Mac OS X, the kernel implementation of read is virtually the same as pread, so there shouldn't be any appreciable performance difference unless the VM is doing something funny. Sure enough, the implementations of read() under RandomAccessFile and read() under FileChannel are totally different. The former relies on either a buffer allocated either on the stack or by malloc, while the latter allocates a native buffer and copies the results to the original array.

Switching to a native buffer in the benchmark yields identical results for ChannelPread and SeparateFile on 1.5 and 1.6 on OS X. I'm attaching an implementation of ChannelPreadDirect that uses a native buffer.

This may be a moot point because any implementation inside Lucene needs to consume a byte[] and not a ByteBuffer, but at least it's informative.



> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jun 30, 2008, 8:53 PM

Post #5 of 13 (472 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609435#action_12609435 ]

Yonik Seeley commented on LUCENE-753:
-------------------------------------

Here are some of my results with 4 threads and a pool size of 4 fds per file. Win XP on a Pentium4 w/ Java5_0_11 -server

{code}
config: impl=PooledPread serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=9616000
answer=322211190, ms=51891, MB/sec=74.12460735002217

config: impl=ChannelPread serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=9616000
answer=322211190, ms=71175, MB/sec=54.04144713733755

config: impl=ClassicFile serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=9616000
answer=322211190, ms=62699, MB/sec=61.34707092617107

config: impl=SeparateFile serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=4 filelen=9616000
answer=322211410, ms=21324, MB/sec=180.37891577565185
{code}


> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jul 1, 2008, 3:05 AM

Post #6 of 13 (464 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609514#action_12609514 ]

Michael McCandless commented on LUCENE-753:
-------------------------------------------


OK it's looking like SeparateFile is the best overall choice... it
matches the best performance on Unix platforms and is very much the
lead on Windows.

It's somewhat surprising to me that after all this time, with these
new IO APIs, the most naive approach (using a separate
RandomAccessFile per thread) still yields the best performance. In
fact, opening multiple IndexReaders to gain concurrency is doing just
this.

Of course this is a synthetic benchmark. Actual IO with Lucene is
somewhat different. EG it's a mix of serial (when iterating through a
term's docs with no skipping) and somewhat random access (when
retrieving term vectors or stored fields), and presumably a mix of
hits & misses to the OS's IO cache. So until we try this out with a
real index and real queries we won't know for sure.

{quote}
The question would be, what would the algorithm for allocating
RandomAccessFiles to which file look like?
{quote}

Ideally it would be based roughly on contention. EG a massive CFS
file in your index should have a separate file per-thread, if there
are not too many threads, whereas tiny CFS files in the index likely
could share / synchronize on a single file

I think it would have thread affinity (if the same thread wants the
same file we give back the same RandomAccessFile that thread last
used, if it's available).

{quote}
When would a new file open, when would a file be closed?
{quote}

I think this should be reference counting. The first time Lucene
calls FSDirectory.openInput on a given name, we must for-real open the
file (Lucene relies on OS protecting open files). Further opens on
that file incRef it. Closes decRef it and when the reference count
gets to 0 we close it for real.

{quote}
If it is based on usage would it be based on the rate of calls to
readInternal?
{quote}

Fortunately, Lucene tends to call IndexInput.clone() when it wants to
actively make use of a file.

So I think the pool could work something like this: FSIndexInput.clone
would "check out" a file from the pool. The pool decides at that
point to either return a SharedFile (which has locking per-read, like
we do now), or a PrivateFile (which has no locking because you are the
only thread currently using that file), based on some measure of
contention plus some configuration of the limit of allowed open files.

One problem with this approach is I'm not sure clones are always
closed, since they are currently very lightweight and can rely on GC
to reclaim them.

An alternative approach would be to sync() on every block (1024 bytes
default now) read, find a file to use, and use it, but I fear that
will have poor performance.

In fact, if we build this pool, we can again try all these alternative
IO APIs, maybe even leaving that choice to the Lucene user as
"advanced tuning".

> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jul 1, 2008, 4:59 AM

Post #7 of 13 (463 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609537#action_12609537 ]

robert engels commented on LUCENE-753:
--------------------------------------

As I stated quit a while ago, this has been a long accepted bug in the JDK.

See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6265734

It was filed and accepted over 3 years ago.

The problem is that the pread performs an unnecessary lock on the file descriptor, instead of using Windows "overlapped" reads.

> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jul 1, 2008, 5:07 AM

Post #8 of 13 (462 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609538#action_12609538 ]

robert engels commented on LUCENE-753:
--------------------------------------

The point being - please vote for this issue so it can be fixed properly. It is really a trivial fix, but it needs to be done by SUN.

> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jul 1, 2008, 7:28 AM

Post #9 of 13 (459 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609606#action_12609606 ]

Yonik Seeley commented on LUCENE-753:
-------------------------------------

.bq OK it's looking like SeparateFile is the best overall choice... it matches the best performance on Unix platforms and is very much the
lead on Windows.

The other implementations are fully-featured though (they could be used in lucene w/ extra synchronization, etc). SeparateFile (opening a new file descriptor per reader) is not a real implementation that could be used... it's more of a theoretical maximum IMO. Also remember that you can't open a new fd on demand since the file might already be deleted. We would need a real PooledClassicFile implementation (like PooledPread).

On non-windows it looks like ChannelPread is probably the right choice.. near max performance and min fd usage



> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jul 1, 2008, 9:16 AM

Post #10 of 13 (455 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609629#action_12609629 ]

Jason Rutherglen commented on LUCENE-753:
-----------------------------------------

Core2Duo Windows XP JDK1.5.15. PooledPread for 4 threads and pool size 2 the performance does not compare well to SeparateFile. PooledPread for 30 threads does not improve appreciably over ClassicFile. If there were 30 threads, how many RandomAccessFiles would there need to be to make a noticeable impact? The problem I see with the pooled implementation is setting the global file descriptor limit properly, will the user set this? There would almost need to be a native check to see if what the user is trying to do is possible.

The results indicate there is significant contention in the pool code. The previous tests used a pool size the same as the number of threads which is probably not how most production systems look, at least the SOLR installations I've worked on. In SOLR the web request thread is the thread that executes the search, so the number of threads is determined by the J2EE server which can be quite high. Unless the assumption is the system is set for an unusually high number of file descriptors.

There should probably be a MMapDirectory test as well.

{noformat}
config: impl=PooledPread serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=2 filelen=18110448
answer=53797223, ms=32715, MB/sec=221.4329573590096

config: impl=SeparateFile serial=false nThreads=4 iterations=100 bufsize=1024 poolsize=2 filelen=18110448
answer=53797223, ms=18687, MB/sec=387.6587574249478

config: impl=SeparateFile serial=false nThreads=30 iterations=100 bufsize=1024 poolsize=2 filelen=18110448
answer=403087371, ms=137871, MB/sec=394.0737646060448

config: impl=PooledPread serial=false nThreads=30 iterations=100 bufsize=1024 poolsize=2 filelen=18110448
answer=403087487, ms=526504, MB/sec=103.19265190767781

config: impl=ChannelPread serial=false nThreads=30 iterations=100 bufsize=1024 poolsize=2 filelen=18110448
answer=403087487, ms=624291, MB/sec=87.02887595688549

config: impl=ClassicFile serial=false nThreads=30 iterations=100 bufsize=1024 poolsize=2 filelen=18110448
answer=403087487, ms=587430, MB/sec=92.48990347786119

config: impl=PooledPread serial=false nThreads=30 iterations=100 bufsize=1024 poolsize=4 filelen=18110448
answer=403087487, ms=552971, MB/sec=98.25351419875544
{noformat}

> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jul 2, 2008, 1:36 AM

Post #11 of 13 (440 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609827#action_12609827 ]

Michael McCandless commented on LUCENE-753:
-------------------------------------------

{quote}
SeparateFile (opening a new file descriptor per reader) is not a real implementation that could be used... it's more of a theoretical maximum IMO. Also remember that you can't open a new fd on demand since the file might already be deleted. We would need a real PooledClassicFile implementation (like PooledPread).
{quote}

True, we'd have to make a real pool, but I'd think we want the sync() to be on cloning and not on every read. I think Lucene's usage of the open files (clones are made & used up quickly and closed) would work well with that approach. I think at this point we should build out an underlying pool and then test all of these different approaches under the pool.

And yes we cannot just open a new fd on demand if the file has been deleted. But I'm thinking that may not matter in practice. Ie if the pool wants to open a new fd, it can attempt to do so, and if the file was deleted it must then return a shared access wrapper to the fd it already has open. Large segments are where the contention will be and large segments are not often deleted. Plus people tend to open new readers if such a large change has taken place to the index.

{quote}
On non-windows it looks like ChannelPread is probably the right choice.. near max performance and min fd usage
{quote}

But on Linux I saw 44% speedup for serial=true case with 4 threads using SeparateFile vs ChannelPread, which I was very surprised by. But then again it's synthetic so it may not matter in real Lucene searches.

> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jul 2, 2008, 6:21 AM

Post #12 of 13 (435 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609916#action_12609916 ]

Yonik Seeley commented on LUCENE-753:
-------------------------------------

bq. (clones are made & used up quickly and closed)

IIRC, clones are often not closed at all.
And for term expanding queries, you can get a *lot* of them all at once.

bq. And yes we cannot just open a new fd on demand if the file has been deleted. But I'm thinking that may not matter in practice. Ie if the pool wants to open a new fd, it can attempt to do so, and if the file was deleted it must then return a shared access wrapper to the fd it already has open.

At first blush, sounds a bit too complex for the benefits.
- one would have to reserve the last fd for synchronized access... can't really hand it out for unsynchronized exclusive access and then go and share it later.
- the shared access should use pread... not seek+read

bq. But on Linux I saw 44% speedup for serial=true case with 4 threads using SeparateFile vs ChannelPread, which I was very surprised by.

In the serial case, there are half the system calls (no seek). When both implementations have a single single system call, all the extra code and complexity that Sun threw into FileChannel comes into play. Compare that with RandomAccessFile.read() which drops down to a native call and presumably just the read with little overhead. I wish Sun would just add a RandomAccessFile.read with a file position.

If access will be truly serial sometimes, larger buffers would help with that larger read() setup cost.


> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org


jira at apache

Jul 2, 2008, 11:01 AM

Post #13 of 13 (428 views)
Permalink
[jira] Commented: (LUCENE-753) Use NIO positional read to avoid synchronization in FSIndexInput [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609990#action_12609990 ]

Michael McCandless commented on LUCENE-753:
-------------------------------------------

bq. And for term expanding queries, you can get a lot of them all at once.

Right but that'd all be under one thread right? The pool would always give the same RandomAccessFile (private or shared) for the same filename X thread.

bq. one would have to reserve the last fd for synchronized access... can't really hand it out for unsynchronized exclusive access and then go and share it later.

Well, I think you'd hand it out first, as a shared file (so you reserve the right to hand it out again, later). If other threads come along you would open a new one (if you are under the budget) and loan it to them privately (so no syncing during read). I think sync'ing with no contention (the first shared file we hand out) should be OK performance in modern JVMs.

bq. the shared access should use pread... not seek+read

But not on Windows...

bq. At first blush, sounds a bit too complex for the benefits.

Yeah I'm on the fence too ... but this lack of concurrency hurts our search performance. It's ashame users have to resort to multiple IndexReaders. Though it still remains to be seen how much the pool or pread approaches really improve end to end search performance (vs other bottlenecks like IndexReader.isDeleted).

Windows is an important platform and doing the pool approach, vs leaving Windows with classic if we do pread approach, lets us have good concurrency on Windows too.

> Use NIO positional read to avoid synchronization in FSIndexInput
> ----------------------------------------------------------------
>
> Key: LUCENE-753
> URL: https://issues.apache.org/jira/browse/LUCENE-753
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Store
> Reporter: Yonik Seeley
> Attachments: FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FileReadTest.java, FSIndexInput.patch, FSIndexInput.patch, lucene-753.patch, lucene-753.patch
>
>
> As suggested by Doug, we could use NIO pread to avoid synchronization on the underlying file.
> This could mitigate any MT performance drop caused by reducing the number of files in the index format.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-dev-help[at]lucene.apache.org

Lucene java-dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.