CN104461845A - 日志采集***线池自适应方法 - Google Patents

Abstract

日志采集***线池自适应方法涉及日志采集***中有关线程池的自适应问题。在日志采集***增加基于事件驱动的检查器，设置与任务队列相关的阈值α、日志处理所需理论时间T_E和日志处理时间容忍度β三个参数创建线程池；***每接受到一个日志即为一个事件，驱动检查器检测当前任务队列大小是否超过α；α＝2；如果超过则启动如下线程启发方法：计算tn定义为理论需要增加的线程个数，T_E定义为处理日志所需的理论时间，AVGT_Q定义为最近α次日志到达***的平均间隔，P_T定义为***当前时刻线程池中线程的数目；然后，判断tn与α大小，然后取较小值最为真正需要增加的线程数目；最后创建空闲等待时间大小为T_E的非核心线程或则日志做缓存处理。本发明动态调整线程池，保证日志快速处理。

Description

日志采集***线池自适应方法

技术领域

本发明主要涉及日志采集***，主要考虑日志采集***中有关线程池的自适应问题。

背景技术

随着信息技术的发展，各组织机构为了其内部网络需要，部署了多种多样的网络设备和应用服务器。这些应用服务器和网络设备每天都在产生大量的日志，这些日志记录了设备的运行情况和用户对应用服务器的访问操作。可以通过分析日志进而监控网络运行，优化网络设备和应用服务器。

目前，由于日志并无统一的格式规范要求不利于进一步的分析工作，所以需要对日志进行处理，由此产生了日志采集***。但随着网络流量的增大，网络设备、应用服务器等日志发送端的日志发送速度远大于日志采集***的日志处理速度，导致大量的日志丢失，因此对日志采集***的响应速度、稳健性和整体性能都提出了较高的要求。除了对服务器的硬件配置和网络等基础设施进行改进提升之外，如何在硬件设施固定的情况下提升日志采集***的性能已经成为人们研究的重要方向。固定的硬件配置，其中的各项***资源(CPU、内存、线程等)是有限的，合理分配和管理这些有限***资源将会给日志采集***的性能带来新的提升。如果使用单个线程技术来处理所有的日志不能保证CPU等***资源的性能充分发挥，所以在日志采集***中使用多线程技术同时并行处理日志较单线程技术能够充分利用CPU等***资源，提高***性能。但是，线程也作为***资源，对每一个日志处理都生成一个新的线程进行处理也不是一个理想的选择。针对合理使用线程资源的需求，线程池是信息***中常用的一种技术。它通过对多个任务复用已有线程，减少反复创建和销毁线程的操作，改善了***的性能并减少了响应时间。

在使用线程池中，需要配置线程池运行的相关参数，包括核心线程个数、线程池最大线程个数、空闲等待时间和任务队列大小等，主要依赖经验和个人判断进行手工配置。当前线程池的研究热点是尽量摆脱以往手工配置的弱点和如何动态调整线程池中线程的个数。本发明也是从优化线程池的角度，来研究日志采集***中线程池的自适应方法，主要包括：

1.用于动态调整线程池中的线程个数的线程创建的启发方法。

2.减少手工配置参数。

3.对个别需要手工配置的参数给出更准确、范围更小的取值建议。

发明内容

本发明不考虑日志发送端的各种因素，根据日志到达日志采集***的间隔、解析处理日志的执行时间等因素动态调整线程池，保证日志快速处理。

线程池自适应方法中最主要的内容为线程启发方法。传统的线程启发方法分为两种，方法一：每次接收到日志都创建一个新的线程用于处理。方法二：缓存接收到的日志将其放在任务队列之中，直到任务队列达到饱和才创建一个新的线程用于处理。

在传统方法一的实际应用中会造成线程频发地创建和撤销。因为线程在创建和撤销的过程中需要执行许多操作，所以创建和撤销线程的执行时间要比处理日志的执行时间长。采用此线程启发方法的日志采集***将会使大部分时间都消耗在线程的相关操作之上，延缓日志的处理。

为了弥补方法一的缺点，进而提出线程池概念，线程池可以重复地利用池中线程处理短小的任务。线程池中线程的启发方法正如方法二的描述。如果采用此线程启发方法，任务队列中的日志因长期等待新线程创建而延缓处理。

