Re: postgres.exe mem usage in task manager - Mailing list pgsql-hackers-win32

>> Have you checked the "Virtual Memory Size" column? (Not enabled by
>> default)
>yes.  Virtual memory is 0 or near 0, which is correct.  Otherwise we
>really would be double dipping into memory (even if not necessarily
>physical memory).  Memory is doled out to each process from the MMF,
>which does not belong to any process.
>
>The virtual memory allocation is in fact somewhere; I have no idea how
>to view it from the task manager: I deliberately hacked it
>down to 128M,
>after which the computer alerted me and bumped it up about when you'd
>expect. (aside: why do they let you set it if the computer always
>overrides you?)

The column "VM Size" is *zero*?
(Note - this is totally unrelated to the Windows settings of Virtual
Memory. Once again, same name, different things. This is the on you get
by View->Select Columns in task manager).
The only process supposed to have that one zero is the "System Idle
Process", which has no memory allocagted at all.

In my installation, I certainly have growing numbers there.

Also, when increasing the shared memory a lot, the Mem Usage of
postmaster goes up, but not of the other processes.

If you use the performance monitor, you will see a large value for
"Virtual Bytes" that corresponds to the shared buffers + everything
else.


A couple of notes about what counters are what:
"Mem Usage" = Physical memory.
"VM Size" = Private committed (non-shared) memory.
"Virtual Bytes" = committed + reserved virtual space, including shared
"Working Set" = physical working set size
"Private Bytes" = private committed memory (again)



>> Microsoft has changed the way task manager reports memory usage
>between
>> pretty much every windows version (particularly the summary
>fields)...
>> Which version are you on?
>
>XP SP1.

Ok. Same as me then


>> Checkpointing is a no-op on win32. sync() does nothing. (OK,
>not quite
>> no-op, it writes a checkpoint record.. But without
>checkpointing, that
>> is actually incorrect).
>
>Well, my observation was based on an apples to apples comparison with
>the Interix version which has no sync() either...but WAL, etc. are not
>all fsynced(), correct?

Oh, ok. Yes, it should be.

>The upshot is everything appears reliable and quick, even
>though current
>syncing can not be relied on.  I just can't seem to figure out how to
>measure server memory consumption in a useful way :(   Interix was much
>better in this regard...there you would allocate x megabytes to the
>server and you could watch them compete for memory resources.

Well, see above. The system wide counter to look at is the Total Commit
Charge. And of course the usual suspects of hard page faults, but that's
just to determine if you are already swapping.


>Also worth noting that the raw brute insert performance with
>fsync = off
>is about 30% faster than Interix and about 15% faster than
>cygwin...this
>pleases me greatly!

That's great to hear. I expected it to be faster, but not quite so much.

//Magnus