Sean, thank for analysis. JFYI, I did some initial profiling, it's described here https://firstname.lastname@example.org/msg19030.html.
On Thu, Mar 20, 2014 at 2:15 PM, Sean Dague <s...@dague.net> wrote: > On 03/20/2014 05:49 AM, Nadya Privalova wrote: > > Hi all, > > First of all, thanks for your suggestions! > > > > To summarize the discussions here: > > 1. We are not going to install Mongo (because "is's wrong" ?) > > We are not going to install Mongo "not from base distribution", because > we don't do that for things that aren't python. Our assumption is > dependent services come from the base OS. > > That being said, being an integrated project means you have to be able > to function, sanely, on an sqla backend, as that will always be part of > your gate. > > > 2. Idea about spawning several collectors is suspicious (btw there is a > > patch that run several collectors: > > https://review.openstack.org/#/c/79962/ .) > > Correct, given that the collector is already one of the most expensive > processes in a devstack run. > > > 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. > > 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. > > > > Tempest guys, if you have any thoughts about first suggestion "start > > ceilometer only for Ceilometer tests" please share. > > The point of the gate is that it's integrated and testing the > interaction between projects. Ceilometer can be tested on it's own in > ceilometer unit tests, or by creating ceilometer functional tests that > only run on the ceilometer jobs. > > While I agree that Tempest's job is not to test performance, we do have > to give some basic sanity checking here that the software is running in > some performance profile that we believe is base usable. > > Based on the latest dstat results, I think that's a dubious assessment. > The answer on the collector side has to be something other than > horizontal scaling. Because we're talking about the collector being the > 3rd highest utilized process on the box right now (we should write a > dstat plugin to give us cumulative data, just haven't gotten there yet). > > So right now, I think performance analysis for ceilometer on sqla is > important, really important. Not just horizontal scaling, but actual > performance profiling. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev