3

I am using db.setProfilingLevel(1, 1000) to set the profile level for each database. I see the level can be set for each database but the slowms is a global state. Is there any way to set this value for each individual database?

If I can't set it for each individual database, why there is a method db.setProfilingLevel(level, slowms) accept the second parameter as slowms. It looks like this parameter is for global value rather than database value. What is confused is this method is specific for setting a single database profile level but for some reasons it also set slowms in global setting.

  • Sadly, answer is no... Without changing source code. – JJussi Apr 11 '18 at 5:38
  • @JJussi Thanks for reply. I have updated my question could you let me know what you think about the method setProfilingLevel? – Joey Yi Zhao Apr 11 '18 at 6:26
2

As per MongoDB documentation of MongoDB High Availability by @Afshin Mehrabani & MongoDB BOL here

To enable profiling for a MongoDB , you can use following function:

db.setProfilingLevel(level, slowms)

where

level - This refers to verbosity level of profiling

slowms - This is optional. It is used to define the slow operation threshold in milliseconds.

The following command is a sample of issuing the proceding function in the mongo interactive shell:

db.setProfilingLevel(1,1000)

so, the proceding command enables profiling for the MongoDB instance with level 1 and threshold 1000 milliseconds.

The output of this command in the mongo shell is as the following below

>db.setProfilingLevel(1,1000)
{"was" : 0, "slowms" : 100, "ok" : 1}

The MongoDB engine supports three main levels of proviling. The following table shows the three different level of profilling:

Level     Description

0        This indicates that profilling is disabled

1        This refer to only slow log operations

2        This refers to all log operations

When using the first level of profiling , the database's profiler doesn't save anything related to operations. With level 1, the profiler logs slow operations.

There is a setting parameter that defines the slow operations threshold. Using the slowOpThresholdMs configuration parameter, you can define a threshold for slow operations. Then, the profiler logs operations with slower execution time than the define value.

To define the slowOpThresholdMs parameter, you can either use a configuration file to define the value or you can pass the value to the second parameter of the setProfilingLevel function.

By using level 2 of profiling , the profiler records all operations without considering any conditions.

To understand the structure of this function better, consider the following command :

db.setProfilingLevel(1, 1000)

after issuing the preceding command , the database profiler records all operations with an execution time greater than 1000 milliseconds.

Note : Using the profiler negatively performance because the profiler records redundant for a part, or the entire database operations. It's recommended to keep it off unless you need to diagnose the database.

After configuring the profiler engine , you can query logs from database using the system.profile collection.

As per MongoDB Jira Blog here The slowms constant is not per database but is process wide.

> db.setProfilingLevel(1,1000)
{ "was" : 0, "slowms" : 100, "ok" : 1 }
> db.getProfilingStatus()
{ "was" : 1, "slowms" : 1000 }
> use test2
switched to db test2
> db.setProfilingLevel(1,2)
{ "was" : 0, "slowms" : 1000, "ok" : 1 }
> db.getProfilingStatus()
{ "was" : 1, "slowms" : 2 }
> use test
switched to db test
> db.getProfilingStatus()
{ "was" : 1, "slowms" : 2 }

Notice how slowms went to 2 in the test database... That is not good.

As here was closed won't fix but if the syntax of db.setProfilingLevel is changed to only affect a single database there will be requirement to have syntax to set globally what slowms is (without having to restart mongod with new slowms setting).

Note that this change as proposed is backwards breaking to every instruction given by our support which is currently assumed to have global effect.

Recommend we consider non-backwards breaking syntax, like db.setProfilingLevel(0,1,false) where last parameter is "applyGlobally" and by default is true. (or applyToCurrentDB only and by default is false).

For further your ref here and here

| improve this answer | |
  • Thanks for your detailed explanation. Why does the method db.setProfilingLevel(1, 1000) change slowms setting for all databases in the instance? – Joey Yi Zhao Apr 12 '18 at 1:46
  • @ZhaoYi , As per MongoDB jira blog jira.mongodb.org/browse/SERVER-4785 db.setProfilingLevel(0,1,false) where last parameter is "applyGlobally" and by default is true. – Md Haidar Ali Khan Apr 12 '18 at 4:06
  • 1
    @MdHaidarAliKhan Jira.mongodb.org is an issue tracker (for feature suggestions and improvements), not a blog. Unless an issue is resolved with a released server fixVersion, syntax discussion such as your quote from SERVER-4785 is a proposal rather than a working example. As at MongoDB 3.6, the slowms threshold can only be set as a global configuration value for a mongod instance. – Stennie Apr 14 '18 at 22:45
2

setProfilingLevel actually affects two things. First parameter (level) tells when system writes to profile -collection (0-never, 1-only when slower than slowms or 2-always). Second parameter (slowms) affects actually always to syslog output of ALL databases. So, with db.setProfilingLevel(0,-1), nothing is ever written to profile-collection, but ALL queries (of all DBs) are written to mongod.log

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.