Windows – 我的32位应用程序可以做什么消耗千兆字节的物理RAM?

前端之家收集整理的这篇文章主要介绍了Windows – 我的32位应用程序可以做什么消耗千兆字节的物理RAM?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
几个月前,一名同事提到我,我们内部的Delphi应用程序似乎占用了8 GB的RAM。我告诉他了:

That’s not possible

32位应用程序仅具有32位虚拟地址空间。即使有内存泄漏,它可能消耗的大多数内存是2 GB。之后,分配将失败(因为虚拟地址空间中不会有空格)。而在内存泄漏的情况下,虚拟页面将被换出到页面文件,释放物理RAM。

但他指出,Windows资源监视器表示系统上可用的RAM不足1 GB。而我们的应用程序只使用220 MB的虚拟内存:关闭它释放了8 GB的物理RAM。

所以我测试了

我让应用程序运行了几个星期,今天我终于决定测试了。

首先我关闭应用程序之前看内存使用情况:

>工作集(RAM)为241 MB
>使用的总虚拟内存:409 MB

我使用资源监视器来检查应用程序使用的内存和正在使用的总RAM:

>应用程序分配的虚拟内存:252 MB
>正在使用的物理内存:14 GB

然后关闭应用程序后的内存使用:

>使用物理内存:6.6 GB(较低7.4 GB)

我还使用Process Explorer查看之前和之后的物理RAM使用情况。唯一的区别是8 GB的RAM真的没有提交,现在免费:

| Item                          | Before     | After     |
|-------------------------------|------------|-----------|
| Commit Charge (K)             | 15,516,388 | 7,264,420 |
| Physical Memory Available (K) |  1,959,480 | 9,990,012 |
| Zeroed Paging List  (K)       |    539,212 | 8,556,340 |

注意:有趣的是,Windows会浪费时间立即清除所有内存,而不是简单地将其放在备用列表中,并根据需要将其清零(因为内存请求需要满足)。

这些东西都没有解释RAM是什么(你在做什么只是坐在那里!你包含什么??)

那是什么记忆!

该RAM必须包含有用的东西;它必须有一些目的。为此,我转向SysInternals的RAMMap。它可能会破坏内存分配。

RAMMap提供的唯一线索是,8 GB的物理内存与称为“会话私有”的内容相关联。这些会话私人分配不与任何进程相关联(即不是我的进程):

| Item                   | Before   | After    |
|------------------------|----------|----------|
| Session Private        | 8,031 MB |   276 MB |
| Unused                 | 1,111 MB | 8,342 MB |

我当然没有在EMS,XMS,AWE等方面做任何事情

在32位非管理员应用程序中可能会发生什么,导致Windows分配额外的7 GB RAM?

>这不是一个交换项目的缓存
>它不是SuperFetch缓存

就在那里消耗RAM。

会话私人

关于“会话私人”内存的唯一信息是a blog post announcing RAMMap

Session Private: Memory that is private to a particular logged in session. This will be higher on RDS Session Host servers.

这是什么样的应用程序

这是一个32位的本机Windows应用程序(即不是Java而不是.NET)。因为它是一个本机的Windows应用程序,当然,大量使用Windows API。

应该指出的是,我并没有要求人们调试应用程序;我希望Windows开发人员知道为什么Windows可能会保留我从未分配的内存。话虽如此,最近才发生的(最近2年或3年)的唯一改变是每5分钟一次屏幕截图,并将其保存到用户的%LocalAppData%文件夹。定时器每五分钟触发一次:

QueueUserWorkItem(TakeScreenshotThreadProc);

和伪代码的线程方法

void TakeScreenshotThreadProc(Pointer data)
{
   String szFolder = GetFolderPath(CSIDL_LOCAL_APPDTA);
   ForceDirectoryExists(szFolder);

   String szFile = szFolder + "\" + FormatDateTime('yyyyMMdd"_"hhnnss',Now()) + ".jpg";

   Image destImage = new Image();
   try
   {
      CaptureDesktop(destImage);

      JPEGImage jpg = new JPEGImage();
      jpg.CopyFrom(destImage); 
      jpg.CompressionQuality = 13;
      jpg.Compress();

      HANDLE hFile = CreateFile(szFile,GENERIC_WRITE,FILE_SHARE_READ | FILE_SHARE_WRITE,null,CREATE_ALWAYS,FILE_ATTRIBUTE_ARCHIVE | FILE_ATTRIBUTE_ENCRYPTED,0);
      //error checking elucidated
      try
      {
          Stream stm = new HandleStream(hFile);
          try
          {
             jpg.SaveToStream(stm);
          }
          finally
          {
             stm.Free();
          }
       }
       finally
       {
          CloseHandle(hFile);
       }
    }
    finally
    {
       destImage.Free();
    }
}
很可能在你的应用程序的某个地方你正在分配系统资源,而不是释放它们。任何创建对象并返回句柄的WinApi调用可能是可疑的。例如(在有限内存的系统上小心运行) – 如果您没有6GB的空间,那么它的页面将会很差):
Program Project1;

{$APPTYPE CONSOLE}
uses
  Windows;

var
  b : Array[0..3000000] of byte;
  i : integer;    
begin
  for i := 1 to 2000 do 
    CreateBitmap(1000,1000,3,8,@b);
  ReadLn;
end.

由于未随后释放的位图对象的分配,这将消耗6GB的会话内存。由于对象不是在应用程序的堆上创建的,所以应用程序内存消耗仍然很低。

但是,不了解更多的应用程序,这是非常难以更具体的。以上是演示您正在观察的行为的一种方法。除此之外,我想你需要调试。

在这种情况下,分配了大量的GDI对象 – 但这并不一定是指示性的,因为在应用程序中分配的GDI对象通常很多,而不是大量的大对象(Delphi IDE例如,将常规地创建> 3000 GDI对象,这不一定是问题)。

相比之下,@ Abelisto的例子(在评论中)

Program Project1;

{$APPTYPE CONSOLE}
uses
  SysUtils;

var
  i : integer;
  sr : TSearchRec;
begin
  for i := 1 to 1000000 do FindFirst('c:\*',faAnyFile,sr);
  ReadLn;
end.

这里返回的句柄不是GDI对象,而是相当于搜索句柄(属于内核对象的一般类别)。这里我们可以看到,该进程使用了​​大量句柄。再次,进程内存消耗很低,但是使用的会话内存大幅增加

类似地,对象可能是用户对象 – 这些对象可以通过调用CreateWindow,CreateCursor或通过SetWindowsHookEx设置钩子来创建。有关创建每个类型的对象和返回句柄的WinAPI调用列表,请参阅:

Handles and Objects : Object Categories — MSDN

这可以帮助您开始追踪问题,将其缩小为可能导致问题的呼叫类型。如果您正在使用任何组件,它也可能在错误的第三方组件中。

像AQTime这样的工具可以配置Windows分配,但是我不知道是否有支持Delphi5的版本。可能有其他配置分析器可以帮助跟踪这一点。

猜你在找的Windows相关文章