Hi Shawn, 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: https://drive.google.com/file/d/1YEsJxnCeRorvBRCSqeowZOu3Fpena5Mo/view?usp=sharing Regards, Edwin On Sat, 26 Jan 2019 at 01:33, Shawn Heisey <apa...@elyograg.org> wrote: > On 1/25/2019 9:11 AM, Zheng Lin Edwin Yeo wrote: > > As requested, below is the link to the screenshot of the resource monitor > > of our system. > > > https://drive.google.com/file/d/1_-Tqhk9YYp9w8injHU4ZPSvdFJOx8A5s/view?usp=sharing > > The wiki page says to sort on the Working Set column. Your screenshot > shows it sorted by the Private column. This might not be a problem, or > switching it might reveal other information. For now, I'm going to > assume that sorting on the other column would show very similar lines in > nearly the same order. If you see a very different process listing when > changing the sort column, I would like to see a new screenshot. > > I can see that Java is not allocating the entire allowed heap > immediately. This can lead to some odd problems. See what happens to > performance if you add this option to the commandline that starts Solr: > > -a "-XX:+AlwaysPreTouch" > > This option is going to make a noticeable difference in the process > listing. I cannot say whether it would help, and it might make things > worse. If it does make things worse, then this machine needs more > memory to do all the jobs it has been asked to do. > > Together the two Solr instances are accessing somewhat less than 9GB of > index data. But the system shows that 22GB of memory is in the disk > cache. This must mean that other software on the machine is accessing a > very large amount of other data. When multiple applications compete for > space in the disk cache, slowdowns will happen. > > Thanks, > Shawn >
