jpountz commented on issue #13193: URL: https://github.com/apache/lucene/issues/13193#issuecomment-2009569950
> The instant approach we take today gives no credit for a longish period of time when no/few bytes were written. My mental model is that the goal of merge throttling is to prevent merges from starving searches from IOPS. So the current approach makes sense from this perspective: if we gave merges credits that would allow them to max out IOPS from time to time, then this could temporarily starve searches from IOPS, which could be extremely disruptive to searches? But then, I don't recall ever seeing indexing/merging max out I/O on a modern drive, so your second suggestion of removing I/O throttling makes sense to me, and I wouldn't mind removing all the complexity around I/O throttling. Presumably, we would still want to have some mechanisms to prevent merges from using all CPU for use-cases when indexing/merging and search are co-located on the same host? -- 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
