[
https://issues.apache.org/jira/browse/LUCENE-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982692#action_12982692
]
Robert Muir commented on LUCENE-2832:
-------------------------------------
In this case, its very extreme. the user had 1.1 billion documents on one
windows server.
I am not sure if this issue will even help anyone at all: will a smaller buffer
really help fragmentation in these cases?
The user never responded to my suggestion to change the buffer size.
I think a good option here is to do nothing at all, but I'm not opposed to
reducing the buffer *if* it will actually help,
mainly because the MultiMMapIndexInput is sped up and it shouldn't cause as
much slowdown as before.
> on Windows 64-bit, maybe we should default to a better maxBBufSize in
> MMapDirectory
> -----------------------------------------------------------------------------------
>
> Key: LUCENE-2832
> URL: https://issues.apache.org/jira/browse/LUCENE-2832
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Reporter: Robert Muir
> Assignee: Robert Muir
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2832.patch
>
>
> Currently the default max buffer size for MMapDirectory is 256MB on 32bit and
> Integer.MAX_VALUE on 64bit:
> {noformat}
> public static final int DEFAULT_MAX_BUFF = Constants.JRE_IS_64BIT ?
> Integer.MAX_VALUE : (256 * 1024 * 1024);
> {noformat}
> But, in windows on 64-bit, you are practically limited to 8TB. This can cause
> problems in extreme cases, such as:
> http://www.lucidimagination.com/search/document/7522ee54c46f9ca4/map_failed_at_getsearcher
> Perhaps it would be good to change this default such that its 256MB on 32Bit
> *OR* windows, but leave it at Integer.MAX_VALUE
> on other 64-bit and "64-bit" (48-bit) systems.
--
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: [email protected]
For additional commands, e-mail: [email protected]
