概述
freeswitch核心框架中有一个定时任务系统task,在开发过程中用来做一些延时操作和异步操作很方便。
我们在VOIP的呼叫流程中,经常会有一些对实时性要求没那么高的操作,或者会有阻塞流程的操作,我们都可以开启一个定时任务子流程,来达到延时和异步的目标。
但是在实际的生产应用中,该task模块在任务高并发的情况下发生了一些问题,通过压力测试可以重现。
问题现象。
1,task的group和desc为空的问题,并有极小概率造成coredump。
2,task.runtime错误的问题,导致任务无法执行。
环境
centos:CentOS release 7.0 (Final)或以上版本
freeswitch:v1.6.20
GCC:4.8.5
task的group和desc为空的问题
在对fs压力测试的同时,使用“show tasks”命令查询当前的任务队列。
其中,47号任务,2184号任务的task_group为空,24586号任务的task_desc和task_group均为空。
freeswitch@as137> show tasks
task_id,task_desc,task_group,task_runtime,task_sql_manager,hostname
1,heartbeat,core,1681351218,0,localhost.localdomain
2,check_ip,core,1681351258,0,localhost.localdomain
3,limit_hash_cleanup,mod_hash,1681351740,0,localhost.localdomain
4,task_keep_redis_alive,task_keep_redis_alive,1681351200,0,localhost.localdomain
5,as_common_city_forbidden_update_task,as_common_city_forbidden_update_task,1681351440,0,localhost.localdomain
6,update_cops_task,update_cops_task,1681351448,0,localhost.localdomain
36,task_report_event_hangup,task_report_event_hangup,1681350862,0,localhost.localdomain
47,task_report_event_hangup,,1681350862,0,localhost.localdomain
61,task_report_event_hangup,task_report_event_hangup,1681350862,0,localhost.localdomain
2077,task_report_event_hangup,task_report_event_hangup,1681350872,0,localhost.localdomain
2184,task_report_event_hangup,,1681350872,0,localhost.localdomain
24586,,,1681350985,0,localhost.localdomain
24647,task_report_event_hangup,task_report_event_hangup,1681350985,0,localhost.localdomain
问题分析
switch_scheduler_add_task函数中,主要逻辑分两步。
第一步,将task加入执行链表。该部分逻辑有加锁
第二步,将task信息通过event事件转发db模块保存。该部分没有加锁。
task_thread_loop函数中,主要逻辑分两步。
第一步,遍历task链表,并执行task。该部分有加解锁。
第二步,遍历task链表,删除已执行的task并清理内存。该部分有加解锁。
在多线程高并发场景下,一个任务在add_task的步骤二晚于task_thread_loop的步骤二执行时,就会发生task_desc和task_group的内存已被清理,event转发db的信息中字段为空的情况。
在极端情况下,task_desc和task_group的内存被重写,event事件在使用task_group的内存时会发生coredump的严重问题。
解决方案
在有switch_event_create函数调用和赋值的过程中,需要加锁,防止task_desc和task_group的内存已被清理。
该问题在1.10.7版本已修复。
task.runtime错误的问题
在对fs压力测试的同时,使用“show tasks”命令查询当前的任务队列。
其中,17022231号和19514678号任务的task_runtime时间为3363320919,换算为UTC时间为“2076-07-30 15:48:39”,这还执行个毛线。
freeswitch@as137> show tasks
task_id,task_desc,task_group,task_runtime,task_sql_manager,hostname
1,heartbeat,core,1681693601,0,localhost.localdomain
2,check_ip,core,1681693641,0,localhost.localdomain
3,limit_hash_cleanup,mod_hash,1681694183,0,localhost.localdomain
4,task_keep_redis_alive,task_keep_redis_alive,1681693584,0,localhost.localdomain
5,as_common_city_forbidden_update_task,as_common_city_forbidden_update_task,1681693584,0,localhost.localdomain
6,update_cops_task,update_cops_task,1681693592,0,localhost.localdomain
17022231,task_report_event_hangup,task_report_event_hangup,3363320919,0,localhost.localdomain
19514678,task_report_event_hangup,task_report_event_hangup,3363352225,0,localhost.localdomain
22295783,task_report_event_hangup,task_report_event_hangup,1681693583,0,localhost.localdomain
问题分析
从数值上分析,3363320919大概是1681693583的两倍,猜测是switch_scheduler_add_task函数第一个参数task_runtime的处理有问题。代码如下。
if (task_runtime < now) {
container->task.repeat = (uint32_t)task_runtime;
task_runtime += now;
}
临界情况下,我们希望任务马上执行,task_runtime传参为当前时间1681693583.999999,但是函数内部now的值取得1681693584.000000,这样task.task_runtime就会变成3363320919这样一个极端值。
解决方案
switch_scheduler_add_task,第一个参数task_runtime的填法,在回调函数中需要做出对应的修改。
1,不删除的定时重复执行的任务。
传入task_runtime = 60
task.repeat =60
task.runtime = 60 + switch_epoch_time_now(NULL)
2,需要马上执行的不需要重复执行的任务。
传入task_runtime = 0
task.repeat = 0
task.runtime = 0 + switch_epoch_time_now(NULL)
3,需要延时执行的不需要重复执行的任务。
传入task_runtime = switch_epoch_time_now(NULL) + 10
task.repeat = 0
task.runtime = switch_epoch_time_now(NULL) + 10
总结
freeswitch的新版本修复了很多问题,应尽量使用最新版本。
在高并发场景下的压力测试是必须要做的。
空空如常文章来源:https://www.toymoban.com/news/detail-426571.html
求真得真文章来源地址https://www.toymoban.com/news/detail-426571.html
到了这里,关于freeswitch的任务引擎问题与解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!