lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zheng Lin Edwin Yeo <>
Subject Re: Indexing in one collection affect index in another collection
Date Sat, 26 Jan 2019 23:48:53 GMT
Hi Shawn,

Thanks for your reply. Below are the replies to your email:

1) We have tried to set the heap size to be 8g previously when we faced the
same issue, and changing to 7g does not help too.

2) We are using standard disk at the moment.

3) In the link is the screenshot of the process list that is sort by Commit.


On Sun, 27 Jan 2019 at 02:07, Shawn Heisey <> wrote:

> On 1/26/2019 9:40 AM, Zheng Lin Edwin Yeo wrote:
> > We have tried to add -a "-XX:+AlwaysPreTouch" that starts Solr, but there
> > is no noticeable difference in the performance.
> >
> > As for the screenshot, I have captured another one after we added  -a
> > "-XX:+AlwaysPreTouch", and it is sorted on the Working Set column.
> > Below is the link to the new screenshot:
> >
> That would mean that it's probably not a heap issue.  You could try
> increasing the heap size on each Solr instance to 7g as a test to see
> whether it helps at all.  I'd be a little bit surprised if that helps.
> I can't tell much about the software other than Solr that's running on
> this machine, but my best guess at this point is that Solr index
> information is being pushed out of the disk cache by the other software
> running on the machine, making it so that when Solr needs to do a query,
> a lot of information must be read from disk instead of the cache.  Disks
> are very very slow compared to memory.  SSD is faster, but still quite a
> bit slower than main memory.
> What kind of disk are you using?  If it's standard disks, I don't know
> how easily you could try putting the index data on SSD.  If doing so
> makes it quite a bit faster, then my suspicion above is probably correct.
> A "by the way" question:  What do you see if you sort the process list
> by Commit instead?  Doing this might not reveal anything useful.  Only
> software using MMAP for file access (which Solr does by default) would
> show up near the top of that list, so it's possible that a new sort
> would not reveal anything interesting.
> Thanks,
> Shawn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message