MongoDB – Understanding Server Status with WiredTiger

compressionmongodb

I was testing my DB with Mongo 3.0 wiredTiger setup.
After restoring my database with wiredTIger i ran db.serverStatus.
I found following in console output.

"bytes currently in the cache" : 6009288998 (5.5 GB),
"maximum bytes configured" : 7516192768 (7 GB),
"bytes read into cache" : 18380155206 (17 GB),
"bytes written from cache" : 17020204785 (16 GB),

Could you please tell em what this output means.

I have 16 GB RAM in my server.
Database configuration is as follows:

MongoD instance 1
Databases 4
Original Data size with 2.6.4 : DB1- 25 GB, DB2- 19 GB, DB3- 5 GB, DB4- 3 GB
With wiredTiger : DB1- 3 GB, DB2- 1.9 GB, DB3- 0.9 GB, DB4- 0.5 GB

I was looking for updatye performance but it seems that performance seems to be degraded and when run bulk update on DB3 with 23000 update command
I saw this in Mongostat

    insert query update delete getmore command % dirty % used flushes vsize  res qr|qw ar|aw netIn netOut conn     time
        *0    *0     *0     *0       0     2|0     0.6   80.0       0  7.7G 7.4G   0|0   1|1  137b    15k    6 11:21:27
        *0    *0     *0     *0       0     3|0     0.9   79.9       0  7.7G 7.4G   0|0   1|1  195b    15k    6 11:21:28
        *0    *0     *0     *0       0     1|0     1.2   80.0       0  7.7G 7.4G   0|0   1|1   79b    15k    6 11:21:29
        *0    *0     *0     *0       0     1|0     1.4   80.0       0  7.7G 7.4G   0|0   1|1   79b    15k    6 11:21:30
        *0    *0     *0     *0       0     2|0     1.7   79.9       0  7.7G 7.4G   0|0   1|1  133b    15k    6 11:21:31
        *0    *0     *0     *0       0     1|0     2.0   80.0       0  7.7G 7.4G   0|0   1|1   79b    15k    6 11:21:32
        *0    *0     *0     *0       0     3|0     2.2   80.0       0  7.7G 7.4G   0|0   1|1  195b    15k    6 11:21:33
        *0    *0     *0     *0       0     1|0     2.4   80.0       0  7.7G 7.4G   0|0   1|1   79b    15k    6 11:21:34
        *0    *0     *0     *0       0     1|0     2.6   80.0       0  7.7G 7.4G   0|0   1|1   79b    15k    6 11:21:35
        *0    *0     *0     *0       0     2|0     2.9   80.0       0  7.7G 7.4G   0|0   1|1  133b    15k    6 11:21:36
    insert query update delete getmore command % dirty % used flushes vsize  res qr|qw ar|aw netIn netOut conn     time
        *0    *0     *0     *0       0     1|0     3.0   80.0       0  7.7G 7.4G   0|0   1|1   79b    15k    6 11:21:37
        *0    *0     *0     *0       0     3|0     3.1   80.0       0  7.7G 7.4G   0|0   1|1  195b    15k    6 11:21:38
        *0    *0     *0     *0       0     1|0     3.3   80.0       0  7.7G 7.4G   0|0   1|1   79b    15k    6 11:21:39
        *0    *0     *0     *0       0     1|0     3.5   80.0       0  7.7G 7.4G   0|0   1|1   79b    15k    6 11:21:40
        *0    *0     *0     *0       0     2|0     3.7   80.0       0  7.7G 7.4G   0|0   1|1  133b    15k    6 11:21:41

If you see dirty% is getting increased continuously.
Also after completing the updates i left the Db without untouched (no read and write) But still i was getting netIn and netOut showing bytes.

Could you please check the behaviour and explain it more as Mongo DB document section is not showing any thing in detail or these parameters.

Also i am not sure with one point does compression of index also reduces RAM requirement.

Best Answer

"bytes currently in the cache" : 6009288998 (5.5 GB), "maximum bytes

The number of bytes currently in wiredTiger cache.

configured" : 7516192768 (7 GB),

Maximum size cache is configured (by default half of physical memory on the server).

"bytes read into cache" : 18380155206 (17 GB),

Cumulative number of bytes that have been read into the cache since startup.

"bytes written from cache" : 17020204785 (16 GB),

Cumulative number of bytes that have been written out of the cache into files on disk since startup.

bulk update on DB3 with 23000 update command

You ran a single command with 23K update operations in it, so you were seeing the results you should have expected - you can see in the mongostat output that commands are constantly running and that you always have active writer.

If you actually want high throughput you should use multiple threads to send the operations in parallel to allow use of all cores on the machine.

see dirty% is getting increased continuously

That shows that in fact the writes are happening - higher and higher percentage of the cache is being written to (dirtied). When a checkpoint starts running, the dirty percentage will go down signifying that data from the cache is being persisted to disk (but of course, it's also been written already into write-ahead-log aka journal at the time of original write).

does compression of index also reduces RAM requirement

Yes, indexes are prefix-compressed and the format is the same on disk and in RAM.

Related Question