[MGNLIMG-211] Implement memory safeguard Created: 09/Nov/18 Updated: 17/Mar/21 Resolved: 17/Mar/21 |
|
| Status: | Closed |
| Project: | Imaging |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Jan Haderka | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Epic Link: | Imaging performance |
| Description |
|
Imaging operation can end up being resource intensive. In particular memory intensive (see Keep in mind that memory is consumed gradually during operation and just starting the op would not allocate all memory for it ... some estimates/assumptions on how much memory would get used will have to be made, perhaps we could even monitor how much was really used and store that for next time. If possible, it would be also of advantage to be able to distinguish between low-memory and high-memory kind of operations/requests and when queueing requests, prioritize those with low-memory requirements so that absolute length of queue is shortest possible one. As for solution itself, I see 2 possible entry points:
Solution could be also combination of both entry points or inserted as some other place. Acceptance criteria:
Possible future improvements:
|
| Comments |
| Comment by Jan Haderka [ 17/Mar/21 ] |
|
Closing in favour of externalizing whole image processing |