JZTXT

Virtual memory running out when there are free physical memory?

发布时间 2023-09-28 16:19:41作者: 不及格的程序员-八神
Asked 7 years, 8 months ago
Modified 7 years, 8 months ago
Viewed 1k times
 
1

My firefox suddenly become sluggish and then froze. I opened Process Explorer to see what's going on and noticed the main thread of firefox.exe was stuck in the kernal function NtAllocateVirtualMemory. At that time, the process was only using 1.5GB of virtual memory space and I had more than 1GB of commit limit free and at least 1GB of RAM free. I thought the memory space of Firefox might have become too fragmented, so I killed it.

Then I got a surprise graph like below.

screen shot

As you can see, there has always been RAM free during the entire period but I seemed to have hit commit limit anyhow. The page files are set to system managed and the system drive have more than 17GB free, so I have no idea how I could hit the limit.... Any thoughts on this?

System is Windows 10 build 10586. I have 8GB of RAM.

(It seems Firefox or some related thing has claimed a hidden 3-4 GB of virtual memory space. I think it could be the display driver, but why did the system not expand the page file?)

Share
Improve this question
 
  •  
    Are you running a 32-bit version of Firefox? 
    – spherical_dog
     Jan 16, 2016 at 0:06
  •  
    Yes, it is 32 bit, but I can normally go up to 1.9GB of virtual memory use with no problem what so ever. 
    – billc.cn
     Jan 16, 2016 at 0:09
  •  
    Well, the virtual memory limit for a single 32-bit process is 2GB if it is not large address space aware. 32-bit Firefox is supposed to be address space aware, which doesn't explain the crash, but you might want to test the 64-bit version and see if it crashes. 
    – spherical_dog
     Jan 16, 2016 at 0:13

1 Answer

4
 

Physical memory and commit limit are distinct resources. You can run out of one even though you have plenty of the other left. You most likely need a larger page file to raise the commit limit.

Physical memory is very much like cash in the bank. Commit limit is very much like checks that you've already written. Even if you have lots of cash in the bank, if you've written a lot of checks, you may be unable to write more checks.

Say you have a system with 3GB of free RAM and no page file. And say an application asks for 2GB of memory. The system will say "yes" and raise the commit limit by 2GB. The system still has 3GB of free RAM, because the application hasn't used any yet. But if another application requests 2GB of memory, the OS will have to refuse. It has 3GB in the bank but has written a check for 2GB, so it can't write another check for 2GB.

Share
Improve this answer
 
  •  
    Okay, this I don't get (even though all the evidences point to it). In my naive computer science-y understanding, the commit limit should be page-able RAM + page file. How could it not be able to use all the RAM? Any pointer to any reading I can do? Also, does not explain why the OS failed to expand the page file as it is set to system managed. 
    – billc.cn
     Jan 16, 2016 at 0:20 
  •  
    I get the argument in your example, but at that point I killed Firefox, it can at most request 500MB more memory before it runs out of process address space. However, the system was 1GB below the commit limit. (I've realised the commit graph has a scaling issue due to the limit nearly halved after FF was killed.) 
    – billc.cn
     Jan 16, 2016 at 0:33
  •  
    @billc.cn Taking your questions in order: It can use all the RAM (for example, to fulfill existing obligations), it just can't reserve any more memory, so requests to reserve memory fail. The OS didn't expand the page file because memory was reserved but not used, the page file won't be expanded until it's used. Likely, at least part of your issue was also that the 32-bit process' virtual address space was fragmented. 
    – David Schwartz
     Jan 17, 2016 at 0:22
  •  
    @billc.cn The point that I think is not clear is that even though total RAM is part of the commit limit, RAM is not marked as "used" just because virtual memory has been committed. If I commit 1 GB, that uses 1 GB of the system commit limit, but it doesn't actually use any RAM at all until I store something in that region. And then it only uses as much as needed to store what I've written. After a while it may use less than that, if I don't reference it much and the OS decides to move some of it to the pagefile to make it more available for some other, higher-activity process. 
    – Jamie Hanrahan
     Apr 7, 2018 at 18:22