linux下多核服务器的编程模型研究

linux下多核服务器的编程模型研究

1多线程和i/o复用作为一种企业级服务器软件平台，linux操作系统已经广泛使用。基于linux的网络服务器程序面临着越来越大的负载压力。如何不断提高服务器程序的性能，并充分挖掘服务器硬件的潜力，一直是服务器软件开发的难题。高性能网络服务器程序要达到的性能目标就是最小的响应时间和最大的吞吐量,而实现高性能网络编程的方法主要包括多线程和I/O复用。目前基于Linux2.6内核的最新多线程库为NPTL,I/O复用方式为EPOLL。基于POSIX标准的NPTL线程库,在Linux上的实现方式是调用clone系统、调用在内核中创建的LWP(轻量级进程),基于NPTL库创建的线程和其它进程一样是由内核统一调度。在早先的I/O复用方式中,select所监控的文件描述符有1024的数量限制,poll的机制和select类似,只是所监控的文件描述符突破了1024的数量限制。select和poll都有一个共同的缺点就是随着所监控的文件描述符个数的不断增长,其性能呈线性下降趋势,而EPOLL在所监控的文件描述符不断增长的情况下不用每次都在用户空间和内核空间拷贝所有监控的文件描述符,因此克服了select和poll的缺点。在目前的Linux平台下,如果不采用类似OPENMP的代码并行化编程方法,单纯的I/O复用的性能提升仅仅限于服务器单核CPU,如果要发挥多核的并行处理能力,还必须使用多线程。2在linux下的线程池设计2.1多线程模型的建立目前,最简单的基于多线程的编程模型就是“线程-任务”模型。Linux服务器程序根据其处理的任务的类型可以分为I/OBOUND型和CPUBOUND型。首先对于I/OBOUND型,服务器程序在短时间内可能需要处理数以万计的网络连接,在Linux上能创建的线程数量受到线程栈大小和进程的用户空间地址大小的限制,如果每个任务仅仅只是响应时间很短的一次请求响应型或者空连接,线程的创建和销毁带来的开销将会随着任务量增多而呈线性增长,因此这种简单的多线程模型将难以胜任。其次,对于CPUBOUND型,理想状态下最佳线程数经验公式为C/P(C为CPU个数,P为单个线程的CPU利用率,每个线程执行同类任务)。由于最佳线程数将使系统的CPU已经处于基本饱和运行状态,此时,如果创建的线程数量多于系统能承载的最佳线程数将会大大增加任务的响应时间并降低服务器吞吐量,这种简单“线程-任务”模型将无法根据系统的实际运行情况来调整服务器的线程数2.2基于c++的线程池模型线程池技术是人们发现了简单的多线程编程模型存在的种种不足之后提出的新解决方案,目前比较成熟的实现了线程池技术的库包括boost和ACE,这两个库都是使用C++实现的,其跨平台性将会使性能受到一些损失,而且要熟练使用这两个库其学习周期也较长。提出的线程池方案仅仅是在企业级Linux上基于c语言的一种轻巧而又灵活的线程池模型。线程池模型最基本的组件包括请求队列、工作线程、线程池、线程池管理。线程池模型框架如图1所示。2.2.1池中一个7000个工作线程当一个任务到来时,首先进入请求队列,由请求队列把任务传送给线程池,线程池再把任务分发给池中一个空闲的工作线程。请求队列的主要功能可以实现对任务的缓冲,避免当任务数超过线程池的容量时,线程池无法处理而直接造成任务失败,请求队列满时新任务将被拒绝入队;队列中所缓冲的任务数为动态调整线程池容量提供参考。2.2.2连续执行多个任务工作线程就是线程池中的所有线程的创建模板。工作线程要实现的主要功能包括:工作线程能够从主线程中获取能执行的任务的函数地址和与此任务相关的参数;线程池中已经创建好的工作线程的实例能够连续执行多个任务;工作线程实现两种状态指示,第一种是本线程的忙或者空闲状态指示,第二种就是当前工作线程实例是否在线程池中存活着;在工作线程中还包括线程异常处理和能优雅地结束当前线程并清除占用的相关资源的功能。2.2.3压力和压力线程池是一个工作线程实例的容器,在初始化时候,可以自动根据检测到的系统的硬件配置预创建最佳的初始线程数。在某些工作负荷可以正确估计和预测的情况下,也可以在配置文件中对线程池中线程的个数予以配置。当采用默认初始化时,为了避免一开始就占用系统过多的资源,线程池初始化时预创建的线程数量是根据检测到的系统逻辑CPU个数的倍数来计算的。线程池还将通过和线程池相对应的数据结构来保存线程池的其它参数,比如线程池容量的最大值和最小值,当前线程数量以及需要动态调整线程池容量时的增量等。2.2.4线程池运行过程的优化管理线程是实现动态自适应的高性能线程池的重要部分。管理线程要实现的功能主要是通过动态获取当前线程池运行过程中的参数来调整线程池相关设置使线程池的运行达到最优化。如果管理线程检测到线程池中某个线程出现错误,应该立即启动相应的错误处理方案,这些错误包括线程被某个I/O永久地阻塞,线程中获取、释放锁和条件等待系统调用返回错误等。3在linux下，epoll和线程池的组合3.1多路i/o复用由于Linux从设计之初就尽可能地遵循一切皆文件的原则,因此I/O复用在Linux上使用的范围很广。多路I/O复用是指一个单独的进程或者线程采用分时复用的方式来并发地处理多个I/O文件描述符上的任务。Linux内核2.6中EPOLL的实现原理就是在内核中注册了一个名为eventpollfs的文件系统,调用epoll3.2pla和epoll同时处理大规模任务设计的线程池中,每个线程一次最多只能处理一个任务,而32位Linux系统进程的用户地址空间又限制了能创建的线程的最大个数,这样在线程池模型下,一个服务器能同时处理的最大任务数也不会超过进程能创建的线程的最大个数。但是当服务器程序属于I/OBOUND型时,网络连接很多的时候,CPU的利用率都很小。由此可见,单纯的线程池服务器的性能瓶颈在于软件的编程模型。同样地,对于一个服务器程序,单纯地采用单进程的EPOLL来处理大规模的任务,根据Linux2.6内核的任务调度算法可知,一个单进程(线程)在任意一个时刻都只能在一个CPU核心上运行,而现在的服务器普遍都是多核的CPU,这样能处理的并发任务数虽然可以达到很高的数值,但剩余的其它CPU核将无法利用,同时随着处理的任务数的增加,也会导致平均响应时间的不断增大。基于以上两个方面的分析可知把线程池技术和E-POLL结合起来,可以充分利用服务器硬件的资源并且能够突破服务器程序的性能瓶颈。单进程的EPOLL就可以同时处理大规模的任务,线程池中只需要分配大于等于服务器CPU核心个数的线程同时运行,如果定义一个单进程的EPOLL能同时处理的任务数为M,线程池容量为N,那么服务器当前总共能同时处理的任务数就可以达到M×N,可见服务器的并发处理能力一下就可以提高很多。设计的解决方案为:把一个单线程的EPOLL分解成多个线程来执行。建立一个全局的eventpollfs文件系统描述符epfd以后,由专门的线程向epfd中添加或删除需要监控的文件描述符,由专门的线程来处理对文件描述符的监控,监控线程所产生的每一类事件由专用的事件处理线程来执行。同时为每个文件描述符任务动态建立一个保存其工作状态和相关数据的全局工作流数据结构。基于单个epoll4基于epoll的线程池网络服务器模型4.1任务线程的传递在线程池的设计中,主要用到3个数据结构,第一个是表示线程执行任务的数据结构ttask,结构中包括了要执行任务的函数指针和与要传递给任务的相关参数指针。第二个是表示工作线程及其状态的tpara结构,每一个tpara类型的结构变量对应着线程池中被创建的一个工作线程。tpara详细内容如下:在EPOLL的处理流程中也有一个主要的数据结构,就是基于任务流程的工作流数据结构workflow,其成员包括与任务执行流程相关的文件描述符,工作流进行到当前的步骤,以及与当前步骤相关的数据指针等。4.2epoll-rw函数基于“事件-线程”的主要部分在epoll-rw函数中,epoll-rw函数为一个单独的线程,其主要任务负责把监听到事件交由线程池处理,其核心部分流程描述如图3所示。5epoll线程池模型测试测试环境主机配置:CPU为intel酷睿2四核处理器,内存1GB,操作系统采用基于linuxkernel2.6.18的cenotos5.5。测试环境为局域网中2台机器,一台运行服务器程序,一台运行客户端程序。在测试中设计3种服务器端测试模型:单进程EPOLL,在一个进程中用EPOLL监控的方式处理所有的并发连接和及其相关的事务逻辑;通用的线程池模型,基于套接字的网络监听程序每接收到一个新的网络连接就放进任务队列中,由线程池分配一个专用线程来处理一个连接上的事务逻辑;文中提出的基于EPOLL的线程池。设计的客户端测试程序为了尽量提高并发度,将套接字通讯的各个步骤分别由不同的线程来执行,主要由3个线程组成,一个线程负责创建一批socket文件描述符并连接,一个线程负责发送数据,一个线程采用EPOLL事件监听的方式负责接收数据。客户端程序发起的并发连接数量分别为1000按递增1000的方式直至10000,测试的内容为客户端和服务器端在一个连接上进行六次交互即客户端发送3次请求数据并接收服务端相应的3次响应数据,数据报文大小控制在1024字节之内。通过程序中记录的完成相应并发连接任务数量的总时间,可以计算出相应的并发连接数量下的每个连接的平均响应时间。每一次测试数据的平均响应时间计算方式为:完成所有连接上任务的总时间/并发连接数,平均吞吐量计算方式为:完成并发连接上的任务数/完成所有任务的总时间。测试的平均响应时间和平均吞吐量的结果如图4和图5所示。从图4可以看出,在单进程EPOLL模型中,当并发连接数为4000和9000这两个点时,相对于这两个点时的平均响应时间高达0.14s和0.18s,其10次测试数据的平均值为0.07s。在线程池模型中,当发连接数为5000、6000、7000时其相应的任务平均响应时间也高达0.30s、0.31s、0.36s,其10次测试数据的平均值为0.24s。在EPOLL线程池模型中任务的平均响应时间始终稳定在左右其次测试数据的平均值为从图中的测试数据来看,单进程EPOLL模型和线程池模型在测试中的平均响应时间会表现出不稳定性,而且这两种模型随着所测试的并发连数的增加其任务的平均响应时间相应地增加。EPOLL线程池模型则相对稳定,而且EPOLL线程池模型的10次测试数据的平均响应时间只占单进程EPOLL和线程池模型模型的29%和8%。从图5可以看出,除了单进程EPOLL模型之外,其它两种模型的平均吞吐量都相对稳定。单进程EPOLL模型、线程池模型和EPOLL线程池模型这3种模型吞吐量的10次测试数据的平均值分别为22、5、42,EPOLL线程池的平均吞吐量达到了单进程EPOLL模型和线程池模型的1.9倍和8.4倍。6epoll模型的优缺点通过总结分析线程池技术和Linux2.6内核下的I/O多路复用技术这两种编程技