Skip to content

Commit 541ba1e

Browse files
author
Sam Kleinman
committed
minor: style updates storage faq
1 parent 88ba69f commit 541ba1e

File tree

1 file changed

+34
-20
lines changed

1 file changed

+34
-20
lines changed

source/faq/storage.txt

Lines changed: 34 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -18,13 +18,13 @@ the :doc:`complete list of FAQs </faq>` or post your question to the
1818
What are memory mapped files?
1919
-----------------------------
2020

21-
22-
A memory-mapped file is a file whose data has been mapped to a region of
23-
virtual memory via the ``mmap()`` system call. Memory-mapped files play a
24-
critical role in the MongoDB storage engine. By using memory mapped files
25-
MongoDB can treat the content of its data files as if they were in memory.
26-
This provides MongoDB with an extremely fast and simple method for accessing
27-
and manipulating data.
21+
A memory-mapped file is a file with data that the operating system
22+
places in memory by way of the ``mmap()`` system call. ``mmap()`` thus
23+
*maps* the file to a region of virtual memory. Memory-mapped files are
24+
the critical piece of the storage engine in MongoDB. By using memory
25+
mapped files MongoDB can treat the content of its data files as if
26+
they were in memory. This provides MongoDB with an extremely fast and
27+
simple method for accessing and manipulating data.
2828

2929
How do memory mapped files work?
3030
--------------------------------
@@ -39,18 +39,28 @@ How does MongoDB work with memory mapped files?
3939

4040
MongoDB uses memory mapped files for managing and interacting with all
4141
data. MongoDB memory maps data files to memory as it accesses
42-
documents. Data that isn't accessed is *not* mapped to memory.
42+
documents. Data that isn't accessed is *not* mapped to memory.
4343

4444
What are page faults?
4545
---------------------
4646

4747
Page faults will occur if you're attempting to access some part of a
48-
memory-mapped file that *isn't* in memory.
48+
memory-mapped file that *isn't* in memory.
49+
50+
If there is free memory, then the operating system can find the page
51+
on disk and load it to memory directly. However, if there is no free
52+
memory, the operating system must:
53+
54+
- find a page in memory that is stale or no longer needed,
4955

50-
This could potentially force the OS to find some not-recently-used
51-
page in physical RAM, get rid of it (maybe write it back to disk if
52-
it's changed since it loaded), go back to disk, read the page, and
53-
load it into RAM...an expensive task, overall.
56+
- if needed, the operating system might need to write this page to
57+
disk before removing it from memory.
58+
59+
- read the page from disk and load it into memory.
60+
61+
This process, particularly on an active system can take a long time,
62+
particularly in comparison to reading a page that is already in
63+
memory.
5464

5565
What is the difference between soft and hard page faults?
5666
---------------------------------------------------------
@@ -64,10 +74,10 @@ one list to another, and does not require as much time to complete.
6474
What tools can I use to investigate storage use in MongoDB?
6575
-----------------------------------------------------------
6676

67-
The :func:`db.stats()` function in the :program:`mongo` shell, will
68-
output the current state of the "active" database. The
77+
The :func:`db.stats()` method in the :program:`mongo` shell,
78+
returns the current state of the "active" database. The
6979
:doc:`/reference/database-statistics` document outlines the meaning of
70-
the fields output by :func:`db.stats()`.
80+
the fields in the :func:`db.stats()` output.
7181

7282
What is the working set?
7383
------------------------
@@ -77,12 +87,16 @@ uses in the course of normal operation. Often this is a subset of the
7787
total data size, but the specific size of the working set depends on
7888
actual moment-to-moment use of the database.
7989

80-
If you run a query that requires MongoDB to scan every document in a collection, the working set will expand to include every document. Depending on physical memory size, this may cause working set documents in other collections to be ejected from physical memory. The next time such documents are accessed, a hard page fault may be incurred.
90+
If you run a query that requires MongoDB to scan every document in a
91+
collection, the working set will expand to include every
92+
document. Depending on physical memory size, this may cause documents
93+
in the working set to "page out," or removed from physical memory by
94+
the operating system. The next time MongoDB needs to access these
95+
documents, MongoDB may incur a hard page fault.
8196

8297
If you run a query that requires MongoDB to scan every
83-
:term:`document` in a collection, the working set includes every active
84-
document in memory.
98+
:term:`document` in a collection, the working set includes every
99+
active document in memory.
85100

86101
For best performance, the majority of your *active* set should fit in
87102
RAM.
88-

0 commit comments

Comments
 (0)