I'm solving a very large MILP using Gurobi -- I typically let it run for days without it proving the optimum. I recently switched to CPLEX because I wanted to try their new automated Benders feature. I was surprised however, that within a day or so, CPLEX runs out of memory (I haven't tried the Benders feature yet). This never happened when I tried solving the model with Gurobi (even after running it once for a week!). I understand from reading about memory issues with CPLEX that this is because the branch and bound tree has gotten very large. Still, I was rather surprised because I'm running this on a linux server with 240 GB RAM (24 threads, 10 GB/thread) and thought that would be sufficient, regardless.

Is there something that Gurobi does behind the scenes that takes care of this memory issue that I need (can?) turn on in CPLEX? I've seen suggestions to turn on the memory emphasis parameter, allowing CPLEX to store nodes in a temporary file on disk, reducing the number of threads, and setting the VarSel parameter to strong branching.

Has anyone used these approaches and have any recommendations? (Should I just go back to Gurobi?)

Thanks!

asked 03 Feb, 09:42

leruckle's gravatar image

leruckle
254
accept rate: 0%

How did you implement your model in CPLEX? Are you using OPL, one of the programming language APIs, or just the MPS file?

(03 Feb, 10:30) Ehsan ♦

I implemented both using their Java APIs. Also, when implementing, I try to avoid a lot of 0 coefficients because I read that those still get stored.

(03 Feb, 10:33) leruckle

It's possible that you have a memory leak in your java code for CPLEX. You should check that before doing anything else. Also, You could export your model in Gurobi as a MPS file and solve it using CPLEX to make sure that the huge memory consumption is not due to CPLEX (although, I highly doubt that).

(03 Feb, 11:00) Ehsan ♦

Thanks for your suggestions. The memory consumption is low though until CPLEX has been branching for a while. It starts off fine, but then the node file gets huge -- after about 30 minutes, the tree goes from 40 MB to 200 MB in about 3 minutes and continues to quickly rise from then on, after 5 more minutes it's 1.6 GB. That's why I thought it was something to do with CPLEX's settings or handling of the node file. Would a memory leak in the way I set things up contribute to that increase?

(03 Feb, 11:46) leruckle

1) If memory consumption goes high drastically after model generation, I don't think you would have a memory leak. I suggest that you test the MPS file to see this happens for that too.

2) I don't think there is any major parameter setting that would affect the memory consumption. The node file parameter should just slow down the solution process as it write the B&B tree on the disk.

3) If you could post the CPLLEX log, that might help us determine the cause.

(03 Feb, 12:43) Ehsan ♦

It's hard to compare the two solvers, both because their internals are different and because their default behaviors may differ. (I've never used Gurobi, so I'm speculating here.) There are parameters you can set in CPLEX to limit the size of the node tree in RAM, compress the tree in RAM, swap parts of the tree out to disk, etc. I think the first thing I would do is make sure that the tolerances for constraint satisfaction, and for how close a node's objective must be to the incumbent to let the solver prune it, are the same across both solvers. After than, maybe run the CPLEX tuning tool on a modest size instance to get recommendations for parameter settings. If CPLEX still runs low on memory, you can also fiddle with those memory settings I mentioned, and maybe mess with the backtrack setting to move the search closer to depth-first (which conserves memory).

It doesn't sound like a memory leak. More likely, the bound is improving slowly, making it hard for CPLEX to prune nodes. If a lot of nodes have similar objective values, and you're doing something close to best bound search, the tree can get fat quickly.

One other thing: if your model contains symmetry (which can make the bound tough to tighten), you might either reformulate to reduce the symmetry or ratchet up CPLEX's symmetry reduction setting.

link

answered 03 Feb, 18:57

Paul%20Rubin's gravatar image

Paul Rubin ♦♦
14.5k412
accept rate: 19%

Thanks, Paul, for your suggestions. I implemented some of the parameters that you mentioned and that seems to have helped, though to be perfectly honest since I tried several in one go, I'm not sure exactly which was responsible. I tried the tuning tool too, but for modestly-sized problems, it didn't have any suggestions outside the default. I appreciate your explanation of why the tree might be getting very big/fat. I know that the model I"m working with has massive degeneracy, which is probably contributing to its difficulties.

(05 Feb, 10:37) leruckle

In case it helps anyone with a similar problem in the future, these are the parameters I used:

CPXPARAM_MIP_Strategy_File 3 # store node file on disk and compress

CPXPARAM_MIP_Strategy_VariableSelect 3 # strong branching

CPXPARAM_Preprocessing_Symmetry 4 # highly aggressive symmetry breaking

(05 Feb, 10:40) leruckle

Primal degeneracy can slow down the rate at which nodes are processed, but I don't think it is likely cause "weight gain" in the tree. Symmetry will definitely contribute to the size of the tree. Dual degeneracy (and thus multiple primal optima) might, I think, cause slow improvement in the bound.

(05 Feb, 10:42) Paul Rubin ♦♦

Could you please contact me at bo.jensen (at) dk (dot) ibm (dot) com, then we can look at your problem and help you. Please send a log file and if possible share the problem instance.

Thank you !

link

answered 05 Feb, 03:18

Bo%20Jensen's gravatar image

Bo Jensen ♦
5.0k2919
accept rate: 14%

Hi Bo, as it currently stands, my model and log files have a lot of proprietary data in them so unfortunately, I can't send them out. I may be able to get you one with a non-proprietary data set in a couple days.

(05 Feb, 10:44) leruckle

Hi Leruckle, the parameters you changed is a good starting point to reduce memory footprint, let me know if you get a non-proprietary version to share.

(06 Feb, 09:57) Bo Jensen ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×192
×22

Asked: 03 Feb, 09:42

Seen: 278 times

Last updated: 06 Feb, 09:57

OR-Exchange! Your site for questions, answers, and announcements about operations research.