On 12/8/05, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > 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. Right, I can definitely see that happening. Some backends are upwards of 200M, some are just a few since they haven't been touched yet. > > 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. Absolutely ... > > I'd trust the totals reported by free and dstat a lot more than summing > per-process numbers from ps or top. > And there's the part that's confusing me: the numbers for used memory produced by free and dstat, after subtracting the buffers/cache amounts, are /larger/ than those that ps and top report. (top says the same thing as ps, on the whole.) > > 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. > Neither can I, which is why I don't blame it. ;) I'm just reporting when/where I noticed the issue. > regards, tom lane > -- Mike Rylander mrylander@xxxxxxxxx GPLS -- PINES Development Database Developer http://open-ils.org