本发明解决传统线程池中线程启发方法的缺点，保证在不频繁地创建和撤销线程的基础之上快速处理日志采集***接受到的日志。本发明有关线程启发方法的内容如下：

在日志采集***之中增加基于事件驱动的检查器，手工设置与任务队列相关的阈值α、日志处理所需理论时间T_E和日志处理时间容忍度β三个参数创建线程池。***每接受到一个日志即为一个事件，驱动检查器检测当前任务队列大小是否超过α。如果超过则启动线程启发方法，首先，计算tn定义为理论需要增加的线程个数，T_E定义为处理日志所需的理论时间，AVGT_Q定义为最近α次日志到达***的平均间隔，P_T定义为***当前时刻线程池中线程的数目。然后，判断tn与α大小，然后取较小值最为真正需要增加的线程数目。最后，计算AVGT_E＞(1+β)T_E的真假值，AVGT_E定义为最近α次日志处理运行的平均值。如果为假值，则创建空闲等待时间大小为T_E的非核心线程，线程数目为tn与α的较小值，并从队列里取出日志进行处理；但是如果为真值，则日志做缓存处理。

具体原理如下:

日志到达***的间隔定义为T_Q，T_Q与日志发送端有关并不断变化。处理日志所需的理论时间定义为T_E，由于每次处理日志所执行的***指令数目大致相等，所以T_E可以近似为常数。线程空闲等待时间定义为T_W，任务队列的大小定义为S_M，T_W和S_M通常可以指定为任意大小，稍后给出并说明一个更小的取值范围。任务队列任意时刻的大小定义为S_T，***任意时刻的线程数目定义为P_T，S_T与P_T反向变化。

当T_Q＞T_E+T_W时，表示日志到达***的速度很慢，一个线程即可满足快速处理，但是此慢速度造成的副作用是在下一个日志到达***之前唯一的线程已经撤销。当T_Q＜T_E+T_W且T_Q＞T_E时，表示日志到达***的速度合理，一个线程即可满足快速处理日志，并且不会造成任何的副作用。针对此两种情况，本发明提出的线程启发方法是在日志采集***运行之初创一个核心线程。核心线程的定义为与***一样生命周期的线程，并不会受T_W的影响。非核心线程的定义为在T_W内没有任务需要执行则自动销毁的线程，生命周期受T_W的影响。

当T_Q＜T_E+T_W且T_Q＜T_E时，表示日志到达***的速度很快，一个线程已经不能满足快速处理日志的需求同时伴随着S_W不断增大，所以当S_W不断增大时需要启动线程启发方法增大P_T。对于此情况，在日志采集***之中增加基于事件驱动的检查器，手工设置α、T_E和β三个参数创建线程池。***每接受到一个日志即为一个事件，驱动检查器检测当前任务队列大小是否超过α。如果超过则启动线程启发方法，首先，计算并判断tn与α大小，然后取较小值最为真正需要增加的线程数目，此步骤是首先计算得是以当前的日志到达***的速率需要多少个线程才能使***处于合理状态，但是任务队列中不可能有这么多日志等待处理，所以还需要与α作比较来确定实际增加的线程数目。然后，计算AVGT_E＞(1+β)T_E的真假值，此步骤是判断***当前线程资源是否达到饱和状态，如果线程资源达到饱和状态，每个线程都在等待当前执行中的线程结束，此时日志处理时间会因等待而增加。因此判断实际执行时间是否超过日志处理时间容忍度来决定是否增加线程。最后，如果上步骤结果为假值，则设置T_W创建非核心线程，并从队列里取出日志进行处理，但是如果为真值，则日志做缓存处理等待***空闲时在做处理。

线程池自适应方法中关键参数的说明如下：

正常情况下，***有足够的处理日志能力时，任务队列中的日志数目应该始终保持为0。一旦任务队列出现日志并且不断增加就说明当前***处理日志的能力不足，需要启动新的线程。因为需要保证到达***的日志需要快速的得到处理，所以α的值应该在[1，+∞)范围内尽可能的小。但是α不建议取1，因为当检测器检测的某一时刻恰好S_T的大小为1，并且有一个线程正在执行最后一个指令，如果此时创建一个非核心线程时则至少有一个线程时因空闲等待超时而停止。所以本发明指定α＝2。

