Available Memory to 32-Bit Applications

  • Thread starter Thread starter Mike Sharpe
  • Start date Start date
M

Mike Sharpe

Guest
We are running Windows XP64 and we are using 4 CPU machines that have 8GB
total. We have a program that was written in 32-Bit code that runs on these
computers. It does some complex mathematics and data crunching. Since we
have 4 CPUs on this computer, we create 4 separate processes. Our assumption
was that each process can have 2 GB worth of addressable space. Since the
code is written in 32-Bit, do these 4 CPUs each share the same 4GB of lower
memory?

What we are seeing is that our code is running out of memory when the total
system memory usage is around 1.8GB. This leads me to believe that the
64-Bit version of Windows cannot remap memory in the 4GB+ range and make that
exposed to these processes.

What I believe is happening is that:
CPU 1 -> CPU 4 all share the same lower 4GB of memory
Instead of
CPU 1 -> gets to use 2GB (say 0GB -> 2GB)
CPU 2 -> gets to use 2GB (say 2GB -> 4GB)
CPU 3 -> gets to use 2GB (say 4GB -> 6GB)
CPU 4 -> gets to use 2GB (say 6GB -> 8GB)

Can someone definitively answer how multiple 32-Bit processes use memory in
the 64-Bit OS? What I am seeing sort of goes against everything that people
have been telling me.
 
Re: Available Memory to 32-Bit Applications

The 32-bit system environment is the limiting factor, it can only deal
with a maximum of 4GB while the actual limit is usually in the 3.2GB -
3.5GB range.

See the info on _*Large Memory Support*_ at:
http://msdn.microsoft.com/en-us/library/aa366718(VS.85).aspx


Mike Sharpe wrote:
> We are running Windows XP64 and we are using 4 CPU machines that have 8GB
> total. We have a program that was written in 32-Bit code that runs on these
> computers. It does some complex mathematics and data crunching. Since we
> have 4 CPUs on this computer, we create 4 separate processes. Our assumption
> was that each process can have 2 GB worth of addressable space. Since the
> code is written in 32-Bit, do these 4 CPUs each share the same 4GB of lower
> memory?
>
> What we are seeing is that our code is running out of memory when the total
> system memory usage is around 1.8GB. This leads me to believe that the
> 64-Bit version of Windows cannot remap memory in the 4GB+ range and make that
> exposed to these processes.
>
> What I believe is happening is that:
> CPU 1 -> CPU 4 all share the same lower 4GB of memory
> Instead of
> CPU 1 -> gets to use 2GB (say 0GB -> 2GB)
> CPU 2 -> gets to use 2GB (say 2GB -> 4GB)
> CPU 3 -> gets to use 2GB (say 4GB -> 6GB)
> CPU 4 -> gets to use 2GB (say 6GB -> 8GB)
>
> Can someone definitively answer how multiple 32-Bit processes use memory in
> the 64-Bit OS? What I am seeing sort of goes against everything that people
> have been telling me.
>
 
Re: Available Memory to 32-Bit Applications

Thank you for the reply but that seems to only make sense on a 32-Bit OS. I
am running a 64-Bit OS so I would expect that the OS should handle where the
2GB of RAM comes from and remap it to the 32-Bit process. For example:

32-Bit Process A requests 8 bytes of memory from the 64 Bit OS. The 64-Bit
OS gets that memory from lets say the 6GB block in its own memory space. It
should then provide this to 32-Bit process in a way that the 32-Bit process
thinks it is coming from a 32-Bit space.

I would think that the 64-bit OS would handle memory in this fashion.
Otherwise, moving to 64-Bit doesn't gain you anything if you want to run
multiple 32-Bit process. I could have 16GB of RAM and it wouldn't make a
difference. Let's say I have a dual quad core machine for a total of 8
CPUs/Cores. Are you suggesting that all 8 of these will use the exact same
32-Bit address space? So ~3GB will be used and the remaining 13GB would not
be used by these?
 
Re: Available Memory to 32-Bit Applications

Hi Mike,

