DOCS-491 review edits

Author: Bob Grabar

source/faq/fundamentals.txt

@@ -169,7 +169,7 @@ Must my working set size fit RAM?
 ---------------------------------
 
 Your working set should stay in memory to achieve good performance.
-Otherwise lots of random disk IO's will occur, and unless you are using
+Otherwise many random disk IO's will occur, and unless you are using
 SSD, this can be quite slow.
 
 One area to watch specifically in managing the size of your working set
@@ -191,14 +191,14 @@ 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 our working set size.
+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 eaten RAM. The test will eject some data from
+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.
 
@@ -227,13 +227,14 @@ limited to:
 
 - The impact of :doc:`journaling </administration/journaling>`
 
-- Using page faults and other MMS gauges to detect when you need more RAM
+- The number or rate of page faults and other MMS gauges to detect when
+  you need more RAM
 
 MongoDB makes no choices regarding what data is loaded into memory from
 disk. It simply :ref:`memory maps <faq-storage-memory-mapped-files>` all
 its data files and relies on the operating system to cache data. The OS
 typically evicts the least-recently-used data from RAM when it runs low
-on memory. For example if indexes are accessed more frequently then
+on memory. For example if indexes are accessed more frequently than
 documents then indexes will more likely stay in RAM, but it depends on
 your particular usage.
 
@@ -246,10 +247,10 @@ your documents. To calculate working set size, see:
 
 - :ref:`faq-fundamentals-working-set-size`
 
-If page faults are low (for example, below than 100 / sec), then your
+If page faults are low (for example, below than 100 / sec), 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
-spinning disks.
+with spinning disks.
 
 How do I read memory statistics in the UNIX ``top`` command
 -----------------------------------------------------------