merge eats CPU much when there are many deleteByQuery [LUCENE-7049]
- Dominant language
- Java
- Stars
- 3.6k
- Forks
- 1.4k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 88
Description
## When
adding very many delete><query>
## Then
we got CPU spike in merge thread that blocks indexing process
## Considerations
Despite adding too many <delete><query> is odd itself, I suppose [the code can more efficient](https://issues.apache.org/jira/browse/LUCENE-5666?focusedCommentId=15129040&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15129040). See sampling snapshots attached.



---
Migrated from [LUCENE-7049](https://issues.apache.org/jira/browse/LUCENE-7049) by Mikhail Khludnev (@mkhludnev), updated Aug 10 2016
Attachments: [Selection_114.png](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-7049/Selection_114.png), [Selection_115.png](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-7049/Selection_115.png), [Selection_116.png](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-7049/Selection_116.png)
Linked issues:
- #6728
- [SOLR-9398](https://issues.apache.org/jira/browse/SOLR-9398)
Contributor guide
Research direction
Start with the reported behavior: add many delete-by-query operations and observe CPU usage in the merge thread while indexing. Review the linked LUCENE-5666 discussion, #6728, and SOLR-9398 for context and possible scope. Done would require a demonstrated reduction in merge CPU contention, supported by a regression test or reproducible measurements.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend, search
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100