[SERVER-1957] implement profile for mongos Created: 16/Oct/10  Updated: 06/Dec/22  Resolved: 31/May/19

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Eliot Horowitz (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 16
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-12521 Can't use system.profile on a sharded... Closed
is duplicated by SERVER-14119 You should be able to set profiler fr... Closed
Related
is related to SERVER-14900 log slow queries on mongos Closed
Assigned Teams:
Sharding
Participants:

 Description   

2 choices:

A) shard level profiling

  • needs to set profiling on all shards
  • needs to aggregate results for a query on profile collection

B) profile in mongos

Leaning towards B.
keep data purely in memory



 Comments   
Comment by Ratika Gandhi [ 31/May/19 ]

We don't have any plans of enhancing profile supports in MongoS at this time. Please re-open if needed. 

Comment by Ramon Fernandez Marina [ 15/Oct/16 ]

Thanks for your interest in this old ticket stefan@close.io. Unfortunately I have no additional information for you, only that tickets in "Planning Bucket A" like this one get regularly revisited for consideration.

As you know, recent releases of MongoDB have included numerous changes around sharding. The good new is that there are many more sharding improvements planned, and the not-so-good news is that this ticket has to compete for resources with other sharding-related work.

Any changes in the planning and scheduling of this ticket will be reflected here, so please continue to watch for updates.

Thanks,
Ramón.

Comment by Stefan Wojcik [ 04/Oct/16 ]

Building on top of option B, I would LOVE to see some extra profiling data for mongos specifically. Right now, there's zero visibility into how much time it took mongos to do a broadcast query, how many shards were targeted, how quickly each of them responded, and how much time it took to merge/sort the results and apply the _skip/_limit. Are you guys planning to address this lack of crucial profiling information in any way?

Comment by Eliot Horowitz (Inactive) [ 17/Aug/11 ]

error message fixed.

Comment by Markus Korn [ 16/Aug/11 ]

Before this feature gets implemented it would be great if mongodb could be a bit more precise and verbose with the error it raises when someone tries to enable profiling in a sharded setup.
Right now I get:

> db.commandHelp("profile")
Tue Aug 16 13:17:12 uncaught exception: error

{ "$err" : "unrecognized command: profile", "code" : 13390 }

> db.setProfilingLevel(2)
Tue Aug 16 13:17:32 uncaught exception: error

{ "$err" : "unrecognized command: profile", "code" : 13390 }

Which I cannot make any sense of.

Generated at Thu Feb 08 02:58:34 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.