[SR-Users] Kamailio 5.4.4 extremely slow carrierroute preloading

[sr.maillists at gmail.com]

Hello there

I nailed the problem down to a version now: It began with version 5.0.4.
With 5.0.3 it's fast, only 10 seconds.
With 5.0.4 it takes 16 minutes!

In postgres log I see always the same query "SELECT * FROM carrierroute 
WHERE carrier=1 and domain=1 and prob>0"
like it's in a loop. I did not observe this with version 5.0.3.

I believe it's this change in carrierroute module:

commit 9800aba65146b72623bb512049300d1beb8c8ec4
Author: Huseyin Dikme <hueseyin.dikme at 1und1.de>
Date:   Tue Sep 12 15:37:17 2017 +0200

     carrierroute: warning for the same carrier/domain having routes with only 0 probability
     
     - While starting kamailio or reloading the routes, if the same carrier/domain pairs do not have
       any route with a probability other than 0 (zero) then an error log will be printed on the screen.
       Besides, the log "invalid dice_max value" in the cr_func.c has been made more clear.
     
     (cherry picked from commit 9741bee7af8136b35af8e6279e530aa0ad54f574)

I don't understand much in the code, but for me it seems like for every 
entry in carrierroute it generates a query to check if there are same 
routes with probability 0.

Regards
Stefan


Am 24.02.21 um 18:02 schrieb sr.maillists at gmail.com:
> Hi Henning
>
> Thanks for your fast response. I switched the parameter back to 2000.
> Ok some more details:
> I compiled now 4.4.7 and this loads like 4.3.6 in 10s.
> Then I compiled 5.0.8 and now it's so slow, I can watch loading single 
> entries in the logfile.
>
> I think somewhere between 4.4.7 and 5.0.8 changed something which 
> makes it so slow.
> Will try to find the e-mail and some hints where the problem could be.
> In the meantime I will try to stick with version 4.4.7.
>
> Regards
> Stefan
>
> Am 24.02.21 um 17:49 schrieb Henning Westerholt:
>> Hello,
>>
>> the fetch_rows parameter is just to specify the number of routes to 
>> load _at once_. So, you should not set it to the complete size, but 
>> keep it more in the range of the default value.
>>
>> About the general slower loading, there has been another e-mail some 
>> weeks ago that mention a similar problem.
>>
>> Please try again with a proper fetch_rows setting. If its still 
>> happens, you can open a github issue about it, it seems indeed like a 
>> regression
>>
>> Cheers,
>>
>> Henning
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210224/c548880f/attachment.htm>