You are quite correct, each app has its own virtual memory space and the OS
will duly map this to real RAM or page file as necessary. In fact the amount
of physical RAM is totally irrelevent - you are most likely running out of
virtual memory (assuming its not something obvious like disk space for the
page file). However it is not sufficient just to tot up the amount of memory
(virtual) you are using. The most likely barrier you are running into is
virtual memory fragmentation whereby the memory allocator cannot find
sufficient *contiguous* memory. This type of issue needs to be dealt with at
a programming level and you are not clear whether you have control over
this? If you do then a programming group might be a more appropriate place
to continue the discussion, but commonly memory fragmentation can be caused
by using auto expanding data structures that are repeatedly resized.

Cheers
Doug Forster

"Mike Sharpe" <MikeSharpe@discussions.microsoft.com> wrote in message
news:07654363-8AF1-43FB-ABB3-F9AC565544D6@microsoft.com...
> Thank you for the reply but that seems to only make sense on a 32-Bit OS.
> I
> am running a 64-Bit OS so I would expect that the OS should handle where
> the
> 2GB of RAM comes from and remap it to the 32-Bit process. For example:
>
> 32-Bit Process A requests 8 bytes of memory from the 64 Bit OS. The
> 64-Bit
> OS gets that memory from lets say the 6GB block in its own memory space.
> It
> should then provide this to 32-Bit process in a way that the 32-Bit
> process
> thinks it is coming from a 32-Bit space.
>
> I would think that the 64-bit OS would handle memory in this fashion.
> Otherwise, moving to 64-Bit doesn't gain you anything if you want to run
> multiple 32-Bit process. I could have 16GB of RAM and it wouldn't make a
> difference. Let's say I have a dual quad core machine for a total of 8
> CPUs/Cores. Are you suggesting that all 8 of these will use the exact
> same
> 32-Bit address space? So ~3GB will be used and the remaining 13GB would
> not
> be used by these?
 
Re: Available Memory to 32-Bit Applications

But, the 32-bit processes are running in a 32-bit environment within the
64-bit OS - the 32-bit environment is in its own little 32-bit world,
not in the OS's 64-bit world.

See info on _*WOW64 Implementation Details*_ at:
http://msdn.microsoft.com/en-us/library/aa384274.aspx

Your 32-bit processes are running in *WOW64* which is the x86 emulator
that allows 32-bit Windows-based applications to run seamlessly on
64-bit Windows.

Se info at: http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx


Mike Sharpe wrote:
> Thank you for the reply but that seems to only make sense on a 32-Bit OS. I
> am running a 64-Bit OS so I would expect that the OS should handle where the
> 2GB of RAM comes from and remap it to the 32-Bit process. For example:
>
> 32-Bit Process A requests 8 bytes of memory from the 64 Bit OS. The 64-Bit
> OS gets that memory from lets say the 6GB block in its own memory space. It
> should then provide this to 32-Bit process in a way that the 32-Bit process
> thinks it is coming from a 32-Bit space.
>
> I would think that the 64-bit OS would handle memory in this fashion.
> Otherwise, moving to 64-Bit doesn't gain you anything if you want to run
> multiple 32-Bit process. I could have 16GB of RAM and it wouldn't make a
> difference. Let's say I have a dual quad core machine for a total of 8
> CPUs/Cores. Are you suggesting that all 8 of these will use the exact same
> 32-Bit address space? So ~3GB will be used and the remaining 13GB would not
> be used by these?
>
 
Re: Available Memory to 32-Bit Applications

Just noticed your original post said you are running out at 1.8GB. This is
actually about par for the course for a 32 bit app that does not have the
LARGEADDRESSAWARE flag set. If you want the full 4GB to be available then
you can set this flag with the EditBin utility (or your dev tool if you are
in control of this) in which case you would run out of virtual memory
somwhere between 3 and 4 GB
 
Re: Available Memory to 32-Bit Applications

http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx has
more information about _*Memory Support and Windows Operating Systems*_

