Click here to Skip to main content

Welcome to the Lounge! RSS Feed     


For lazing about and discussing anything in a software developer's life that takes your fancy.

The Lounge is rated PG. If you're about to post something you wouldn't want your kid sister to read then don't post it. No flame wars, no abusive conduct and please don't post ads.

Technical discussions are welcome, but if you need specific help please use the programming forums.


 
You must Sign In to use this message board. (secure sign-in)
 
Search this forum  
 FAQ
    Noise  Layout  Per page  Show 
  Refresh
GeneralRe: Minimize Applications PinmemberJudah Himango5:14 30 Aug '07  
GeneralRe: Minimize Applications PinPopularmemberGraham Bradshaw4:08 30 Aug '07  
GeneralRe: Minimize Applications Pinmemberleppie4:33 30 Aug '07  
GeneralRe: Minimize Applications PinmemberZoltan Balazs4:43 30 Aug '07  
GeneralRe: Minimize Applications Pinmemberleppie5:13 30 Aug '07  
GeneralRe: Minimize Applications PinmemberPIEBALDconsult6:25 30 Aug '07  
GeneralRe: Minimize Applications PinmemberMike Dimmick12:25 30 Aug '07  
Task Manager's 'Mem Usage' column (in Windows Server 2003 and earlier) shows process working set size. The working set is the set of pages belonging to that application which are currently in physical memory. Windows trims (discards pages of) the working set of a process when a window belonging to the process is minimized.
 
When the pages are discarded from the working set, they are not immediately cleared. Instead, they are placed on the end of either the standby list (if not modified) or the modified list (if they are modified since last read). The processor helps out by setting a bit in the corresponding page table entry when it writes to a page. The OS lazy-writes pages on the modified list; once written back (to the original file for a memory-mapped file or to the page file for other pages) the page is put on the standby list. Windows has another list, the zero-page list, which contains only pages where every byte is zero. When a CPU is idle, it runs the zero-page thread, which takes pages from the top of the standby list and writing zeros to them, then puts them on the zero page list. This happens until a threshold of zero pages has been reached - it won't consume the entire standby list.
 
When an application or the OS needs a new page, the OS will grab a page near the top of the zero-page or standby list. If it's giving the page to an application, it will always be a zero page, unless the page is going to be filled with data from a file (for example, a memory-mapped file, or being paged back in from a page file). Executables and DLLs are memory-mapped files. Kernel-mode requests get standby pages. If the appropriate list is empty it will first grab a page from the other list (zeroing it if taking from the standby list). If both are empty it will start stealing pages from other working sets.
 
The issue of interpreting what Windows is doing with memory is tricky because of these lists and how Task Manager displays them. The standby and modified lists are counted under 'Available', but because they contain recently-used application data, they are also considered a cache and are counted under 'System Cache'. On my systems, Available + System Cache often exceeds the actual amount of physical memory in the system!
 
Because the working set size is effectively out of the application's control - being trimmed by the OS or growing as the application references pages - it's not really a good measure of anything much. The same application with the same workload will use a greater or lesser amount of physical memory depending on how much physical memory is fitted in total, and what other activity is happening on the system. A slightly better measure is the 'VM Size' column, which is actually the same as the Process:Private Bytes counter in the Performance console's System Monitor. This measures how many bytes (really, how many pages) have been committed by use of the VirtualAlloc API. Other allocation APIs (HeapAlloc, malloc, new, garbage-collected heap in the .NET Framework) manage blocks of virtual address space on behalf of the application, to allow more flexible allocation sizes.
 
Stability. What an interesting concept. -- Chris Maunder

GeneralBuzzyCode = dotnetspider [modified] PinmvpJ4amieC2:48 30 Aug '07  
GeneralRe: BuzzyCode = dotnetspider [modified] PinmvpNishant Sivakumar3:36 30 Aug '07  
GeneralRe: BuzzyCode = dotnetspider PinmemberTony M John5:39 7 Sep '07  
GeneralRe: BuzzyCode = dotnetspider PinmvpNishant Sivakumar7:11 7 Sep '07  
GeneralRe: BuzzyCode = dotnetspider PinmvpNishant Sivakumar3:39 30 Aug '07  
GeneralRe: BuzzyCode = dotnetspider Pinmvptoxcct3:49 30 Aug '07  
GeneralRe: BuzzyCode = dotnetspider PinmvpNishant Sivakumar3:51 30 Aug '07  
GeneralRe: BuzzyCode = dotnetspider Pinmvptoxcct3:59 30 Aug '07  
AnswerRe: BuzzyCode = dotnetspider PinmemberVikram A Punathambekar4:49 30 Aug '07  
GeneralRe: BuzzyCode = dotnetspider PinmemberVasudevan Deepak Kumar3:01 31 Aug '07  
GeneralRe: BuzzyCode = dotnetspider PinmemberTony M John6:38 7 Sep '07  
GeneralRe: BuzzyCode = dotnetspider PinmemberVasudevan Deepak Kumar0:31 31 Aug '07  
GeneralRe: BuzzyCode = dotnetspider Pinmemberleppie4:29 30 Aug '07  
GeneralRe: BuzzyCode = dotnetspider PinmemberChris Meech5:17 30 Aug '07  
GeneralRe: BuzzyCode = dotnetspider PinsupporterJohn Cardinal9:25 30 Aug '07  
GeneralRe: BuzzyCode = dotnetspider Pinmemberdan neely9:56 30 Aug '07  
GeneralRe: BuzzyCode = dotnetspider PinmemberTony M John20:13 1 Sep '07  
GeneralRe: BuzzyCode = dotnetspider Pinmembermartin_hughes5:16 30 Aug '07  

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.


Advertise | Privacy | Mobile
Web04 | 2.5.120210.1 | Last Updated 13 Feb 2012
Copyright © CodeProject, 1999-2012
All Rights Reserved. Terms of Use
Layout: fixed | fluid