mongodb · epc · Jan 23, 2015
diff --git a/source/administration/monitoring.txt b/source/administration/monitoring.txt
@@ -8,7 +8,7 @@ Monitoring is a critical component of all database administration. A
 firm grasp of MongoDB's reporting will allow you to assess the state
 of your database and maintain your deployment without crisis.
 Additionally, a sense of MongoDB's normal operational parameters will
-allow you to diagnose before they escalate to failures.
+allow you to diagnose problems before they escalate to failures.
 
 This document presents an overview of the available monitoring utilities
 and the reporting statistics
@@ -362,7 +362,7 @@ Locks
 
 MongoDB uses a locking system to ensure data set consistency. However, if
 certain operations are long-running, or a queue forms, performance
-will slow as requests and operations wait for the lock. Lock-related
+will degrade as requests and operations wait for the lock. Lock-related
 slowdowns can be intermittent. To see if the lock has been affecting
 your performance, look to the data in the
 :ref:`globalLock` section of the :dbcommand:`serverStatus` output. If

diff --git a/source/administration/production-notes.txt b/source/administration/production-notes.txt
@@ -200,7 +200,7 @@ NUMA configuration may degrade performance.
 
 See `The MySQL "swap insanity" problem and the effects of NUMA
 <http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the
--nu ma-architecture/>`_ post, which describes the effects of NUMA on
+-numa-architecture/>`_ post, which describes the effects of NUMA on
 databases. This blog post addresses the impact of NUMA for MySQL,
 but the issues for MongoDB are similar. The post introduces NUMA and
 its goals, and illustrates how these goals are not compatible with

diff --git a/source/reference/command/serverStatus.txt b/source/reference/command/serverStatus.txt
@@ -138,7 +138,7 @@ page.
 
    .. data:: serverStatus.locks.acquireCount
 
-      Number of times the lock was aquired in the specified mode.
+      Number of times the lock was acquired in the specified mode.
 
    .. data:: serverStatus.locks.acquireWaitCount
 

diff --git a/source/reference/method/db.currentOp.txt b/source/reference/method/db.currentOp.txt
@@ -384,7 +384,7 @@ Output Fields
    .. data:: currentOp.lockStats.timeAcquiringMicros
 
       Cumulative time in microseconds that the operation had to wait to
-      aqcuire the locks.
+      acquire the locks.
 
       :data:`~currentOp.lockStats.timeAcquiringMicros` divided by
       :data:`~currentOp.lockStats.acquireWaitCount` gives an

diff --git a/source/release-notes/3.0-compatibility.txt b/source/release-notes/3.0-compatibility.txt
@@ -429,7 +429,7 @@ The minimum fully compatible driver versions are:
 .. list-table::
    :header-rows: 1
 
-   * - Driver Lanugage
+   * - Driver Language
      - Minimum Fully Compatible Version
 
    * - :ecosystem:`C </drivers/c>`