Mike Sharpe wrote:
> Thank you for the reply but that seems to only make sense on a 32-Bit OS. I
> am running a 64-Bit OS so I would expect that the OS should handle where the
> 2GB of RAM comes from and remap it to the 32-Bit process. For example:
>
> 32-Bit Process A requests 8 bytes of memory from the 64 Bit OS. The 64-Bit
> OS gets that memory from lets say the 6GB block in its own memory space. It
> should then provide this to 32-Bit process in a way that the 32-Bit process
> thinks it is coming from a 32-Bit space.
>
> I would think that the 64-bit OS would handle memory in this fashion.
> Otherwise, moving to 64-Bit doesn't gain you anything if you want to run
> multiple 32-Bit process. I could have 16GB of RAM and it wouldn't make a
> difference. Let's say I have a dual quad core machine for a total of 8
> CPUs/Cores. Are you suggesting that all 8 of these will use the exact same
> 32-Bit address space? So ~3GB will be used and the remaining 13GB would not
> be used by these?
>
 
Re: Available Memory to 32-Bit Applications

The documents were helpful but did not answer my question. I understand
64-Bit addresses. I understand 32-Bit addresses. What I am not
understanding is whether or not the 64-Bit Windows Virtual Memory Manager can
provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit
process or if they all share the same. I have an 8 core computer with 16GB
of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page file
is setup for 10GB which should leave me with a total of approximately 26GB of
Virtual Memory.

I start up an application 8 times. Each one runs in its own process and
assigned to its own CPU. This application is 32-Bit and let's say each one
uses about 1GB of RAM. What I am seeing is that when the Physical Memory of
the box (not per process, the whole box) reaches about 1.8GB, my processes
start experiencing problems and I get Out of Memory errors. If I do some
quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has 16GB
total, I should be consuming only about half. And each 32-Bit process is
under the 2 GB limit.

What I suspect is happening is that each process is sharing the SAME 32-Bit
space instead of being granted their own space in the Virtual memory and the
64-Bit memory manager controlling where each process recognizes its space.
Even if some data is in the 64-Bit range for a single process, it should be
able to map that down to the process specific 32-Bit range.
 
Re: Available Memory to 32-Bit Applications

Each 32-bit program has it own block of memory which will be shared by
the processes running within that program just as if it were actually
running that program on a Windows XP Pro (32-bit) system. I thought
that was pointed out in the info on WOW64.


Mike Sharpe wrote:
> The documents were helpful but did not answer my question. I understand
> 64-Bit addresses. I understand 32-Bit addresses. What I am not
> understanding is whether or not the 64-Bit Windows Virtual Memory Manager can
> provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit
> process or if they all share the same. I have an 8 core computer with 16GB
> of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page file
> is setup for 10GB which should leave me with a total of approximately 26GB of
> Virtual Memory.
>
> I start up an application 8 times. Each one runs in its own process and
> assigned to its own CPU. This application is 32-Bit and let's say each one
> uses about 1GB of RAM. What I am seeing is that when the Physical Memory of
> the box (not per process, the whole box) reaches about 1.8GB, my processes
> start experiencing problems and I get Out of Memory errors. If I do some
> quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has 16GB
> total, I should be consuming only about half. And each 32-Bit process is
> under the 2 GB limit.
>
> What I suspect is happening is that each process is sharing the SAME 32-Bit
> space instead of being granted their own space in the Virtual memory and the
> 64-Bit memory manager controlling where each process recognizes its space.
> Even if some data is in the 64-Bit range for a single process, it should be
> able to map that down to the process specific 32-Bit range.
>
>
>
 
Re: Available Memory to 32-Bit Applications

A 32-bit process can only adddress up to 2 GB of virtual address space. A
32-bit Large Address Aware process can get up to 4 GB of virtual address
space when run on Windows x64.

Each process has it's own unique address space. Every THREAD in that process
shares the same virtual address space.

Physical memory is managed by the operating system and will be mapped to
each process on demand. The mapping is completely up to the OS and is
dynamic, so there's no hard and firm rule here. If you are runnning a x64 OS
with 8 GB of physical RAM available, then the system will allocate it based
on the runtime demand. Multiple 32-bit processes running at the same time
can utilize more than 2 GB of physical memory.

To determine what is really happening you should look at your runtime
environment and determine how much viritual address space is allocated by
each process, and how large each working set is at runtime.

--
-Chuck Walbourn
SDE, XNA Developer Connection

