[Spce-user] Questions about mr4.5.4

[Walter Klomp]

Hi Bill,

Depends a bit on how many users you have. MySQL is by far the biggest bottleneck in the operations and giving it more RAM (16GB minimum) and SSD drives (bigger impact) have helped us preventing these issues.  (Obviously with 1 customer this should not happen)

The log messages are just warnings as far as I know, shouldn't affect normal operations. 

You may even want to look at MySQL slow logs as there are a few optimizations I made on indexes (just can't remember). The fraud script also is a very lengthy query that requires a lot of RAM and better indexing, especially if you have a lot of customers (I'm running SPCE 3.8.x with > 40k live subscribers on a dell power edge with 4 cores and 1 half-hourly run takes about 5-10 minutes, with SSD.)

Yours sincerely,
Walter

> On 26 May 2017, at 6:21 AM, William Fulton <wfulton at thirdhatch.com> wrote:
> 
> As an update, we started getting this message as well just before calls are terminate early before either party hangs up:
> WARNING: dialog [dlg_handlers.c:1226]: dlg_onroute(): unable to find dialog for ACK with route param '9a.9cf1' [169:8137]
>  
> Thanks,
> Bill
>  
> From: Spce-user [mailto:spce-user-bounces at lists.sipwise.com] On Behalf Of William Fulton
> Sent: Thursday, May 25, 2017 12:23 PM
> To: spce-user at lists.sipwise.com
> Subject: [Spce-user] Questions about mr4.5.4
>  
> This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing
> Feedback
> Hello,
>  
> We have been using mr3.7.1 with very few problems for the past few years. The only minor thing we found is that around 180 days or so we have to perform a reboot or our sip clients lose connectivity at random intervals. This is all manageable and not really an issue for us. However, we want to move to mr4.5.4 LTS version. I have been testing this for a few days with the same sip providers, but am getting some warnings and errors in the proxy log as well as what seems like inconsistent call connectivity. Here are the Notices we are getting:
> 
> NOTICE: <core> [action.c:1560]: run_actions(): alert - action [save (25)] cfg [/etc/kamailio/proxy/registrar.cfg:159] took too long [125 ms]
> NOTICE: <core> [db_query.c:60]: db_do_submit_query(): alert - query execution too long [125 ms] for [update `location` set `expires`='2017-05-25 12:13:]
> NOTICE: <core> [db_query.c:60]: db_do_submit_query(): alert - query execution too long [125 ms] for [update `dialog` set `state`=4,`timeout`=1495782546]
>  
> Is it possible that some of these notices are the cause of our inconsistent connectivity? I’m surprised that query executions are taking too long. This is a test server with one subscriber. It also has a lot of processing power with 8 Xeon cores and 4GB of memory with SAS hard drives. Does anyone have any insight in to what could be the cause of these notices? Are they normal? Can I make adjustments to the config.yml to fix them?
>  
> Thanks,
> Bill
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> https://lists.sipwise.com/listinfo/spce-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20170526/334a465a/attachment-0001.html>