We have modified the kubernetes configuration and restarted SolrCloud cluster, now we have 16 cores per Solr instance. The performance does not seem to be improved though. The load average is 0.43 0.83 1.00, to me it seems an IO bound problem. Looking at the index I see 162M documents, 234M maxDocs, 71M deleted... maybe this core needs to be optimized. The INDEX.size is 70GB, what do you think if I raise the size allocated from the JVM to 64GB in order to have the index in memory? At last, I'm looking at Solr metric but really not sure how to understand if it is CPU bound or IO bound.
On Fri, Mar 18, 2022 at 6:34 PM Walter Underwood <wun...@wunderwood.org> wrote: > First look at the system metrics. Is it CPU bound or IO bound? Each > request is single threaded, so a CPU bound system will have one core used > at roughly 100% for that time. An IO bound system will not be using much > CPU but will have threads in iowait and lots of disk reads. > > After you know that, then you know what to work on. If it is IO bound, get > enough RAM for the OS, JVM, and index files to all be in memory. If it is > CPU bound, get a faster processor and work on the config to have the > request do less work. Sharding can also help. > > I’m not a fan of always choosing 31 GB for the JVM. Allocate only as much > as is needed. Java will use the whole heap whether it is needed or not. You > might only need 8 GB. All of our clusters run with 16 GB. That includes > some machines with 36 cores. > > -- Vincenzo D'Amore
