Memory usage in Windows Server

One possibility is that the process requested more than the remaining amount of memory. I see this happen often with the version of malloc that I program against. It grabs an initial block of memory from the heap. When that all gets allocated, it grabs a second block the size of the first. When that gets used up, it requests a block that size of what is in use, doubling the size of memory under management each time. Eventually, it requests more than is available, even though all memory isn't in use and my program might not ever need that much. Alternatively, there could be enough memory available, but not in a single piece due to fragmentation, so malloc can't return a single piece large enough so it fails.

How many cores? How many processes does CPLEX use? Is every bit of everything CPLEX uses true 64 bit code? Spidey sense tingles with 4 worker and 1 aggregator processes each hitting their 4G 32 bit memory limit minus 4 or 5 chunks of memory that aren't actual allocated memory but shared mapped memory for IPC. 4 workers @ 4G plus the master at 4G but 4x128M of that is shared to communicate with the workers == ~19.5G. (could also be a 4G per process limit with 5 processes instead of a 64/32 bit limit).

Thanks all - solution is a bit of everything suggested here. CPLEX is absolutely 64-bit throughout. The workaround seems to be a suite of memory efficiency routines of which workmem is one, and which effectively stop a progress trace being held in RAM. Forcing the trace to be written to disk is dog slow, but it does at least run. It's parallel code, and it does look as though there's a preemptive survey of available RAM to allow graceful failure ahead of one core actually failing, which explains the odd limit of RAM observed - it's not an OOM error so much as a HAL-style warning. Much obliged!