We are running into an issue with JuMP models run in an API that are leading to our servers running out of RAM. Oddly, it does appear that the memory consumption plateaus after some time/iterations. Also, it can be recreated outside of the API. A MWE is: using REoptLite, JuMP, CPLEX for _ in rang…

[image] nlaws: Unfortunately, all solutions so far (using 1 THREAD or limiting the solver’s memory use) will lead to slower jobs, which negates 1,000’s of hours of work spent making the app faster. Calling GC manually, was not a solution?

No, we deployed GC in the API a few weeks ago and it has not solved the problem. You can see in the charts above that is just slows the memory growth.

Per my latest test in https://github.com/jump-dev/Xpress.jl/issues/128 This happens in linux but not in windows.

[image] joaquimg: There is no Julia code on threads, right? perhaps callbacks? That is correct: our app does not use Threads.

[image] joaquimg: Have you already opened issues with FICO/IBM? I have not because testing with FICO Xpress alone does not lead to memory growth (see previous posts).

[image] nlaws: I have not because testing with FICO Xpress alone does not lead to memory growth (see previous posts). My understanding is that in the Xpress “alone” case you were calling is as a subprocess, which opens and completely closes a process right after it finishes. In terms of juli…

Sorry, what I meant by Xpress “alone” is this case: [image] nlaws: The results indicate that the memory leak is not a Mosel issue (422 iterations completed before I killed it): in which I used a shell script to loop over mosel knapsack.mos

[image] joaquimg: It would be nice to see this graph: Including a version with THREADS=1 . So that we can compare with xpress w/GC It might be that THREADS=1 simply allocates less that free number of threads. Then the problem would be GC only. Here is the chart with THREADS=1: what can we …

[image] nlaws: I have not found a reason to contact FICO yet as I have not identified any issue with Xpress It doesn’t hurt to tell them you would be interested in commercial support for Xpress.jl. They may have suggestions for parameters to set to help with the memory usage. Here is the ch…

[mem_xpress_reopt_GC_finalize_backend] The memory growth with for i in range(1,stop=500) m = direct_model(Xpress.Optimizer(OUTPUTLOG = 0)) r = run_reopt(m, "outage.json") finalize(backend(m)) GC.gc() end starts lower and is slower than any thing tried so far, but still appears to…

Memory consumption growth with many large MILP's in JuMP

Specific Domains Optimization (Mathematical)

odow July 15, 2021, 8:55pm 56

See Does the GC respond based on memory pressure?. Seems like @ericphanson is having similar troubles.

Topic		Replies	Views
Excessive memory usage when adding millions of variables to a JuMP Model Optimization (Mathematical) jump , gurobi	12	468	July 12, 2025
How to manage memory when using JuMP+Gurobi? Optimization (Mathematical) question , jump , gurobi	8	106	April 22, 2026
JuMP, excessive memory usage? Optimization (Mathematical) question	16	3357	February 14, 2018
Is JuMP.@variable slow when the number gets large? Optimization (Mathematical) question , jump , gurobi	12	216	April 5, 2026
Optimal model creation (and garbage collection) Optimization (Mathematical)	20	1594	December 7, 2021

Memory consumption growth with many large MILP's in JuMP

Related topics