This posting is provided "AS IS" with no warrenties, and confers no rights.
 
Re: Available Memory to 32-Bit Applications

And just one last thought: Are you sure your apps are actually completely
independent. I have come across bugs in such a situation where apps were
inadvertently sharing temporary files and crashing as a consequence of
processing unexpected data.

Cheers
Doug Forster

"Mike Sharpe" <MikeSharpe@discussions.microsoft.com> wrote in message
news:1E61C353-56A5-435F-841A-59B702CC5434@microsoft.com...
> The documents were helpful but did not answer my question. I understand
> 64-Bit addresses. I understand 32-Bit addresses. What I am not
> understanding is whether or not the 64-Bit Windows Virtual Memory Manager
> can
> provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit
> process or if they all share the same. I have an 8 core computer with
> 16GB
> of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page
> file
> is setup for 10GB which should leave me with a total of approximately 26GB
> of
> Virtual Memory.
>
> I start up an application 8 times. Each one runs in its own process and
> assigned to its own CPU. This application is 32-Bit and let's say each
> one
> uses about 1GB of RAM. What I am seeing is that when the Physical Memory
> of
> the box (not per process, the whole box) reaches about 1.8GB, my processes
> start experiencing problems and I get Out of Memory errors. If I do some
> quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has 16GB
> total, I should be consuming only about half. And each 32-Bit process is
> under the 2 GB limit.
>
> What I suspect is happening is that each process is sharing the SAME
> 32-Bit
> space instead of being granted their own space in the Virtual memory and
> the
> 64-Bit memory manager controlling where each process recognizes its space.
> Even if some data is in the 64-Bit range for a single process, it should
> be
> able to map that down to the process specific 32-Bit range.
>
>
 
Re: Available Memory to 32-Bit Applications

An architectural limit has been reached. Some commonly reported
architectural limits in Windows include:

1. 2 GB of shared virtual address space for the system
2. 2 GB of private virtual address space per process
3. 660 MB System PTE storage
4. 470 MB paged pool storage
5. 256 MB nonpaged pool storage
6. 1 GB System cache
7. 16,000 GB pagefile size

Your current set of applications are using 18GB of virtual address space. (8
application processes, 1 OS)
So answering you're original question, Yes. Each process has it's own 2GB of
virtual memory.

But, here's the rub:
Your're running 32-bit applications in a 64-bit OS. For this to occur, the
32-bit application must be converted, on-the-fly, to a 64-bit application.
It now uses twice as much memory to do the same thing while being limited to
the 32-bit rules. The executable stays the same size (only converted as
used), but the data produced is retained in 64-bit. Example: Your routine is
1KB, but it calculates Pi to 1GB places. To store the number, you need 2GB
for this emulated x64 application. Since these are data intensive
applications, you may be running out of memory, not addresses. Run less
processes, or set the page file bigger.

You have 16 GB of RAM, paging will occur as you are currently setup
significantly reducing the performance of your applications. But, more
importantly, the Paged Pool Entry Table is trying to handle a huge amount of
information. You may be running out of Shared Virtual Memory (the OS) which
is reported as Out of Memory, and not Private Virtual Memory for your
processes. Because you hit the limit at 1.8GB, I suspect your problem is
Shared Virtual Memory (the OS) running out of memory as it sets up tables
for paging all the data produced.

A kernel debugger is needed to find out which limit you are violating.

