Virtual Threads: Understanding memory usage on Linux
Popularity Report
 |
|||
|
|||
|
|||
|
|||
|
|||
|
Rank
URL Tag Cloud
- linux
- , memory
- , ps
- , usage
- , shared
- , misc
- , process
- , sysadmin
- , ram
- , libraries
- , administration
- , allocation
- , virtualthreads
- , .so
- , toread
- , reference
- , opensource
Public Sticky notes
What it is really doing is showing how much real memory each process would take up if it were the only process running.
Highlighted by http://www.diigo.com/profile/
Linux is able to use a great trick: it will load a single copy of the shared libraries into memory and use that one copy for every program that references it.
For better or worse, many tools don't care very much about this very common trick; they simply report how much memory a process uses, regardless of whether that memory is shared with other processes as well.
For better or worse, many tools don't care very much about this very common trick; they simply report how much memory a process uses, regardless of whether that memory is shared with other processes as well.
Highlighted by http://www.diigo.com/profile/
we'll use the pmap program (with the -d flag):
Highlighted by http://www.diigo.com/profile/
especially true when you deal with programs that create a lot of identical children processes, like Apache. ps might report that each Apache process uses 10 megabytes of memory, when the reality might be that the marginal cost of each Apache process is 1 megabyte of memory
Highlighted by http://www.diigo.com/profile/
If you run KDE for your desktop, but mostly use Gnome applications, then you are paying a large price for a lot of redundant (but different) shared libraries. By sticking to just KDE or just Gnome apps as much as possible, you reduce your overall memory usage due to the reduced marginal memory cost of running new KDE or Gnome applications, which allows Linux to use more memory for other interesting things (like the file cache, which speeds up file accesses immensely).
Highlighted by http://www.diigo.com/profile/
A well-behaved app can still end up eating many, many MB of memory that it isn't actually using.
For example, say the app need to make a number of large allocations for some temporary working space for some operation. It also needs to allocate some book keeping information (undo history, for example) and other bits of info to store/utilize the computed data.
When allocations are made, the heap grows. However, the heap can only shrink by truncation. This is, the program can only release memory back to the OS by shrinking the heap, not by cutting it into pieces. So if the app makes many allocations, and frees only some (or even most) of them, its heap may end up looking like:
X: free memory
U: used memory
UUUXXXXXXXXXXXXU
That's four pages of used memory and 12 pages of unused memory that can't be freed.
For example, say the app need to make a number of large allocations for some temporary working space for some operation. It also needs to allocate some book keeping information (undo history, for example) and other bits of info to store/utilize the computed data.
When allocations are made, the heap grows. However, the heap can only shrink by truncation. This is, the program can only release memory back to the OS by shrinking the heap, not by cutting it into pieces. So if the app makes many allocations, and frees only some (or even most) of them, its heap may end up looking like:
X: free memory
U: used memory
UUUXXXXXXXXXXXXU
That's four pages of used memory and 12 pages of unused memory that can't be freed.
Highlighted by http://www.diigo.com/profile/
Public Comment
on 2006-08-01 by aquilax
on 2006-10-25 by notre1