[MGNLIMG-213] Asset upload in ZIP file to DAM may cause the whole instance to go down due to memory exhaustion Created: 12/Jul/19 Updated: 18/Apr/23 Resolved: 28/Feb/23 |
|
| Status: | Closed |
| Project: | Imaging |
| Component/s: | None |
| Affects Version/s: | 3.4.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Laura Delnevo | Assignee: | Chuong Doan Huy |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | maintenance | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | 2.5d | Time Spent: | 2.5d |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Issue Links: |
|
|||||||||||||||||||||||||
| Sub-Tasks: |
|
|||||||||||||||||||||||||
| 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)
|
|||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
|||||||||||||||||||||||||
| Date of First Response: | ||||||||||||||||||||||||||
| Epic Link: | Support | |||||||||||||||||||||||||
| Sprint: | DevX 32 | |||||||||||||||||||||||||
| Story Points: | 5 | |||||||||||||||||||||||||
| Team: | ||||||||||||||||||||||||||
| Work Started: | ||||||||||||||||||||||||||
| Description |
|
Assets upload in ZIP file to DAM cause memory leak. In the example provided by the client the root cause seems to be related to the generation of thumbnails, as Magnolia 6.1 allocates tons of RAM killing production server (see comments in 10161 for more technical details and screenshots). |
| Comments |
| Comment by Rico Jansen [ 02/Nov/21 ] |
|
There is a partial fix in the version of magnolia-imaging 3.4.2-SUPPORT-10161. That fix limits the number of concurrent requests in the image servlet to a configurable number (default 4). Since this limits both the image serving (from cache) as well as the image rendering this gives the issue that on a public instance the number of concurrent requests is high but number of renders is relatively low. Especially since the image cache code bundles renders of the same image with its variation. That means that if you set it high you can still have the problem but if you set it too low the public instance no longer performs. For the author instance this is less of an issue as the number of concurrent requests is lower, however it would still require tuning for the number of editors that use the instance. So I would suggest that it is better to limit the number of concurrent renders in either the ImageStreamer or the ImageGenerator code to actually limit the number of concurrent image generating jobs instead of both the serving and generating jobs.
|
| Comment by Jaroslav Simak [ 28/Feb/23 ] |
|
Cannot reproduce on the latest 6.2. |