PSS/USS Linux-Android. Does Pss contain Uss? [duplicate] - linux

This question already has an answer here:
Android : PSS (Proportional Set Size) Calculation
(1 answer)
Closed 7 years ago.
I would like to ask you:
I understand that on Linux, there are process that have shared libreries, and for look this, we can use PSS because this give information about the shared libraries size. And Uss is private dirty memory of a process.
But my question is:
Pss doesn't contains Uss, it's only about the proportionally shared memory;
or
Pss = Uss + proportionally shared memory.
Which interpretation is correct?

Sorry, this question was already answered here:
Android : PSS (Proportional Set Size) Calculation
The "proportional set size" (PSS) of a process is the count of pages
it has in memory, where each page is divided by the number of
processes sharing it. So if a process has 1000 pages all to itself,
and 1000 shared with one other process, its PSS will be 1500

Related

how to know process working set size in linux /proc [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Process Working Set Info in LINUX
I am finding Working Set Size of process in proc folder
this link say that I can find working set size in /proc but I don't know how to know. I knew RSS is working set size but RSS is different from working set size can I know working set size using /proc/[pid]/statm?
I don't believe that /proc/[pid]/statm gives the WSS, or /proc/[pid]/status for that matter.
WSS is the number of pages a process needs in memory to keep "working".
RSS is the number of pages of a process that actually reside in main memory.
So RSS >= WSS. Meaning that RSS may include some pages that the process doesn't really need right now. Maybe it used those stale pages in the past.
From my understanding of linux internals, the kernel doesn't really keep track of the WSS on a per-process basis. WSS is too involved to track continuously and doesn't have an exact formula. RSS is simpler to calculate, so the kernel just reports that.
Note that if the sum of WSS of all processes is greater than or equal to the main memory size (i.e. the system is thrashing or close to thrashing) then RSS equals WSS because only the pages absolutely needed by a process are kept in the main memory. Got it?
RSS (resident virtual size) is how much memory this process currently has in main memory (RAM). VSZ (virtual size) is how much virtual memory the process has in total.
From your question I believe you're after virtual size, i.e. total memory usage.
Regarding statm - from Linux manpages:
proc/[pid]/statm
Provides information about memory usage, measured in pages. The columns are:
size (1) total program size
(same as VmSize in /proc/[pid]/status)
resident (2) resident set size
(same as VmRSS in /proc/[pid]/status)
share (3) shared pages (i.e., backed by a file)
text (4) text (code)
lib (5) library (unused in Linux 2.6)
data (6) data + stack
dt (7) dirty pages (unused in Linux 2.6)
So you need the first integer, which will return total page count used. If you however need in more readable output, status will provide information in kilobytes. For example:
rr-#burza:~$ cat /proc/29262/status | grep -i rss
VmRSS: 1736 kB
rr-#burza:~$ cat /proc/29262/status | grep -i vmsize
VmSize: 5980 kB
This means process 29262 uses 5980 kB, out of which 1736 resides in RAM.

How much stack space is typically reserved for a thread? (POSIX / OSX)

The answer probably differs depending on the OS, but I'm curious how much stack space does a thread normally preallocate. For example, if I use:
push rax
that will put a value on the stack and increment the rsp. But what if I never use a push op? I imagine some space still gets allocated, but how much? Also, is this a fixed amount or is does it grow dynamically with the amount of stuff pushed?
POSIX does not define any standards regarding stack size, it is entirely implementation dependent. Since you tagged this OSX, the default allocations there are :
Main thread (8MB)
Secondary Thread (512kB)
Naturally, these can be configured to suit your needs. The allocation is dynamic :
The minimum allowed stack size for secondary threads is 16 KB and the
stack size must be a multiple of 4 KB. The space for this memory is
set aside in your process space at thread creation time, but the
actual pages associated with that memory are not created until they
are needed.
There is too much detail to include here. I suggest you read :
Thread Management (Mac Developer Library)

differences between cached and buffered memory on Linux [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Linux memory: buffer vs cache
When using command like ps/free to monitor memory on a Linux box, we can see a statistic called buffered memory and another called cached memory. I have searched Internet but cannot find a consistent answer for their differences. Appreciate if anyone could give me any hints.
BTW: I am debugging a program's memory usage pattern, so understanding the concepts are useful for my development.
thanks in advance,
Lin
Buffers are the I/O buffers whereas cached is the page cache.

Calculating memory of a Process using Proc file system

I am writing small process monitor script in Perl by reading values from Proc file system. Right now I am able to fetch number of threads, process state, number of bytes read and write using /proc/[pid]/status and /proc/[pid]/io files. Now I want to calculate the memory usage of a process. After searching, I came to know memory usage will be present /proc/[pid]/statm. But I still can't figure out what are necessary fields needed from that file to calculate the memory usage. Can anyone help me on this? Thanks in advance.
You likely want resident or size. From kernel.org.
size total program size
This is the whole program, including stuff never swapped in
resident resident set size
Stuff in RAM at the current moment (this does not include pages swapped out)
It is extremely difficult to know what the "memory usage" of a process is. VM size and RSS are known, measurable values.
But what you probably want is something else. In practice, "VM size" seems too high and RSS often seems too low.
The main problems are:
Multiple processes can share the same pages. You can add up the RSS of all running processes, and end up with much more than the physical memory of your machine (this is before kernel data structures are counted)
Private pages belonging to the process can be swapped out. Or they might not be initialised yet. Do they count?
How exactly do you count memory-mapped file pages? Dirty ones? Clean ones? MAP_SHARED or MAP_PRIVATE ones?
So you really need to think about what counts as "memory usage".
It seems to me that logically:
Private pages which are not shared with any other processes (NB: private pages can STILL be copy-on-write!) must count even if swapped out
Shared pages should count divided by the number of processes they're shared by e.g. a page shared by two processes counts half
File-backed pages which are resident can count in the same way
File-backed non-resident pages can be ignored
If the same page is mapped more than once into the address-space of the same process, it can be ignored the 2nd and subsequent time. This means that if proc 1 has page X mapped twice, and proc 2 has page X mapped once, they are both "charged" half a page.
I don't know of any utility which does this. It seems nontrivial though, and involves (at least) reading /proc/pid/pagemap and possibly some other /proc interfaces, some of which are root-only.
Another (less simple, but more precise) possibility would be to parse the /proc/123/maps file, perhaps by using the pmap utility. It gives you information about the "virtual memory" (i.e. the address space of the process).

How do I find which process is leaking memory? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a system (Ubuntu) with many processes and one (or more) have a memory leak. Is there a good way to find the process that has the leak? Some of the process are JVMs, some are not. Some are home grown some are open source.
You can run the top command (to run non-interactively, type top -b -n 1). To see applications which are leaking memory, look at the following columns:
RPRVT - resident private address space size
RSHRD - resident shared address space size
RSIZE - resident memory size
VPRVT - private address space size
VSIZE - total memory size
if the program leaks over a long time, top might not be practical. I would write a simple shell scripts that appends the result of "ps aux" to a file every X seconds, depending on how long it takes to leak significant amounts of memory. Something like:
while true
do
echo "---------------------------------" >> /tmp/mem_usage
date >> /tmp/mem_usage
ps aux >> /tmp/mem_usage
sleep 60
done
I suggest the use of htop, as a better alternative to top.
In addition to top, you can use System Monitor (System - Administration - System Monitor, then select Processes tab). Select View - All Processes, go to Edit - Preferences and enable Virtual Memory column. Sort either by this column, or by Memory column
If you can't do it deductively, consider the Signal Flare debugging pattern: Increase the amount of memory allocated by one process by a factor of ten. Then run your program.
If the amount of the memory leaked is the same, that process was not the source of the leak; restore the process and make the same modification to the next process.
When you hit the process that is responsible, you'll see the size of your memory leak jump (the "signal flare"). You can narrow it down still further by selectively increasing the allocation size of separate statements within this process.
Difficult task. I would normally suggest to grab a debugger/memory profiler like Valgrind and run the programs one after one in it. Soon or later you will find the program that leaks and can tell it the devloper or fix it yourself.
As suggeseted, the way to go is valgrind. It's a profiler that checks many aspects of the running performance of your application, including the usage of memory.
Running your application through Valgrind will allow you to verify if you forget to release memory allocated with malloc, if you free the same memory twice etc.

Resources