保证线程始终存活的充分条件为T_W＞T_Q，因为只有T_Q＜T_E+T_W且T_Q＜T_E情况下才会创建非核心线程，指定T_W的值，所以T_W＝T_E即可。如果线程在T_W内没有启动，则表明日志到达***的速度在减慢，P_T较大需要减小，这时线程因空闲等待超时而停止正好符合P_T较小的需求。

当检查器检测S_T超过α启动线程启发方法创建非核心线程增大P_T。因为检查器是事件驱动的，能够保证每次S_T增加都会触发检查器，而且S_T与P_T反向变化，所以S_T≤α＜S_M，S_M略大于α即可，本发明采用S_M＝1+α。

日志处理时间容忍度β是用于判断当前日志采集***线程资源是否饱和的重要参数。线程资源饱和指的是因过多线程竞争资源(主要为CPU资源)，处理日志的线程在线程调度的就绪队列中等待时间增加进而造成日志处理时间增加到不如执行日志缓存的状态。此时执行日志处理的所需时间大于执行日志缓存所需的时间，为了保证日志采集***的快速处理能力，就不应该再创建新的线程加剧线程的竞争，而是应该缓存日志。缓存日志就是将日志存储到先存储介质之上，然后等待***空闲时再从存储介质读出日志，最后处理日志，即执行两次IO操作(输入输出操作)和一次处理日志操作。IO操作包含三步骤，分别为寻道、旋转和传送，因此IO操作时间等于执行三个步骤的时间总和。IO操作时间定义为T_IO，存储介质的寻道平均时间定义为T_F，存储介质的旋转速度定义为SP_R，存储介质的传送速度为SP_T，IO操作文件大小定义为S_F。由以上定义可知，因此 $\mathrm{\β}\≥\frac{2\×T_{\mathrm{IO}}+T_E}{T_E}-1=\frac{2T_{\mathrm{IO}}}{T_E}.$

由以上分析可知，在本发明中使用的配置参数有三个，分别为与任务队列相关的阈值α、日志处理所需理论时间T_E和日志处理时间容忍度β。本发明使用的三个参数，T_E可通过测量确定，α已经在上述内容中给出取值范围及建议，β可以根据存储介质的参数确定。而当前大部分非自适应线程池在配置中需要四个参数，分别为核心线程池个数、最大线程池个数、空闲等待时间和任务队列大小，这四个参数值都需要依赖配置人的经验和能力，如果配置不好，非但不能提高***运行效率，反而会降低***吞吐能力。通过比较可以得出，本发明提出的线程池自适应方法减少手工配置参数并且对个别参数给出更准确、范围更小的取值建议。

附图说明

图1线程池中线程数目变化趋势

图2日志处理实际时间

图3实验一线程池中线程数目变化趋势

图4实验一任务队列中日志数目变化趋势

图5实验一缓存日志数目变化趋势

图6实验一日志处理实际时间

图7实验二线程池中线程数目变化趋势

图8实验二任务队列中日志数目变化趋势

图9实验二日志处理实际时间

图10实验三线程池中线程数目变化趋势

图11实验四线程池中线程数目变化趋势

图12实验四日志处理实际时间

具体实施方式

下面我们将通过实验来观察在日志采集***中使用本发明提出的线程池自适应方法的工作效果。

在日志采集***中部署自适应线程池，为了便于观察将所有有关时间的参数进行放大，由毫秒级的时间单位提升到秒级。根据实验所用的硬盘参数计算一次IO操作实际所需要的时间为14毫秒，所以实验参数T_IO＝14秒，日志处理理论时间T_E＝1秒。所以日志发送端发送的速率分为四个阶段，分别为慢、较慢、较快、快，如表1所示。

表1日志发送端发送速率及发送数目

	速度	日志数目
			慢	每2秒发送一条日志	20个
较慢	每1.5秒发送一条日志	20个
			较快	每0.5秒发送一条日志	20个
快	每0.1秒发送一条日志	20个

