We have a Linux system (kubuntu 7.10) that runs several CORBA Server processes. Server software uses glibc libraries to allocate memory. Linux PC has 4G physical memory. Swap is disabled for speed reasons.
After receiving a request for data processing, one of the server processes allocates a large data buffer (using the standard C ++ operator "new"). The size of the buffer depends on several parameters, but usually is about 1.2 GB. It can be up to about 1.9 GB. When the request is complete, the buffer is freed using "delete".
This is great for multiple consecutive requests that allocate buffers of the same size or if the request allocates a smaller size than the previous one. The memory seems to be free — otherwise, buffer allocation attempts will ultimately fail after only a few requests. In any case, we can see that buffer memory is allocated and freed for each request using tools such as KSysGuard, etc.
The problem occurs when a request requires that the buffer be larger than the previous one. In this case, the operator "new" throws an exception. It is as if a memory free from the first allocation cannot be reassigned, even if there is sufficient free physical memory.
If I killed and restarted the server process after the first operation, then the second request for a larger buffer will succeed. those. killing the process seems to completely free the freed memory back to the system.
Can someone give an explanation as to what could be happening here? Could this be some kind of fragmentation problem or map table size? I am thinking of replacing new / delete with malloc / free and using mallopt to configure how memory is released to the system.
BTW - I'm not sure if this is relevant to our problem, but the server uses Pthreads, which are created and destroyed with every processing request.
source
share