Mike Rylander <mrylander@xxxxxxxxx> 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
