Skip site navigation (1) Skip section navigation (2)

Re: measuring shared memory usage on Windows

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Harald Armin Massa" <haraldarminmassa(at)gmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: measuring shared memory usage on Windows
Date: 2006-10-16 12:30:56
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCEA357F5@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-performance
> > > "anonymous mapped memory"  site:microsoft.com turns out 0 (zero) 
> > > results. And even splitting it up there seems to be nearly no 
> > > information ... is the same thing by any chance also known by 
> > > different names?
> >
> > Hmm. Yeah, most likely :) I may have grabbed that name from 
> something 
> > else. THe documentation for the call is on 
> > 
> http://windowssdk.msdn.microsoft.com/en-us/library/ms685007(VS.80).asp
> > x, we specify INVALID_HANDLE_VALUE for hFile, which means:
> 
> [...]
> CreateFileMapping creates a file mapping object of a 
> specified size that _the operating system paging file backs_ [...]
> 
> I assume that DWORD dwMaximumSizeHigh and  DWORD 
> dwMaximumSizeLow get filled with whatever I configure in 
> shared_memory?

Yes. See the code in src/backend/port/win32 for details ;)


> My reading of that function gives me the impression, that 
> this kind of shared *memory* is essentially a shared disk 
> file - "_the operating system paging file backs_"

Yes. Note that this does *not* mean that it actually stores anything in
the file. All it means that *if* windows needs to *page out* this data,
it will do so to the pagefile, so the pagefile has to have enough room
for it. With a normal file, it would be paged out to the file instead of
the pagefile. But as long as there is enough free memory around, it will
stay in RAM.

If a specific part of shared memory (the mmaped pagefile) is not
accessed in a long time, it will get swapped out to the pagefile, yes.
And I don't beleive there is a way to make that not happen.


> Especially documentation lines like "If an application 
> specifies a size for the file mapping object that is larger 
> than the size of the actual named file on disk, the file on 
> disk is increased to match the specified size of the file 
> mapping object."

This is irrelevant, because we are not mapping a file.


> really makes me think that that area is just a comfortable 
> way to access files on disk as memory areas; with the hope of 
> propably better caching then not-memory-mapped files.

That shows that you don't really know how the memory manager in NT+
works ;-) *ALL* normal file I/O is handled through the memory manager
:-) So yes, they are both different access methods to the memory
manager, really.


> That would explain my disturbing impressions of performance 
> of PostgreSQL on win32 rising when lowering shared_memory...

Not exactly. I can still see such a thing happening in some cases, but
not because all our shared memory actually hit disks. We'd be *dead* on
performance if it did.

//Magnus

In response to

Responses

pgsql-performance by date

Next:From: Mark KirkwoodDate: 2006-10-16 12:34:30
Subject: Re: Hints proposal
Previous:From: David BorehamDate: 2006-10-16 12:27:24
Subject: Re: measuring shared memory usage on Windows

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group