-
Type: Improvement
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: 2.0.5
-
Component/s: Diagnostics
-
None
-
Environment:Linux 64 Bit
-
Server 2.7.3, Server 2.7.4, Query 2.7.8
When a profile line becomes too large, essential fields as for example "millis" are omitted:
PRIMARY> db.system.profile.findOne({err:{$exists:true},abbreviated:{$exists:false}}) { "ts" : ISODate("2012-06-26T04:37:06.372Z"), "client" : "x.x.x.x", "user" : "", "err" : "profile line too large (max is 100KB)" }
However, in some cases there is a field "abbreviated" in which we can find the missing "millis" field:
PRIMARY> db.system.profile.findOne({err:{$exists:true},abbreviated:{$exists:true}}) { "ts" : ISODate("2012-06-24T19:02:46.054Z"), "client" : "x.x.x.x", "user" : "", "err" : "profile line too large (max is 100KB)", "abbreviated" : "{ ts: new Date(1340564566053), op: \"getmore\", ns: \"offerStore.offer\", query: { _id: { $in: [ 258406435, ...cut out... ] } }, cursorid: 532897853037598938, nreturned: 2708, responseLength: 4195498, millis: 5620, client: \"x.x.x.x\", user: \"\" }" }
As the field "abbreviated" is a String, not an Object, we can't even use dot notation to reach into the object to retrieve millis. Thus, we need to use eval or a regexp to do so.
Essential information like millis, cursorid, nreturned, responseLength, client and user should ALWAYS be present in a profiling document. When the profile line is too large, then it's certainly not to large because of these fields. It's too large because of the query! So cut out or shorten the query but not the other fields!
Last but not least: What are the rules to have an "abbreviated" field or not? Btw. what has been abbreviated - it seems to be complete though?
- is related to
-
SERVER-16324 Command execution log line displays "query not recording (too large)" instead of abbreviated command object
- Closed
- related to
-
SERVER-14990 Do not omit the information about the batch if its too big
- Closed