MongoDb: acquireWaitCount and timeAcquiringMicros is missing from system.profile output I enabled profiling in a mongodb database since sometimes a query is fast while sometimes the exact same query takes a very long time, despite the execution plan being a IXSCAN. I suspect it is due to locking issues but in the database profiler output acquireWaitCount, timeAcquiringMicros and deadlockCount are missing. How can I find these values and how can I find the query that holds those locks? I am using mongodb 4.2
Here is the output from a database profiler query:
{
  &quot;op&quot;: &quot;query&quot;,
  &quot;ns&quot;: &quot;db.Caratula-221&quot;,
  &quot;command&quot;: {
    &quot;find&quot;: &quot;Caratula-221&quot;,
    &quot;filter&quot;: {
      &quot;EmpresaId&quot;: &quot;33707830439&quot;,
      &quot;Carpeta&quot;: &quot;VALOR CRITERIO&quot;
    },
    &quot;limit&quot;: 1,
    &quot;readConcern&quot;: {
      &quot;level&quot;: &quot;linearizable&quot;
    },
    &quot;$db&quot;: &quot;db&quot;,
    &quot;lsid&quot;: {
      &quot;id&quot;: &quot;a4c0937f-a77c-40c4-ae4a-f14fc8c67042&quot;
    },
    &quot;$clusterTime&quot;: {
      &quot;clusterTime&quot;: &quot;Timestamp(1598361984, 1)&quot;,
      &quot;signature&quot;: {
        &quot;hash&quot;: &quot;BinData(0,\&quot;AAAAAAAAAAAAAAAAAAAAAAAAAAA=\&quot;)&quot;,
        &quot;keyId&quot;: 0
      }
    }
  },
  &quot;keysExamined&quot;: 1,
  &quot;docsExamined&quot;: 1,
  &quot;cursorExhausted&quot;: true,
  &quot;numYield&quot;: 0,
  &quot;nreturned&quot;: 1,
  &quot;queryHash&quot;: &quot;D282DB09&quot;,
  &quot;planCacheKey&quot;: &quot;8921BB9F&quot;,
  &quot;locks&quot;: {
    &quot;ParallelBatchWriterMode&quot;: {
      &quot;acquireCount&quot;: {
        &quot;r&quot;: 2
      }
    },
    &quot;ReplicationStateTransition&quot;: {
      &quot;acquireCount&quot;: {
        &quot;w&quot;: 3
      }
    },
    &quot;Global&quot;: {
      &quot;acquireCount&quot;: {
        &quot;r&quot;: 2,
        &quot;w&quot;: 1
      }
    },
    &quot;Database&quot;: {
      &quot;acquireCount&quot;: {
        &quot;r&quot;: 1,
        &quot;w&quot;: 1
      }
    },
    &quot;Collection&quot;: {
      &quot;acquireCount&quot;: {
        &quot;r&quot;: 1
      }
    },
    &quot;Mutex&quot;: {
      &quot;acquireCount&quot;: {
        &quot;r&quot;: 1
      }
    },
    &quot;oplog&quot;: {
      &quot;acquireCount&quot;: {
        &quot;w&quot;: 1
      }
    }
  },
  &quot;flowControl&quot;: {
    &quot;acquireCount&quot;: 1
  },
  &quot;storage&quot;: {},
  &quot;responseLength&quot;: 2492,
  &quot;protocol&quot;: &quot;op_msg&quot;,
  &quot;millis&quot;: 8383,
  &quot;planSummary&quot;: &quot;IXSCAN { EmpresaId: 1, Carpeta: 1 }&quot;,
  &quot;ts&quot;: &quot;2020-08-25T13:26:32.526Z&quot;,
  &quot;client&quot;: &quot;192.168.2.78&quot;,
  &quot;allUsers&quot;: [
    {
      &quot;user&quot;: &quot;dbadmin&quot;,
      &quot;db&quot;: &quot;admin&quot;
    }
  ],
  &quot;user&quot;: &quot;dbadmin@admin&quot;
}
When those fields are not present in the profiling output, it means their value was 0.
That is, if the query never had to wait to acquire a lock, the acquireWaitCount field will not be present in the profiling data.
The profiling data out contains &quot;storage&quot;: {} which could mean 2 things:

all necessary documents and indexes were already in cache so the query didn't need to request anything from storage
there was a timeout attempting to retrieve the storage data

In the second case, there should be a log entry to that effect in the mongod log.
Another possibility is too many simultaneous read operations.  The storage engine has an upper limit on the number of concurrent reads it can handle, when that limit is exceeded, operations queue waiting for a turn in the storage engine.  This is not the same as locking, and is not reported in the profiling data.  You can see this occurring in the output of the serverStatus command