Good afternoon everyone! Someone can tell me please, metric request time can be
taken only by cores? Are there any aggregates on the collection or in the
collection + host?
Are there any open best practices for situations where there are many cores?
--
Alex Bulygin
Uwe,
I understand that mmap would only map *a part* of the index from virtual
address space to physical memory as and when the pages are requested.
However the limitation on our side is that in most cases, we cannot ask for
more than 128 GB RAM (and unfortunately even that would be a stretch) for
t
This is not true. Memory mapping does not need to load the index into ram, so
you don't need so much physical memory. Paging is done only between index files
and ram, that's what memory mapping is about.
Please read the blog post:
https://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64
Hi folks-
I'm curious to understand the history/context of using PFOR for positions
and frequencies while continuing to use basic FOR for docid encoding. I've
done my best to turn up any past conversations on this, but wasn't able to
find much. Apologies if I missed it in my digging! From what I'v
Correction: the windows limitation is only till windows server 2012 / Windows
8. So you can memory map easily terabytes of data nowadays.
Uwe
Am March 15, 2021 7:42:26 PM UTC schrieb Uwe Schindler :
>Hi Mike,
>
>Windows has unfortunately some crazy limitation on address space, so
>number of addr
Mike,
Yes I am using a 64 bit JVM on Windows. I haven't tried reproducing the
issue on Linux yet. In the past we have had problems with mmap on Windows
with the machine freezing. The rationale I gave to myself is the amount of
disk and CPU activity for paging in and out must be intense for the OS
w
Hi Mike,
Windows has unfortunately some crazy limitation on address space, so number of
address bits is limited to 43, see my blog post @
https://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
That's 8 Terabyte.
On Linux this limitation is at 47 bits, and with later kernels a
Thanks Rahul.
> primary reason being that memory mapping multi-terabyte indexes is not
feasible through mmap
Hmm, that is interesting -- are you using a 64 bit JVM? If so, what goes
wrong with such large maps? Lucene's MMapDirectory should chunk the
mapping to deal with ByteBuffer int only addr
Should be done now.
https://github.com/apache/solr-operator/commit/d236b4f2cc2713c410554cc5166064b566b58342#diff-b4c2a69650f9ac84008ad9f745859a645c9466350ffdfe5f919655039ee2e2c3
- Houston
On Mon, Mar 15, 2021 at 1:37 PM Uwe Schindler wrote:
> Hi Houston,
>
> Can we change the commit mail addre
Hi Houston,
Can we change the commit mail address of this repository? Or does this need
INFRA involvement?
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: hous...@apache.org
> Sent: Monday, March 15, 20
Deleting unneeded tags is easy, so starting with the automatied script is fine.
I agree to remove those “orking” branches/tags in the lucene and solr repos.
Once done, the disk space may reduce, as “git gc” will remove all refs.
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
I am a software programmer from China.I having been reading the source of lucene version 6.6.0. I have 3 questions to ask.1. is about this method: org.apache.lucene.codecs.blocktree.BlockTreeTermsWriter.TermsWriter.pushTerm(BytesRef). I can not understand one line in this method: [ prefixStarts[i]
What's the point of even having a tag for "branch_8x", "branch_7x" etc.?
Their very existence was fundamentally to commit code to, and were
constantly moving forward as work happens. They will still exist in
lucene-solr repo, so "no history is lost" will be true as well.
Having tags for actual rel
Hi,
With the new lucene.git repo up and running, we (Uwe, Dawid and I) like to get
rid of some clutter.
We discussed on Slack and later her on list[1] the option of pruning all the
112 old branches. It makes no sense to keep stale branch_x_y branches in
lucene.git repo, as any future 8.x or 7
This should be fixed on main.
D.
On Sun, Mar 14, 2021 at 8:22 PM Policeman Jenkins Server
wrote:
>
> Build: https://jenkins.thetaphi.de/job/Lucene-main-Linux/29697/
> Java: 64bit/jdk-16-ea+36 -XX:+UseCompressedOops -XX:+UseZGC
>
> No tests ran.
>
>
15 matches
Mail list logo
