On Tue, 2003-02-11 at 12:49, Merlin Moncure wrote:
> Does anyone know whether cygwin has a setting comparable to SHMMAX,
> and if so what is its default value? How about the upcoming native
> Windows port --- any issues there?
>
> >From a pure win32 point of view, a good approach would be to use the
> VirtualAlloc() memory allocation functions and set up a paged memory
> allocation system. From a very top down point of view, this is the
> method of choice if portability is not an issue. An abstraction to use
> this technique within pg context is probably complex and requires
> writing lots of win32 api code, which is obviously not desirable.
>
> Another way of looking at it is memory mapped files. This probably most
> closely resembles unix shared memory and is the de facto standard way
> for interprocess memory block sharing. Sadly, performance will suffer
> because you have to rely on the virtual memory system (think: writing to
> files) to do a lot of stupid stuff you don't necessarily want or need.
> The OS has to guarantee that the memory can be swapped out to file at
> any time and therefore mirrors the pagefile to the allocated memory
> blocks.
>
> With the C++/C memory malloc/free api, you are supposed to be able to
> get some of the benefits of virtual alloc (in particular, setting a
> process memory allocation limit), but personal experience did not bear
> this out. However, this api sits directly over the virtual allocation
> system and is the most portable. The application has to guard against
> fragmentation and things like that in this case. In win32, server
> thrashing is public enemy #1 for database servers, mostly due to the
> virtual allocation system (which is quite fast when used right, btw).
IIRC, there is a mechanism which enables it to be directly
supported/mapped via pagefile. This is the preferred means of memory
mapped files unless you have a specific need which dictates otherwise.
Meaning, it allows for many supposed optimizations to be used by the OS
as it is suppose to bypass some of the filesystem overhead.
Regards,
--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting
