Re: [SR-Users] Kamailio 5.4.4 extremely slow carrierroute preloading

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 -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: sr.maillists(a)gmail.com &lt;sr.maillists(a)gmail.com&gt; Sent: Wednesday, February 24, 2021 10:06 PM To: sr-users(a)lists.kamailio.org Cc: Henning Westerholt &lt;hw(a)skalatan.de&gt; Subject: Re: [SR-Users] Kamailio 5.4.4 extremely slow carrierroute preloading 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><mailto: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<mailto: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