隨緣

 

 

星期日, 今天還真陽光普照啊, 竟然在冬天會有23°C的天氣. 難得有這麼好的天氣, 就去看看花展吧! 果然, 還是車位會特別緊張, 要兜了4~5圈才有個位子停車. 原來今天有一對新人在這裏照相啊, 果然在結婚的時候人, 會特別的美麗的. 這個花展雖然不算很大, 但卻挺漂亮的; 雖然不是有很多的種類, 但就有著很多不同的排列.

今天就來練習一下淺景深的攝影吧! 結果還算有一些滿意的, 有空就到相簿去看看吧! 哈哈! 照了好的相還真開心喎!

Processes and Address Spaces
 
All processes (e.g. application executables) running under 32 bit Windows gets virtual memory addresses (a Virtual Address Space) going from 0 to 4,294,967,295 (2*32-1 = 4 GB), no matter how much RAM is actually installed on the computer. 
 
In the default Windows OS configuration, 2 GB of this virtual address space are designated for each process’ private use and the other 2 GB are shared between all processes and the operating system.  Normally, applications (e.g. Notepad, Word, Excel, Acrobat Reader) use only a small fraction of the 2GB of private address space.  The operating system only assigns RAM page frames to virtual memory pages that are in use. 
 
Physical Address Extension (PAE) is the feature of the Intel 32 bit architecture that expands the physical memory (RAM) address to 36 bits (see KB articles 268363 and 261988).  PAE does not change the size of the virtual address space, which remains at 4 GB, just the amount of actual RAM that can be addressed by the processor.
 
The translation between the 32 bit virtual memory address used by the code running in a process and the 36 bit RAM address is handled automatically and transparently by the computer hardware according to translation tables maintained by the operating system.  Any virtual memory page (32 bit address) can be associated with any physical RAM page (36 bit address).
 
Here's a list of how much RAM the various Windows versions and editions support (as of Nov 2004):
 
     Windows NT 4.0: 4 GB
     Windows 2000 Professional: 4 GB
     Windows 2000 Standard Server: 4 GB
     Windows 2000 Advanced Server: 8GB
     Windows 2000 Datacenter Server: 32GB
     Windows XP Professional: 4 GB
     Windows Server 2003 Web Edition: 2 GB
     Windows Server 2003 Standard Edition: 4 GB
     Windows Server 2003 Enterprise Edition: 32 GB
     Windows Server 2003 Datacenter Edition: 64 GB
 
Pagefile
 
RAM is a limited resource, whereas virtual memory is, for most practical purposes, unlimited.  There can be a large number of processes each with its own 2 GB of private virtual address space.  When the memory in use by all the existing processes exceeds the amount of RAM available, the operating system will move pages (4 KB pieces) of one or more virtual address spaces to the computer’s hard disk, thus freeing that RAM frame for other uses.  In Windows systems, these “paged out” pages are stored in one or more files called pagefile.sys in the root of a partition.  There can be one such file in each disk partition.  The location and size of the page file is configured in SystemProperties, Advanced, Performance (click the Settings button).
 
A frequently asked question is how big should I make the pagefile?  There is no single answer to this question, because it depends on the amount of installed RAM and how much virtual memory that workload requires.  If there is no other information available, the normal recommendation of 1.5 times the amount of RAM in the computer is a good place to start.  On server systems, a common objective is to have enough RAM so that there is never a shortage and the pagefile is essentially, not used.  On these systems, having a really large pagefile may serve no useful purpose.  On the other hand, disk space is usually plentiful, so having a large pagefile (e.g. 1.5 times the installed RAM) does not cause a problem and eliminates the need to fuss over how large to make it. 
 
Performance, Architectural Limits and RAM
 
On any computer system, as load (number of users, amount of work being done) increases, performance (how long it takes to do each task) will decrease, but in a non linear fashion.  Any increase in load (demand) beyond a certain point will result in a dramatic decrease in performance.  This means that some resource is in critically short supply and has become a bottleneck.
 
