<div><br></div><div><br></div><div><includetail><div style="font:Verdana normal 14px;color:#000;"><div style="position:relative;">On 2017-12-01 05:03 AM, 李田清 wrote:<br>>> Hello,<br>>>       we test workload partition, and find it's much slower than not <br>>> using it.<br>>>       After some review, we find that, after get samples from <br>>> notifications.sample<br>>>       ceilometer unpacks them and sends them one by one to the pipe<br>>>       ceilometer.pipe.*, this will make the consumer slow. Right now, <br>>> the rabbit_qos_prefetch_count to 1. If we sent it to 10, the connection <br>>> will be reset<br><br>> currently, i believe rabbit_qos_prefetch_count will be set to whatever <br>> value you set batch_size to.</div><div style="position:relative;">You mean in the past, it can not be set to whatever?</div>We test newton, and find under 1k vm, if we open workload partition,</div><div style="font:Verdana normal 14px;color:#000;">it will be reset regularly. <br><div style="position:relative;"><br>>>       regularly. Under this pos, the consumer will be very slow in <br>>> workload partition. If you do not use workload partition, the messages <br>>> can all be consumer. If you use it, the messages in pipe will be piled <br>>> up more and more。<br><br>> what is "pos"? i'm not sure it means the same thing to both of us... or <br>> well i guess it could :)<br>sorry, it is qos. this qos. <br><br>>>      May be right now workload partition is not a good choice? Or any <br>>> suggestion?<br>>> <br><br>>i'll give a two part answer but first i'll start with a question: what <br>>version of oslo.messaging do you have?<br><br>newton 5.10.2</div><div style="position:relative;"><br>>i see a performance drop as well but the reason for it is because of an <br>>oslo.messaging bug introduced into master/pike/ocata releases. more <br>>details can be found here: <br>>https://bugs.launchpad.net/oslo.messaging/+bug/1734788. we're working >on <br>>backporting it. we've also done some work regarding performance/memory <br>>to shrink memory usage of partitioning in master[1].<br><br>>with that said, there are only two scenarios where you should have <br>>partitioning enabled. if you have multiple notification agents AND:<br><br>>1. you have transformations in your pipeline<br>>2. you want to batch efficiently to gnocchi<br><br>>if you don't have workload partitioning on, your transform metrics will <br>>probably be wrong or missing values. it also won't batch to gnocchi so <br>>you'll see a lot more http requests there.<br><br>>so yes, you do have a choice to disable it, but the above is your tradeoff.<br><br>>[1] <br>>https://review.openstack.org/#/q/topic:plugin+</div><div style="position:relative;">>(status:open+OR+status:merged)+project:openstack/ceilometer<br><br>>cheers,<br><br>>-- <br>>gord<br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div></div><!--<![endif]--></includetail></div>