Are there Memory Leaks on Linux/Progress 10.1C
- Thread starter ERobinson
- Start date
We are moving to a SUSE Linux 64 bit solution that will run about 300 users. On our initial tests, memory seems to be allocated to memory--outside of the database buffers--and never released (according to the top command). The memory is also immediately "cached". Do you show the same results?
MaximMonin
Member
Top shows private memory consumed by process and shared memory consumed by db server. Bioth attached to 1 process.
TomBascom
Curmudgeon
The short answer -- no.
Longer answer...
There are several possibilities here:
1) if "memory seems to be allocated to memory--outside of the database buffers" seems pretty confused. When you allocate -B you are allocating shared memory to be used for database buffers. It is still memory so it is accounted for, by the OS, as memory. The "buffers" that TOP shows are file system buffers. Those are a different thing entirely and unrelated to -B or shared memory.
Shared memory shows up in the size of every process that connects self-service to that database. If you simply sum the sizes of all the processes the total will appear to be far larger than available RAM. But that is just an accounting illusion. There is no good generic way to look at process memory size excluding shared memory.
Shared memory is not released until every process using it terminates. But that isn't a leak -- that's what is supposed to happen.
- or -
2) Are you looking at "cached" and thinking that it is evidence of a memory leak?
It is not. It is perfectly normal for Linux (or any modern OS) to behave in this way. Basically the OS has no better use for the memory so it hangs on to it on the theory that you just might possibly ask for it again sometime soon. If you were to actually need it for some other purpose the OS will hand it over.
Longer answer...
There are several possibilities here:
1) if "memory seems to be allocated to memory--outside of the database buffers" seems pretty confused. When you allocate -B you are allocating shared memory to be used for database buffers. It is still memory so it is accounted for, by the OS, as memory. The "buffers" that TOP shows are file system buffers. Those are a different thing entirely and unrelated to -B or shared memory.
Shared memory shows up in the size of every process that connects self-service to that database. If you simply sum the sizes of all the processes the total will appear to be far larger than available RAM. But that is just an accounting illusion. There is no good generic way to look at process memory size excluding shared memory.
Shared memory is not released until every process using it terminates. But that isn't a leak -- that's what is supposed to happen.
- or -
2) Are you looking at "cached" and thinking that it is evidence of a memory leak?
Code:
top - 07:55:35 up 363 days, 22:22, 2 users, load average: 9.06, 9.17, 9.52
Tasks: 616 total, 2 running, 614 sleeping, 0 stopped, 0 zombie
Cpu(s): 13.7%us, 1.8%sy, 0.0%ni, 47.8%id, 36.6%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 4049052k total, 4019532k used, 29520k free, 35972k buffers
Swap: 2104472k total, 156k used, 2104316k free, [b]2315064k cached[/b]
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
...It is not. It is perfectly normal for Linux (or any modern OS) to behave in this way. Basically the OS has no better use for the memory so it hangs on to it on the theory that you just might possibly ask for it again sometime soon. If you were to actually need it for some other purpose the OS will hand it over.
Similar threads
- Locked
- The Progress Team
- Progress Blog
