最近终于解决了一个和cgo有关的问题。这个问数携题从发现到解决前后经历了接近4个月,当然,和人手不足也有关系。而对于我个人而言,这个问题其实历时2年!这得从头说起。
在上一家公司的一个项目里,有一个服务做音视频数据的提取,这个服务运行在嵌入式设备TX2上。音视频提取这一关键功能主要利用nvidia基于gstreamer开发的插件,这个插件可以发挥nvidia gpu的硬件解码功能。当时这个服务使用go和c混编的方式,问题的症状是服务运行一段时间后,不输出音视频数据。遗憾的是,由于疫情,项目停止,因此没有机会继续研究这个问题。
时间来到去年底。当前这个项目进行压力测试,发现关键的语音处理服务运行一段时间后,会出现不拉流的情况,因此也没有后续的结果输出。症状和上一个项目非常像。虽然使用的第三方SDK不一样,但同样用了go和c混编的方式。一开始,焦点就放在go的运行时上,觉得可能是go和c相互调用的方式不对。经过合理猜测,并用测试进行验证后,发现问题还是在第三方拉流的SDK上,它们的回调函数必须要快,否则有可能会阻塞它们的回调线程。当然,在go调用c的时候,如果耗时比较长,会对go的运行时造成一些副作用;在c回调go的时候,go的祥毕哗运行时也有可能阻塞c的回调线程。但go的运行时已经比较成熟,因此我觉得它对这个问题的贡献不大。以上采用了假设-验证的方法,主要的原因还是第三方的拉流SDK不开源。在定位问谨行题的过程中,使用了gdb的gcore来生成堆栈;也搭建了灰度环境来进行压力测试,以及完善监控,这些都是解决方法的一部分。
正是这一问题,促使我更多的了解go的运行时。而我看得越多,越觉得go的运行时是一个庞大的怪物。因此,抱着能了解一点是一点的心态,不断的完善这篇笔记。
公司需要实现一个定期抓取分销系统数据并以声音播放的方式通知的pc端程序,本人对golang非常感兴趣,于是打算用golang来实现。
1、golang语言非常团改旦简单高效。
2、有问题,大家可以百度,谷歌,到 社区 提问。
3、如果您塌扰想支持歼乎作者,可以到 B站 上,给作者点个赞,关注作者。
个人理解的channel超时处理思路分享戚滑,若有错误或者不足,请联系我:qq 869329877
主程序通过go timeout()挂起一个协程,在timeout方法里面利用select来监控逻辑处理的变化,如果请求时间过长或者连接到其他服务比如grpc、mysql等服务中断导致高兆腊的请求时间过长,则直接超时,超猜睁时要返回定义的管道数据结果,否则程序会报错。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)