Mitigating HiGHS out-of-memory

[Gbtank]

Hi HiGHS team,

I am running HiGHS on a K8S cluster with typically with 1vCPU & 2 GB RAM so we can cram as many instances of HiGHS into one node as possible.

As a result, I'm running into out-of-memory errors for particularly "hard" MIP problems where the solver has to explore large B&B trees.

I am looking for the best way to mitigate this risk. I believe that Gurobi has the option to write notes to a file on disk, if exceeding the memory limit for nodes: https://docs.gurobi.com/projects/optimizer/en/current/reference/parameters.html#nodefiledir (if I understand the reference correctly)

Does HiGHS have a similar mechanism? I saw this discussion: #1194 which led to the implementation of an option to write the incumbent solution when out-of-memory.

Would you advise turning on that option and then warm starting the OOM instance using the same incumbent to carry-on the optimisation?

Thanks in advance :)

[Opt-Mucca]

@Gbtank I don't believe having an option to write the branch-and-bound tree to file to save space during the solve process is going to happen for a long while. It's truly a fair bit of work, and we'd need to introduce memory tracking throughout the entire code base.

I do think saving the best incumbent to file and then re-optimising will give more chances of solving the instance within the memory limit. Potentially even trying a new seed or two if you're confident that the solve has stopped because of memory limits.

[jajhall]

As @Opt-Mucca says, we're not going to have anything like Gurobi's option to "write notes to a file on disk" for the foreseeable future.

Since #1194, we've also added callbacks to supply improving solutions to the user, which is neater than saving to a file

Note that in no sense can supplying the best incumbent as an initial solution be described as "warm starting the OOM instance ... to carry-on the optimisation". You're just giving a good initial primal bound, with all dual bounding information from the previous run having been lost. Even if you give the optimal solution to a MIP as a starting solution, it can be no faster than having no starting solution, as checking optimality of a feasible solution to a MIP is as hard as solving it.

The suggestion of using a new seed or two is a good one.