[Bug 1518430] [NEW] liberty: ~busy loop on epoll_wait being called with zero timeout

[JuanJo Ciarlante]

Public bug reported:

Context: openstack juju/maas deploy using 1510 charms release
on trusty, with:
  openstack-origin: "cloud:trusty-liberty"
  source: "cloud:trusty-updates/liberty

* Several openstack nova- and neutron- services, at least:
nova-compute, neutron-server, nova-conductor,
neutron-openvswitch-agent,neutron-vpn-agent
show almost busy looping on epoll_wait() calls, with zero timeout set
most frequently.
- nova-compute (chose it b/cos single proc'd) strace and ltrace captures:
  http://paste.ubuntu.com/13371248/ (ltrace, strace)

As comparison, this is how it looks on a kilo deploy:
- http://paste.ubuntu.com/13371635/

* 'top' sample from a nova-cloud-controller unit from
   this completely idle stack:
  http://paste.ubuntu.com/13371809/

FYI *not* seeing this behavior on keystone, glance, cinder,
ceilometer-api.

As this issue is present on several components, it likely comes
from common libraries (oslo concurrency?), fyi filed the bug to
nova itself as a starting point for debugging.

** Affects: nova (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: canonical-bootstack

** Description changed:

  Context: openstack juju/maas deploy using 1510 charms release
  on trusty, with:
-   openstack-origin: "cloud:trusty-liberty" 
-   source: "cloud:trusty-updates/liberty
+   openstack-origin: "cloud:trusty-liberty"
+   source: "cloud:trusty-updates/liberty
  
- * Several openstack nova- and neutron- services, at least: 
+ * Several openstack nova- and neutron- services, at least:
  nova-compute, neutron-server, nova-conductor,
  neutron-openvswitch-agent,neutron-vpn-agent
  show almost busy looping on epoll_wait() calls, with zero timeout set
  most frequently.
- - nova-compute (chose it b/cos single proc'd) strace and ltrace captures: 
-   http://paste.ubuntu.com/13371248/ (ltrace, strace)
+ - nova-compute (chose it b/cos single proc'd) strace and ltrace captures:
+   http://paste.ubuntu.com/13371248/ (ltrace, strace)
  
  As comparison, this is how it looks on a kilo deploy:
  - http://paste.ubuntu.com/13371635/
  
- * 'top' sample from a nova-cloud-controller unit:
-   http://paste.ubuntu.com/13371809/
+ * 'top' sample from a nova-cloud-controller unit from
+    this completely idle stack:
+   http://paste.ubuntu.com/13371809/
  
  FYI *not* seeing this behavior on keystone, glance, cinder,
  ceilometer-api.
  
  As this issue is present on several components, it likely comes
  from common libraries (oslo concurrency?), fyi filed the bug to
  nova itself as a starting point for debugging.

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1518430

Title:
  liberty: ~busy loop on epoll_wait being called with zero timeout

Status in nova package in Ubuntu:
  New

Bug description:
  Context: openstack juju/maas deploy using 1510 charms release
  on trusty, with:
    openstack-origin: "cloud:trusty-liberty"
    source: "cloud:trusty-updates/liberty

  * Several openstack nova- and neutron- services, at least:
  nova-compute, neutron-server, nova-conductor,
  neutron-openvswitch-agent,neutron-vpn-agent
  show almost busy looping on epoll_wait() calls, with zero timeout set
  most frequently.
  - nova-compute (chose it b/cos single proc'd) strace and ltrace captures:
    http://paste.ubuntu.com/13371248/ (ltrace, strace)

  As comparison, this is how it looks on a kilo deploy:
  - http://paste.ubuntu.com/13371635/

  * 'top' sample from a nova-cloud-controller unit from
     this completely idle stack:
    http://paste.ubuntu.com/13371809/

  FYI *not* seeing this behavior on keystone, glance, cinder,
  ceilometer-api.

  As this issue is present on several components, it likely comes
  from common libraries (oslo concurrency?), fyi filed the bug to
  nova itself as a starting point for debugging.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1518430/+subscriptions