Mike Rylander <mrylander@gmail.com> writes:
> To cut to the chase, here are
> some numbers for everyone to digest:
> total gnu ps resident size
> # ps ax -o rss|perl -e '$x += $_ for (<>);print "$x\n";'
> 5810492
> total gnu ps virual size
> # ps ax -o vsz|perl -e '$x += $_ for (<>);print "$x\n";'
> 10585400
> total gnu ps "if all pages were dirtied and swapped" size
> # ps ax -o size|perl -e '$x += $_ for (<>);print "$x\n";'
> 1970952
I wouldn't put any faith in those numbers at all, because you'll be
counting the PG shared memory multiple times.
On the Linux versions I've used lately, ps and top report a process'
memory size as including all its private memory, plus all the pages
of shared memory that it has touched since it started. So if you run
say a seqscan over a large table in a freshly-started backend, the
reported memory usage will ramp up from a couple meg to the size of
your shared_buffer arena plus a couple meg --- but in reality the
space used by the process is staying constant at a couple meg.
Now, multiply that effect by N backends doing this at once, and you'll
have a very skewed view of what's happening in your system.
I'd trust the totals reported by free and dstat a lot more than summing
per-process numbers from ps or top.
> Now, I'm not blaming Pg for the apparent discrepancy in calculated vs.
> reported-by-free memory usage, but I only noticed this after upgrading
> to 8.1.
I don't know of any reason to think that 8.1 would act differently from
older PG versions in this respect.
regards, tom lane