[
https://issues.apache.org/jira/browse/JAMES-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3745.
---------------------------------
Resolution: Fixed
> FastByteArrayOutputStream is never downsized
> ---------------------------------------------
>
> Key: JAMES-3745
> URL: https://issues.apache.org/jira/browse/JAMES-3745
> Project: James Server
> Issue Type: Improvement
> Components: IMAPServer
> Affects Versions: 3.7.0
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.8.0
>
> Attachments: fastByteArray.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I started studying production heap dump in an effort to reduce the per user
> memory footprint. In conjunction with issues discussed in JAMES-3740 I found
> that in FastByteArrayOutputStream, upon writing a long line this buffer is
> sized up and never sized down.
> We can end up with 60KB+ memory allocated per user... Forever.
> While the impact is not as huge as the one described in JAMES-3740 yet for
> James deployment with a high connection density this could be non neglictible
> (100s MB of RAM).
> Furthermore given the long lived lifecycle of this buffer (connection) it is
> very likely to be promoted to the old gen, which could build up to eventually
> get long GC pauses.
> Suggestion: create a new IMAP composer for each request, 2 -> 64KB allocation
> is anyway neglictibe, likely cheaper than the lookups to get them back! We
> will thus allocate more memory, yes, but only for short lived durations, wich
> JVM GC is really good at.
> IMO it is so easy to avoid this unwanted behaviour that it would be sad not
> to do it.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
