Verify journalCommitInterval and running journalLatencyTest

I am using MongoDB 2.6.3 on CentOS, and I have changed the  --journalCommitInterval parameter by passing its value as a command line param to mongod, upon start-up.

Now I am trying to verify if the change is effective or not. Looking at the documentation, I see 2 ways to do it, but none of them is working on my server:

(1) Running db.serverStatus() command - The output of this command does NOT have any 'Journaling' document. I can not find any way to force the command to give more details or to return that document in its output. In fact what I get as the output is much much less than the info that the documentation on the webpage claims that will be returned. 

(2) Running  journalLatencyTest . I see that I have to enable test commands once I am starting mongod. So I added that parameter to my mongod strat-up scripts as:

mongod --shardsvr --dbpath $dataPath --port $port --journal --journalCommitInterval $interval --fork--setParameter enableTestCommands=1

and then tried to run the test against admin db (as documentation suggests) - but no success:

mongos> use admin;
switched to db admin
mongos> db.runCommand({ journalLatencyTest: 1 });
{ "ok" : 0, "errmsg" : "no such cmd: journalLatencyTest", "code" : 59 }


Thus the documentation on this matter seems confusing (at least to me), and I am just wondering how I can verify my desired changed.

Thanks in advance for any help or hint.



In db.serverStatus() journaling details are in section "durability" or "dur"

You could simple raise the logging verbosity and see how frequently the logs show journal flush happening.

Thanks for your reply.
But that was one of my issues, the output of serverStatus() command does NOT have any such document on my front.
Is there a param or flag that I need to set, so serverStatus() command returns more details ?

Here is what I get:

mongos> db.serverStatus();
{
        "host" : "host-10",
        "version" : "2.6.3",
        "process" : "mongos",
        "pid" : NumberLong(16227),
        "uptime" : 3139,
        "uptimeMillis" : NumberLong(3138514),
        "uptimeEstimate" : 3096,
        "localTime" : ISODate("2014-11-13T01:43:34.076Z"),
        "asserts" : {
                "regular" : 0,
                "warning" : 0,
                "msg" : 0,
                "user" : 0,
                "rollovers" : 0
        },
        "connections" : {
                "current" : 1,
                "available" : 3275,
                "totalCreated" : NumberLong(1)
        },
        "extra_info" : {
                "note" : "fields vary by platform",
                "heap_usage_bytes" : 3263376,
                "page_faults" : 0
        },
        "network" : {
                "bytesIn" : 463,
                "bytesOut" : 1001,
                "numRequests" : 6
        },
        "opcounters" : {
                "insert" : 0,
                "query" : 0,
                "update" : 0,
                "delete" : 0,
                "getmore" : 0,
                "command" : 6
        },
        "mem" : {
                "bits" : 64,
                "resident" : 10,
                "virtual" : 226,
                "supported" : true
        },
        "metrics" : {
                "getLastError" : {
                        "wtime" : {
                                "num" : 0,
                                "totalMillis" : 0
                        }
                }
        },
        "ok" : 1
}

Well, this is because this process is the mongos - unlike mongod,
mongos does not have any storage of its own.

You need to run this directly on mongod in question.