I would try to make more broader groups in order to reduce the number of shards. I think having 65 small shards creates unnecessary overhead. Maybe someone with more experience with shared collections can pitch in.
Cheers, Renato > On 11 Aug 2026, at 08:42, Harshit Sharma <[email protected]> > wrote: > > Hii Renato > > Are you running on fast storage (pd-ssd on GCP)? > > Yes, we are using SSD storage on GCP. > > What is the reason for having 65 shards with only 10-nodes and RF=1, having >> that many shards is creates overhead. > > Regarding the 65 shards, we have separated the data based on logical > groupings that align with our data access patterns. This allows us to > efficiently retrieve data from Solr by using the route parameter, ensuring > that > queries are routed directly to the relevant shard rather than querying > across all shards. > > RamBuffer of 200MB seems to small for large batches. > > Thanks for the suggestion. We’ll increase the RAM buffer size and monitor > the metrics to evaluate the impact. > > On Sat, Aug 8, 2026 at 2:41 AM Renato <[email protected]> wrote: > >> Hi Harshit, >> >> Just some thoughts: >> >> Are you running on fast storage (pd-ssd on GCP)? >> What is the reason for having 65 shards with only 10-nodes and RF=1, >> having that many shards is creates overhead. >> RamBuffer of 200MB seems to small for large batches. >> >> Cheers, >> >> Renato >> >>> On 7 Aug 2026, at 12:29, Harshit Sharma <[email protected]> >> wrote: >>> >>> Hii all >>> >>> We're looking for advice on reducing the time our indexing client waits >> for >>> Solr to acknowledge update requests. >>> >>> Our indexing throughput is currently limited primarily by the time taken >>> for each batched update request to complete. Before changing client-side >>> concurrency or scaling the application, we'd like to understand whether >> any >>> Solr-side optimisations could reduce this acknowledgement latency. >>> Production Environment >>> >>> - >>> >>> SolrCloud 9.6.1 >>> - >>> >>> 10-node cluster on GCP Compute Engine >>> - >>> >>> Two collections: >>> - >>> >>> ~180M documents (250+ GB, 65 shards) >>> - >>> >>> ~70M documents (180+ GB, 65 shards) >>> - >>> >>> Mostly RF=1 >>> - >>> >>> Implicit routing >>> - >>> >>> SolrJ client sending batched update requests (3k-4k documents/request) >>> - >>> >>> Hard commit every *30 minutes* (openSearcher=false) >>> - >>> >>> Soft commit every *15 minutes* >>> - >>> >>> ramBufferSizeMB=*200* >>> - >>> >>> TieredMergePolicy >>> - >>> >>> Default ConcurrentMergeScheduler >>> - >>> >>> StandardDirectoryFactory (MMapDirectory) >>> >>> What we're observing >>> >>> From the client side, a blocking update request typically takes: >>> >>> - >>> >>> ~700 ms for batches of 3,000 documents >>> - >>> >>> ~1.5 s for batches of 4,000 documents >>> >>> Occasionally we see several-second outliers, but the median latency >> remains >>> consistent even during peak query traffic. >>> >>> We aim to reduce this latency to increase indexing throughput. >>> Questions >>> >>> 1. >>> >>> For batched update requests in SolrCloud, what typically contributes >>> most to the acknowledgement latency (request distribution, update >>> processing, tlog fsync, merges, etc.)? >>> >>> 2. >>> >>> Which Solr metrics would you recommend checking first to identify where >>> this time is being spent? >>> >>> 3. >>> >>> Are there any Solr configuration settings that commonly have a >>> significant impact on update acknowledgement latency (merge policy, >> merge >>> scheduler, indexing buffer, commit settings, update log configuration, >>> etc.)? >>> >>> 4. >>> >>> Has anyone run into similar indexing latency at this scale (60+ shards, >>> ~200M documents), and if so, what changes provided the biggest >> improvement? >>> >>> We'd appreciate any suggestions or best practices to reduce update >> request >>> latency and improve indexing throughput. Please let us know if any >>> additional configuration details or metrics would be helpful. >>> >>> >>> Thanks & Regards >>> >>> Harshit Sharma >> >> > > -- > > Thanks & Regards > > Harshit Sharma > > Sr. Engineer | IM-Search
