# Paramedic - what do the the values in the index shard details mean? **URL:** \ **Category:** Elasticsearch\ **Created:** [January 9, 2013, 12:48pm UTC](https://discuss.elastic.co/t/paramedic-what-do-the-the-values-in-the-index-shard-details-mean/10279 "2013-01-09T12:48:50Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![timbunce](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timbunce/32/44945_2.png) [@timbunce](https://discuss.elastic.co/u/timbunce)\ **Post date:** [January 9, 2013, 12:48pm UTC](https://discuss.elastic.co/t/paramedic-what-do-the-the-values-in-the-index-shard-details-mean/10279/1 "2013-01-09T12:48:50Z")
We're using Paramedic ([https://github.com/karmi/elasticsearch-paramedic](https://github.com/karmi/elasticsearch-paramedic)) and finding it helpful to monitor our ElasticSearch cluster. At the bottom of the display it shows a summary line for each index with a Show Details button. When click that reveals a series of boxes for each shard (columns) on each node (rows). In each box there's a status heading and two figures: a time and a size. There's no indication what the figures relate to, other than relating to a particular shard on a particular node, obviously. I'm especially interested because we're having some performance issues and these number may shed light on it. For reference we have 3 nodes and our indices are about 5GB and get rolled over daily. Most of the figures are very low, say 20ms and 58b, but the shards for one row (node) show very high figures, say 52s and 1012mb. (I also once saw high values in just one column, i.e., one shard across several nodes.) It's possible it may be due to the particular way we're loading and querying the data, but I can't be sure without knowing more about the numbers. I'd be grateful if someone could shed some light on them. Tim. -- ---
**Author:** ![drewr](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/drewr/32/7803_2.png) [@drewr](https://discuss.elastic.co/u/drewr)\ **Post date:** [January 9, 2013, 8:44pm UTC](https://discuss.elastic.co/t/paramedic-what-do-the-the-values-in-the-index-shard-details-mean/10279/2 "2013-01-09T20:44:23Z")
Tim Bunce wrote: > We're using Paramedic ([GitHub - karmi/elasticsearch-paramedic: A simple tool to inspect the state and statistics about ElasticSearch clusters](https://github.com/karmi/elasticsearch-paramedic)) > and finding it helpful to monitor our Elasticsearch cluster. [...] > Most of the figures are very low, say 20ms and 58b, but the shards > for one row (node) show very high figures, say 52s and 1012mb. (I > also once saw high values in just one column, i.e., one shard > across several nodes.) > > It's possible it may be due to the particular way we're loading and > querying the data, but I can't be sure without knowing more about > the numbers. > > I'd be grateful if someone could shed some light on them. They're related to recovery, which is ES's term for initializing shards and making them ready for use. I believe the numbers are only updated when the shard is first recovered. Mine do not seem to update for ongoing replication. The primary shards (blue) will probably never have large numbers because they don't need to recover data (unless a replica has been promoted to a primary). And you may small numbers on replica shards if they were created at index time. From my usage, the numbers seems to be large when a replica was created from a large-ish primary shard and had to be recovered with a non-trivial amount of data. In your case, that 52s/1G was likely an initialized shard on a remote node, which is effectively 19.69MBps. That may or may not be acceptable depending on your network, but it's likely normal operation. -Drew -- ---
**Author:** ![Karel\_Minarik\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/karel_minarik_2/32/1078_2.png) [@Karel\_Minarik\_2](https://discuss.elastic.co/u/Karel_Minarik_2)\ **Post date:** [January 10, 2013, 2:45pm UTC](https://discuss.elastic.co/t/paramedic-what-do-the-the-values-in-the-index-shard-details-mean/10279/3 "2013-01-10T14:45:50Z")
To add to Drew's earlier explanation: - Paramedic is just an interface to the "Index Status API" here, to see the raw data: [http://localhost:9200/\_status?recovery=true](http://localhost:9200/_status?recovery=true) - The first value is indeed "time" spent recovering the shard, and the second value is the size in MB/GB of the index (see the raw data) These numbers indeed stay the same once the shard has been successfuly loaded/recovered. If one of the shards _of the same index_ is too big compared to the other shards (of the same index), you may be using the `routing` feature in a sub-optimal way, creating a "hot shard" with too much data. Karel On Wednesday, January 9, 2013 9:44:23 PM UTC+1, Drew Raines wrote: > Tim Bunce wrote: > > > We're using Paramedic ([GitHub - karmi/elasticsearch-paramedic: A simple tool to inspect the state and statistics about ElasticSearch clusters](https://github.com/karmi/elasticsearch-paramedic)) > > > and finding it helpful to monitor our Elasticsearch cluster. > > [...] > > > Most of the figures are very low, say 20ms and 58b, but the shards > > for one row (node) show very high figures, say 52s and 1012mb. (I > > also once saw high values in just one column, i.e., one shard > > across several nodes.) > > > > It's possible it may be due to the particular way we're loading and > > querying the data, but I can't be sure without knowing more about > > the numbers. > > > > I'd be grateful if someone could shed some light on them. > > They're related to recovery, which is ES's term for initializing > shards and making them ready for use. I believe the numbers are only > updated when the shard is first recovered. Mine do not seem to > update for ongoing replication. > > The primary shards (blue) will probably never have large numbers > because they don't need to recover data (unless a replica has been > promoted to a primary). And you may small numbers on replica shards > if they were created at index time. > > From my usage, the numbers seems to be large when a replica was > created from a large-ish primary shard and had to be recovered with a > non-trivial amount of data. In your case, that 52s/1G was likely an > initialized shard on a remote node, which is effectively 19.69MBps. > That may or may not be acceptable depending on your network, but it's > likely normal operation. > > -Drew -- ---
**Author:** ![timbunce](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timbunce/32/44945_2.png) [@timbunce](https://discuss.elastic.co/u/timbunce)\ **Post date:** [January 10, 2013, 7:27pm UTC](https://discuss.elastic.co/t/paramedic-what-do-the-the-values-in-the-index-shard-details-mean/10279/4 "2013-01-10T19:27:47Z")
On Thu, Jan 10, 2013 at 06:45:50AM -0800, Karel Minařík wrote: > To add to Drew's earlier explanation: > > - Paramedic is just an interface to the "Index Status API" here, to see the raw > data: [http://localhost:9200/\_status?recovery=true](http://localhost:9200/_status?recovery=true) > - The first value is indeed "time" spent recovering the shard, and the second value is the size in MB/GB > of the index (see the raw data) > These numbers indeed stay the same once the shard has been successfuly loaded/recovered. If one of the > shards _of the same index_ is too big compared to the other shards (of the same index), you may be using > the `routing` feature in a sub-optimal way, creating a "hot shard" with too much data. Thank you both for the detailed replies. Tim. -- ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:56am UTC](https://discuss.elastic.co/t/paramedic-what-do-the-the-values-in-the-index-shard-details-mean/10279/5 "2017-07-06T02:56:59Z")