[Spce-user] Questions about mr4.5.4

[William Fulton]

Thanks, Walter.  I will throw more hardware at it and see if this resolves the issues.  The new system is running nearly the same specs as the 3.7.1 system except twice as many cpu cores.  But SSD and more memory isn’t ever a bad idea.

I am much more concerned with the calls ending early.  It has happened on 3 out of 10 calls today.  I am going to try upgrading the hardware first, then revisit the new version of LTS.

Thanks again!

Bill

From: Walter Klomp [mailto:walter at myrepublic.net]
Sent: Thursday, May 25, 2017 5:23 PM
To: William Fulton <wfulton at thirdhatch.com>
Cc: spce-user at lists.sipwise.com
Subject: Re: [Spce-user] Questions about mr4.5.4

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<mailto: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<mailto: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<http://aka.ms/LearnAboutSpoofing>

Feedback<http://aka.ms/SafetyTipsFeedback>

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<mailto: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/6cc1845e/attachment-0001.html>