@@ -219,6 +219,62 @@ incompatible with production databases.
219219
220220.. _production-readahead:
221221
222+ Virtualization
223+ --------------
224+
225+ Generally MongoDB works very well in virtualized environments, with
226+ the exception of OpenVZ.
227+
228+ EC2
229+ ~~~
230+ Compatible. No special configuration requirements.
231+
232+ VMWare
233+ ~~~~~~
234+
235+ Some suggest not using overcommit as they may cause issues. Otherwise compatible.
236+
237+ Cloning a VM is possible. For example you might use this to spin up a
238+ new virtual host that will be added as a member of a replica set. If
239+ Journaling is enabled, the clone snapshot will be consistent. If not
240+ using journaling, stop mongod, clone, and then restart.
241+
242+ OpenVZ
243+ ~~~~~~
244+
245+ Issues have been reported here.
246+
247+ iostat
248+ ------
249+
250+ On Linux, use the iostat command to check if disk I/O is a bottleneck
251+ for your database.
252+
253+ We generally find the form:
254+
255+ .. code-block:: bash
256+
257+ iostat -xm 2
258+
259+ to work well. (Use a number of seconds with iostat, otherwise it will
260+ display stats since server boot, which is not very useful.)
261+
262+ Use the mount command to see what device your :term:`data directory
263+ <dbpath` resides on.
264+
265+ Key fields from ``iostat``:
266+
267+ - %util: this is the most useful field for a quick check, it
268+ indicates what percent of the time the device/drive is in use. If
269+ the number if near 100%, your server may be physical disk I/O
270+ bound. (There are some volume situations where this statistic
271+ overstates, but most often it is correct.)
272+
273+ - avgrq-sz: average request size. The smaller this number, the more
274+ random your IO operations are. This is in sectors : typically
275+ sectors are 512 bytes, so multiply by 0.5 to see average request
276+ size in kilobytes.
277+
222278Hard Drive Readahead
223279--------------------
224280
0 commit comments