On 3/27/2018 9:35 PM, mganeshs wrote:
I am using the default configuration, as all solr experts say default one
suits for most of the cases and so following the defaults. We changed only
the commits part and using 15000 for hard commits and 1 sec for soft commit.
All other setting like locking, deleting policy, merge, directory, etc are
left to default ones.
One second for autoSoftCommit has a tendency to cause a lot of issues.
That interval should be set as large as you can tolerate for change
visibility. I personally would want to see a setting there of at least
one minute, but I know that this is not fast enough for a lot of users.
Does autoCommit have openSearcher set to false? This is a typical
configuration, and recommended.
One strange thing we noticed after moving from solr 5.x to solr 6.5.1 is
that CPU and RAM usage is increased drastically. We have two solr nodes, one
for data and another for replica. It's EC2 r4.xlarge machine. We have almost
6 collection and each carries around 5GB of data in average and in couple
of collection we have frequent updates too.
That kind of instance has 30.5 GB of total memory. With 8GB assigned to
the heap, that leaves about 22GB for everything else. If Solr is the
only thing running on the machine, and your numbers mean that each
server has about 30GB of index data, then that means you can get about
two thirds of the index into the OS disk cache. Usually this is enough
for decent performance, but that's not the case for everyone. If this
is an accurate picture of your Solr install, I am not really worried
about total memory size. I can't make a guess about it unless I have
accurate information.
The way you're phrasing things, it sounds like you're running in
SolrCloud mode. Is that correct?
Since you're probably running Solr on Linux, can you get me a screenshot
from the "top" program? It must be specifically that program -- don't
use an alternate utility like "htop".
Run top, press shift-M to sort the display by memory, and then grab a
screenshot or photo of the display. Share that file somewhere and
provide a URL to access it. With that info, we can get a good picture
of system health. Be sure that when that "top" display is grabbed, that
the system is experiencing whatever problems you're trying to fix.
What do you know about your query load and how fast the data is being
indexed?
In solr 5.x we didn't feel this much of RAM and CPU usages. CPU is always 80
to 90% even if we are trying to index or update some 50 docs at one shot and
RAM it occupies whatever we give. We started with 8GB of Heap. But its
always 8GB. Initially we were using CMS GC and tried with G1 GC. Only
difference is that, In case of CMS, even after starting solr, cpu goes to
80%, where as in G1, after started solr it's around 10% and when load comes
( around 100 to 200 docs in 5 mins ) it's goes 90% ( in both CMS and G1 )
The default garbage collection tuning does a pretty good job most of the
time. For some people, G1 works even better, but this can only happen
if it is tuned. Simply turning on G1GC and leaving it untuned will
probably get you WORSE performance than leaving the GC tuning at the
settings that the project has provided.
When we tried to profile the solr process, we found that merging is keep on
happening.
Can you elaborate more on exactly what you observed, and what
conclusions you came to based on that information?
This spikes of CPU and memory, we are seeing only after moving to 6.5.1. Is
that stable version ? moving to latest stable will solve this issue or we
miss something wrt configurations ? Do we need to change the solr default
config ?
Virtually all releases are considered stable at the time of release. If
they weren't, then they wouldn't be released! I'm only aware of two
times that versions were released without being called "stable." Those
were the 4.0-ALPHA and 4.0-BETA releases. There have been no ALPHA or
BETA releases since then.
Pretty much every version is later revealed to have bugs, and sometimes
those problems are big enough that the release could be called
unstable. But that is a determination made AFTER release, not before.
6.5.1 was announced on 27 April 2017. It is a bugfix release, mostly
identical to 6.5.0, which was announced exactly one month earlier, on 27
March 2017. Which makes it one year old.
There are a number of bugfixes in 6.5.1 compared to 6.5.0, but the two
are substantially similar.
http://mail-archives.apache.org/mod_mbox/www-announce/201704.mbox/%3CCAKUpjcQiYLZ1a+ZM=ohuxjywlj9vnub8q9b_ilrvmkididv...@mail.gmail.com%3E
If you're going to run 6.x, then you should run 6.6.3. The latest
version currently out is 7.2.1. Version 7.3.0 is just around the corner
-- release is underway right now. I haven't looked through the
changelogs, so I don't really know what's coming.
Thanks,
Shawn