设置自适应线程池参数α＝2，β＝28，启动日志采集***观察在各个阶段线程池中的线程数目，如图1所示，横坐标为时间轴(单位：秒)，纵坐标为线程池中线程的数目(单位：个)。由图可见，线程池中的线程数目随日志发送端速度增快而增加。线程池中线程的数目在前两个阶段都很稳定，数目一直维持在1，与原理部分中的前两种情况相符，证明了使用1个核心线程即可满足慢和较慢两种发送速率的情况。线程池中的线程数目在后两个阶段稳步增加，没有出现抖动的情况即创建后马上销毁，销毁后马上又创建新的线程。因为使用了本发明提出的线程池自适应方法，一旦感知到日志发送端发送速度增加，自适应方法根据当前***运行状态自动调整线程池中的线程数目来加快处理速度，所以在运行过程之中没有出现***处理日志速度不够而缓存日志的现象，不另用图表形式展示。

图2展示了日志发送端发送的各个日志在日志采集***中的执行处理的时间。因为前面定义日志处理理论时间为1秒，所以实际日志处理要大于等于1秒，所有日志处理实际时间总和为81.609秒。由图可见，第1至41个日志处理实际时间几乎等于理论时间，同样证明了使用1个核心线程即可满足慢和较慢两种发送速率的情况。但是，第42和43个日志处理时间明显增加，此时正好对应到日志发送端的第三个阶段刚开始部分，线程池中线程数量不够，日志在任务队列里等待，所以这两个日志因为等待而延缓了处理进而增加运行时间。此后，自适应方法感知到***处理能力不够，迅速创建了新的线程将任务队列中等待的日志取出进行处理即图1第一次线程数目增加，之后一段时间内日志的处理实际时间几乎等于日志处理理论时间，表明***又一次达到合理的运行状态。同样，第63、66、68和72日志处理实际时间增加分别对应到图1其余四次线程数目增加。图1和图2的后四次变化都是连续出现的，原因是每次线程增加的数目不会超过α＝2但是实际需要更多的线程，所以需要快速地、连续地增加线程数目。每次增加不超过2个线程是出于以下原因考虑的：首先，无法预测日志发送端以一种速度发送日志的数量。以实验第四阶段为例，每0.1秒发送一个日志，通过计算可以得到需要10个线程能满足此速率下日志的处理，但是如果第四阶段只发送9个日志或者更少，在这种情况之下立即将线程池中线程数目增加到10，就会有至少1个或者更多个线程，从创建到销毁整个生命周期之中没有处理过任何一个日志，浪费宝贵的线程资源，所以每次增加少量线程，依靠多次快速地逐渐增加来代替一次性增加。然则，每次增加少量线程具体是多少，本发明考虑到任务队列阀值α，只有当任务队列里日志数量超过α时才能触发线程启发方法，所以肯定会有α个日志等待处理，所以创建不超过α大小的线程能够保证每个新创建的线程都有任务可以执行，不至于浪费线程资源。

下面通过另一组实验来观察在日志采集***中使用没有自适应方法完全靠手工配置的传统线程池的工作效果。日志处理理论时间仍为1秒，日志发送端发送的速率及发送数量同样如表1所示。

实验一，***在各个阶段线程池中的线程数目如图3所示。传统线程池在工作过程中是将不能马上处理的日志加入到任务队列，如果任务队列达到饱和才创建一个新的线程。由图4可见，当***运行到79.5秒时，任务队列达到饱和，创建一个新线程，正好对应到图3第一次线程数目增加的时刻。此后，任务队列一直处于饱和状态，传统线程池不断增加线程数目，直到达到最大线程数目。当线程数目达到最大值并且任务队列也已饱和，此时只能将日志做缓存处理，缓存日志数目变化趋势如图5所示，图5中***运行到80.5秒时开始缓存日志，此时由图3可知当时正好线程池中线程数目达到最大。

实验一各个日志处理实际时间如图6所示，所有日志处理实际时间总和为161.443秒。由图可见，在日志发送端进入第三个阶段开始，日志处理实际时间就一直在增加。

