Open Stack

Hey,

Thanks for your answer!
OK, I understand the why ;) also because we hit some issues on our deployment.
So we increase the number of threads to 100 but we also enable the deferred deletion (keeping in mind the quota usage downsides that it brings).
We also disabled the periodic task to compute usage and use the less precise way from db.
First question here: do you think we are going the right path?

One thing we are not yet sure is how to calculate correctly the number of threads to use.
Should we do basic math with the number of deletion per minutes? Or should we take the number of volumes in the backend into account? Something in the middle?

Thanks!

Arnaud



Le 5 juillet 2022 18:06:14 GMT+02:00, Rajat Dhasmana <rdhasman at redhat.com> a écrit :
>Hi Arnaud,
>
>We discussed this in last week's cinder meeting and unfortunately we
>haven't tested it thoroughly so we don't have any performance numbers to
>share.
>What we can tell is the reason why RBD requires a higher number of native
>threads. RBD calls C code which could potentially block green threads hence
>blocking the main operation therefore all of the calls in RBD to execute
>operations are wrapped to use native threads so depending on the operations
>we want to
>perform concurrently, we can set the value of
>backend_native_threads_pool_size for RBD.
>
>Thanks and regards
>Rajat Dhasmana
>
>On Mon, Jun 27, 2022 at 9:35 PM Arnaud Morin <arnaud.morin at gmail.com> wrote:
>
>> Hey all,
>>
>> Is there any recommendation on the number of threads to use when using
>> RBD backend (option backend_native_threads_pool_size)?
>> The doc is saying that 20 is the default but it should be increased,
>> specially for the RBD driver, but up to which value?
>>
>> Is there anyone tuning this parameter in their openstack deployments?
>>
>> If yes, maybe we can add some recommendations on openstack large-scale
>> doc about it?
>>
>> Cheers,
>>
>> Arnaud.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220705/7bf8bc46/attachment-0001.htm>