Databases Reference
In-Depth Information
NOTE
The
Memory: Page Faults/sec
counter in Performance Monitor includes
both hard and soft page faults; therefore, if you want to monitor just the
performance that is sapping hard page faults, you need to look at
Memory: Page
Reads/sec
to get the number of times the disk was accessed to resolve hard
page faults, and then compare it to
Memory: Pages Input/sec
to calculate the average
number of pages being read in each disk access.
On a system with enough RAM to give every process all the memory it needs, the VMM doesn't
have to do much other than hand out memory and clean up after a process is done with it. On a
system without enough RAM to go around, the job is a little more involved. The VMM has to do
some work to provide each process with the memory it needs when it needs it. It does this by using
the page i le to temporarily store data that a process hasn't accessed for a while. This process is
called
paging
, and the data is often described as having been paged out to disk.
The Virtual Memory Manager keeps track of each mapping for VAS addresses using page tables, and the
mapping information itself is stored in a page table entry (PTE). This is illustrated in Figure 3-2 using
two SQL Server instances as an example. Note that the dashed arrow indicates an invalid reference that
will generate a hard page fault when accessed, causing the page to be loaded from the page i le.
Virtual Memory Manager
Page Table
Physical RAM
Virtual Memory
Address 1
Virtual Memory
Address 2
Page Table Entry
(PTE)
000 1
00 1 0
0000
0101 1
1001
0
00
01 10
0101
01 10
0000
01 1 1
1101 0
1100
0
00
PTE
SQL
Server
Inst 1
Virtual Memory
Address 3
000 1
01 10
00 1 0
0000
0111 1
1001
1
00
PTE
Virtual Memory
Address 4
PTE
8TB VAS
Page Table
Page file
Virtual Memory
Address 1
Virtual Memory
Address 2
PTE
000 1
01 10
00 1 0
0000
0101 1
1001
0
00
PTE
SQL
Server
Inst 2
Virtual Memory
Address 3
PTE
Virtual Memory
Address 4
PTE
8TB VAS
FIGURE 3-2
Search WWH ::
Custom Search