Some CMS search modules send every update with commitWithin=1000: each one asks Solr to make the change searchable within a second. On a busy site that means a new searcher every second, all day.
What each commit costs
A commit writes a new small segment, opens a new searcher, warms its caches, and later has to be merged into bigger segments. Every replica downloads each new version of the index. Per-second commits keep all of that running continuously.
Let Solr schedule commits
Set the module's commit setting to 0 so the server's own autoCommit and autoSoftCommit apply. In Drupal Search API Solr this is the "Commit within" field of the Solr server; 0 turns the per-request value off.
<autoCommit> <maxTime>60000</maxTime> <openSearcher>false</openSearcher> </autoCommit> <autoSoftCommit> <maxTime>30000</maxTime> </autoSoftCommit>
Choose the visibility you need
A change visible within 30 to 60 seconds is fine for almost every site. Product stock or prices that must show at once are better served from the database than from the search index.
Merging after a busy period is normal
After hours of per-second commits an index holds many small segments, and Solr spends CPU merging them in the background for a while. It ends on its own; forcing an optimize only adds a full rewrite on top. More: indexing into Solr without a memory spike.
Solr best practices
CMS integrations that commit every second (this page)