Re: measuring shared memory usage on Windows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > "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


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux