The resident memory size represents the number of pages in memory actually touched by the mongod
process. If that is significantly lower than the available memory and data exceeds the available memory (yours does), then it could be a case of simply not having actively touched enough pages yet.
To determine if this is the case, you should run free -m
, the output should look something like this:
free -m
total used free shared buffers cached
Mem: 3709 3484 224 0 84 2412
-/+ buffers/cache: 987 2721
Swap: 3836 156 3680
In my example, cached is not close to the total, which means that not only has mongod not touched enough pages, the filesystem cache has not yet even been filled by pages being read from the disk in general.
A quick remedy for this would be the touch command (added in 2.2) - it should be used with caution on large data sets as it will attempt to load everything into RAM even if the data is far too large to fit (causing a lot of disk IO and page faults). It will certainly fill up the memory effectively though :)
If your cached value is close to the total available, then your issue is that a large number of pages being read into memory from disk are not relevant to (and hence not touched by) the mongod process. The usual candidate for this kind of discrepency is readahead. I've already covered that particular topic elsewhere in detail, so I'll just link those two answers for future reading if necessary.
I tested this, first I installed MongoDB 2.4.6 with brew, and then used launchctl to load and unload. In my testing, it sends a SIGTERM to the mongod process which then shuts down as expected. Here are the commands I used as well as the logs for the mongod
process:
Commands:
launchctl load -w /usr/local/Cellar/mongodb/2.4.6/homebrew.mxcl.mongodb.plist
launchctl unload -w /usr/local/Cellar/mongodb/2.4.6/homebrew.mxcl.mongodb.plist
Logs:
tail -f /usr/local/var/log/mongodb/mongo.log
Tue Oct 22 17:33:32.774 [initandlisten] MongoDB starting : pid=13192 port=27017 dbpath=/usr/local/var/mongodb 64-bit host=adamc-mbp.local
Tue Oct 22 17:33:32.774 [initandlisten] db version v2.4.6
Tue Oct 22 17:33:32.774 [initandlisten] git version: nogitversion
Tue Oct 22 17:33:32.774 [initandlisten] build info: Darwin minimountain.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 BOOST_LIB_VERSION=1_49
Tue Oct 22 17:33:32.774 [initandlisten] allocator: tcmalloc
Tue Oct 22 17:33:32.774 [initandlisten] options: { bind_ip: "127.0.0.1", command: [ "run" ], config: "/usr/local/etc/mongod.conf", dbpath: "/usr/local/var/mongodb", logappend: "true", logpath: "/usr/local/var/log/mongodb/mongo.log" }
Tue Oct 22 17:33:32.775 [initandlisten] journal dir=/usr/local/var/mongodb/journal
Tue Oct 22 17:33:32.775 [initandlisten] recover : no journal files present, no recovery needed
Tue Oct 22 17:33:32.806 [websvr] admin web console waiting for connections on port 28017
Tue Oct 22 17:33:32.806 [initandlisten] waiting for connections on port 27017
Tue Oct 22 17:34:21.682 [signalProcessingThread] got signal 15 (Terminated: 15), will terminate after current cmd ends
Tue Oct 22 17:34:21.682 [signalProcessingThread] now exiting
Tue Oct 22 17:34:21.682 dbexit:
Tue Oct 22 17:34:21.682 [signalProcessingThread] shutdown: going to close listening sockets...
Tue Oct 22 17:34:21.682 [signalProcessingThread] closing listening socket: 9
Tue Oct 22 17:34:21.682 [signalProcessingThread] closing listening socket: 10
Tue Oct 22 17:34:21.682 [signalProcessingThread] closing listening socket: 11
Tue Oct 22 17:34:21.682 [signalProcessingThread] removing socket file: /tmp/mongodb-27017.sock
Tue Oct 22 17:34:21.682 [signalProcessingThread] shutdown: going to flush diaglog...
Tue Oct 22 17:34:21.682 [signalProcessingThread] shutdown: going to close sockets...
Tue Oct 22 17:34:21.682 [signalProcessingThread] shutdown: waiting for fs preallocator...
Tue Oct 22 17:34:21.682 [signalProcessingThread] shutdown: lock for final commit...
Tue Oct 22 17:34:21.683 [signalProcessingThread] shutdown: final commit...
Tue Oct 22 17:34:21.692 [signalProcessingThread] shutdown: closing all files...
Tue Oct 22 17:34:21.692 [signalProcessingThread] closeAllFiles() finished
Tue Oct 22 17:34:21.692 [signalProcessingThread] journalCleanup...
Tue Oct 22 17:34:21.692 [signalProcessingThread] removeJournalFiles
Tue Oct 22 17:34:21.692 [signalProcessingThread] shutdown: removing fs lock...
Tue Oct 22 17:34:21.693 dbexit: really exiting now
I did this several times to confirm the behavior. In Chrome at least the status page no longer responds and I receive an error (as expected) once it has been shut down.
The only difference between what I am doing and what you have posted is that I am not using sudo
(in fact it refuses to load or unload due to dubious ownership of the file). So, I changed the ownership of the plist file to root and tried sudo
with the same results.
The only way I was able to recreate a failure to unload was as follows:
- Start with
sudo launchctl
(root is the owner of the plist file)
- Change ownership of the plist file back to my regular user
- Try to unload without
sudo
This fails with an error however:
launchctl: Error unloading: homebrew.mxcl.mongodb
Note: Subsequently changing the ownership back to the regular user made the unload successful
Similarly, this also produces the same error:
- Start without
sudo
(regular user owns the plist file)
- Change ownership of the plist file to root
- Try to unload with sudo
I was unable to recreate the silent failure you seem to be having with any of the various combinations I tried.
Some information gathering tips which may give you a clue:
- When you launch with launchctl, what does the output of this command say:
launchctl list | grep mongodb
? (it should list something like 13340 - homebrew.mxcl.mongodb
- If you run this same command after you run unload (without error), it should show the exit status in that middle column (-15)
- Sometimes it can take a while for MongoDB to exit - so tail the log (see example above), see if the TERM signal is being received
- Why is it you are using sudo? Have you installed brew as root? If so this might be at the core of the issue here - generally it is not recommended to run MongoDB as root.
Best Answer
The commands you've listed are administrative commands that you should expect to be limited when using a managed Database-as-a-Service provider. I would anticipate further restriction for commands that are either subsumed by the managed platform functionality (for example, replica set configuration) or likely to introduce performance/stability issues. For comparison, MongoDB Atlas also has a list of unsupported commands for shared or dedicated clusters.
In the event your deployment gets in state where admin help is needed, the provider's support staff can presumably escalate as required.
For context on the specific commands you've listed:
clone
andcopydb
are officially deprecated since MongoDB 4.0 but also discouraged in older server versions. These commands do not produce point-in-time snapshots of the source database and will introduce performance and concurrency problems (such as blocking foreground index builds). Usemongodump
andmongorestore
instead.clean
is an internal command with no end user utility.shutdown
doesn't make sense for a managed service where you don't have direct access to restart a MongoDB process. It is possible the provider's UI or API provides an option to restart or suspend a member of your deployment but reasonable not to have direct access.repairDatabase
andrepairCursor
should only be used as a last resort to salvage data if you don't have a viable backup for your deployment. This is definitely a scenario where you'd be working with the provider's support team to get your deployment back online with the most reasonable approach.