Leak mem in TimesTen 6.0.3. Could you help me?

Question

Hi,
I've got some problems when using TimesTen version 6.03. I've built TTClasses with CC compiler of Sun Studio 11 and using these libs for building my application. All of them have been done on Sunsolaris 10 OS on a Sun Fire V440 server with sparc architecture. Everything seems OK except leak mem detection. This application must run 24h per day and the used memory increases so fast.
I use select, update, delete command using class TTCmd in the application and I think that's the problem of leak memory.
I used Insure++ 7.0 for pinpointing where the leak is but no result found.
Anh I tried a tool of TimesTen whose name is ttsql and the leak mem ditection was still found. After selecting or deleting about 100000 records, I can see the mem (via top comand) which ttsql used increase significantly.
My application and ttisql both used a DSN to connect to DataStore. I tried to change the type of connection in 2 ways: direct and client-server but this problem still occur.
So does anyone have got the same problem like that? Are TimesTen's libs (TTClasses libs) not safe.
Please tell me how to solve it. Thanks for advanced
Best regards,

Answer 1

TimesTen is used in thousands of 24/7 mission critical applications around the world. I'm confident that TimesTen itself does not leak memory. Please note that "top" is not the proper tool to use to look for memory leaks, especially for a program like TimesTen.
"Top" will over-report the amount of memory consumed by TimesTen in at least two ways.
1. Top will report that memory used by the operating system to cache recently-read files is not "free". Top is actually correct - the memory isn't "free"; it's caching a recently-read file in case some user reads it again. But that's what the operating system is supposed to do, it's not a bug. If the memory is needed for something more important then the OS will do the right thing.
If you have a large TimesTen data store, then starting it up will result in a large checkpoint file being read. This will change the "free" memory reported by top, but isn't a problem at all.
2. Top doesn't understand shared memory. Suppose you have a 1 GB TimesTen datastore, which is in shared memory. That datastore will take up 1 GB of memory. But "top" will report that 1 GB of memory in the "size" of every application that connects to it! So if you have 10 applications connected to TimesTen, "top" will report that each of them is using 1 GB of memory. This is not true, and "top" is simply broken in how it accounts for shared memory in this way.
SO, if you are looking for memory leaks, please put away "top". It's not the right tool to use.
I did a simple Google search for "Sun Studio Leak" and found a number of hits showing how to use the tools that Studio includes for doing leak detection. I'm sure that they will provide you with more accurate and finer grained debugging facilities than "top".
Hope that helps!
...Sam Drake / Architect / Oracle TimesTen In-Memory Database