[Perfomance] Incorrect usage of notification listeners
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Ceilometer | Status tracked in Mitaka | |||||
Liberty |
New
|
Undecided
|
Kirill Bespalov | |||
Mitaka |
Fix Released
|
High
|
Kirill Bespalov |
Bug Description
Notification agent in the Ceilometer for each target creates its own NotificationLis
It leads to perfomance overhead for the agent and overloading an amqp broker.
You can explore current implementation here:
https:/
For example by default Ceilometer uses 60 targets:
6 sources (cpu_source, meter_source, etc) x 10 processing queues for coordination stuff (IPC queues mechanisms):
ceilometer-
ceilometer-
ceilometer-
...
ceilometer-
...
So, after initialization will be run 2 workers proccess of notification agents, then each worker will be create 60 NotificationLis
As a result, every controller node with the notification agen has around 120 TCP connections to the amqp broker and 7680 started greenthreads.
Changed in ceilometer: | |
assignee: | nobody → Kirill Bespalov (k-besplv) |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in ceilometer: | |
importance: | Undecided → High |
Fix proposed to branch: master /review. openstack. org/306035
Review: https:/