<div dir="ltr"><div><div><div><div><div>Hi all,<br></div><div>First of all, thanks for your suggestions! <br></div><div><br></div>To summarize the discussions here:<br></div>1. We are not going to install Mongo (because "is's wrong" ?)<br>
</div>2. Idea about spawning several collectors is suspicious (btw there is a patch that run several collectors: <a href="https://review.openstack.org/#/c/79962/">https://review.openstack.org/#/c/79962/</a> .)<br><br>Let's try to get back to original problem. All these solutions were suggested to solve the problem of high load on Ceilometer. AFAIK, Tempest's goal is to test projects` interactions, not performance testing. The perfect tempest's behaviour would be "start ceilometer only for Ceilometer tests". From one hand it will allow not to load db during other tests, from the other hand "projects` interactions" will be tested because during Ceilometer test we create volums, images and instances. But I'm afraid that this scenario is not possible technically.<br>
</div></div><div>There is one more idea. Make Ceilometer able to monitor not all messages but filtered set of messages. But anyway this is a new feature and cannot be added right now.<br><br></div><div>Tempest guys, if you have any thoughts about first suggestion  "start ceilometer only for Ceilometer tests" please share.<br>
<br></div><div>Thanks,<br></div><div>Nadya<br></div><div> <br></div><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 20, 2014 at 3:23 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 03/19/2014 06:09 PM, Doug Hellmann wrote:<br>
> The ceilometer collector is meant to scale horizontally. Have you tried<br>
> configuring the test environment to run more than one copy, to process<br>
> the notifications more quickly?<br>
<br>
</div>The ceilometer collector is already one of the top running processes on<br>
the box -<br>
<a href="http://logs.openstack.org/82/81282/2/check/check-tempest-dsvm-full/693dc3b/logs/dstat.txt.gz" target="_blank">http://logs.openstack.org/82/81282/2/check/check-tempest-dsvm-full/693dc3b/logs/dstat.txt.gz</a><br>
<br>
<br>
Often consuming > 1/2 a core (25% == 1 core in that run, as can been<br>
seen when qemu boots and pegs one).<br>
<br>
So while we could spin up more collectors, I think it's unreasonable<br>
that the majority of our cpu has to be handed over to the metric<br>
collector to make it function responsively. I thought the design point<br>
was that this was low impact.<br>
<div class="HOEnZb"><div class="h5"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
Samsung Research America<br>
<a href="mailto:sean@dague.net">sean@dague.net</a> / <a href="mailto:sean.dague@samsung.com">sean.dague@samsung.com</a><br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>