asterisk users - Aug 2015 - 786 000 files limit Centos 7 - Asterisk (Stefan Viljoen)

Hi List

Regarding this Asterisk instance as discussed previously (Asterisk 1.8.11.0)
that was consuming enormous amounts of file descriptors (100 000+ for about
50 simultaneous calls) it appears I have managed to solve my problem by
upgrading the 1.8.11.0 Asterisk instance to an 1.8.32.3 Asterisk instance.

Also, the file descriptors apparently leaking were paired with timer
problems in 1.8.11.0 whenever I went above about 50 concurrent calls on the
box while running on 1.8.11.0.

The thing is in our setup we have about 15 instances of 1.8.11.0 at the
various branches of the company, all running 1.8.11.0, BUT at none of these
sites do we ever exceed 40 simultaneous calls.

The defining factor was (in our case, with our dialplan) to run 1.8.11.0 and
try to run 50+ concurrent calls.

What would happen was that thousands of these messages would come up in the
CLI:

[Aug 13 09:41:38] ERROR[25193]: res_timing_dahdi.c:89 dahdi_timer_set_rate:
Failed to configure DAHDI timing fd for 0 sample timer ticks

when we reached or exceeded 50 calls.

The same happened whether pthread timing or kernel timerfd timing was used.

Several other weird errors would manifest in the CLI, to whit:

---
format_gsm.c:102 gsm_write: Bad write (32/33): Destination address required

[Aug 12 12:23:33] WARNING[29436]: channel.c:1474 __ast_queue_frame:
Exceptionally long voice queue length queuing to Local/number at local-3E1C;1

WARNING[8210]: res_rtp_asterisk.c:1773 ast_rtcp_read: RTCP Read error: Bad
file descriptor.  Hanging up.

[Aug 12 09:56:55] WARNING[29931]: file.c:198 ast_writestream: Translated
frame write failed
---

when we were spamming the timer errors. Practical effects were dropped
calls, calls with bad quality / what sounds like severe jitter, and
mixmonitor recording files that were not written or corrupt.

The solution (so far, still checking) was simply to upgrade to 1.8.32.0 and
most of our problems disappeared, for us in our setup, with our dialplans.
The upgrade was painless, since we stayed in the 1.8 range, we did not have
to modify any of our config files or dialplans.

Maybe this can assist someone else struggling with older 1.8 series timer
issues.

Regards

Stefan

On Mon, Aug 17, 2015 at 2:01 AM, Stefan Viljoen <viljoens at
verishare.co.za>
wrote:
> Hi List
>
> Regarding this Asterisk instance as discussed previously (Asterisk
> 1.8.11.0)
> that was consuming enormous amounts of file descriptors (100 000+ for about
> 50 simultaneous calls) it appears I have managed to solve my problem by
> upgrading the 1.8.11.0 Asterisk instance to an 1.8.32.3 Asterisk instance.
>
> Also, the file descriptors apparently leaking were paired with timer
> problems in 1.8.11.0 whenever I went above about 50 concurrent calls on the
> box while running on 1.8.11.0.
>
> The thing is in our setup we have about 15 instances of 1.8.11.0 at the
> various branches of the company, all running 1.8.11.0, BUT at none of these
> sites do we ever exceed 40 simultaneous calls.
>
> The defining factor was (in our case, with our dialplan) to run 1.8.11.0
> and
> try to run 50+ concurrent calls.
>
> What would happen was that thousands of these messages would come up in the
> CLI:
>
> [Aug 13 09:41:38] ERROR[25193]: res_timing_dahdi.c:89 dahdi_timer_set_rate:
> Failed to configure DAHDI timing fd for 0 sample timer ticks
>
> when we reached or exceeded 50 calls.
>
> The same happened whether pthread timing or kernel timerfd timing was used.
>
> Several other weird errors would manifest in the CLI, to whit:
>
> ---
> format_gsm.c:102 gsm_write: Bad write (32/33): Destination address required
>
> [Aug 12 12:23:33] WARNING[29436]: channel.c:1474 __ast_queue_frame:
> Exceptionally long voice queue length queuing to Local/number at
local-3E1C;1
>
> WARNING[8210]: res_rtp_asterisk.c:1773 ast_rtcp_read: RTCP Read error: Bad
> file descriptor.  Hanging up.
>
> [Aug 12 09:56:55] WARNING[29931]: file.c:198 ast_writestream: Translated
> frame write failed
> ---
>
> when we were spamming the timer errors. Practical effects were dropped
> calls, calls with bad quality / what sounds like severe jitter, and
> mixmonitor recording files that were not written or corrupt.
>
> The solution (so far, still checking) was simply to upgrade to 1.8.32.0 and
> most of our problems disappeared, for us in our setup, with our dialplans.
> The upgrade was painless, since we stayed in the 1.8 range, we did not have
> to modify any of our config files or dialplans.
>
> Maybe this can assist someone else struggling with older 1.8 series timer
> issues.
>
> Regards
>
Always nice to hear that we fixed things. Thanks for the follow-up!


-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20150817/35c4508a/attachment.html>