I felt the need to follow up on this for others reading.
We experimented switching `ioThrottle` to `false` on the CMS settings and on
face value, all our problems have gone away.
Merges are significantly faster (average minor merge time down from 9mins to 2)
and we're consistently using more of o
We've lowered our autoCommit from 1 min to 3 min and that's help quite a lot
with the number of small segments being constantly merged and has lowered the
overall load on solr. Will continue to monitor. We're tempted to go to 5
minutes, but the size of tlogs then would be a bit uncomfortable (
The documents are pretty large yes, 650 fields, circa 20kb/document so at peak
(300/sec) that's circa 6meg/sec. ramBufferSizeMB is 512 so we'd be averaging 1
segment every 90 seconds (ish)?
>This means you never explicitly commits from the client? But You
> autoCommit openSearcher=false ev
>- Update rate, and how you do commits?
>
> Update rates very throughout the day, but range from 20ops/sec to 300ops/sec.
> Commits are done using autoCommit on 1 min interval, softCommit on 15min
> interval.
This means you never explicitly commits from the client? But You autoCommit
open
Hello Jan!
Thanks for your reply.
- Number of nodes and sepc of each node
9 nodes each 24vCPU 70GB ram, 28GB heap rest for OS. Disks are 768GB SSDs now
(going from 512 -> 768 made little difference really).
- Nuber of shards and replicas
1 shard, 9 replicas, eg each node holds all dat
Karl,
Your screen shots were lost at my end, perhaps they did not make it to the
list. You may consider sharing graphics through an external service?
What do you mean by "heavy write"? Can you quantify your cluster in terms of
e.g.
- Number of nodes and sepc of each node
- Nuber of shards and re
