本文原地址: http://www.feitianzhi.com/boke/index.php/archives/27/

转载请注明出处,有疑问或错误请发邮件到xiaozhi@fslib.org 或加QQ群:869598376

概述

      "小雉视频系统"虽采用面向过程对象(参见:http://www.feitianzhi.com/boke/index.php/archives/18/)编程,去除线程池等复杂的设计,并减少线程的使用量,但线程数依然高达40个之多;
      40个线程数虽对cpu而言已没有任何压力了,但多线程的复杂性依然存在,其中线程死锁是多线程中最常见同时也难以定位的问题;

线程死锁产生的原因分析

1. 能否通过合理的设计规划避免线程死锁?

"小雉视频系统"是一份持续维护并增加新功能的代码,代码的修改必须考虑与老代码的兼容,需要处理的细节多,对每次修改都做出完美的设计几乎是不能实现的;

2. 能否使用第三方工具查找线程死锁?

对开发阶段就能发现的死锁用第三方工具定位是处理问题的通用方法,但使用第三方工具会导致系统速度指数级别的下降,在生产环境中无法使用,同时"小雉视频系统"模块众多,模块均支持按需开启和关闭,任何一个修改需要准备的测试用例太多,死锁后难以确定与此死锁相关的模块;

理想化设计

1. 死锁时自动报告是哪些线程卡住了?卡在源码的哪一行?卡时的调用堆栈是什么样?
2. 可在任意时间接受外部干预,报告所有线程当前执行到哪段源代码的哪行并提供调用堆栈;

小雉视频系统--线程死锁设计预览

1. 线程死锁时自动报告,"小雉视频系统"并不能判断线程死锁,"小雉视频系统"是做视频应用,5S以上的卡顿足以让用户不满,"小雉视频系统"是监视所有线程,看哪个线程连续5S时间内一直停在同一句代码处,以此认为其死锁了,效果如下:

2. 任意时间打印所有线程的调用堆栈,"小雉视频系统"监听linux下10的信号,在收到信号后打印所有线程当前的调用堆栈,效果如下:

猜您可能喜欢

小雉系统安装:http://www.feitianzhi.com/boke/index.php/archives/11/
小雉系统网络配置:http://www.feitianzhi.com/boke/index.php/archives/15/
小雉系统硬盘配置:http://www.feitianzhi.com/boke/index.php/archives/16/
小雉系统远程升级:http://www.feitianzhi.com/boke/index.php/archives/14/

本文原地址: http://www.feitianzhi.com/boke/index.php/archives/18/

转载请注明出处,有疑问或错误请发邮件到xiaozhi@fslib.org 或加QQ群:869598376

概述

对一个软件的运行占用的资源进行统计,可得到资源占用的"均值"和"峰值",从性能的角度评估软件的框架,自认为可分三个层次:

1. 峰值架构:按这种架构设计的软件需要按资源使用的峰值配置硬件,一些云服务商(如阿里云)评估的cpu均值与峰值比为2:10,基于此数据,云服务器商可提供更高的突发性能(这也是阿里云服务器测试时感觉比其他云服务器商快的原因);
2. 总线式峰值架构:如选用高于软件资源消耗均值但低于软件资源消耗峰值的硬件,在软件峰值时不仅会卡顿影响体验且会丢失数据,影响最终结果;"总线式峰值架构"是把数据采集(数据采集的资源消耗肯定是低于均值的)和处理分开,把采到的数据进行缓存再分发给各处理模块处理(处理模块排队完成);
3. 均值架构:目标是可选用性能略大于软件资源消耗的均值的硬件,实现硬件资源的利用最大化;"总线式峰值架构"相对"峰值架构"会增加业务流程,增大储存资源消耗,而"均值架构"相对"峰值架构"不会增加业务处理流程,同时可合并同类业务的排列顺序,让数据更好地类数组化,增加cpu或储存设备cache的命中率,进一步提升性能,降低软件资源消耗的均值;

直接均值架构

"小雉视频系统"采用"均值架构",同时"小雉视频系统"是单进程设计,数据在多模块之间传递采用引用方式完成,所有操作都能直接完成;
合理的算法让数据的移除和插入使用位于链表的头和尾,保持数据的数组特性,提高cpu缓存命中;
合理的业务分解让数据快速被过滤,大大减少堆积数据量,据统计视频中可能感兴趣的数据不足10%;
采用"直接均值架构"的"小雉视频系统"的硬件利用率可达90%,即cpu均值达90%不会影响使用体验;