MongoDB has a profiler and it’s not SQL

2 minute read time.

Today we are going to look into how to adjust the profiler logging in mongodb. Why, you may ask? Because. . .  Actually, it is to help reduce the total number of rows logged by mongodb. In recent iterations of Syracuse component updates, R&D has added a new collection called dbmessage. What is it? No clue. Will anyone tell me what the heck it is? nope. top secret.

I guess we just have to live with it? right? We could just drop the collection right out of the database. Yep we sure can. And the dbmessage just disappears. Until you restart Syracuse in which it realizes its missing and regenerates a new collection. My best guess is that it’s a visual representation of the constant connection Syracuse needs to mongo. The dbmessage calls will make up roughly 70% of the logs in mongo (if you look right now you can see them).

So, since we cannot get rid of it permanently, we can at least reduce its total impact on the logging process. We can do this with a specific set of logging controls called “operationProfiling”. The profiler will record all requests that take a specific amount of time or greater and write it to the logs. Whether or not the profiler is actually enabled (it’s a hard-coded default setting that is not changeable). This threshold is set in the same config file for mongo where the operationProfiling is.

As you can see (in above screenshot) by default, it’s recording any call that takes longer than 100ms which is majority of the requests that Syracuse will ask for. At this point we can remove the # signs and make our corrections. The slowOpThresholdMs can be set to any number. As far as I can tell, that is. I usually just set it to 999999 because I am lazy and I don’t want to see anything.

If you do what I did it would look like this:

Now you can save the config file and restart the mongodb service so that the service will re-cache the config file. Just so you all know, In a production environment you will want to start off with a small number and adjust according to the need of the system. 999999 is just for representation and is not used in a production environment (I do however use it in demo environments because mongo logs are annoying).

Example of what they look like in the logs

I set the config file, stopped mongodb service, deleted the log file, started service and now my log is empty like this.

It should remain like this and only record any calls over the set ms.

No more annoying getMore calls. YAY!

There is a multitude of adjustments and settings you can do besides asjusting the logging or rotateLogs on MongoDB’s website. If you would like to dive deeper into Mongo config file I would suggest taking gander at their forum at: https://docs.mongodb.com/manual/reference/configuration-options/

If you want to read more about the profiler in general, you can read about it here:

https://docs.mongodb.com/manual/tutorial/manage-the-database-profiler/