[DOCS-9559] Docs for SERVER-10443: Compact command with LOW priority Created: 05/Dec/16 Updated: 24/Jan/17 Resolved: 24/Jan/17 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Emily Hall | Assignee: | Allison Reinheimer Moore |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | compaction, indexing, performance, sharding, storage | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 7 years, 3 weeks, 1 day ago | ||||||||
| Description |
|
Engineering Ticket Description: The 'compact' command should be runnable at low priority on any system without affecting existing performance. Current 'compact' command restrictions:
This case covers the trivial and straightforward case of regular maintenance. That is, the compact command should be runnable at any time, or set up as a background process. It should scan through all chunks, one at a time. The least recently used chunk should be addressed first. Processing:
This could be done without affecting performance by querying the locking percentage on the individual shards once per minute, and if the lock percentage is higher than 80%, pause compaction I/O. Alternatively, looking up IOSTAT's IO utilitization percentage will give an idea if the chunk's location can handle more IO. An additional parameter could be a rate limit on the number of chunks processed per minute/hour, or a max percentage of available IO to use. |
| Comments |
| Comment by Kay Kim (Inactive) [ 24/Jan/17 ] |
|
Feel free to reopen if you think this needs documentation. |