At some point, the resource in critical short supply can not be increased.  This means an architectural limit has been reached.  Some commonly reported architectural limits in Windows include:
 
  1. 2 GB of shared virtual address space for the system
  2. 2 GB of private virtual address space per process
  3. 660 MB System PTE storage
  4. 470 MB paged pool storage
  5. 256 MB nonpaged pool storage
 
The above applies to Windows 2003 Server specifically (from Knowledgebase article 294418), but also apply to Windows XP and Windows 2000.
 
Commonly found and quoted statements such as:
 
   with a Terminal Server, the 2 GB of shared address space will be completely used before 4 GB of RAM is used
 
may be true in some situations, but you need to monitor your system to know whether they apply to your particular system or not.  In some cases, these statements are conclusions from specific Windows NT 4.0 or Windows 2000 environments and don't necessarily apply to Windows Server 2003.  Significant changes were made to Windows Server 2003 to reduce the likelihood that these architectural limits will in fact be reached in practice.  For example, some processes that were in the kernel have been moved to non kernel processes to reduce the amount of memory used in the shared virtual address space.
 
Monitoring RAM and Virtual Memory usage
 
Performance Monitor (Start, Administrative Tools, Performance) is the principle tool for monitoring system performance and identifying what the bottleneck really is.  Here's a summary of some important counters and what they tell you.
 
Memory, Committed Bytes - this is a measure of the demand for virtual memory
         It shows how many bytes have been allocated by processes and to which the operating system has committed a RAM page frame or a page slot in the pagefile (perhaps both).  As Committed Bytes grows above the amount of available RAM, paging will increase and the amount of the pagefile in use will also increase.  At some point, paging activity will start to significantly impact perceived performance.
 
Process, Working Set, _Total - this is a measure of the amount of virtual memory in "active" use
          It shows how much RAM is required so that the actively used virtual memory for all processes is in RAM. This is always a multiple of 4,096, which is the page size used in Windows.  As demand for virtual memory increases above the available RAM, the operating system will adjust how much of a process's virtual memory is in its Working Set to optimize the use of available RAM and minimize paging.
 
Paging File, %pagefile in use - this is a measure of how much of the pagefile is actually being used.
          This is the counter to use to determine if the pagefile is an appropriate size.  If this counter gets to 100, the pagefile is completely full and things will stop working.  Depending on the volatility of your workload, you probably want the pagefile large enough so that it is normally no more than 50 - 75% used.  If a lot of the pagefile is in use, having more than one on different physical disks, may improve performance. 
 
Memory, Pages/Sec - this is one of the most misunderstood measures. 
          A high value for this counter does not necessarily imply that your performance bottleneck is shortage of RAM.  The operating system uses the paging system for purposes other than swapping pages due to memory over commitment.
 
Memory, Pages Output/Sec - this shows how many virtual memory pages were written to the pagefile to free RAM page frames for other purposes each second.
         This is the best counter to monitor if you suspect that paging is your performance bottleneck.  Even if Committed Bytes is greater than the installed RAM, if Pages Output/sec is low or zero most of the time, there is not a significant performance problem from not enough RAM.
 
Memory, Cache Bytes
Memory, Pool Nonpaged Bytes
Memory, Pool Paged Bytes
Memory, System Code Total Bytes
Memory, System Driver Total Bytes
          The sum of these counters is a measure of how much of the 2GB of the shared part of the 4 GB virtual address space is actually in use.  Use these to determine if your system is reaching one of the architectural limits discussed above.
 
Memory, Available MBytes - this measures how much RAM is available to satisfy demands for virtual memory (either new allocations, or for restoring a page from the pagefile).
          When RAM is in short supply (e.g. Committed Bytes is greater than installed RAM), the operating system will attempt to keep a certain fraction of installed RAM available for immediate use by copying virtual memory pages that are not in active use to the pagefile.  For this reason, this counter will not go to zero and is not necessarily a good indication of whether your system is short of RAM.