Working with the Run-time Viewer

Use the Run-time Viewer to view run-time information for queries issued by various applications and to cancel long-running queries (if your user is permitted to do so).

When you execute a search or a query in the Finder or run an aggregation command in the Aggregation Builder these are timed by the system and the run-time is shown on the Finder or Aggregation Builder itself. Only the last run is displayed. Click on the clock icon to open the Run-time Viewer. The Run-time Viewer shows you timing information for all latest runs (the number shown is configured by a preference value) as shown below:


For each timed item the Run-time Viewer shows the command run (e.g. a find or an aggregation command), which collection it was run on, how long it took, when it was run, what application it was run from, and details (such as the find projection sort or the aggregation pipeline stages). You can sort or filter on any of these items. The default sort order is most recent first. To return to this sort order sort on the “Run At” column. Regardless of the sort order, when a new entry occurs it is always placed at the top (the Run-time Viewer has a 10 second polling interval but you can always refresh manually). To reset filters click the refresh icon and to clear the display click the clear icon. Click the “open table” icon to export the data into tabular data

A run time of -1 means that the operation being timed is still running; it will be updated to the elapsed time when the operation completes. You may also see a -1 as the runtime if the operation resulted in an error (e.g. you ran an aggregation pipeline and the result was too large).

You can interrupt long-running database operations using each screen’s “cancel long running” button or on the Run-time Viewer’s screen. When an operation is canceled the run time information is set to -2. See Canceling long running operations: for more information.

The Finder provides granular timing information. It times the initial find operation but since the result set is a cursor, it also times the next chunk brought back each time you skip or advance the cursor. It also measures the time taken to compute the result set size. Note that this is controlled by a preference since large collections and/or slow databases can cause the computation of the result set to do a full collection scan. Therefore, be careful when using this preference. When you set the size to be computed the result set size will also be computed for you as part of the query timing.

In addition to viewing the data in the Run-time Viewer you can configure the Run-time Viewer to persist run-time data in either the main database you connect to or in the Studio database. Use the Preferences link in the Run-time Viewer application to set this (0 to not persist, 1 to persist in the Studio database and 2 to persist in your database). Note that if you are running the Studio in read-only mode you can only persist this information in a Studio database. By default no run-time information is persisted. When you persist this data in a Studio database it maintains the documents in a collection called lmrm__json_studio_runner_times. When you persist the data in your database it maintains the documents in a collection called json_studio_runner_times.

When persisted, each document recording a run-time measurement takes the following form:

   "_id" : ObjectId("52bc7bfdda06a172221f8d1a"),
   "app" : "Finder",
   "at" : ISODate("2013-12-26T18:57:01Z"),
   "time" : NumberLong(0),
   "connection" : "",
   "jsonStudio" : "",
   "collection" : "chargeDevices",
   "q" : {
      "text" : "Operated by Source East  \r\n0845 519 8676\r\nSee",
      "st_addr" : "Volcan Road North",
      "_id" : ObjectId("5281404abb1177ca391c0d7c")
   "p" : {
      "text" : 1,
      "country" : 1,
      "kw" : 1,
      "org" : 1
   "s" : {

   "type" : "find"

This is useful since you can later load such a collection into the Finder or Aggregation Builder and do your own analysis on run-times, use the Visualizer to create graphs, etc.

Note that all executions are displayed by the Run-time Viewer but not all are persisted. This is intentional so as not to fill these collections with transient queries. When you use the Finder for example, you may have the setting that a new query is issued every time you point-and-click or use a facet. These are all logged in the Run-time Viewer but never persisted to the database. A record is persisted only when you explicitly click one of the execute buttons.

Canceling long running operations:

When you click on the cancel-long-operation button the Studio tries to cancel all currently running database operations. There are two types of cancels - an in-Studio cancel and a Mongodb interruption.

If the long-running operation is within the Studio itself, an example being an iteration where each database operation is short but there are many, then the operation is canceled always. If the long-running operation is within Mongodb (an example being a query that involves a scan of a very large collection without the use of an index) then the Studio cannot itself cancel the operation, it needs Mongodb to do so. Mongodb has a mechanism called killop to do this and the Studio attempts to make this call. Whether this call succeeds or not depends on the roles possessed by the user you are logged in with. In current versions of Mongodb the killOp is called by db.eval and can only be performed by a user with full admin privileges prior to version 2.6. If your user possesses these permissions then the database operations will be interrupted. Otherwise, the database operation will complete and the Studio will remain blocked on the database.

If your user does not posses full admin privileges the other options for continuing to work are:

  • Ask a DBA to run the killOp on your query on your behalf.
  • Restart the Tomcat server and re-login. Note that your query will still be running within the database until completion.
  • Close your browser completely, open a new process and re-login. Note that your query will still be running within the database until completion.

Also note that canceling long operations does not work in sharded environments.

If you are running version 2.6 you can ask a DBA to create a custom roles with the appropriate privileges so that you can kill long-running queries. The command to create the new role (and then grant the role to your user) is:

use admin
   createRole: "killOpRole",
   privileges: [
      { resource: {cluster: true}, actions: ["killop", "inprog"]},
      { resource: {db: "", collection: ""}, actions: ["killCursors"]}
   roles: []

Additionally, you can simply use the SRM to control these queries.

Table Of Contents

Previous topic

Working with Sonar SQL Transfer

Next topic

Working with SonarProfiler

Copyright © 2013-2016 jSonar, Inc
MongoDB is a registered trademark of MongoDB Inc. Excel is a trademark of Microsoft Inc. JSON Studio is a registered trademark of jSonar Inc. All trademarks and service marks are the property of their respective owners.