gpt4 book ai didi

c - Freeswitch 阻塞

转载 作者:太空宇宙 更新时间:2023-11-04 11:57:49 25 4
gpt4 key购买 nike

FreeSwitch 软件在几天内运行良好(~3 - 5 天),然后由于 FreeSwitch 被阻止,新的来电请求被接受!!正在进行的调用继续他们的 session ,他们的调用似乎没有受到影响,但不接受新调用。我获得了 FreeSwitch 快照并在 GDB 中对其进行了分析。

我有 601 个 Therads,其中大部分都在等待

Thread 0x7f16bc55f700 (LWP 28544) pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

当我在 gdb 中应用“thread apply all bt”时,我看到大多数线程都试图将事件插入队列 (switch_queue_push)

Thread 600 (Thread 0x7f16bc55f700 (LWP 28544)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f180cf9b87d in apr_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at locks/unix/thread_cond.c:68
#2 0x00007f180cf92dd0 in apr_queue_push (queue=queue@entry=0x7f180db157a8, data=data@entry=0x7f16d3d5ec20) at misc/apr_queue.c:166
#3 0x00007f180cc958fb in switch_queue_push (queue=0x7f180db157a8, data=data@entry=0x7f16d3d5ec20) at src/switch_apr.c:1134
#4 0x00007f180cd17850 in switch_event_queue_dispatch_event (eventp=0x7f16bc55ec48) at src/switch_event.c:384
#5 switch_event_fire_detailed (file=file@entry=0x7f180cfb07ea "src/switch_channel.c", func=func@entry=0x7f180cfb2ba0 <__func__.18348> "switch_channel_perform_set_running_state", line=line@entry=2260, event=event@entry=0x7f16bc55ec48, user_data=user_data@entry=0x0) at src/switch_event.c:1986
#6 0x00007f180cc9f118 in switch_channel_perform_set_running_state (channel=0x7f17e3e7de00, state=CS_NEW, file=0x7f180cfbc590 "src/switch_core_state_machine.c", func=<optimized out>, line=543) at src/switch_channel.c:2260
#7 0x00007f180ccc87d0 in switch_core_session_run (session=0x7f17e3e7fd28) at src/switch_core_state_machine.c:543
#8 0x00007f180ccc36de in switch_core_session_thread (thread=<optimized out>, obj=0x7f17e3e7fd28) at src/switch_core_session.c:1629
#9 0x00007f180ccbf47d in switch_core_session_thread_pool_worker (thread=0x7f17e3e9abb0, obj=0x80) at src/switch_core_session.c:1692
#10 0x00007f180cfa1910 in dummy_worker (opaque=0x7f17e3e9abb0) at threadproc/unix/thread.c:151
#11 0x00007f180c1e0064 in start_thread (arg=0x7f16bc55f700) at pthread_create.c:309
#12 0x00007f180b8b862d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

为什么我要得到这个状态?任何想法、提示、技巧将不胜感激。问候,

最佳答案

我深入研究并找到了我的解决方案,

您应该了解Freeswitch的“事件处理机制”才能解决这个问题。因为有很多生产者线程产生并把它的事件放到这个队列中,但是在这个机制中只有一个消费者线程。作为已知事件处理程序的消费者线程将事件传递给所有监听器,例如监听适当事件的模块。

这些监听器中的一个或多个可以阻止(通过阻塞)这个消费者线程,事件队列可能会变满。当事件队列满时,您的费用开关将被阻止。

解决这些问题的三种方案:

1:在默认配置中,事件处理机制使用事件队列。但是,您可以使用线程解决方案来改变“events-use-dispatch=false”值在“post_load_switch.conf”文件中。

2: 增加消费者线程数,因为单个消费者线程对于重负载的 freeswitch 服务器来说不是好的解决方案您可以使用“post_load_switch.conf”文件中的“initial-event-threads=X”来实现,其中 X 代表初始线程数。

3:在您的模块中,您也可以使用事件处理程序机制。当您从 Freeswitch 的核心获取事件时,创建一个新线程并将其分配给您新创建的线程,以便不等待 Freeswitch 的消费者线程。

关于c - Freeswitch 阻塞,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53609817/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com