[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:
Relates
relates to MAGNOLIA-7326 Improve import & export functions to ... Closed
relates to MGNLDAM-768 Pre cache image variants on save Closed
relates to MGNLUI-3601 Thumbnail/List View are slow with lar... Closed
causality
relation
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLIMG-282 Implement Sub-task Closed Chuong Doan Huy  
MGNLIMG-283 Review code Sub-task Closed  
MGNLIMG-284 Pre-int QA Sub-task Closed  
MGNLIMG-285 Final QA Sub-task Closed  
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: DeveloperX
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.

Generated at Mon Feb 12 02:13:23 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.