Hi
Stefan,
good catch. It looks indeed like a regression
which was introduced there. The check seems valid, but it do
not need to be executed so many times probably.
Can you open an issue on our tracker with the
details and the referenced commit?
Thanks and regards,
Henning
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
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