实验一表明手工配置任务队列和最大线程数目两个参数值过小会导致***处理能力过低。所以在实验二中增大任务队列大小观察***处理能力。实验二中线程池中线程数目变化如图7所示，因为任务队列容量增大，所以传统型线程池在实验二的环境下新建线程时间较实验一延后，同时，线程数目在实际运行中的峰值为4没有超过线程池配置的最大线程数5，所以不会出现缓存日志的现象，不另用图表形式展示。图8为任务队列数目的变化，在***运行到81.8秒时任务队列饱和，传统型线程池开始创建新的线程对应图7中上升直线的开始点。虽然较实验一来说处理能力得到了提升不存在缓存日志的现象，但是图9说明了实验二中各个日志的处理实际时间较实验一有所增加，原因就是日志在任务队列中等待的时间过长。实验二所有日志处理实际时间总和为250.451秒。

总结实验一和实验二中传统型线程池的手工配置参数中的问题生成实验三的配置方案，实验三的参数已经与自适应线程池自动生成的配置参数十分相似，唯有空闲等待时间不一样。图10中表明实验三较实验一和实验二能够较早的生成新的线程，原因就是使用了较小的任务队列，任务队列很容易饱和从而生成新的线程。但是因为空闲等待时间过小，导致了新增线程当任务队列为空时，马上又销毁了，即***运行到79秒时销毁了一个线程，而很快任务队列里面又充满了等待处理的日志，又开始重新创建新的线程。如果此情况长期运行就会造成***抖动现象。

修改实验三中的空闲等待时间为1秒生成实验四。至此，实验四的参数已经与自适应线程池自动生成的配置参数一致。图11中展示的传统型线程池线程数目变化已经和图1展示的自适应型线程池线程数目变化大体相似，但是从第四阶段增加的坡度来看，自适应型线程池是阶梯式增加而传统型线程池线程是直线增加。这说明了，自适应型线程池每次增加可以短暂的满足***的处理要求，而传统型线程池每次增加都不能满足***对处理速度的要求，从日志处理实际时间也能够印证这一现象，如图12所示。实验四所有日志处理实际时间总和为250.451秒110.888秒。

由以上四个实验可以得出，实验一中***处理能力最低，出现了日志缓存。实验二中***处理能力较低，虽没有日志缓存，但是所有的日志处理实际时间很长，是采用本发明所用的时间的3倍。实验四中***处理能力最接近采用本发明的***能力，实际处理时间相差无几。但是，因为不存在根据***当前状态适当调整线程数目的方法，所以有可能每次增加线程数目仍不能满足***需要，也有可能当***中存在大量线程时，不会停止创建线程。综上所述，使用本发明的线程池自适应方法可以明显提升日志采集***的性能，而且避免手工配置不当造成的性能低下。

Claims (1)

1.日志采集***线池自适应方法，其特征在于：在日志采集***之中增加基于事件驱动的检查器，设置与任务队列相关的阈值α、日志处理所需理论时间T_E和日志处理时间容忍度β三个参数创建线程池；

***每接受到一个日志即为一个事件，驱动检查器检测当前任务队列大小是否超过α；α＝2；如果超过则启动如下线程启发方法：

首先，计算tn定义为理论需要增加的线程个数，T_E定义为处理日志所需的理论时间，AVGT_Q定义为最近α次日志到达***的平均间隔，P_T定义为***当前时刻线程池中线程的数目；

然后，判断tn与α大小，然后取较小值最为真正需要增加的线程数目；

最后，计算AVGT_E>(1+β)T_E的真假值，AVGT_E定义为最近α次日志处理运行的平均值；如果为假值，则创建空闲等待时间大小为T_E的非核心线程，线程数目为tn与α的较小值，并从队列里取出日志进行处理；但是如果为真值，则日志做缓存处理；

缓存日志就是将日志存储到先存储介质之上，然后等待***空闲时再从存储介质读出日志，最后处理日志，即执行两次IO操作即输入输出操作，和一次处理日志操作；IO操作包含三步骤，分别为寻道、旋转和传送，因此IO操作时间等于执行三个步骤的时间总和；IO操作时间定义为T_IO，存储介质的寻道平均时间定义为T_F，存储介质的旋转速度定义为SP_R，存储介质的传送速度为SP_T，IO操作文件大小定义为S_F；由以上定义可知， $\mathrm{\β}\≥\frac{2\×T_{\mathrm{IO}}+T_E}{T_E}-1=\frac{2T_{\mathrm{IO}}}{T_E}.$