[openstack-dev] Question about performance of ceilometer API
Yuanjing (D)
yj.yuan at huawei.com
Thu Apr 3 10:24:58 UTC 2014
Hi:
I have deployed a RDO havana version's openstack environment for a period.
By chance I tested APIs of ceilometer, in the first I defined a new meter like meter_test, then used 'ceilometer sample-list -m yjmeter' command to check the result.
I found that the query cost about 13 seconds, why it was so slow with one record?
Now that RDO used mongodb as default DB for ceilometer, I logging into it and found that the meter collection had about 2,700,000 records. Maybe the mass records slowed the query.
Take production environemnt into account, If there are 100 hosts , each host contains 30 VM.
CeilometerI use default configuration of 11 compute pollsters and the pipeline interval is 600s.
Then one day system will generate 4,752,000 record, the formula is: 11(meter) * 30(VM) * 6(system run pollsters 6 times an hour) * 24(a day) * 100(host) = 4,752,000 records.
For above case I think it is necessary to restrict number of records by some mechanism, below are my immature idea:
1. Make restriction on max supported records by time or number of samples, discard old records.
2. Providing API to delete samples by resource_id or some other conditions, so the third integration system may call this API to delete related samples when delete a resource.
3. Running period task of accounting on raw samples, using 1min samples to generate 5min statistics samples, using 5min statistics to generate 30min statistics samples, and so on. Every period of sample has individual data table and has resriction on max supported records .
I am not a ceilometer programmer and I apologize if I am missing something very obvious.
Can you give me some help to make me clear about them and how to implement my requirement?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/1a1a7e5c/attachment.html>
More information about the OpenStack-dev
mailing list