工艺尺寸和32位与64位Windows版本的行为差异 [英] Process sizes and differences in behaviour on 32bit vs. 64bit Windows versions

查看:222
本文介绍了工艺尺寸和32位与64位Windows版本的行为差异的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我调查一个奇怪的问题,我的应用程序,其中的行为是在2版本的Windows不同的:

  • 的Windows XP(32位)
  • 的Windows Server 2008(64位)

我的研究结果如下。

的Windows XP(32位)

在运行我的测试场景中,XML解析器一个非常大的配置文件的解析过程中失败在某一点(见<一href="http://stackoverflow.com/questions/2144219/how-can-i-determine-why-a-call-to-ixmldomdocumentload-fails">this问题获得更多信息)。

目前故障的时间,则处理大小约为2.3GB。请注意,注册表项已设置为允许进程超过2GB,默认的最大进程大小(在32位操作系统)。

失败的系统是的IXMLDOMDocument一个电话::负载()失败,如在上面链接的问题描述。

的Windows Server 2008(64位)

我跑的完全的相同的测试场景在Windows Server 2008 - 唯一的变量是操作系统。当我看到我在任务管理器的过程中,它有一个 * 32 旁边,这我假设它是在32位兼容模式下运行的手段。

我所注意到的是,在其中,在Windows XP,Windows Server 2008上的进程大小的XML解析出现故障的时间只有大约1GB(IOW,大约有一半的进程大小为Windows XP系统)。

中的XML解析时的不可以失败的Windows Server 2008上,它的所有作品,因为它应该。

我的问题是:

  1. 为什么一个32位的应用程序(在32位模式下运行),占用的内存的一半在64位操作系统的数量?难道真的用了一半的内存,通常是虚拟内存的不同,或者是其他什么东西?

  2. 承认我的应用程序(似乎)被使用的内存的Windows Server 2008上半量,没有任何人有任何想法,为什么XML解析将失败的Windows XP?每次运行测试的情况下,通过 IXMLDOMParseError 访问的错误(见<一href="http://stackoverflow.com/questions/2144219/how-can-i-determine-why-a-call-to-ixmldomdocumentload-fails/2146301#2146301">this答案)是不同的。因为这似乎是不确定的,它表明,我认为我遇到一个内存使用问题,而不是处理畸形XML。

解决方案

你没有说你怎么观察的过程。我假设你使用的TaskMgr.exe。要注意的是它的默认视图提供非常误导值在存储器列。它显示工作组大小,的RAM正在被使用的过程的量。这已无关,与你的问题的根源,运行的虚拟内存空间。没有多少理由认为Windows 2008中会表现出相同的值,XP,它有显著不同的内存管理器。

您可以看到虚拟内存的大小为好,使用View +列。

的原因,你的程序不会在64位操作系统轰炸是因为32位进程已接近4 GB的可寻址的虚拟内存。在32位操作系统上,它需要分享与操作系统的地址空间,仅得到2千兆字节。如果使用/ 3GB启动选项更多。

使用SAX解析器,以避免消耗这么多的内存。

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:

  1. 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?

  2. 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.

这篇关于工艺尺寸和32位与64位Windows版本的行为差异的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