问题描述
最近生产环境的red5经常出现拒绝服务的问题,仔细查看日志后发现所有的请求都是NioProcessor-1来完成,如果请求服务过多,会导致该线程处理不过来,也将导致线上其它服务将无响应,仔细查看了下RTMPMinaTransport构造源码
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
public void start() throws Exception { initIOHandler(); IoBuffer.setUseDirectBuffer(!useHeapBuffers); // this is global, oh well if (useHeapBuffers) { // dont pool for heap buffers IoBuffer.setAllocator(new SimpleBufferAllocator()); } log.info("RTMP Mina Transport Settings"); log.info("Connection Threads: {}", connectionThreads); log.info("I/O Threads: {}", ioThreads); //use default parameters, and given number of NioProcessor for multithreading I/O operations //acceptor = new NioSocketAcceptor(ioThreads); //create separate executors to handle connections and i/o Executor connectionExecutor = Executors.newFixedThreadPool(connectionThreads); Executor ioExecutor = Executors.newFixedThreadPool(ioThreads); acceptor = new NioSocketAcceptor(connectionExecutor, new NioProcessor(ioExecutor)); acceptor.setHandler(ioHandler); acceptor.setBacklog(50); log.info("TCP No Delay: {}", tcpNoDelay); log.info("Receive Buffer Size: {}", receiveBufferSize); log.info("Send Buffer Size: {}", sendBufferSize); ... } |
我们可以看到NioSocketAcceptor的构造是通过connectionExecutor与NioProcessor来完成的,从作者的代码上看,他希望监听连接与I/O处理使用不同的线程池处理,理论上说这种做法没有错,但进一步去看NioSocketAcceptor的构造方法会发这种构造方式有些问题.由于已经指定了connectionExecutor与ioExecutor,从代码中我们可以看出,这两种其实都是FixedThreadPool,即固定线程数的线程池,所有任务会在一个阻塞的队列中等待处理,在cpu资源与memory资源足够的情况下,这种做法显然有些保守了.
解决方案
既然已经知道red5的问题可能出在线程池的构造上,那么我们直接使用最直接的方法去构造NioSocketAcceptor
|
1 2 3 |
acceptor = new NioSocketAcceptor(DEFAULT_IO_THREADS); |
这种方式其实是构造了两个CachedThreadPool,保证任务的优先处理,这样无疑提高了系统处理能力,问题也就得以解决,但这种做法并不是最优方案,如果想要达到更好的效果,必须了解red5的decode与encode,尽可能减少I/O线程的占用时间,尽可能减少线程上下文切换,以及使用用高效的序列化与反序列化工具.