Red5问题总结

问题描述

最近生产环境的red5经常出现拒绝服务的问题,仔细查看日志后发现所有的请求都是NioProcessor-1来完成,如果请求服务过多,会导致该线程处理不过来,也将导致线上其它服务将无响应,仔细查看了下RTMPMinaTransport构造源码

我们可以看到NioSocketAcceptor的构造是通过connectionExecutor与NioProcessor来完成的,从作者的代码上看,他希望监听连接与I/O处理使用不同的线程池处理,理论上说这种做法没有错,但进一步去看NioSocketAcceptor的构造方法会发这种构造方式有些问题.由于已经指定了connectionExecutor与ioExecutor,从代码中我们可以看出,这两种其实都是FixedThreadPool,即固定线程数的线程池,所有任务会在一个阻塞的队列中等待处理,在cpu资源与memory资源足够的情况下,这种做法显然有些保守了.

解决方案

既然已经知道red5的问题可能出在线程池的构造上,那么我们直接使用最直接的方法去构造NioSocketAcceptor

这种方式其实是构造了两个CachedThreadPool,保证任务的优先处理,这样无疑提高了系统处理能力,问题也就得以解决,但这种做法并不是最优方案,如果想要达到更好的效果,必须了解red5的decode与encode,尽可能减少I/O线程的占用时间,尽可能减少线程上下文切换,以及使用用高效的序列化与反序列化工具.

发表评论(沙发空缺中,还不快抢~)

设置头像

*

:wink: :twisted: :smile: :sleep: :shock: :sad: :roll: :razz: :oops: :neutral: :mad: :grin: :evil: :eek: :cry: :cool: