mikemccand commented on issue #13883: URL: https://github.com/apache/lucene/issues/13883#issuecomment-3019714085
> A downside with option 1 could be limited control on merge scheduling. Maybe with option 1 we could add a package private API that allows the manager to drop threads to 0 in the "8 indexes on 4 cores" starvation case? +1 to start with option 1 (separate CMS manager), and iterate/pivot later if needed. Ideally in the happy path (merge demand/requests is less than the allowed maximum concurrent merges), all writers would work as they do today, where every merge runs. The unhappy path (more merge demand that allowed capacity) is where it gets more interesting how to share resources... CMS today allows N merges to be requested, and up to M (M <= N) running at once, and has the ability to pause a merge thread when we are between M and N merges. Ideally, the manager can just build on top of CMS, e.g. simply allocating the M and N that it was told to the M and N for each CMS it is managing, changing as merge demand comes and goes on the writers. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