"Bobby Johnson" <rjohnson@aol.NOSPAM.com> wrote in message
news:OMXFqSVNJHA.5232@TK2MSFTNGP05.phx.gbl...
> Each 32-bit program has it own block of memory which will be shared by
> the processes running within that program just as if it were actually
> running that program on a Windows XP Pro (32-bit) system. I thought
> that was pointed out in the info on WOW64.
>
>
> Mike Sharpe wrote:
> > The documents were helpful but did not answer my question. I understand
> > 64-Bit addresses. I understand 32-Bit addresses. What I am not
> > understanding is whether or not the 64-Bit Windows Virtual Memory
Manager can
> > provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit
> > process or if they all share the same. I have an 8 core computer with
16GB
> > of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page
file
> > is setup for 10GB which should leave me with a total of approximately
26GB of
> > Virtual Memory.
> >
> > I start up an application 8 times. Each one runs in its own process and
> > assigned to its own CPU. This application is 32-Bit and let's say each
one
> > uses about 1GB of RAM. What I am seeing is that when the Physical
Memory of
> > the box (not per process, the whole box) reaches about 1.8GB, my
processes
> > start experiencing problems and I get Out of Memory errors. If I do
some
> > quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has 16GB
> > total, I should be consuming only about half. And each 32-Bit process
is
> > under the 2 GB limit.
> >
> > What I suspect is happening is that each process is sharing the SAME
32-Bit
> > space instead of being granted their own space in the Virtual memory and
the
> > 64-Bit memory manager controlling where each process recognizes its
space.
> > Even if some data is in the 64-Bit range for a single process, it should
be
> > able to map that down to the process specific 32-Bit range.
> >
> >
> >
 
Re: Available Memory to 32-Bit Applications

I don't know where you obtained your information, but it is seriously
flawed. 32-bit application are NOT converted "on-the fly" in Windows
x64! The are run in a virtual 32-bit environment space under WOW64.
You need to do some more research before you make such erroneous
statements! And each APPLICATION gets 2GB for ALL its processes to share!


Mark H wrote:
> An architectural limit has been reached. Some commonly reported
> architectural limits in Windows include:
>
> 1. 2 GB of shared virtual address space for the system
> 2. 2 GB of private virtual address space per process
> 3. 660 MB System PTE storage
> 4. 470 MB paged pool storage
> 5. 256 MB nonpaged pool storage
> 6. 1 GB System cache
> 7. 16,000 GB pagefile size
>
> Your current set of applications are using 18GB of virtual address space. (8
> application processes, 1 OS)
> So answering you're original question, Yes. Each process has it's own 2GB of
> virtual memory.
>
> But, here's the rub:
> Your're running 32-bit applications in a 64-bit OS. For this to occur, the
> 32-bit application must be converted, on-the-fly, to a 64-bit application.
> It now uses twice as much memory to do the same thing while being limited to
> the 32-bit rules. The executable stays the same size (only converted as
> used), but the data produced is retained in 64-bit. Example: Your routine is
> 1KB, but it calculates Pi to 1GB places. To store the number, you need 2GB
> for this emulated x64 application. Since these are data intensive
> applications, you may be running out of memory, not addresses. Run less
> processes, or set the page file bigger.
>
> You have 16 GB of RAM, paging will occur as you are currently setup
> significantly reducing the performance of your applications. But, more
> importantly, the Paged Pool Entry Table is trying to handle a huge amount of
> information. You may be running out of Shared Virtual Memory (the OS) which
> is reported as Out of Memory, and not Private Virtual Memory for your
> processes. Because you hit the limit at 1.8GB, I suspect your problem is
> Shared Virtual Memory (the OS) running out of memory as it sets up tables
> for paging all the data produced.
>
> A kernel debugger is needed to find out which limit you are violating.
>
> "Bobby Johnson" <rjohnson@aol.NOSPAM.com> wrote in message
> news:OMXFqSVNJHA.5232@TK2MSFTNGP05.phx.gbl...
>
>> Each 32-bit program has it own block of memory which will be shared by
>> the processes running within that program just as if it were actually
>> running that program on a Windows XP Pro (32-bit) system. I thought
>> that was pointed out in the info on WOW64.
>>
>>
>> Mike Sharpe wrote:
>>
>>> The documents were helpful but did not answer my question. I understand
>>> 64-Bit addresses. I understand 32-Bit addresses. What I am not
>>> understanding is whether or not the 64-Bit Windows Virtual Memory
>>>
> Manager can
>
>>> provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit
>>> process or if they all share the same. I have an 8 core computer with
>>>
> 16GB
>
>>> of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page
>>>
> file
>
>>> is setup for 10GB which should leave me with a total of approximately
>>>
> 26GB of
>
>>> Virtual Memory.
>>>
>>> I start up an application 8 times. Each one runs in its own process and
>>> assigned to its own CPU. This application is 32-Bit and let's say each
>>>
> one
>
>>> uses about 1GB of RAM. What I am seeing is that when the Physical
>>>
> Memory of
>
>>> the box (not per process, the whole box) reaches about 1.8GB, my
>>>
> processes
>
>>> start experiencing problems and I get Out of Memory errors. If I do
>>>
> some
>
>>> quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has 16GB
>>> total, I should be consuming only about half. And each 32-Bit process
>>>
> is
>
>>> under the 2 GB limit.
>>>
>>> What I suspect is happening is that each process is sharing the SAME
>>>
> 32-Bit
>
>>> space instead of being granted their own space in the Virtual memory and
>>>
> the
>
>>> 64-Bit memory manager controlling where each process recognizes its
>>>
> space.
>
>>> Even if some data is in the 64-Bit range for a single process, it should
>>>
> be
>
>>> able to map that down to the process specific 32-Bit range.
>>>
>>>
>>>
>>>
>
>
>
 
