For example, when this failed in the log link above, around time 21:44:09.859, you can see in dstat that ceilometer agent notification was really impacting the CPU:
It'd be cool if we could dynamically adjust timeouts based on current system load...but maybe that's just overly complicating things - the alternative is probably just making ceilometer better and consuming less CPU all the time.
For example, when this failed in the log link above, around time 21:44:09.859, you can see in dstat that ceilometer agent notification was really impacting the CPU:
http:// logs.openstack. org/08/ 92608/1/ gate/gate- tempest- dsvm-postgres- full/57b137a/ logs/dstat. txt.gz
09-05 21:44:09| 68 14 16 1 0 1|3933M 184M 2529M 837M| 0 0 | 48k 7780k|5.00 192 |4588 8707 |8.20 6.81 3.49| 13 0 52|ceilometer- agent-noti2052 7.5%3552B 97k
It'd be cool if we could dynamically adjust timeouts based on current system load...but maybe that's just overly complicating things - the alternative is probably just making ceilometer better and consuming less CPU all the time.