CN110554920A - 处理容量不健康模块的方法以及装置 - Google Patents
处理容量不健康模块的方法以及装置 Download PDFInfo
- Publication number
- CN110554920A CN110554920A CN201910804986.0A CN201910804986A CN110554920A CN 110554920 A CN110554920 A CN 110554920A CN 201910804986 A CN201910804986 A CN 201910804986A CN 110554920 A CN110554920 A CN 110554920A
- Authority
- CN
- China
- Prior art keywords
- capacity
- module
- unhealthy
- server
- called
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5083—Techniques for rebalancing the load in a distributed system
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请公开了一种处理容量不健康模块的方法以及装置。该方法包括记录容量不健康模块下服务器的被调用量和被调用权重;确定容量不健康模块的模块容量;计算单台服务器容量支撑能力;确定所述模块容量的预设安全阈值;在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升;对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否仍属于不健康,如果是则继续处理。本申请解决了缺乏处理容量不健康的业务模块进行容量调优的方案的技术问题。通过本申请让服务器之间的容量尽可能都集中在一个能接受的容量区间内,从而使得不健康业务模块容量成为容量健康业务模块。
Description
技术领域
本申请涉及业务集群处理领域,具体而言,涉及一种处理容量不健康模块的方法以及装置。
背景技术
业务请求发起经负载均衡接入,请求数量会基本均匀落在被调用模块下服务器上,因服务器之间的性能差异,就会导致容量上就会出现差别。
发明人发现,由于缺乏处理容量不健康的业务模块进行容量调优的方案,从而不利于使得该业务模块容量成为健康的状态。
针对相关技术中缺乏处理容量不健康的业务模块进行容量调优的方案的问题,目前尚未提出有效的解决方案。
发明内容
本申请的主要目的在于提供一种处理容量不健康模块的方法以及装置,以解决缺乏处理容量不健康的业务模块进行容量调优的方案的问题。
为了实现上述目的,根据本申请的一个方面,提供了一种处理容量不健康模块的方法。
根据本申请的处理容量不健康模块的方法包括:记录容量不健康模块下服务器的被调用量和被调用权重;确定容量不健康模块的模块容量;计算单台服务器容量支撑能力;确定所述模块容量的预设安全阈值;在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升;对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否仍属于不健康,如果是则继续处理。
进一步地,判断所述容量不健康模块的容量是否仍属于不健康时,采用如下方法:
当业务集群中接收到对于同一个业务模块下的服务器调用请求时,判断服务器之间的模块容量是否具有差别;
如果模块容量有差别,则调整所述服务器的被调用权重,以均衡所述服务器之间的容量。
进一步地,在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升,采用如下方法:
在服务器之间的模块容量有差别时,调整所述服务器的被调用权重得到新的权重=(单台支撑能力*容量基准)/被调用量;
其中所述容量基准为容量最高的安全阈值,所述单台支撑能力是指服务器容量支撑能力。
进一步地,计算单台服务器容量支撑能力采用如下方法:
单台支撑能力=(被调用量*被调用权重)/模块容量
所述模块容量选用CPU使用率。
进一步地,确定所述模块容量的预设安全阈值之后,还包括:
根据所述预设安全阈值寻找所述业务模块下容量最高的服务器,并且确认所述最高的容量是否在安全阈值范围内;
在所述被调用量保持不变的情况下,以最高容量作为基准值。
为了实现上述目的,根据本申请的另一方面,提供了一种处理容量不健康模块的装置,用于集群中的服务器。
根据本申请的处理容量不健康模块的装置包括:记录模块,用于记录容量不健康模块下服务器的被调用量和被调用权重;第一确定模块,用于确定容量不健康模块的模块容量;计算模块,用于计算单台服务器容量支撑能力;第二确定模块,用于确定所述模块容量的预设安全阈值;权重提升模块,用于在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升;对比模块,用于对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否任然属于不健康,如果是则继续处理。
进一步地,所述对比模块,用于
当业务集群中接收到对于同一个业务模块下的服务器调用请求时,判断服务器之间的模块容量是否具有差别;
如果模块容量有差别,则调整所述服务器的被调用权重,以均衡所述服务器之间的容量。
进一步地,所述权重提升模块,用于进行如下操作:
在服务器之间的模块容量有差别时,调整所述服务器的被调用权重得到新的权重=(单台支撑能力*容量基准)/被调用量;
其中所述容量基准为容量最高的安全阈值,所述单台支撑能力是指服务器容量支撑能力。
进一步地,所述计算模块用于进行如下操作:
单台支撑能力=(被调用量*被调用权重)/模块容量
所述模块容量选用CPU使用率。
进一步地,装置还包括:阈值模块,用于
根据所述预设安全阈值寻找所述业务模块下容量最高的服务器,并且确认所述最高的容量是否在安全阈值范围内;
在所述被调用量保持不变的情况下,以最高容量作为基准值。
在本申请实施例中处理容量不健康模块的方法以及装置,采用记录容量不健康模块下服务器的被调用量和被调用权重;确定容量不健康模块的模块容量;计算单台服务器容量支撑能力;确定所述模块容量的预设安全阈值;在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升;对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否仍属于不健康,如果是则继续处理的方式,通过调整模块权重,达到了让服务器之间的容量尽可能都集中在一个能接受的容量区间内的目的,从而实现了使得不健康业务模块容量成为容量健康业务模块的技术效果,进而解决了缺乏处理容量不健康的业务模块进行容量调优的方案的技术问题。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解,使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1是根据本申请第一实施例的处理容量不健康模块的方法流程示意图;
图2是根据本申请第二实施例的处理容量不健康模块的方法流程示意图;
图3是根据本申请第三实施例的处理容量不健康模块的方法流程示意图;
图4是根据本申请实施例的处理容量不健康模块的装置结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
在本申请中,术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本申请及其实施例,并非用于限定所指示的装置、元件或组成部分必须具有特定方位,或以特定方位进行构造和操作。
并且,上述部分术语除了可以用于表示方位或位置关系以外,还可能用于表示其他含义,例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言,可以根据具体情况理解这些术语在本申请中的具体含义。
此外,术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如,可以是固定连接,可拆卸连接,或整体式构造;可以是机械连接,或电连接;可以是直接相连,或者是通过中间媒介间接相连,又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言,可以根据具体情况理解上述术语在本申请中的具体含义。
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
在本申请中当同一个模块下每台服务器面对同数量被调用请求,服务器之间的容量出现差别较大时,需要对该模块下的服务器被调用权重进行优化调整,通过对服务器权重的调整,让服务器之间的容量尽可能都集中在一个能接受的容量区间内,使该业务模块容量成为容量健康业务模块。
如图1所示,该方法包括如下的步骤S102至步骤S112:
步骤S102,记录容量不健康模块下服务器的被调用量和被调用权重;
步骤S104,确定容量不健康模块的模块容量;
步骤S106,计算单台服务器容量支撑能力;
步骤S108,确定所述模块容量的预设安全阈值;
步骤S110,在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升;
步骤S112,对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否仍属于不健康,如果是则继续处理。
需要注意的是,由于业务请求发起经负载均衡接入,请求数量会基本均匀落在被调用模块下服务器上,因服务器之间的性能差异,就会导致容量上就会出现差别。具体地,有一些模块下服务器之间容量差别不大,在能接受范围内的,定义为容量健康模块。此外,另有一些模块下服务器之间容量差别较大,那定义为容量不健康模块。
上述的处理容量不健康模块的方法,通过记录容量不健康模块下服务器的被调用量和被调用权重,可以选用业务使用高峰期进行记录。确定容量不健康模块的模块容量,优选地,所述模块容量选用CPU使用率。
通过计算单台服务器容量支撑能力作用计算新权重股你值的基础。
确定所述模块容量的预设安全阈值,并以安全阈值为基准在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升,然后再对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否仍属于不健康,如果是则继续处理。
具体地,以下以模块A,容量核心指标CPU使用率,模块下7台服务器,如业务高峰期每台服务器被访问/被调用量N=2000次/秒,每台服务器被调用权重都是q=100作为例子进行举例。
步骤一:在业务使用高峰期容量不健康模块记录如下数据:
服务器1 | 服务器2 | 服务器3 | 服务器4 | 服务器5 | 服务器6 | 服务器7 | |
被调用量 | 2000次/秒 | 2000次/秒 | 2000次/秒 | 2000次/秒 | 2000次/秒 | 2000次/秒 | 2000次/秒 |
被调用权重 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
CPU使用率(%) | 70 | 60 | 55 | 81 | 72 | 48 | 51 |
步骤二:计算单台服务器容量支撑能力,单台支撑能力=(被调用量*被调用权重)/CPU,单台支撑能力取整,计算得数据:
(被调用量*被调用权重)=2000*100=200000
服务器1 | 服务器2 | 服务器3 | 服务器4 | 服务器5 | 服务器6 | 服务器7 | |
计算过程 | =20000/70 | =20000/60 | =20000/55 | =20000/81 | =20000/72 | =20000/48 | =20000/51 |
单台支撑能力 | 2857 | 3333 | 3636 | 2469 | 2777 | 4166 | 3921 |
步骤三:制定的容量最高安全值:比如,表中的CPU利用率为85%,寻找该模块下容量最高的服务器,并且确认所述最高的容量是否在安全值范文内,如上表中服务器4容量最高,为81,且在最高范围值内。
步骤四:在被调用量不变的情况下,已最高容量81为基准值,对容量没有达到81的模块进行权重提升,让其容量达到81,计算方法如下:
新的权重值=(单台支撑能力*容量基准)/被调用量;
然后根据其它服务器的容量进行新权重计算,结果取整,数据如下:
步骤五:现网调整权重,然后观察高峰时期模块下各服务器容量的数据并记录。
现网调整权重可具体见下表。由于理论计算值和调优后服务器真实容量值可能存在一定的差异,理论是应该也是一致的。比如,下表中的x1..x7的值都应该是81,但实际可能存在一些偏差,有些服务器因硬件性能不一样。
所以在请求增加时,负载上升的幅度会比预期的高,采用x1...x7作为标识。比如,x1...x7中的值不是81,并且和81相减的绝对值大于5且在调优后服务器1容量真实值x1=86时,就需要再对该服务器1容量做一次调优。调整后高峰期容量计算理论值:
服务器1 | 服务器2 | 服务器3 | 服务器4 | 服务器5 | 服务器6 | 服务器7 | |
调整后权重 | 116 | 135 | 147 | 100 | 112 | 169 | 159 |
权重调整后新容量值 | 81 | 81 | 81 | 81 | 81 | 81 | 81 |
调整后高峰期容量真实值:
服务器1 | 服务器2 | 服务器3 | 服务器4 | 服务器5 | 服务器6 | 服务器7 | |
调整后权重 | 116 | 135 | 147 | 100 | 112 | 169 | 159 |
权重调整后新容量值 | x1 | x2 | x3 | x4 | x5 | x6 | x7 |
从以上的描述中,可以看出,本申请实现了如下技术效果:
在本申请实施例中,采用记录容量不健康模块下服务器的被调用量和被调用权重;确定容量不健康模块的模块容量;计算单台服务器容量支撑能力;确定所述模块容量的预设安全阈值;在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升;对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否仍属于不健康,如果是则继续处理的方式,通过调整模块权重,达到了让服务器之间的容量尽可能都集中在一个能接受的容量区间内的目的,从而实现了使得不健康业务模块容量成为容量健康业务模块的技术效果,进而解决了缺乏处理容量不健康的业务模块进行容量调优的方案的技术问题
根据本申请实施例,作为本实施例中的优选,如图2所示,判断所述容量不健康模块的容量是否仍属于不健康时,采用如下方法:
步骤S202,当业务集群中接收到对于同一个业务模块下的服务器调用请求时,判断服务器之间的模块容量是否具有差别;
当业务集群中接收到对于同一个业务模块下的服务器调用请求时需要判断服务器之间的模块容量是否具有差别。比如判断服务器之间的模块容量是否有较大差别,或者,判断服务器之间的模块容量的差别是否超出了阈值。
具体地,所述模块容量是指,根据模块的功能从模块的多个指标维度中选出一个指标做为模块容量衡量的唯一核心标准。
需要注意的是,可以作为指标有:模块中服务器的CPU使用率、内存使用率、I/O使用率、模块程序上业务返回码等等。
比如,接入型服务,一般选CPU的使用率做为本模块支撑性能唯一核心指标,CPU使用率90%了,说明该模块已达到性能最大支撑瓶颈。
又比如,数据存储模块,一般选磁盘I/O读写性能做为唯一核心指标。
步骤S204,如果模块容量有差别,则调整所述服务器的被调用权重,以均衡所述服务器之间的容量。
如果根据判断结果得知模块容量有差别,则调整所述服务器的被调用权重,以均衡所述服务器之间的容量使得模块容量为健康容量模块。
需要注意的是,由于业务请求发起经负载均衡接入,请求数量会基本均匀落在被调用模块下服务器上,因服务器之间的性能差异,就会导致容量上就会出现差别。具体地,有一些模块下服务器之间容量差别不大,在能接受范围内的,定义为容量健康模块。此外,另有一些模块下服务器之间容量差别较大,那定义为容量不健康模块。
还需要注意的是,判断模块容量是否属于健康容量的方法可以采用多种,在本申请的实施例中并不进行具体限定,本领域技术人员可以根据实际使用情况进行选择。
所述业务集群是指,多个业务模块的组成后实现一个完整业务功能或者某各核心功能的集合。
所述业务模块是指,某个业务功能点部署在单个服务器或者一组服务器上的集合。
根据本申请实施例,作为本实施例中的优选,在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升,采用如下方法:
在服务器之间的模块容量有差别时,调整所述服务器的被调用权重得到新的权重=(单台支撑能力*容量基准)/被调用量;
其中所述容量基准为容量最高的安全阈值,所述单台支撑能力是指服务器容量支撑能力。
通过确定接收到对于同一个业务模块下的服务器调用请求时被调用量和被调用权重,然后在服务器之间的模块容量有差别时,调整所述服务器的被调用权重得到新的权重=(单台支撑能力*容量基准)/被调用量。
所述容量基准为容量最高的安全阈值,所述单台支撑能力是指服务器容量支撑能力。
上述调优方法,通过被调用模块下服务器被调用权重的调整,让模块下不同性能的服务器利用率都能最大化,并且能均衡服务器之间的容量,避免某台服务器容量短板而引起连锁奔溃,让业务在运营中更稳定,服务器成本最优。
根据本申请实施例,作为本实施例中的优选,计算单台服务器容量支撑能力采用如下方法:
单台支撑能力=(被调用量*被调用权重)/模块容量
所述模块容量选用CPU使用率。
优选地,如果一次调优结果不能够满足需求即达不到容量标准值,则需要进行多次调优。
计算单台服务器容量支撑能力,单台支撑能力=(被调用量*被调用权重)/CPU,单台支撑能力取整,计算得数据。
根据本申请实施例,作为本实施例中的优选,如图3所示,确定所述模块容量的预设安全阈值之后,还包括:
步骤S302,根据所述预设安全阈值寻找所述业务模块下容量最高的服务器,并且确认所述最高的容量是否在安全阈值范围内;
步骤S304,在所述被调用量保持不变的情况下,以最高容量作为基准值。
根据所述预设安全阈值寻找所述业务模块下容量最高的服务器,并且确认所述最高的容量是否在安全阈值范围内,同时在所述被调用量保持不变的情况下,以最高容量作为基准值。
具体地,制定的容量最高安全值:比如,表中的CPU利用率为85%,寻找该模块下容量最高的服务器,并且确认此最高的容量是否在安全值范文内,在被调用量不变的情况下,已最高容量81为基准值,对容量没有达到81的模块进行权重提升,让其容量达到81。
需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
根据本申请实施例,还提供了一种用于实施上述处理容量不健康模块的方法的装置,用于集群中的服务器,如图4所示,该装置包括:记录模块10,用于记录容量不健康模块下服务器的被调用量和被调用权重;第一确定模块20,用于确定容量不健康模块的模块容量;计算模块30,用于计算单台服务器容量支撑能力;第二确定模块40,用于确定所述模块容量的预设安全阈值;权重提升模块50,用于在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升;对比模块60,用于对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否任然属于不健康,如果是则继续处理。
需要注意的是,由于业务请求发起经负载均衡接入,请求数量会基本均匀落在被调用模块下服务器上,因服务器之间的性能差异,就会导致容量上就会出现差别。具体地,有一些模块下服务器之间容量差别不大,在能接受范围内的,定义为容量健康模块。此外,另有一些模块下服务器之间容量差别较大,那定义为容量不健康模块。
上述的处理容量不健康模块的方法,通过记录容量不健康模块下服务器的被调用量和被调用权重,可以选用业务使用高峰期进行记录。确定容量不健康模块的模块容量,优选地,所述模块容量选用CPU使用率。
通过计算单台服务器容量支撑能力作用计算新权重股你值的基础。
确定所述模块容量的预设安全阈值,并以安全阈值为基准在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升,然后再对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否仍属于不健康,如果是则继续处理。
具体地,以下以模块A,容量核心指标CPU使用率,模块下7台服务器,如业务高峰期每台服务器被访问/被调用量N=2000次/秒,每台服务器被调用权重都是q=100作为例子进行举例。
步骤一:在业务使用高峰期容量不健康模块记录如下数据:
服务器1 | 服务器2 | 服务器3 | 服务器4 | 服务器5 | 服务器6 | 服务器7 | |
被调用量 | 2000次/秒 | 2000次/秒 | 2000次/秒 | 2000次/秒 | 2000次/秒 | 2000次/秒 | 2000次/秒 |
被调用权重 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
CPU使用率(%) | 70 | 60 | 55 | 81 | 72 | 48 | 51 |
步骤二:计算单台服务器容量支撑能力,单台支撑能力=(被调用量*被调用权重)/CPU,单台支撑能力取整,计算得数据:
(被调用量*被调用权重)=2000*100=200000
服务器1 | 服务器2 | 服务器3 | 服务器4 | 服务器5 | 服务器6 | 服务器7 | |
计算过程 | =20000/70 | =20000/60 | =20000/55 | =20000/81 | =20000/72 | =20000/48 | =20000/51 |
单台支撑能力 | 2857 | 3333 | 3636 | 2469 | 2777 | 4166 | 3921 |
步骤三:制定的容量最高安全值:比如,表中的CPU利用率为85%,寻找该模块下容量最高的服务器,并且确认所述最高的容量是否在安全值范文内,如上表中服务器4容量最高,为81,且在最高范围值内。
步骤四:在被调用量不变的情况下,已最高容量81为基准值,对容量没有达到81的模块进行权重提升,让其容量达到81,计算方法如下:
新的权重值=(单台支撑能力*容量基准)/被调用量;
然后根据其它服务器的容量进行新权重计算结果取整,数据如下:
步骤五:现网调整权重,然后观察高峰时期模块下各服务器容量的数据并记录。
现网调整权重可具体见下表。由于理论计算值和调优后服务器真实容量值可能存在一定的差异,理论是应该也是一致的。比如,下表中的x1..x7的值都应该是81,但实际可能存在一些偏差,有些服务器因硬件性能不一样。
所以在请求增加时,负载上升的幅度会比预期的高,采用x1...x7作为标识。比如,x1...x7中的值不是81,并且和81相减的绝对值大于5且在调优后服务器1容量真实值x1=86时,就需要再对该服务器1容量做一次调优。调整后高峰期容量计算理论值:
服务器1 | 服务器2 | 服务器3 | 服务器4 | 服务器5 | 服务器6 | 服务器7 | |
调整后权重 | 116 | 135 | 147 | 100 | 112 | 169 | 159 |
权重调整后新容量值 | 81 | 81 | 81 | 81 | 81 | 81 | 81 |
调整后高峰期容量真实值:
服务器1 | 服务器2 | 服务器3 | 服务器4 | 服务器5 | 服务器6 | 服务器7 | |
调整后权重 | 116 | 135 | 147 | 100 | 112 | 169 | 159 |
权重调整后新容量值 | x1 | x2 | x3 | x4 | x5 | x6 | x7 |
根据本申请实施例,作为本实施例中的优选,所述对比模块60,用于当业务集群中接收到对于同一个业务模块下的服务器调用请求时,判断服务器之间的模块容量是否具有差别;如果模块容量有差别,则调整所述服务器的被调用权重,以均衡所述服务器之间的容量。
本申请实施例的所述对比模块60中当业务集群中接收到对于同一个业务模块下的服务器调用请求时需要判断服务器之间的模块容量是否具有差别。比如判断服务器之间的模块容量是否有较大差别,或者,判断服务器之间的模块容量的差别是否超出了阈值。
具体地,所述模块容量是指,根据模块的功能从模块的多个指标维度中选出一个指标做为模块容量衡量的唯一核心标准。
需要注意的是,可以作为指标有:模块中服务器的CPU使用率、内存使用率、I/O使用率、模块程序上业务返回码等等。
比如,接入型服务,一般选CPU的使用率做为本模块支撑性能唯一核心指标,CPU使用率90%了,说明该模块已达到性能最大支撑瓶颈。
又比如,数据存储模块,一般选磁盘I/O读写性能做为唯一核心指标。
本申请实施例的所述对比模块60中如果根据判断结果得知模块容量有差别,则调整所述服务器的被调用权重,以均衡所述服务器之间的容量使得模块容量为健康容量模块。
需要注意的是,由于业务请求发起经负载均衡接入,请求数量会基本均匀落在被调用模块下服务器上,因服务器之间的性能差异,就会导致容量上就会出现差别。具体地,有一些模块下服务器之间容量差别不大,在能接受范围内的,定义为容量健康模块。此外,另有一些模块下服务器之间容量差别较大,那定义为容量不健康模块。
还需要注意的是,判断模块容量是否属于健康容量的方法可以采用多种,在本申请的实施例中并不进行具体限定,本领域技术人员可以根据实际使用情况进行选择。
所述业务集群是指,多个业务模块的组成后实现一个完整业务功能或者某各核心功能的集合。
所述业务模块是指,某个业务功能点部署在单个服务器或者一组服务器上的集合。
根据本申请实施例,作为本实施例中的优选,所述权重提升模块50,用于进行如下操作:在服务器之间的模块容量有差别时,调整所述服务器的被调用权重得到新的权重=(单台支撑能力*容量基准)/被调用量;其中所述容量基准为容量最高的安全阈值,所述单台支撑能力是指服务器容量支撑能力。
通过确定接收到对于同一个业务模块下的服务器调用请求时被调用量和被调用权重,然后在服务器之间的模块容量有差别时,调整所述服务器的被调用权重得到新的权重=(单台支撑能力*容量基准)/被调用量。
所述容量基准为容量最高的安全阈值,所述单台支撑能力是指服务器容量支撑能力。
上述调优方法,通过被调用模块下服务器被调用权重的调整,让模块下不同性能的服务器利用率都能最大化,并且能均衡服务器之间的容量,避免某台服务器容量短板而引起连锁奔溃,让业务在运营中更稳定,服务器成本最优。
根据本申请实施例,作为本实施例中的优选,所述计算模块30用于进行如下操作:单台支撑能力=(被调用量*被调用权重)/模块容量,所述模块容量选用CPU使用率。
优选地,如果一次调优结果不能够满足需求即达不到容量标准值,则需要进行多次调优。
计算单台服务器容量支撑能力,单台支撑能力=(被调用量*被调用权重)/CPU,单台支撑能力取整,计算得数据。
根据本申请实施例,作为本实施例中的优选,装置还包括:阈值模块(未示出),用于根据所述预设安全阈值寻找所述业务模块下容量最高的服务器,并且确认所述最高的容量是否在安全阈值范围内;在所述被调用量保持不变的情况下,以最高容量作为基准值。
本申请实施例的阈值模块中根据所述预设安全阈值寻找所述业务模块下容量最高的服务器,并且确认所述最高的容量是否在安全阈值范围内,同时在所述被调用量保持不变的情况下,以最高容量作为基准值。
具体地,制定的容量最高安全值:比如,表中的CPU利用率为85%,寻找该模块下容量最高的服务器,并且确认此最高的容量是否在安全值范文内,在被调用量不变的情况下,已最高容量81为基准值,对容量没有达到81的模块进行权重提升,让其容量达到81。
显然,本领域的技术人员应该明白,上述的本申请的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本申请不限制于任何特定的硬件和软件结合。
以上所述仅为本申请的优选实施例而已,并不用于限制本申请,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
Claims (10)
1.一种处理容量不健康模块的方法,其特征在于,用于集群中的服务器,所述方法包括:
记录容量不健康模块下服务器的被调用量和被调用权重;
确定容量不健康模块的模块容量;
计算单台服务器容量支撑能力;
确定所述模块容量的预设安全阈值;
在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升;
对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否仍属于不健康,如果是则继续处理。
2.根据权利要求1所述的处理容量不健康模块的方法,其特征在于,判断所述容量不健康模块的容量是否仍属于不健康时,采用如下方法:
当业务集群中接收到对于同一个业务模块下的服务器调用请求时,判断服务器之间的模块容量是否具有差别;
如果模块容量有差别,则调整所述服务器的被调用权重,以均衡所述服务器之间的容量。
3.根据权利要求1所述的处理容量不健康模块的方法,其特征在于,在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升,采用如下方法:
在服务器之间的模块容量有差别时,调整所述服务器的被调用权重得到新的权重=(单台支撑能力*容量基准)/被调用量;
其中所述容量基准为容量最高的安全阈值,所述单台支撑能力是指服务器容量支撑能力。
4.根据权利要求1所述的处理容量不健康模块的方法,其特征在于,计算单台服务器容量支撑能力采用如下方法:
单台支撑能力=(被调用量*被调用权重)/模块容量
所述模块容量选用CPU使用率。
5.根据权利要求1所述的处理容量不健康模块的方法,其特征在于,确定所述模块容量的预设安全阈值之后,还包括:
根据所述预设安全阈值寻找所述业务模块下容量最高的服务器,并且确认所述最高的容量是否在安全阈值范围内;
在所述被调用量保持不变的情况下,以最高容量作为基准值。
6.一种处理容量不健康模块的装置,其特征在于,用于集群中的服务器,所述装置包括:
记录模块,用于记录容量不健康模块下服务器的被调用量和被调用权重;
第一确定模块,用于确定容量不健康模块的模块容量;
计算模块,用于计算单台服务器容量支撑能力;
第二确定模块,用于确定所述模块容量的预设安全阈值;
权重提升模块,用于在所述被调用量保持不变的情况下,根据所述预设安全阈值对容量没有达到所述预设安全阈值的模块进行权重提升;
对比模块,用于对比调整后的理论值和真实值,并判断所述容量不健康模块的容量是否任然属于不健康,如果是则继续处理。
7.根据权利要求6所述的处理容量不健康模块的装置,其特征在于,所述对比模块,用于
当业务集群中接收到对于同一个业务模块下的服务器调用请求时,判断服务器之间的模块容量是否具有差别;
如果模块容量有差别,则调整所述服务器的被调用权重,以均衡所述服务器之间的容量。
8.根据权利要求6所述的处理容量不健康模块的装置,其特征在于,所述权重提升模块,用于进行如下操作:
在服务器之间的模块容量有差别时,调整所述服务器的被调用权重得到新的权重=(单台支撑能力*容量基准)/被调用量;
其中所述容量基准为容量最高的安全阈值,所述单台支撑能力是指服务器容量支撑能力。
9.根据权利要求6所述的处理容量不健康模块的装置,其特征在于,所述计算模块用于进行如下操作:
单台支撑能力=(被调用量*被调用权重)/模块容量
所述模块容量选用CPU使用率。
10.根据权利要求6所述的处理容量不健康模块的装置,其特征在于,还包括:阈值模块,用于
根据所述预设安全阈值寻找所述业务模块下容量最高的服务器,并且确认所述最高的容量是否在安全阈值范围内;
在所述被调用量保持不变的情况下,以最高容量作为基准值。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910804986.0A CN110554920A (zh) | 2019-08-27 | 2019-08-27 | 处理容量不健康模块的方法以及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910804986.0A CN110554920A (zh) | 2019-08-27 | 2019-08-27 | 处理容量不健康模块的方法以及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN110554920A true CN110554920A (zh) | 2019-12-10 |
Family
ID=68736772
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910804986.0A Pending CN110554920A (zh) | 2019-08-27 | 2019-08-27 | 处理容量不健康模块的方法以及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110554920A (zh) |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107124472A (zh) * | 2017-06-26 | 2017-09-01 | 杭州迪普科技股份有限公司 | 负载均衡方法及装置、计算机可读存储介质 |
CN109343965A (zh) * | 2018-10-31 | 2019-02-15 | 北京金山云网络技术有限公司 | 资源调整方法、装置、云平台和服务器 |
CN110083512A (zh) * | 2019-04-16 | 2019-08-02 | 上海易点时空网络有限公司 | 集群监控的方法及装置 |
CN110134513A (zh) * | 2019-04-17 | 2019-08-16 | 平安科技(深圳)有限公司 | 负载均衡方法、装置、计算机设备及存储介质 |
-
2019
- 2019-08-27 CN CN201910804986.0A patent/CN110554920A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107124472A (zh) * | 2017-06-26 | 2017-09-01 | 杭州迪普科技股份有限公司 | 负载均衡方法及装置、计算机可读存储介质 |
CN109343965A (zh) * | 2018-10-31 | 2019-02-15 | 北京金山云网络技术有限公司 | 资源调整方法、装置、云平台和服务器 |
CN110083512A (zh) * | 2019-04-16 | 2019-08-02 | 上海易点时空网络有限公司 | 集群监控的方法及装置 |
CN110134513A (zh) * | 2019-04-17 | 2019-08-16 | 平安科技(深圳)有限公司 | 负载均衡方法、装置、计算机设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110018799B (zh) | 一种存储池pg主确定方法、装置、设备及可读存储介质 | |
CN107124472A (zh) | 负载均衡方法及装置、计算机可读存储介质 | |
KR102047900B1 (ko) | 분산 데이터베이스의 부하를 레벨링하는 방법 및 장치 | |
CN102111813B (zh) | 一种载波负荷均衡的方法和设备 | |
CN111045808B (zh) | 一种分布式网络任务调度方法及装置 | |
US9807008B2 (en) | Tournament scheduling | |
US11889354B2 (en) | Method for load imbalance optimization under same network coverage, apparatus, device, and storage medium | |
CN105871983A (zh) | 一种选择服务器的方法及装置 | |
WO2014194704A1 (en) | A grouping processing method and system | |
CN107220108A (zh) | 一种实现云数据中心负载均衡的方法和*** | |
CN104158902B (zh) | 一种基于请求数的Hbase数据块分配方法及装置 | |
CN110543366A (zh) | 用于业务集群的业务模块容量调优方法以及装置、服务器 | |
CN110554920A (zh) | 处理容量不健康模块的方法以及装置 | |
CN105282045A (zh) | 一种基于一致性哈希算法的分布式计算和储存方法 | |
CN110018797B (zh) | 一种数据迁移方法、装置、设备及可读存储介质 | |
CN104899072B (zh) | 基于虚拟化平台的细粒度资源调度***及方法 | |
CN102647362B (zh) | 一种多控制器存储***负载均衡的方法 | |
CN111967682B (zh) | 设备上架方案寻优方法、装置及终端设备 | |
CN106326252A (zh) | 数据库的数据处理方法及装置 | |
CN101730147B (zh) | 载频分配方法及装置 | |
US9479579B2 (en) | Grouping processing method and system | |
CN116955271A (zh) | 一种数据副本存储的方法、装置、电子设备及存储介质 | |
CN107480229B (zh) | 用于对象检索的分布式计算机数据库***及其检索方法 | |
CN112003900A (zh) | 实现分布式***中高负载场景下服务高可用的方法、*** | |
CN109474959A (zh) | 一种小区接入的方法和装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20191210 |
|
RJ01 | Rejection of invention patent application after publication |