# Excessive number of "rescheduling interrupts" **URL:** \ **Category:** Elasticsearch\ **Created:** [July 4, 2012, 8:22pm UTC](https://discuss.elastic.co/t/excessive-number-of-rescheduling-interrupts/8317 "2012-07-04T20:22:30Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Douglas\_Muth](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/douglas_muth/32/29006_2.png) [@Douglas\_Muth](https://discuss.elastic.co/u/Douglas_Muth)\ **Post date:** [July 4, 2012, 8:22pm UTC](https://discuss.elastic.co/t/excessive-number-of-rescheduling-interrupts/8317/1 "2012-07-04T20:22:30Z")
I noticed some slowness on one of my EC2 instances running Amazon Linux today, and discovered that my install of Elastic Search is chewing up hundreds of thousands of interrupts every second: [![](http://i.imgur.com/O0P9r.png) ](http://i.imgur.com/O0P9r.png) There is very little load on that instance, and just to make sure my indexer wasn't at fault, I stopped it. Then I stopped Elastic Search, and saw the number of interrupts as reported by vmstat drop to almost zero. I am running Elastic Search version 0.18.5, on a single node with no clustering. Can anyone offer any suggestions for things I can look at or check? Thanks, -- Doug -- [http://twitter.com/dmuth](http://twitter.com/dmuth) ---
**Author:** ![otisg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/otisg/32/492_2.png) [@otisg](https://discuss.elastic.co/u/otisg)\ **Post date:** [July 5, 2012, 5:16am UTC](https://discuss.elastic.co/t/excessive-number-of-rescheduling-interrupts/8317/2 "2012-07-05T05:16:01Z")
That's a crazy high number. Have you tried this on a different/multiple servers? Different OS? Kernel? JVM? ## Otis Search Analytics - [Cloud Monitoring Tools & Services | Sematext](http://sematext.com/search-analytics/index.html) Scalable Performance Monitoring - [Sematext Monitoring | Infrastructure Monitoring Service](http://sematext.com/spm/index.html) On Wednesday, July 4, 2012 4:22:30 PM UTC-4, Douglas Muth wrote: > I noticed some slowness on one of my EC2 instances running Amazon > Linux today, and discovered that my install of Elastic Search is > chewing up hundreds of thousands of interrupts every second: > > [Imgur: The magic of the Internet](http://i.imgur.com/O0P9r.png) > > There is very little load on that instance, and just to make sure my > indexer wasn't at fault, I stopped it. Then I stopped Elastic Search, > and saw the number of interrupts as reported by vmstat drop to almost > zero. > > I am running Elastic Search version 0.18.5, on a single node with no > clustering. > > Can anyone offer any suggestions for things I can look at or check? > > Thanks, > > -- Doug > > -- > [http://twitter.com/dmuth](http://twitter.com/dmuth) ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [July 5, 2012, 5:54am UTC](https://discuss.elastic.co/t/excessive-number-of-rescheduling-interrupts/8317/3 "2012-07-05T05:54:27Z")
Leapsecond effect ? David 😉 Twitter : @dadoonet / @elasticsearchfr Le 5 juil. 2012 à 07:16, Otis Gospodnetic [otis.gospodnetic@gmail.com](mailto:otis.gospodnetic@gmail.com) a écrit : > That's a crazy high number. Have you tried this on a different/multiple servers? Different OS? Kernel? JVM? > > ## Otis > > Search Analytics - [Cloud Monitoring Tools & Services | Sematext](http://sematext.com/search-analytics/index.html) > Scalable Performance Monitoring - [Sematext Monitoring | Infrastructure Monitoring Service](http://sematext.com/spm/index.html) > > On Wednesday, July 4, 2012 4:22:30 PM UTC-4, Douglas Muth wrote: > I noticed some slowness on one of my EC2 instances running Amazon > Linux today, and discovered that my install of Elastic Search is > chewing up hundreds of thousands of interrupts every second: > > [http://i.imgur.com/O0P9r.png](http://i.imgur.com/O0P9r.png) > > There is very little load on that instance, and just to make sure my > indexer wasn't at fault, I stopped it. Then I stopped Elastic Search, > and saw the number of interrupts as reported by vmstat drop to almost > zero. > > I am running Elastic Search version 0.18.5, on a single node with no clustering. > > Can anyone offer any suggestions for things I can look at or check? > > Thanks, > > -- Doug > > -- > [http://twitter.com/dmuth](http://twitter.com/dmuth) ---
**Author:** ![Douglas\_Muth](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/douglas_muth/32/29006_2.png) [@Douglas\_Muth](https://discuss.elastic.co/u/Douglas_Muth)\ **Post date:** [July 9, 2012, 3:34pm UTC](https://discuss.elastic.co/t/excessive-number-of-rescheduling-interrupts/8317/4 "2012-07-09T15:34:03Z")
On Thu, Jul 5, 2012 at 1:54 AM, David Pilato [david@pilato.fr](mailto:david@pilato.fr) wrote: > Leapsecond effect ? Revisiting this old thread, I just wanted to update everyone with the resolution. It WAS in fact a leap-second issue! I wasn't sure if that was the culprit at first, since it was right around the time Amazon Web Services had that EC2 outage, and I didn't know if it might have been related to that or not. (we had issues with some of our other instances) That said, here was the fix: /etc/init.d/ntp stop; date; date `date +"%m%d%H%M%C%y.%S"`; date; CPU usage of Elastic Search, and the interrupt usage dropped to pre-leap second levels instantly. 🙂 -- Doug ---
**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, 3:20am UTC](https://discuss.elastic.co/t/excessive-number-of-rescheduling-interrupts/8317/5 "2017-07-06T03:20:55Z")