一种监测线程使用率的方法、装置及存储装置
技术领域
本申请涉及互联网技术领域,特别是涉及一种监测线程使用率的方法、装置及存储装置。
背景技术
随着互联网技术的发展,互联网的后端服务需要处理的请求增多,其中,互联网的后端服务主要是多线程并发处理请求任务,运行阶段容易因有些线程阻塞或执行时间比较长,导致线程资源不够用,不能处理新请求的故障。此时通常都是需要开发人员查看日志才能发现是处理什么请求导致的问题,这种方式工作量大,比较耗时,特别是处理请求较多时,更不易查找定位。
发明内容
本申请主要解决的技术问题是提供一种监测线程使用率的方法、装置及存储装置,能够实现对线程使用率的监控与分析。
为解决上述技术问题,本申请采用的一个技术方案是:提供一种监测线程使用率的方法,所述方法包括:获取线程处理请求的开始时间;获取线程处理请求的结束时间,并计算线程处理请求的时延数据,时延数据为结束时间与开始时间的时间差;计算预定周期内线程池的容量总时间;计算预定周期内线程处理请求占用线程池容量的占用率,占用率为时延数据与容量总时间的比值。
其中,计算预定周期内线程处理请求占用线程池容量的总占用率,其中,计算线程处理请求的总时延数据,总时延数据为线程处理请求的请求次数乘以单次请求的时延数据,总占用率为总时延数据与容量总时间的比值。
其中,计算线程池的线程使用率,线程使用率为所有线程处理请求的占用率的总和。
其中,容量总时间为线程池的总线程数乘以预定周期的统计时间。
其中,根据占用率对线程处理请求按照占用率的大小进行排序。
其中,将占用率与预设的阈值进行比较;标记占用率大于预设的阈值的线程处理请求。
其中,限制占用率大于预设的阈值的线程处理请求在预定周期内的请求次数或频率。
为解决上述技术问题,本申请采用的另一个技术方案是:提供一种监测线程使用率的装置,所述装置包括:第一获取模块,用于获取线程处理请求的开始时间;第二获取模块,用于获取线程处理请求的结束时间,并计算线程处理请求的时延数据,时延数据为结束时间与开始时间的时间差;第一计算模块,用于计算预定周期内线程池的容量总时间;第二计算模块,用于计算预定周期内线程处理请求占用线程池容量的占用率,占用率为时延数据与容量总时间的比值。
为解决上述技术问题,本申请采用的另一个技术方案是:提供一种监测线程使用率的装置,所述装置包括处理器,处理器用于获取线程处理请求的开始时间及结束时间,并计算线程处理请求的时延数据,时延数据为结束时间与开始时间的时间差;处理器还用于计算预定周期内线程池的容量总时间;并计算预定周期内线程处理请求占用线程池容量的占用率,占用率为时延数据与容量总时间的比值。
为解决上述技术问题,本申请采用的另一个技术方案是:提供一种具有存储功能的装置,所述装置存储有程序,所述程序被执行时实现权上述的监测线程使用率的方法。
本申请的有益效果是:区别于现有技术的情况,本申请提供一种监测线程使用率的方法,通过计算线程处理请求的占用率能够得到该线程处理请求占用了线程池多少资源,进而监测线程池的使用率,有效控制防止线程池发生阻塞,同时能够监测定位到导致线程池阻塞的线程处理请求,进而采取相应的解决措施。
附图说明
图1是本申请监测线程使用率的方法第一实施方式的流程示意图;
图2是本申请监测线程使用率的方法第二实施方式的流程示意图;
图3是本申请监测线程使用率的装置第一实施方式的结构示意图;
图4是本申请监测线程使用率的装置第二实施方式的结构示意图;
图5是本申请具有存储功能的装置第一实施方式的结构示意图。
具体实施方式
为使本申请的目的、技术方案及效果更加清楚、明确,以下参照附图并举实施例对本申请进一步详细说明。
本申请提供一种监测线程使用率的方法、装置及存储装置,至少应用于如下场景,在后台服务器处理任务请求时,监测计算每一任务请求所占用线程池总容量的比例,以便于分析哪些任务请求过多的消耗了线程池资源,导致线程阻塞、使线程资源不够用,不能处理新请求的故障。
请参阅图1,图1是本申请监测线程使用率的方法第一实施方式的流程示意图。在该实施方式中,监测线程使用率的方法包括如下步骤:
S101:获取线程处理请求的开始时间。
其中,线程池是一种多线程处理形式,能有效的处理多个线程的并发问题,避免大量的线程因为互相强占***资源导致阻塞现象,能够有效的降低频繁创建和销毁线程对性能所带来的开销。默认情况下,在创建了线程池后,线程池中的线程数为0;当有任务来之后,就会创建一个线程去执行任务;当线程池中的线程数目达到最大线程数后,就会把到达的任务放到缓存队列当中。其中,最大线程数表示在预定周期内,线程池中最多能创建多少个线程。其中,在对预定周期进行统计时,在统计周期开始时,开始计时;在统计周期结束时,停止计时;随后时间归零,开始新的一个周期的统计。以统计周期开始时间为基准,记为0点或0秒,当有任务来之后,开始创建一个新的线程去执行任务,记为线程处理请求的开始时间;例如,统计周期的起始时间为0秒,在第200ms时开始创建一个新的线程去执行任务,那么该线程处理请求的开始时间即为200ms。
S102:获取线程处理请求的结束时间,并计算线程处理请求的时延数据。
其中,在线程处理请求开始之后,继续进行计时,并记录线程处理请求的结束时间,例如,在第500ms时线程处理请求结束,那么线程处理请求的结束时间即为500ms。其中,整个线程处理请求所持续的时间为时延数据,具体地,时延数据为结束时间与开始时间的时间差。可以是利用结束时间减去开始时间得到,也可以是开始时间减去结束时间,然后取正得到时延数据。例如,线程处理请求的开始时间是200ms,结束时间是500ms,那么时延数据为300ms(500ms-200ms)。
S103:计算预定周期内线程池的容量总时间。
其中,线程池的容量总时间为在一个统计周期内线程池所有线程的执行总时间。即线程池的总线程数乘以预定周期的统计时间。
S104:计算预定周期内线程处理请求占用线程池容量的占用率。
其中,占用率为时延数据与容量总时间的比值。在一个统计周期内,线程池的容量总时间小于或等于预设的时间,具体与线程池的线程数有关;每运行一个线程处理请求都会占用一部分线程池的资源,当线程池被占满时容易发生阻塞。在该实施方式中,通过计算线程处理请求的占用率能够得到该线程处理请求占用了线程池多少资源,进而监测线程池的使用率,有效控制防止线程池发生阻塞,同时能够监测定位到导致线程池阻塞的线程处理请求,进而采取相应的解决措施。
可选地,在一个统计周期内,同一线程处理请求可能运行了多次,因此,一方面可以计算单次线程处理请求的占用率,另一方面也可以计算同一线程处理请求的总占用率,即计算一个统计周期内同一线程处理请求的总时延数据,总时延数据为该线程处理请求的请求次数乘以该线程处理请求单次的时延数据,然后计算总时延数据与线程池容量总时间的比值,得到该线程处理请求的总占用率。通过计算线程处理请求的总占用率,能够更全面的评估该线程处理请求占用了线程池多少资源。
可选地,除了监测计算每一线程处理请求的占用率外,还可以计算线程池的线程使用率,以监测线程池的使用状态。其中,线程使用率为所有线程处理请求的占用率的总和。可以分别计算每一线程处理请求的占用率,然后对占用率求和得到线程使用率;也可以计算所有线程处理请求的总时延数据,然后计算总时延数据与线程池容量总时间的比值,得到线程使用率。
可选地,在监测计算线程处理请求占用率的同时,可以根据占用率对线程处理请求进行排序,例如将线程处理请求按照占用率从大到小进行倒序排列。通过根据占用率对线程处理请求进行排序可以直观快速的获知哪些线程处理请求占用了线程池较多的资源。
可选地,为了合理利用线程池资源,可以对占用率较大的线程处理请求进行限制,或合理规划该线程处理请求发生的时间、次数。其中,预先设定一个占用率的高值阈值,将占用率大于该预设的阈值的线程处理请求定义为占用线程池资源较多的线程处理请求。
具体地,将线程处理请求的占用率与预设的阈值进行比较;标记占用率大于预设的阈值的线程处理请求。其中,可以逐一将线程处理请求的占用率与预设的阈值进行比较;也可以根据占用率将线程处理请求分为多个等级;如占用率在40~60%之间的为第一等级,占用率在20~40%之间的为第二等级,占用率在5~20%之间的为第三等级;然后仅对某一等级内的线程处理请求进行比较和标记,也可以直接对某一等级内的所有线程处理请求进行标记。通过对线程处理请求进行标记,能够快速定位出占用了线程池较多资源的线程处理请求。
可选地,对被标记的线程处理请求进行限制,即限制占用率大于预设的阈值的线程处理请求在预定周期内的请求次数或频率;如当其请求次数达到限制值时,则将其加入等待队列。通过对这些线程处理请求进行限制,能够合理利用线程池的资源,防止出现阻塞,进而提高线程池的利用率。
以上方案,通过计算线程处理请求的占用率能够得到该线程处理请求占用了线程池多少资源,进而监测线程池的使用率,有效控制防止线程池发生阻塞,同时能够监测定位到导致线程池阻塞的线程处理请求,进而采取相应的解决措施。下面,以一个应用场景对上述方法进行描述,该应用场景只是一个示例,对技术方案不做限定。
请参阅图2,图2是本申请监测线程使用率的方法第二实施方式的流程示意图。在该实施方式中,线程池内包括3个线程,监测线程使用率的方法包括如下步骤:
在线程池内获取线程处理请求并记录开始时间。如获取请求uri1:/getGiftList和请求uri2:/sendGift,记录开始时间,例如300ms。
在线程处理请求执行完时记录结束时间,并计算时延数据,时延数据为结束时间与开始时间的时间差。其中,请求1的时延数据为100ms(时延数据)=400ms(结束时间)-300ms(开始时间);请求2的时延数据为200ms(时延数据)=500ms(结束时间)-300ms(开始时间)。
将监控所得数据发送给采集运算器进行聚合运算。
其中,计算一个统计周期内线程池中所有线程能执行的总时间,即:180s(容量总时间)=60s(时间周期)*3(线程数)。
其中,计算一个统计周期内各请求处理实际的时延总时间,即:150s(实际总时间)=100s(sum(uri 1时延))+50s(sum(uri 2时延))。其中,在这一统计周期内,请求1被执行了1000次,所以请求1的总时延数据100s(uri1总时延)=1000(执行次数)*100ms(单次时延数据);请求2被执行了500次,所以请求2的总时延数据50s(uri1总时延)=500(执行次数)*100ms(单次时延数据)。
其中,计算线程池资源容量占比,即:83.33(线程使用率)=150s(实际总时间)/180s(容量总时间)。
其中,在计算线程使用率的同时,也可以计算单个线程处理请求的占用率,然后根据占用率排列出消耗线程资源的请求URI(Uniform Resource Identifier,URI)倒序列表,定位到导致线程使用率高的线程处理请求。然后可以对这些占用资源较多的线程处理请求进行限制,以提高线程池的使用率。
基于上述监测线程使用率的方法,本申请还提供一种监测线程使用率的装置,请参阅图3,图3是本申请监测线程使用率的装置第一实施方式的结构示意图。在该实施方式中,监测线程使用率的装置30包括:处理器301,处理器301用于获取线程处理请求的开始时间及结束时间,并计算线程处理请求的时延数据,时延数据为结束时间与开始时间的时间差;处理器301还用于计算预定周期内线程池的容量总时间;并计算预定周期内线程处理请求占用线程池容量的占用率,占用率为时延数据与容量总时间的比值。
其中,在一实施方式中,处理器301还用于计算预定周期内线程处理请求占用线程池容量的总占用率,其中,处理器301具体用于计算线程处理请求的总时延数据,总时延数据为线程处理请求的请求次数乘以单次时延数据,总占用率为总时延数据与容量总时间的比值。
其中,在一实施方式中,处理器301还用于计算线程池的线程使用率,线程使用率为所有线程处理请求的占用率的总和。
其中,在一实施方式中,处理器301还用于根据占用率对线程处理请求进行排序。
其中,在一实施方式中,处理器301还用于将占用率与预设的阈值进行比较;标记占用率大于预设的阈值的线程处理请求。
其中,在一实施方式中,处理器301还用于限制占用率大于预设的阈值的线程处理请求在预定周期内的请求次数或频率。
以上,该监测线程使用率的装置可用于执行上述方法,对相应数据进行聚合运算,且具有相应的有益效果,具体请参阅上述实施方式的描述,在此不再赘述。其中该监测线程使用率的装置可以是独立于后台服务器的独立装置,也可以是服务器中的某一模块,或某一处理单元。
请参阅图4,图4是本申请监测线程使用率的装置第二实施方式的结构示意图。在该实施方式中,监测线程使用率的装置40包括第一获取模块401、第二获取模块402、第一计算模块403和第二计算模块404,其中,第一获取模块401用于获取线程处理请求的开始时间;第二获取模块402用于获取线程处理请求的结束时间,并计算线程处理请求的时延数据,时延数据为结束时间与开始时间的时间差。第一计算模块403用于计算预定周期内线程池的容量总时间;第二计算模块404用于计算预定周期内线程处理请求占用线程池容量的占用率,占用率为时延数据与容量总时间的比值。
其中,在一实施方式中,第一计算模块403具体用于将线程池的总线程数乘以预定周期的统计时间以算得线程池的容量总时间。
其中,在一实施方式中,第二计算模块404还用于计算预定周期内线程处理请求占用线程池容量的总占用率,其中,第二计算模块404具体用于计算线程处理请求的总时延数据,总时延数据为线程处理请求的请求次数乘以单次时延数据,总占用率为总时延数据与容量总时间的比值。第二计算模块404还用于计算线程池的线程使用率,线程使用率为所有线程处理请求的占用率的总和。
其中,在一实施方式中,监测线程使用率的装置还包括排序模块(图未示),排序模块用于根据占用率对线程处理请求进行排序。
其中,在一实施方式中,监测线程使用率的装置还包括比较模块(图未示),比较模块用于将占用率与预设的阈值进行比较;标记占用率大于预设的阈值的线程处理请求。
其中,在一实施方式中,监测线程使用率的装置还包括限制模块(图未示),限制模块用于限制占用率大于预设的阈值的线程处理请求在预定周期内的请求次数或频率。
以上,该监测线程使用率的装置可用于执行上述方法,对相应数据进行聚合运算,且具有相应的有益效果,具体请参阅上述实施方式的描述,在此不再赘述。其中该监测线程使用率的装置可以是独立于后台服务器的独立装置,也可以是服务器中的某一模块,或某一处理单元。
基于上述监测线程使用率的方法,本申请还提供一种具有存储功能的装置,请参阅图5,图5是本申请具有存储功能的装置第一实施方式的结构示意图。在该实施方式中,存储装置50存储有程序501,程序501被执行时实现上述监测线程使用率的方法。具体工作过程与上述方法实施例中一致,故在此不再赘述,详细请参阅以上对应方法步骤的说明。其中具有存储功能的装置可以是便携式存储介质如U盘、光盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟等各种可以存储程序代码的介质,也可以是终端、服务器等。
以上方案,本申请提供一种监测线程使用率的方法,通过计算线程处理请求的占用率能够得到该线程处理请求占用了线程池多少资源,进而监测线程池的使用率,有效控制防止线程池发生阻塞,同时能够监测定位到导致线程池阻塞的线程处理请求,进而采取相应的解决措施。
在本申请所提供的几个实施方式中,应该理解到,所揭露的***,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施方式仅仅是示意性的,例如,所述模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。
另外,在本申请各个实施方式中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本申请各个实施方式所述方法的全部或部分步骤。
以上所述仅为本申请的实施方式,并非因此限制本申请的专利范围,凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本申请的专利保护范围内。