Quote:
Virtual swap = ram + disk. (shown in swap -s)
Quote:
Originally Posted by
javanoob
- Virtual memory reservation does not take up physical space. (vmstat free still reflect as unused space, swap -l still reflect as free blocks)
- Virtual memory reservation is just a reserved amount and has nothing with the physical allocation of the ram / swap disk. In the sense that an allocated virtual memory area (non-shared) cannot be shared with another process, but the underlying physical ram could be randomly use by different processes at different time.
Please kindly let me know if my understanding thusfar is correct
More or less: yes. Still, you shouldn't use incorrect terminology because at some point - language is the "coagulated thought process" - it will be in the way of your understanding. There is no "virtual swap". There is "virtual memory", which is RAM + swap space(s). It is called "virtual" because to processes it looks like one contiguous address space. To running processes there is no difference between RAM and swap. There is just "memory". Only the operating system (to be precise: the part of it which manages memory) "knows" that RAM is faster than swap and therefore tries its best to keep the most possible of the most used process memory in RAM so that paging operations (swap in/swap out) happen as rarely as possible. A process can ask for the memory it allocates to be (and remain) in RAM, but it has no way to ascertain that this is the case.
Memory reservation is in fact like reserving a table at a restaurant like jiliagre has so astutely explained: you call and say you want to come tomorrow at 20:00, table for four. They will either take or refuse your reservation but if they take it then the table cannot be used by anybody but your party, regardless of you showing up (using the table) or not. A process can reserve (=allocate) memory. Directly it will have no control over where this memory will be: RAM or swap. It can ask the OS for it being in RAM (database software does this regularly, i.e. Oracle allocates its SGA as "not swappable"), but it will have to take the OS's word for it that this in fact has happened.
Quote:
Originally Posted by
javanoob
What could have contributed to the 3GB swap disk ?
Could it be at some point of time, i am running low on physical ram and swap/paging need to be done ?
When does physical space used in swapdisk be release ?
It is gradually increasing (slow.. but like 5-10MB more of swapdisk used per week) - that is the worrying part.
There is "early" and "late" swap allocation as i have explained up in this thread. I do not know your application but maybe it uses shared memory and allocates it via the
shmget() system call. This function can reserve swap space (see the
SHM_NORESERVE flag) along with the allocated memory so that the process is guaranteed to have swap space should the necessity ever occur to swap it out. Alternatively it may use memory mapped I/O, the
mmap() system call has an analogous functionality. If this is the case it might be sloppily programmed and thus create a memory sink: that is: memory is allocated but instead of giving it back the process "forgets" about it and allocates new memory the next time it performs the same function. (The sad truth is that this is a very common phenomenon.) This could account for the slow increase of allocated swap over time.
But even then, "swap allocated" is not the same as "swap used" which in fact comes down to: "pages swapped out" and "pages swapped in". This is why it is useless to look at
swap -l's output. This only tells you if you need to increase the amount of available swap space. It will not tell you how much is actually written to/read from the swap. This is only told by the pi/po counter of
vmstat (and all the other counter discussed above in detail).
I hope this helps.
bakunin