DOCS-491 review edits

Author: Bob Grabar

source/faq/fundamentals.txt

@@ -43,13 +43,11 @@ database table, and each document has
 one or more fields, which corresponds to a column in a relational
 database table.
 
-Collections are have some important differences from RDMS tables:
-
-- Documents in a single collection may have unique combination and set
-  of fields. Documents need not have identical fields.
-
-- You can add a field to some documents in a collection without adding
-  that field to all documents in the collection.
+Collections have important differences from RDMS tables. Documents in a
+single collection may have a unique combination and set of fields.
+Documents need not have identical fields. You can add a field to some
+documents in a collection without adding that field to all documents in
+the collection.
 
 .. see:: :doc:`/reference/sql-comparison`
 
@@ -174,7 +172,7 @@ SSD, this can be quite slow.
 
 One area to watch specifically in managing the size of your working set
 is index access patterns. If you are inserting into indexes at random
-locations (for example, with id's, which are effectively randomly
+locations (as would happen with id's that are randomly
 generated by hashes), you will continually be updating the whole index.
 If instead you are able to create your id's in approximately ascending
 order (for example, day concatenated with a random id), all the updates
@@ -183,35 +181,37 @@ index pages will be much smaller.
 
 It is fine if databases and thus virtual size are much larger than RAM.
 
-.. _faq-fundamentals-working-set-size:
+.. todo Commenting out for now:
+
+   .. _faq-fundamentals-working-set-size:
 
-How can I measure working set size?
------------------------------------
+   How can I measure working set size?
+   -----------------------------------
 
-Measuring working set size can be difficult; even if it is much smaller
-than total RAM. If the database is much larger than RAM in total, all
-memory will be indicated as in use for the cache. Thus you need a
-different way to estimate the working set size.
+   Measuring working set size can be difficult; even if it is much
+   smaller than total RAM. If the database is much larger than RAM in
+   total, all memory will be indicated as in use for the cache. Thus you
+   need a different way to estimate the working set size.
 
-One technique is to use the
-`eatmem.cpp <https://github.com/mongodb/mongo-snippets/blob/master/cpp/eatmem.cpp>`_.
-utility, which reserves a certain amount of system memory for itself.
-You can run the utility with a certain amount specified and see if the
-server continues to perform well. If not, the working set is larger than
-the total RAM minus the consumed RAM. The test will eject some data from
-the file system cache, which might take time to page back in after the
-utility is terminated.
+   One technique is to use the `eatmem.cpp
+   <https://github.com/mongodb/mongo-snippets/blob/master/cpp/eatmem.cpp>`_.
+   utility, which reserves a certain amount of system memory for itself.
+   You can run the utility with a certain amount specified and see if
+   the server continues to perform well. If not, the working set is
+   larger than the total RAM minus the consumed RAM. The test will eject
+   some data from the file system cache, which might take time to page
+   back in after the utility is terminated.
 
-Running eatmem.cpp continuously with a small percentage of total RAM,
-such as 20%, is a good technique to get an early warning if memory is
-too low. If disk I/O activity increases significantly, terminate
-eatmem.cpp to mitigate the problem for the moment until further steps
-can be taken.
+   Running eatmem.cpp continuously with a small percentage of total RAM,
+   such as 20%, is a good technique to get an early warning if memory is
+   too low. If disk I/O activity increases significantly, terminate
+   eatmem.cpp to mitigate the problem for the moment until further steps
+   can be taken.
 
-In :term:`replica sets <replica set>`, if one server is underpowered the
-eatmem.cpp utility could help as an early warning mechanism for server
-capacity. Of course, the server must be receiving representative traffic
-to get an indication.
+   In :term:`replica sets <replica set>`, if one server is underpowered
+   the eatmem.cpp utility could help as an early warning mechanism for
+   server capacity. Of course, the server must be receiving
+   representative traffic to get an indication.
 
 How do I calculate how much RAM I need for my application?
 ----------------------------------------------------------
@@ -221,7 +221,7 @@ How do I calculate how much RAM I need for my application?
 The amount of RAM you need depends on several factors, including but not
 limited to:
 
-- The relationship between :ref:`database storage </faq/storage>` and working set.
+- The relationship between :doc:`database storage </faq/storage>` and working set.
 
 - The operating system's cache strategy for LRU (Least Recently Used)
 
@@ -241,13 +241,9 @@ your particular usage.
 To calculate how much RAM you need, you must calculate your working set
 size, i.e., the portion of your data that is frequently accessed. This
 depends on your access patterns, what indexes you have, and the size of
-your documents. To calculate working set size, see:
-
-- :ref:`faq-fundamentals-working-set`
-
-- :ref:`faq-fundamentals-working-set-size`
+your documents. To calculate working set size, see :ref:`faq-fundamentals-working-set`.
 
-If page faults are low (for example, below than 100 / sec), your
+If page faults are infrequent, your
 working set fits in RAM. If fault rates rise higher than that, you risk
 performance degradation. This is less critical with SSD drives than
 with spinning disks.
@@ -305,15 +301,16 @@ directly from the indexes and/or data files.
 Are writes written to disk immediately, or lazily?
 --------------------------------------------------
 
-Writes are physically written to the journal within 100
+Writes are physically written to the :doc:`journal </administration/journaling>` within 100
 milliseconds. At that point, the write is "durable" in the sense that
 after a pull-plug-from-wall event, the data will still be recoverable after
 a hard restart.
 
 While the journal commit is nearly instant, MongoDB writes to the data
 files lazily. MongoDB may wait to write data to the data files for as
-much as one minute. This does not affect durability, as the journal
-has enough information to ensure crash recovery.
+much as one minute by default. This does not affect durability, as the journal
+has enough information to ensure crash recovery. To change the interval
+for writing to the data files, see :setting:`syncdelay`.
 
 What language is MongoDB written in?
 ------------------------------------