Re: Available Memory to 32-Bit Applications

Thank you for the correction on the use of the word application where I
stated process. Reading the below, you may understand while I crossed my
words. But, "converting" on the fly is the process for x86 on x64.


Regarding WOW64: (from MS)
http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx
(in case you want to read up on WOW64)
"Many 32-bit applications will not be updated for Windows Vista x64 Edition;
however, most 32-bit software will still function because of a Microsoft
emulation layer. This emulation layer, known as Windows on Windows 64 or
WoW64, enables 32-bit programs to run as though on a 32-bit version of
Windows by translating instructions passing in and out of 32-bit
applications into 64-bit instructions. Emulated programs act as though they
are running on an x86 computer and operate within the 2 GB of virtual memory
that a 32-bit version of Windows allocates to every process. However,
despite Wow64, 32-bit programs on Windows Vista x64 Edition cannot take
advantage of the larger 64-bit address spaces or wider 64-bit registers on
64-bit processors."

The phrase "by translating instructions passing in and out of 32-bit
applications into 64-bit instructions" would be "on-the-fly."
The phrase "operate within the 2 GB of virtual memory that a 32-bit version
of Windows allocates to every process" would be the "being limited to 32-bit
rules."

In most cases, 32-bit instructions are converted "on-the-chip"... (a 32-bit
instruction is put into a 64-bit register.) Most kernel routines require
conversion to a 64-bit equivalent call. In this case, WOW64 adds overhead as
it must maintain both 32-bit and 64-bit stacks to allow communication within
the executable and externally to any kernel connections (kernel32.dll,
ntdll.dll, user32.dll, imm32.dll ,gdi32.dll, rpcrt4.dll).

"WOW64 adds significant virtual memory overhead if two or more instances of
the same 32-bit application are run concurrently. read-only memory pages are
not shared between 32-bit processes as they are on x86 NT/Win9x."

"WOW64 does not support access to more than 2gb of memory - there is no
support for 3gb usermode processes via /LARGEADDRESSAWARE:YES
All kernelmode drivers must be ported to 64-bit native code."

Beyond that, well, have a good day.



