This page considers general tactics to help identify the source of memory limitations. In some cases, you may find that the application really does need more memory to run to completion. In others, you may find that a simple change to machine configuration, the mathematical model, the code that expresses the model, or ILOG CPLEX parameter settings will drastically reduce memory use, enabling your application to run more efficiently.

Memory errors in an ILOG CPLEX application typically fall into one of four categories:

Unexpected memory limits imposed by the operating system
An application may run out of memory unexpectedly because it cannot access all available memory on the computer. Possible reasons include:

• Limits on individual accounts or processes. Use the 'ulimit -a' command on UNIX or Windows Task Manager to check resources available for the individual account.
• Memory restrictions imposed by the compiler, linker, or operating system. For example, programs compiled and linked as standard 32-bit applications using default options can access no more than 2 gigabytes of memory, regardless of the amount of memory available. 32-bit applications on AIX have a default of 256 MB of allocated memory.   When a 32-bit application imposes a memory limit on memory that ILOG CPLEX uses, consider moving to a 64-bit operating system instead.
• Miscellaneous factors, such as multiple users on the computer or overly restrictive virtual memory configurations.

Tools such as 'top' and 'vmstat' on UNIX or Windows Task Manager can help you isolate these potential problems. Using a program that simply allocates, initializes, and frees arbitrary amounts of memory can help determine whether your problem is specific to your ILOG CPLEX application or if it is a general issue.

Unexpected memory consumption by the application that calls ILOGCPLEX
When an ILOG CPLEX based application runs of memory, you should find out whether the majority of the memory consumption occurs inside ILOG CPLEX or in the invoking application. If ILOG CPLEX inherits very little free memory from the application, it will probably issue an “out-of-memory” error message. Potential memory reductions are more likely to occur in the code surrounding ILOG CPLEX. The following tactics can help you assess the distribution of memory use among various parts of the application:

• Monitor the memory consumption of the program as it proceeds, detecting spikes in use to isolate the parts of the application that may consume excessive memory.
• Compare your ILOG CPLEX application’s memory use with interactive ILOG CPLEX or a simple example program on the same model. This will help you determine how much memory ILOG CPLEX will need to solve the model. Contrast that amount with the total memory use of your application to determine whether it is reasonable to use memory outside of ILOG CPLEX.
• Use tools like Purify, Insure, Bounds Checker, and Valgrind to check for memory leaks in the application.
• Be certain that you have solved the intended model. If the modeling code inadvertently creates a much larger model, memory use may also increase. By writing out a SAV file of the model and reading it into interactive ILOG CPLEX, you can examine the model statistics (turn the datacheck parameter on and use the display problem stats command) to verify they are consistent with the intended model.

Unnecessary memory use during the modeling phase
When writing code to build the model for ILOG CPLEX, do not create or retain problem data that is no longer needed after ILOG CPLEX has received or extracted the model. In the C API, ILOG CPLEX makes copies of arrays passed to problem-creation or modification routines, so you can free the corresponding arrays in your programs if they are no longer needed. In C++, inadvertent calls to copy constructors or lazy copy mechanisms can result in unnecessary memory use. In Java, using the class IloLPMatrix (or the equivalent method of ILPMatrix in .NET) has the potential to save memory during model generation.

Excessive memory use by ILOG CPLEX optimization routines
If you have determined that most memory use occurs in one of the ILOG CPLEX optimization algorithms, determine whether memory use by ILOG CPLEX is reasonable based on the problem size.

• For linear programs, allow one megabyte per thousand constraints (or one gigabyte per million constraints).
• For integer programs, no simple formula exists since memory use depends on the size of the branch and bound tree. The estimate for linear programs still provides a lower bound.
• For quadratic programs, add the number of constraints and variables, then allow one megabyte for every thousand.

If these estimates reveal that the requirements of ILOG CPLEX dramatically exceed the available memory on the machine, either add more memory to the machine or switch from a 32-bit to a 64-bit operating system. If the ILOG CPLEX requirements barely exceed available memory, you may be able to reduce ILOG CPLEX memory use by changing some parameter settings, including the following:

Note: Refer to the ILOG CPLEX user manual for additional information.

• Users of ILOG CPLEX 10.0: When you turn on the ILOG CPLEX memory emphasis parameter, ILOG CPLEX will set various internal parameters to conserve memory. This setting may result in a slight increase in run time, but when solving linear programs with an ILOG CPLEX simplex method, this setting limits solution information that requires a factorized basis (i.e., sensitivity analysis or the basis condition number). Users of ILOG CPLEX 9.1 and earlier do not have access to the memory emphasis parameter, but can attain many of the same benefits by turning on the pre-solve compress, barrier out of core, or simplex FinalFactor parameters (consolidated into the memory emphasis parameter for version 10.0). Turn pre-solve off as a last resort. This will save more memory, but can result in dramatic solve time increases in for many models.
• For linear and quadratic programs, consider using a different algorithm, since each algorithm uses memory differently. Turn the pre-solve dual parameter on to save memory. The memory required to solve the dual model may differ significantly from that required to solve the primal.
• For mixed integer programs, the size of the branch and cut tree dominates memory use beyond that required to solve the initial LP relaxation. Anything you can do to reduce the size of the branch and cut tree will help. Improving the run time will often also reduce memory. See the MIP performance tuning page for more information. You should also consider setting the node file parameter to 3 to write the nodes to disk, in order to save memory with minimal overhead.
• If all else fails, create an equivalent formulation of the model that requires less memory.