ElasticSearch profile API `time_in_nanoseconds` value higher than `took` time

ElasticSearch profile API `time_in_nanoseconds` value higher than `took` time



I'm using the ElasticSearch profile API to help with a slow query.



When I read the elasticsearch profiling docs it sounded like the time_in_nanos value for queries in the shards should be less than the total took time when running a profiling query.


time_in_nanos


took



However, I got the following results back:



"took": 109695,
...
"profile":
"shards": [

"searches": [

"query": [

"type": "BooleanQuery",
"time": "1550750.786ms",
"time_in_nanos": 1550750786163
...

]

]

...
]




So, I see that the query took 109695 ms ~= 109 seconds which seems about right.


took


109695


109



However, I see the 1550750786163 value for time_in_nanos which corresponds to over 20 minutes. This does not match the took value. The curl command took about 2 minutes so the took time seems accurate while the time_in_nanos time does not seem accurate.


1550750786163


time_in_nanos


20


took


curl


took


time_in_nanos



What is the correct way to interpret the time_in_nanos value in an ElasticSearch profile query?


time_in_nanos



ES version: 5.6





When leveraging profiling, you need to be aware that this adds a fair amount of overhead, so what you see in the profiling results should be considered relative (e.g. to other query parts), not absolute times.
– Val
Aug 30 at 4:04





@Val - I know that profiling slows down the query (definitely not using in production). However, took should be <= than time_in_nanos in the same query, right? Or am I misunderstanding something?
– not_user9123
Aug 30 at 5:08


took


<=


time_in_nanos




1 Answer
1



According to the Elastic search Github repository, profile timings are a result of sampling. Because they are sampled, the raw timing numbers may not be accurate for large queries.



However, these numbers can be used to compare parts of the query with other parts of the query to determine the relative expense of the respective parts.



Source: https://github.com/elastic/elasticsearch/issues/33489



Required, but never shown



Required, but never shown






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.