Hi Sandeep,
alright - this is a very long list of question and I don't have time to address all of it right now.
Therefore I'll start with just some of the questions.
As the majority of this topic really is not so much about SAP HANA but general Linux memory management, please make sure to educate yourself about this as well.
This paper is an excellent source for this (maybe a bit too detailed for your questions):
What Every Programmer Should Know About Memory http://www.akkadia.org/drepper/cpumemory.pdf
2. Resident memory vs Virtual memory:
When (part of) the virtually allocated memory actually needs to be used, it is loaded or mapped to the real, physical memory of the host, and becomes “resident”.
a. Virtual memory- Swap space=Resident memory is right way of understanding?
b. Doesn't Resident memory also mean Allocated memory in use? i.e. part of HANA memory pool in use?
I think you misinterpret the term "virtual memory" here. For Linux this simply is the size of the address room that the process is currently reaching out to.
Let's say the process accesses some data at memory address 0001, say 10K. These 10K would reside in memory between the addresses 0001 and 0011, OK?
Now, the process loads 20K to address 1000, just because e.g. that's the place in memory where you need to put your graphics data if it should be displayed. Still with me? Good!
Now our virtual memory spans from 0001 till 1020 as we've used addresses within this range.
The virtual memory manager of Linux needs to take care of presenting these memory areas to our process as if we would be the only process in the system and that the data would actually be at these places.
On the other hand, how much memory did we use? 10K + 20K = 30K.
Seen from the other side, these 30K are now not available to any other process anymore.
We've used this resource.
And if you follow this idea of "what did we take away from other processes?" then you see that theresident size needs to include all the memory that is reserved for our process.
This includes of course the executable code of the process itself.
It's process structures like the stack.
And of course the actual data the process works on.
If you want to, the resident size is about resource consumption while virtual size is rather a Linux internal management figure (and much less important since we have 64-Bit address room).
7. HANA Code and stack comprises of?
Code = the indexserver executable + all loaded libraries and shared objects.
In Commodore C64 terms: it's what you get into memory when you type in LOAD "file name",8,1
Stack = the information about the current state of processing for the process. What threads are created, what files are open, at which address it the current execution for each thread? Stuff like that.
More about that: http://lmgtfy.com/?q=linux+process+code+and+stack
5. I observe that during my tests HANA CPU consumption increases due to some reason not very clear to me.
a. I briefly know that it is due to some background processes like delta merge etc… Any pointers/links on the reason for the same?
b. How to identify and confirm this?
c. Is there any way to avoid this during my test execution?
Hmm... this one has nothing to do with memory management at all and sticks out from the other questions.
CPU usage is likely increased by... tatataaa... your usage of SAP HANA.
That's the whole point of SAP HANA that you run a query and our software tries to throw as much parallel CPU time at the task as possible to return the query as fast as possible.
You may want to check the "Threads" overview tab in the SAP HANA studio if the CPU usage stays at a high level for a longer period of time.
Ok, my time's up for today and I guess you already have a bit to read and think about.
- Lars