I run the same application on Windows 10 and Windows 7 (both 64-bit) and used Process Explorer to monitor the Virtual Size. I noticed that the Virtual Size of the application running on Windows 10 is much larger than running on Windows 7.
By using VMMap, in Private Data:
Windows 10 - 1 address with 4.2GB is reserved and not committed.
Windows 7 - 2 address with 15MB are reserved and not committed.
So my questions are:
Why there is a large memory has been reserved? Is it just a different memory management done by Win10 and Win7?
Or, there is something to do with the application that I ran? (The application has no problem to run on Win10 & Win7)
Is there any suitable indicator to track memory leak? (Eg: 'Committed' value in VMMap) It seems like so much discussion/argument on this :P
Related
I am curious to know about the difference between memory management in Windows and Linux.Does Windows OS support paging or segmentation?
I trying to understand, If all processes cumulatively uses all RAM on Windows machine then every user is prevented even from log in to the system but that is not the case with Linux systems.
So how it's achieved in Linux system?
Additionally to the recent posts, Windows 10 also supports compressing of the RAM. that means, before Windows tries so SWAP out memmory on hard drive, it will try to compress the RAM
I have an application that uses a fair number (don't ask!) of Thread Local Storage variables. It has been operable without issue for almost a decade ... until a recent surprise.
A customer has a laptop running Windows7 (64 bit)... and on his system, the TLS allocation fails. (My problem isn't exactly this, but close enough). He claims his system is pretty standard; he has a ZoneAlarm but claims everything else is stock; take that with a grain of salt). How do I find out who or what is allocating other TLS slots (and running me effectively out of slots)?
The application is a console standalone application and fairly vanilla: open/read/write files, some multithreading, practically nothing else, so I expect only the basic Windows DLLs to be actively involved. I know that some DLLs (even the Windows ones) may service thread-based activities and so will allocate their own TLS slots, and that's OK. But I don't expect that lots and lots are allocated by anything sane. Is there something else that can insert itself into my process space as part of my application startup (maybe a firewall)?
How many TLS slots should be allocated in a typical process when it starts up? Where is the demand coming from? Can I trace TLS calls to see who is allocating them somehow?
EDIT: Jan 1, 2013: Having some experience now, and having my tool report the TLS demand when it starts, I see something like the following:
Win XP 64 8 cores 16 Gb RAM: 3 TLS variables busy
Windows Vista 32 4 Gb RAM: 4 TLS variables busy
Win 7 Pro: 4 cores 8 Gb RAM: 7 TLS variables busy
Win 7 (French version): 2 cores, 4 GB: minimum of 25 TLS variables busy, more in some configurations
We're checking on Windows 8, but its TLS demand appears to be higher. But what on earth accounts for the huge difference between the two Windows 7 systems? Any why is there any need for TLS variables (presumably for DLLs to store thread state) before my application starts running, especially considering there was no need for in earlier version of Windows?
If it helps, we are running a 32 bit application.
I have a VB6 application that uses FileNet Visual Workflo (on FileNet Image Services) for the workflow engine. All of our application code has been updated to work correctly on both Windows XP and Windows 7, but there is a performance problem on Win 7 when attempting to get work object information from FileNet.
Within the application are calls such as
ErrorCode = APIVWAPI.VW_GetString(wobjid, lvFldName(idx - 1), aStr)
to which I've isolated the performance issue.
APIVWAPI is defined via late binding as follows:
Set APIVWAPI = CreateObject("VWApi.Srv")
The
ErrorCode = APIVWAPI.VW_GetString(wobjid, lvFldName(idx - 1), aStr)
line takes approximately 40 times longer on the Windows 7 machine (Core i7 3.4GHz CPU 8GB RAM) as it does on a Windows XP machine (Pentinum 4 3.2GHz, 1GB RAM). This line (and those like it) is called multiple times when retrieving queue items. As an example, a 120 item queue will take about 40 seconds to load on Windows 7 and <1 second on Windows XP.
Both systems are using the latest FileNet IDM components (4.0.3 fix pack 1). The Windows 7 environment is 64-bit Enterprise. XP is 32-bit Professional. The FileNet Visual Workflo components are the last, version 3.6.
Does anybody have any experience with FileNet IDM on Windows 7, and/or dealing with performance problems that appear to be DLL related on Windows 7 - and suggestions?
It turns out that the performance issue was related to drawing a ListView on the screen. Making the ListView not visible while retrieving the data, and then drawing the ListView once all data was retrieved, greatly increased performance.
I'll chalk this up to differences between 32-bit and 64-bit systems.
I am developing a 32 bit application in .NET that for various reasons cannot be compiled as a 64 bit application.
I need to run many of these concurrently and they use a lot of memory. I want to load up a Windows 7 box with tonnes of memory and consequently would like to use the 64 bit version of Windows 7 so that we can put many gigabytes of RAM on those boxes.
My question is this: The maximum memory used by each instance of my app is ~500mb. In Windows 7 64bit, these 32-bit applications will run (I assume) using the WOW64 emulation layer in Windows. As I begin to run more and more of these instances concurrently, will they all be stuck running in the bottom 2gb of ram, or will Windows allocate memory for them using all of the higher-address range of memory possible within 64-bit Windows? Is the addressable-memory limitation of 32 bit software only a per-instance limitation in this case, or will all the instances be limited to the bottom 2gb of ram?
You are confusing memory (physical address space) with virtual address space. You can put more than 4GB of memory into a 32-bit system; you don't need to move to 64-bit to gain physical address space. Each process gets its own virtual address space, so each one will get its own 2GB of user-mode address space to play with. (Or 3GB if /3GB or 4GB if running on WOW64 with /LARGEADDRESSAWARE.)
I am investigating a strange problem with my application, where the behaviour is different on 2 versions of Windows:
Windows XP (32-bit)
Windows Server 2008 (64-bit)
My findings are as follows.
Windows XP (32-bit)
When running my test scenario, the XML parser fails at a certain point during the parsing of a very large configuration file (see this question for more information).
At the time of failure, the process size is approximately 2.3GB. Note that a registry key has been set to allow the process to exceed the default maximum process size of 2GB (on 32-bit operating systems).
The system of the failure is a call to IXMLDOMDocument::load() failing, as described in the question linked above.
Windows Server 2008 (64-bit)
I run exactly the same test scenario in Windows Server 2008 -- the only variable is the operating system. When I look at my process under Task Manager, it has a * 32 next to it, which I am assuming means it is running in 32-bit compatibility mode.
What I am noticing is that at the point where the XML parsing fails on Windows XP, the process size on Windows Server 2008 is only about 1GB (IOW, approximately half the process size as on Windows XP).
The XML parsing does not fail on Windows Server 2008, it all works as it should.
My questions are:
Why would a 32-bit application (running in 32-bit mode) consume half the amount of memory on a 64-bit operating system? Is it really using half the memory, it is usual virtual memory differently, or is it something else?
Acknowledging that my application (seems) to be using half the amount of memory on Windows Server 2008, does anyone have any ideas as to why the XML parsing would be failing on Windows XP? Every time I run the test case, the error accessed via IXMLDOMParseError (see this answer) is different. Because this appears to be non-deterministic, it suggests to me that I am running into a memory usage problem rather than dealing with malformed XML.
You didn't say how you observed the process. I'll assume you used Taskmgr.exe. Beware that it's default view gives very misleading values in the Memory column. It shows Working set size, the amount of RAM that's being used by the process. That has nothing to do with the source of your problem, running out of virtual memory space. There is not much reason to assume that Windows 2008 would show the same value as XP, it has a significantly different memory manager.
You can see the virtual memory size as well, use View + Columns.
The reason your program doesn't bomb on a 64-bit operating system is because 32-bit processes have close to 4 gigabytes of addressable virtual memory. On a 32-bit operating system, it needs to share the address space with the operating system and gets only 2 gigabytes. More if you use the /3GB boot option.
Use the SAX parser to avoid consuming so much memory.
Not only are there differences in available memory between 32 bit and 64 bit (as discussed in previous answers), but its the availability of contiguous memory that may be killing your app on 32 bit.
On 32 bit machine your app's DLLs will be littering the memory landscape in the first 2GB of memory (app at 0x00400000, OS DLLs up at 0x7xxx0000, other DLLs elsewhere). Most likely the largest contiguous block you have available is about 1.1GB.
On a 64 bit machine (which gives you the 4GB address space with /LARGEADDRESSAWARE) you'll have a least one block in that 4GB space that is 2GB or more in size.
So there is your difference. If your XML parser is relying on a large blob of memory rather than many small blobs it may be that your XML parser is running out of contiguous usable space on 32 bit but is not running out of contiguous usable space on 64 bit.
If you want to visualize this on the 32 bit OS, grab a copy of VMValidator (free) and look at the Virtual view for a visualization of your memory and the Pages and Paragraphs views to see the data for each memory page/paragraph.