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@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@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