Information Technology Reference
In-Depth Information
window of time) in real memory so they can operate without spending most of
their time waiting for pages to be swapped to and from disk. When virtualization
was first introduced, the replacement algorithms and multiprogramming controls
needed to prevent thrashing had yet to be developed.
In a thrashing system, an application runs briefly, and then experiences a page
fault by referring to a virtual address that is not currently in memory. It stalls and
waits for that page to be fetched from disk, which may take millions of instruction
times. Most elapsed time is spent waiting for disk rather than running applica-
tions. In a thrashing system, an application spends its time slice page-faulting
its working set from disk into memory, and in so doing evicts the pages of other
applications from memory to disk. At the end of the application's time slice, the
next application runs and does the same thing to pages loaded by its predecessor.
Applications continually evict one another's pages and try to reestablish their own
working sets, rather than accomplishing actual work.
Thrashing can happen on any virtual memory system, but was especially intense
with virtual machines because guest operating systems have larger memory foot-
prints than a single application, and because they exhibit poor locality of reference.
An application program running in a virtual memory OS such as Oracle Solaris or
a Linux distribution has a working set size based on its application needs. In con-
trast, most operating systems refer to as much RAM as is installed on the computer,
typically for buffering file contents. If such an OS runs on a machine with 8 GB of
RAM, it will use 8 GB of RAM, regardless of application needs. When an OS runs
in a real machine, this practice makes perfect sense, as unused RAM is wasted and
could have been used to reduce I/O delays. In a virtual machine, however, memory
seen by the guest is virtual memory, backed by physical RAM shared by all guests.
Using extra virtual memory in one guest reduces the physical memory available for
other guests. It is typical for the physical memory footprint of a guest to approach
the virtual memory size of the guest. For example, a Solaris or Linux guest running
in a virtual machine sized as 1 GB would tend to occupy 1 GB of RAM because it will
touch all of the pages it thinks it owns. A “best practice” for virtual machines is to
reduce the virtual memory size as much as is feasible to reduce this effect.
A pathological situation called “double paging” can occur when the guest oper-
ating system itself provides virtual memory. Consider a guest's application that
suffers a page fault, causing the guest OS to write a least recently used (LRU)
page to its swap disk to provide a real-memory page frame to page-in the faulted
location; this operation requires a disk write and a disk read. Recall that what the
guest considers “real memory” is actually “virtual memory” from the hypervisor's
view. If that guest's page has already been swapped out by the hypervisor, there
will be an additional disk read (from the hypervisor's external swap/page space) to
bring in the page, which the guest will immediately write to its swap/page space
and then discard.
Search WWH ::
Custom Search