Answer
On a single MPS worker the memory ceiling during a hot-deployment is the Java heap configured for the server, not a per-archive limit enforced by the MATLAB Compiler Runtime. With R2020b+ hot-deployment, a new archive version is loaded into the same JVM heap that is hosting the previous version. The old version remains reachable until all in-flight requests that started on it finish and MATLAB’s internal reference counting releases it. There is no built-in configurable threshold that forces immediate release of the previous archive once the new version is active.
Confirmed facts
- The effective memory ceiling is the JVM heap size set via MATLAB Production Server JVM options, typically -Xmx in server.conf. The MCR does not impose a separate hard limit.
- During transition both archive versions can coexist in the same worker heap until the old version’s reference count drops to zero.
- Release timing depends on MATLAB internal reference counting and JVM garbage collection cycles, not on a user-settable timeout or memory pressure threshold.
- Workers complete in-flight requests on the old version before that version becomes eligible for cleanup. New requests are routed to the new version.
Likely explanation for peak usage
For memory-intensive archives with large static data or preloaded models, the overlap period can temporarily double peak memory usage on a worker. The risk is highest when the archive loads data at startup and keeps it resident for the lifetime of the version. JVM garbage collection pauses may increase during the overlap due to memory pressure. This behavior is consistent with the design of hot-deployment for zero-downtime updates, not a bug.
Verification steps for this case
- Check current JVM heap settings. Inspect server.conf for the -Xmx value and confirm it matches the expected capacity for the worker host.
- Monitor worker process memory during a deployment. Use OS tools such as ps or top to observe resident set size before, during, and after the archive swap.
- Review server logs for archive lifecycle messages, e.g., archive loaded and archive unloaded events, to correlate memory peaks with version transitions.
- Test with a representative large archive to measure the actual memory delta between versions on your configuration.
Assumptions: R2020b+ MPS, default hot-deployment behavior, and JVM heap as the limiting resource. Configuration changes to heap size require a server restart and affect all workers.
One diagnostic detail that changes the recommendation: what is the measured resident memory of a single archive instance under production load, and what -Xmx is currently set per worker? Without those numbers it is not possible to size the heap safely for the overlap period.
matlab