Database Reference
In-Depth Information
Counting the number of network connection descriptors is just as easy:
lsof | grep mongo | grep TCP | wc -l
When it comes to file descriptors, the best strategy is to start with a high limit so that
you never run out in production. You can check the current limit temporarily with the
ulimit
utility:
ulimit -Hn
To r a i s e t h e l i m it p e r m a n e n t ly, o p e n y o u r
limits.conf
file with your editor of choice:
sudo vim /etc/security/limits.conf
Then set the soft and hard limits. These are specified on a per-user basis. This exam-
ple assumes that the
mongodb
user will be running the
mongod
process:
mongod hard nofile 2048
mongod hard nofile 10240
The new settings will take effect when that user logs in again.
C
LOCKS
It turns out that replication is susceptible to
clock skew
. If the clocks on the machines
hosting the various nodes of a replica set ever diverge, then replication may not func-
tion properly. This isn't ideal, but fortunately there's a solution. You need to ensure
that each of your servers uses
NTP
(Network Time Protocol)
to keep their clocks synchro-
nized. On Unix variants, this means running the
ntpd
daemon. On Windows, the Win-
dows Time Services fulfills this role.
T
HE
CLOUD
More and more users are running MongoDB in virtualized environments, collectively
known as
the cloud
. Among these, Amazon's
EC2
has become a deployment environ-
ment of choice because of its ease of use, wide geographic availability, and competitive
pricing.
EC2
, and other environments like it, can be adequate for deploying
MongoDB, but you should keep in mind the drawbacks, especially if your application
will be pushing MongoDB to its limits.
The first problem with
EC2
is that you're forced to choose from a limited set of
instance types. At the time of this writing, you can't get a virtual instance with more
than 68
GB
of
RAM
. A limit like this forces you to shard your database once your work-
ing set grows beyond those 68
GB
, and this might not be appropriate for every applica-
tion. If you can run on real hardware, you can run with more
RAM
; the cost of
hardware being equal, this can affect the decision to shard.
Another potential problem is that
EC2
is essentially a black box. You may experi-
ence service blips or instance slowdowns and have no way of diagnosing or remedying
them.
The third issue concerns storage.
EC2
allows you to mount virtual block devices
known as
EBS
volumes
.
EBS
volumes provide a great deal of flexibility, allowing you to
add storage and move volumes across machines as needed.
EBS
also allows you to take