"Bobby Johnson" <rjohnson@aol.NOSPAM.com> wrote in message
news:%23Hi3gFdNJHA.1960@TK2MSFTNGP04.phx.gbl...
> I don't know where you obtained your information, but it is seriously
> flawed. 32-bit application are NOT converted "on-the fly" in Windows
> x64! The are run in a virtual 32-bit environment space under WOW64.
> You need to do some more research before you make such erroneous
> statements! And each APPLICATION gets 2GB for ALL its processes to share!
>
>
> Mark H wrote:
> > An architectural limit has been reached. Some commonly reported
> > architectural limits in Windows include:
> >
> > 1. 2 GB of shared virtual address space for the system
> > 2. 2 GB of private virtual address space per process
> > 3. 660 MB System PTE storage
> > 4. 470 MB paged pool storage
> > 5. 256 MB nonpaged pool storage
> > 6. 1 GB System cache
> > 7. 16,000 GB pagefile size
> >
> > Your current set of applications are using 18GB of virtual address
space. (8
> > application processes, 1 OS)
> > So answering you're original question, Yes. Each process has it's own
2GB of
> > virtual memory.
> >
> > But, here's the rub:
> > Your're running 32-bit applications in a 64-bit OS. For this to occur,
the
> > 32-bit application must be converted, on-the-fly, to a 64-bit
application.
> > It now uses twice as much memory to do the same thing while being
limited to
> > the 32-bit rules. The executable stays the same size (only converted as
> > used), but the data produced is retained in 64-bit. Example: Your
routine is
> > 1KB, but it calculates Pi to 1GB places. To store the number, you need
2GB
> > for this emulated x64 application. Since these are data intensive
> > applications, you may be running out of memory, not addresses. Run less
> > processes, or set the page file bigger.
> >
> > You have 16 GB of RAM, paging will occur as you are currently setup
> > significantly reducing the performance of your applications. But, more
> > importantly, the Paged Pool Entry Table is trying to handle a huge
amount of
> > information. You may be running out of Shared Virtual Memory (the OS)
which
> > is reported as Out of Memory, and not Private Virtual Memory for your
> > processes. Because you hit the limit at 1.8GB, I suspect your problem is
> > Shared Virtual Memory (the OS) running out of memory as it sets up
tables
> > for paging all the data produced.
> >
> > A kernel debugger is needed to find out which limit you are violating.
> >
> > "Bobby Johnson" <rjohnson@aol.NOSPAM.com> wrote in message
> > news:OMXFqSVNJHA.5232@TK2MSFTNGP05.phx.gbl...
> >
> >> Each 32-bit program has it own block of memory which will be shared by
> >> the processes running within that program just as if it were actually
> >> running that program on a Windows XP Pro (32-bit) system. I thought
> >> that was pointed out in the info on WOW64.
> >>
> >>
> >> Mike Sharpe wrote:
> >>
> >>> The documents were helpful but did not answer my question. I
understand
> >>> 64-Bit addresses. I understand 32-Bit addresses. What I am not
> >>> understanding is whether or not the 64-Bit Windows Virtual Memory
> >>>
> > Manager can
> >
> >>> provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit
> >>> process or if they all share the same. I have an 8 core computer with
> >>>
> > 16GB
> >
> >>> of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page
> >>>
> > file
> >
> >>> is setup for 10GB which should leave me with a total of approximately
> >>>
> > 26GB of
> >
> >>> Virtual Memory.
> >>>
> >>> I start up an application 8 times. Each one runs in its own process
and
> >>> assigned to its own CPU. This application is 32-Bit and let's say
each
> >>>
> > one
> >
> >>> uses about 1GB of RAM. What I am seeing is that when the Physical
> >>>
> > Memory of
> >
> >>> the box (not per process, the whole box) reaches about 1.8GB, my
> >>>
> > processes
> >
> >>> start experiencing problems and I get Out of Memory errors. If I do
> >>>
> > some
> >
> >>> quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has
16GB
> >>> total, I should be consuming only about half. And each 32-Bit process
> >>>
> > is
> >
> >>> under the 2 GB limit.
> >>>
> >>> What I suspect is happening is that each process is sharing the SAME
> >>>
> > 32-Bit
> >
> >>> space instead of being granted their own space in the Virtual memory
and
> >>>
> > the
> >
> >>> 64-Bit memory manager controlling where each process recognizes its
> >>>
> > space.
> >
> >>> Even if some data is in the 64-Bit range for a single process, it
should
> >>>
> > be
> >
> >>> able to map that down to the process specific 32-Bit range.
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
 

Similar threads

H
Exception for Custom Memset function with Large array to set value.
Replies
0
Views
868
Harsha_MR
H
V
Memory dumps to study a high-CPU performance issue
Replies
0
Views
265
Viorel-Alexandru
V
V
Memory dumps to study a memory-leak performance issue
Replies
0
Views
258
Viorel-Alexandru
V
V
Memory dumps for hang or performance issues, "automated" approach
Replies
0
Views
249
Viorel-Alexandru
V
V
Memory dumps for hang or performance issues, "manual" approach
Replies
0
Views
279
Viorel-Alexandru
V
Back
Top