Guest Mike Sharpe Posted October 23, 2008 Posted October 23, 2008 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.
Guest Bobby Johnson Posted October 23, 2008 Posted October 23, 2008 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. >
Guest Mike Sharpe Posted October 23, 2008 Posted October 23, 2008 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?
Guest Doug Forster Posted October 23, 2008 Posted October 23, 2008 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?
Guest Bobby Johnson Posted October 23, 2008 Posted October 23, 2008 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? >
Guest Doug Forster Posted October 23, 2008 Posted October 23, 2008 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
Guest Bobby Johnson Posted October 23, 2008 Posted October 23, 2008 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? >
Guest Mike Sharpe Posted October 23, 2008 Posted October 23, 2008 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.
Guest Bobby Johnson Posted October 23, 2008 Posted October 23, 2008 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. > > >
Guest Chuck Walbourn [MSFT] Posted October 24, 2008 Posted October 24, 2008 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.
Guest Doug Forster Posted October 24, 2008 Posted October 24, 2008 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. > >
Guest Mark H Posted October 24, 2008 Posted October 24, 2008 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. > > > > > >
Guest Bobby Johnson Posted October 24, 2008 Posted October 24, 2008 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. >>> >>> >>> >>> > > >
Guest Mark H Posted October 24, 2008 Posted October 24, 2008 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. > >>> > >>> > >>> > >>> > > > > > >
Recommended Posts