<div dir="ltr">Hi Gordon，<div><br></div><div>Thanks for your test results， we investigate more on our env, finally it turns out that our ceph cluster isn't work as expected.</div><div>which made gnocchi performance decrease a lot. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 19, 2017 at 1:09 AM, gordon chung <span dir="ltr"><<a href="mailto:gord@live.ca" target="_blank">gord@live.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 2017-10-18 12:15 PM, Yaguang Tang wrote:<br>
><br>
> We launched 300vms and each vm has about 10 metrics, OpenStack cluster<br>
> have 3 controllers and 2 compute nodes(ceph replication is set to 2).<br>
<br>
</span>seems smaller than my test, i have 20K metrics in my test<br>
<span class=""><br>
><br>
> what we want to archive is to make all metric measures data get<br>
> processed as soon as possible, metric processing delay is set to 10s,<br>
> and ceilometer polling interval is 30s.<br>
<br>
</span>are you batching the data you push to gnocchi? in gnocchi4.1, the redis<br>
driver will (attempt to) process immediately, rather than cyclically<br>
using the metric processing delay.<br>
<span class=""><br>
><br>
> when the backend of incoming and storeage is set to ceph, the average of<br>
> "gnocchi status"<br>
> shows that there are around 7000 measures waiting to be process, but<br>
> when changing incoming and storage backend to Redis, the result of<br>
> gnocchi status shows unprocessed measures is around 200.<br>
<br>
</span>i should clarify, having a high gnocchi status is not a bad thing, ie,<br>
if you just send a large spike of measures, it's expected to jump. it's<br>
bad if never shrinks.<br>
<br>
that said, how many workers do you have? i have 18 workers for 20K<br>
metrics and it takes 2minutes i believe? do you have debug enable? how<br>
long does it take to process metric?<br>
<br>
when i tested gnocchi+ceph vs gnocchi+redis, i didn't see a very large<br>
difference in performance (redis was definitely better though). maybe<br>
it's your ceph environment?<br>
<span class=""><br>
><br>
> we try to add more metricd process on every controller nodes, to improve<br>
> the performance of<br>
> calculate and writing speed to storage backend but  have little effect.<br>
<br>
</span>performance should increase (relatively) proportionally. ie. if you 2x<br>
metricd, you should perform (almost) 2x quicker. if you add 5% more<br>
metricd, you should perform (almost) 5% quicker.<br>
<div class="HOEnZb"><div class="h5"><br>
cheers,<br>
<br>
--<br>
gord<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Tang Yaguang</div><div><br></div><br><div> </div></div></div>
</div>