High resident memory size when creating in-memory db

Question

Capsule summary: an in-memory db created with a cache size of 8 Gb reports a resident size of 2 Gb without any data stored in it.
Details:
We have a need for creating an entirely "in-memory" database, i.e. without a backing file store.The application in question will be writing to and reading from the db frequently, and there is no need to incur the penalty of writing out to disk.
I read the white paper "Writing In-Memory Applications" published by Oracle, and modified our db creation code accordingly. More or less all I did was to allow "open" to be called with a NULL instead of file name.
This seems to work just fine, in that no file is created, and both writing and querying seem to work correctly. However, the resident memory size, even without anything written to the database, seems inordinately high. For example, if I set the cache size to be 8 Gb (the size of physical memory on my Linux FC11 machine), the resident size reported by "top" is 2.0 Gb:
Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.7%us, 0.3%sy, 0.0%ni, 98.3%id, 0.6%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8114752k total, 8054072k used, 60680k free, 45344k buffers
Swap: 11717624k total, 204896k used, 11512728k free, 3977788k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12827 rao 20 0 2243m 2.0g 9.9m S 0.0 26.0 0:01.53 pypix
Running strace on the process shows that there are three calls to mmap as soon as "open" is called, one of them being responsible for a majority of the allocation.
Is this expected behavior? The documentation explicitly states the following:
"... Note that the size you specify for your cache is actually a maximum size; DB will only use memory as required so if you specify a cache size of 1 GB but your data set is only ever 10 MB in size, then 10 MB is what the DB will use...."
This does not appear to be consistent with what I am seeing.
Any ideas on what I might be doing wrong?
Thanks in advance.

Answer 1

Have you checked what script is causing the issue ? anything from application ? and OLAP things running on this instance ? how many sql instances are running ? anyother application like sharepoint etc runinning on this host ?
Check If your SQL Server instance encounters the following conditions then there is a possibility of
Non-yielding scheduler (SQL Server 2005 and above for the first occurrence. This is equivalent to a 17883 dump in SQL Server 2000.)
Non-yielding resource monitor (SQL server 2005 and above for the first occurrence)
Non-yielding IOCP listener (SQL server 2005 and above for the first occurrence)
Deadlocked Schedulers (SQL server 2005 and above. This is equivalent to a 17884 in SQL Server 2000.)
Exceptions/Assertions
Database Corruption
Latch Timeout
Other conditions (eg: when DUMPTRIGGER is used to generate a dump for a particular exception)
http://www.sqlskills.com/BLOGS/PAUL/post/How-to-download-a-sqlservrpdb-symbol-file.aspx
http://support.microsoft.com/kb/311503
http://blogs.msdn.com/b/sqlcat/archive/2009/09/11/looking-deeper-into-sql-server-using-minidumps.aspx
Diagnose and Correct Errors 17883, 17884, 17887, and 17888
http://technet.microsoft.com/en-us/library/cc917684.aspx
Raju Rasagounder Sr MSSQL DBA