问题调研
随着业务增长,ES集群规模越来越大。各集群的使用场景不同,机器节点配置不同以及业务场景使用ES的方式不同, 会造成集群单点CPU飙高,内存不足、GC时间过长以及磁盘使用率不足从而影响集群整体性能。目前,ES集群的调度方法是人工依赖Zabbix以及Grafana监控手动调整集群节点,这种方式一定程度上降低了ES集群机器的利用效率。
为提高集群的工作效率、节省机器资源、降低运维成本,本文建立了一种基于粒子群算法的ES集群调度优化模型。因为存在一些动态不可控的环境因素,静态调度方案失效因此建立可滚动的优化调度模型。该模型描述为每一个时间段开始前根据当前环境(内存、CPU、磁盘)调整这一时间段的调度安排。若环境没有发生改变,则进入下一时间段。但这样的调度方案随着计划周期的不断细化,计算量也随之变大甚至可能出现”维数灾难”( Curse of Dimensionality)。针对以上问题,本文采用混合粒子群算法来提高搜索效率。利用Python语言设计并验证了混合粒子群算法用于ES集群调度优化的可行性和有效性。
ES集群日负荷优化调度建模
Elasticsearch作为一个“开箱即用”的存储分析组件越来越受到各大互联网公司的青睐。作为集群部署当遇到热点shard导致CPU使用率升高、机器OOM宕机等问题时,我们可以很方便地横向扩、缩容节点。
本文着眼于ES集群层面
的日负荷调度。下图是某个线上ES集群CPU利用率、堆内存使用以及索引存储一天的使用情况。通常情况下,ES集群的CPU利用率、堆内存使用情况会随着一天的不同时段而变化但索引的存储相对于集群磁盘的总体容量
来说变化及影响不是很大。
-
CPU利用率、内存使用率以及磁盘利用率打分模型
对于一个线上运行的ES集群而言,CPU使用率高可能会致使慢查询增多导致业务查询超时而内存使用率过高则会导致GC暂停、触发old GC。磁盘利用率高,高于水位线时会将写入请求重新reroute到其他节点,但也可能会触发ES的熔断机制导致该集群上的索引不可写入。因此,CPU利用率、内存使用率以及磁盘利用率是衡量ES集群整体性能的重要指标。本文的做法是将备选机器放入资源池,对资源池里的机器进行打分,然后通过PSO算法选择合适的机器作为ES集群的data节点。
CPU利用率计算公式如下:
s c o r e c p u score_{cpu} scorecpu = C P U a l l − C P U a v a i l a b l e C P U a l l \frac{CPU_{all}-CPU_{available}}{CPU_{all}} CPUallCPUall−CPUavailable (1)内存使用率计算公式如下:
s c o r e m e m score_{mem} scoremem = M E M a l l − M E M a v a i l a b l e M E M a l l \frac{MEM_{all}-MEM_{available}}{MEM_{all}} MEMallMEMall−MEMavailable (2)磁盘使用率计算公式如下:
s c o r e f s score_{fs} scorefs = F S a l l − F S a v a i l a b l e F S a l l \frac{FS_{all}-FS_{available}}{FS_{all}} FSallFSall−FSavailable (3)根据以上三个指标对于线上业务重要程度的不同,分别赋予不同的权重,公式如下:
P e r f o r m a n c e Performance Performance = 0.5* s c o r e c p u score_{cpu} scorecpu+ 0.35* s c o r e m e m score_{mem} scoremem+ 0.15* s c o r e f s score_{fs} scorefs (4) -
资源均衡度打分模型
设想一个场景,当面临节假日流量猛增等情况,ES集群需要进行扩容。这时可能遇到备选机器CPU利用率高但内存使用率低或其内存使用率高但CPU使用率低等资源不均衡的情况。针对该问题,使用以下公式对备选机器的cpu资源以及内存资源的均衡情况进行打分:B a l a n c e Balance Balance = 1 – | s c o r e c p u score_{cpu} scorecpu - s c o r e m e m score_{mem} scoremem | (5)
结合以上(4)和(5)两个公式,本文使用如下公式作为粒子群算法的适应值函数:
C
o
s
t
Cost
Cost = 1/2*(Performance+Balance) (6)
粒子群算法的介绍
通常,ES的集群部署是需要在备选机器中选择合适的机器进行节点部署。在一堆机器中寻找集群部署的最佳方案使之既能满足业务需求又不浪费机器资源,这在数学中可以简化为一个最优化问题:即在特定的解空间中搜索最优解。
粒子群算法(PSO)是JamesKennedy 和Russell Eberhart 在1995 年共同提出的,它是受到鸟群的社会行为启发建立的一种依赖于随机过程的启发式搜索算法。PSO通过粒子之间的相互协作,朝着局部最优和全局最优调整。该算法全局搜索能力强,可以融合其他算法的长处设计出适合于实际问题的改进算法 。
- 速度更新和位置更新公式
基本粒子群算法中,解空间的每个粒子代表一个潜在的解。数学描述为:在一个D维解空间中,由m个粒子组成的种群 X = ( X 1 X_1 X1 … X i X_i Xi… X m X_m Xm) 。 其中第i个粒子位置为 X i X_i Xi = ( x i 1 , x i 2 . . . x i D ) T (x_{i1},x_{i2}...x_{iD})^{T} (xi1,xi2...xiD)T,其速度为 V i V_i Vi = ( v i 1 , v i 2 . . . v i D ) T (v_{i1},v_{i2}...v_{iD})^{T} (vi1,vi2...viD)T ,粒子的个体值为 p i p_i pi = ( p i 1 , p i 2 . . . p i D ) T (p_{i1},p_{i2}...p_{iD})^{T} (pi1,pi2...piD)T 其种群的全局值为 p g p_g pg = ( p g 1 , p g 2 . . . p g D ) T (p_{g1},p_{g2}...p_{gD})^{T} (pg1,pg2...pgD)T 。首先求每个粒子的个体最优解,利用式子(7),(8)来更新每个粒子当前的速度和位置。
v i j [ i t e r + 1 ] v_{ij}[iter+1] vij[iter+1] = w* v i j [ i t e r ] v_{ij}[iter] vij[iter]+ c 1 c_1 c1 r 1 r_1 r1 * ( p i j p_{ij} pij[ iter] - x i j [ i t e r ] x_{ij}[ iter ] xij[iter])+ c 2 c_2 c2 r 2 r_2 r2 *( p i j p_{ij} pij[ iter] - P g j [ i t e r ] P_{gj}[ iter ] Pgj[iter]) (7)
X i j [ i t e r + 1 ] X_{ij}[iter+1] Xij[iter+1] = X i j [ i t e r ] X_{ij}[iter] Xij[iter] + v i j [ i t e r + 1 ] v_{ij}[iter+1] vij[iter+1] (8)
式中:iter代表迭代次数,r1,r2为[0,1]之间的随机数, c1,c2为加速常数, w为惯性权值。
- 算法步骤
(1)初始化种群规模和迭代次数
(2)粒子群的初始化:在解空间内产生随机粒子,初始化粒子的位置以及速度。
(3)评价每个粒子的个体适应值,淘汰适应值差的粒子
(4)迭代进化:
在每一次迭代更新中, 粒子根据两个“极值”: pbest 和 gbsest来更新本身: pbest是该粒子当前找到的最佳解;gbsest是整个种群目前找到的最好解, 称为全局极值点。
(4)迭代终止条件:
如果当前迭代次数达到开始设置的最大迭代次数或达到最小误差要求,则迭代终止,输出结果;否则继续迭代。
基于粒子群算法的改进
-
软约束策略
在ES集群基于PSO算法调度过程中,决策变量会受到当前集群规模的约束:集群节点(data)个数受当前索引分片数以及分片存储策略(total_shards_per_node)的限制。在此约束下,只要决策变量稍微超出约束范围一点,粒子的最优解就无法到达最优位置。为了得到满足约束条件下可行的最优解,需要对适应值函数进行软化,然后基于软约束策略将约束函数加入适应值函数中。ζ {\zeta} ζ = λ {\lambda} λ* ∣ N b e f o r e − N a f t e r ∣ N b e f o r e \frac{| N_{before}-N_{after}|}{N_{before}} Nbefore∣Nbefore−Nafter∣ (9)
式中: N b e f o r e N_{before} Nbefore为未调整前的初始data数量, N a f t e r N_{after} Nafter为推荐的备选data节点的总数。如果推荐的备选机器数和初始集群规模不等,则可以进行一定的妥协,这个妥协通过惩罚因子 λ {\lambda} λ进行调节,其核心思想为,节点数量’变化’的增加,权重系数不断增大,并且当这个误差达到最大上限时,惩罚为无穷大。
-
惩罚函数
获取备选机器的端口信息,假如ES集群运行的端口在备选机器中已经被占用则需要进行惩罚。γ {\gamma} γ = θ {\theta} θ *Performance (10)
式中: θ {\theta} θ为惩罚因子。
综上, 改进后的粒子群适应值函数为:
C
o
s
t
Cost
Cost = 1/2(
θ
{\theta}
θ * Performance+Balance)+
λ
{\lambda}
λ*
∣
N
b
e
f
o
r
e
−
N
a
f
t
e
r
∣
N
b
e
f
o
r
e
\frac{| N_{before}-N_{after}|}{N_{before}}
Nbefore∣Nbefore−Nafter∣ (11)
-
使用环形领域拓扑搜索全局最优解
为了寻找全局最优解(gbest)避免过早收敛陷入局部最优,本文使用环形邻域拓扑的搜索方式即所有粒子首尾相连构成环形,每个粒子与k个邻近粒子相连。假设有N个粒子,当k=1时,每个粒子只能选择左右两边的一个粒子进行比较;当k=2时,每个粒子可以选择左右两边的两个相邻粒子进行比较;而当k = N-1时,此时整体拓扑结构为全互联结构。在快速查找邻近点过程中,使用kd树可以快速查找任何点的最近邻居。本文使用scipy.spatial.cKDTree来计算k邻近粒子。 -
迭代滚动优化调度策略
线上集群需要每天持续稳定地提供服务,而每台机器的CPU、内存和磁盘情况都会随着不同时段发生变化。因此单一次调度并非一劳永逸,需要建立迭代滚动优化机制。即每个时间段根据当前资源池每台机器的情况来调整这一时间段的集群节点安排。
Airflow是基于有向无环图(DAG)的一个可编程,调度的工作流平台。本文通过Airflow进行定时调度,将每小时作为一个计量点,每天一共24个计量点。
仿真实验及分析
实验环境
- ES 6.2.4 集群(集群规模:三主九从,一台备机)
基于安全考虑屏蔽机器ip:
- 主节点:ES-216,ES-217,ES-218
- Data节点 :ES-100,ES-101, ES-102,ES-103,ES-104,ES-105,ES-106,ES-107,ES-108
- 冷备: ES-111
- 粒子群算法的种群规模30,迭代次数1000
- 100G的压测数据、Rally极限压测脚本
- 根据baseline的压测时间大约两小时,在airflow中配置半小时调度策略进行模拟
实验
- 实验步骤
step 1: 运行Rally脚本对集群进行压测,生成baseline的压测结果报告
step 2: 再次运行Rally脚本,每隔半小时进行一次集群调度
step 3: 每次通过python的paramiko模块获取冷备机器的feature,通过_nodes/stats获取集群data节点机器的 feature
step 4: 数据清洗,整理成dataframe代入算法模型迭代计算
step 5: 对调度结果中位置为0的机器ip逐个执行exclude操作,通过_cat/recovery查看分片情况
step 6: 等分片结束后,卸掉exclude掉的机器。
step 7: 对调度结果中位置为1且不在集群data节点中的机器ip,通过paramiko ssh到目标机器启动该节点
step 8: 生成contender压测结果报告,和baseline的压测结果比较分析 - 实验结果
-
baseline压测: 压测过程中的CPU使用率
-
baseline压测: 同一时间,堆内存使用的情况
-
contender压测:最后一次算法调度结果
如上图结果所示,我们选择ES-111,ES-108,ES-102,ES-106,ES-100,ES-107,ES-105作为ES集群的data节点
机器数实际节省 : (9-7)/9 * 100% = 22%
-
contender压测:适应值函数收敛图
如上图所示,因为解空间比较小适应函数收敛速度很快,中间有些波动是因为粒子编码采用的one-hot encoding并非连续值。 -
contender压测: 压测过程中的CPU使用率
从Grafana CPU监控来看CPU使用率明显降低。其中在1:10到1:25分有CPU波动是因为集群分片过程持续了十几分钟。
-
- contender压测: 同一时间,堆内存使用的情况
和baseline 相比较整体有所降低
- 实验对比分析
------------------------------------------------------
_______ __ _____
/ ____(_)___ ____ _/ / / ___/_________ ________
/ /_ / / __ \/ __ `/ / \__ \/ ___/ __ \/ ___/ _ \
/ __/ / / / / / /_/ / / ___/ / /__/ /_/ / / / __/
/_/ /_/_/ /_/\__,_/_/ /____/\___/\____/_/ \___/
------------------------------------------------------
| Metric | Task | Baseline | Contender | Diff | Unit |
|--------------------------------:|---------------------:|------------:|------------:|---------:|-------:|
| Indexing time | | 1717.08 | 150.959 | -1566.12 | min |
| Indexing throttle time | | 0.00118333 | 0 | -0.00118 | min |
| Merge time | | 316.819 | 132.466 | -184.353 | min |
| Refresh time | | 22.0931 | 8.14423 | -13.9489 | min |
| Flush time | | 6.80153 | 2.20312 | -4.59842 | min |
| Merge throttle time | | 122.167 | 80.5742 | -41.5932 | min |
| Total Young Gen GC | | 23.547 | 35.524 | 11.977 | s |
| Total Old Gen GC | | 0 | 0 | 0 | s |
| Heap used for segments | | 107.607 | 107.648 | 0.04025 | MB |
| Heap used for doc values | | 0.313099 | 0.319702 | 0.0066 | MB |
| Heap used for terms | | 92.3869 | 92.4321 | 0.04518 | MB |
| Heap used for norms | | 0.0146484 | 0.0146484 | 0 | MB |
| Heap used for points | | 4.31084 | 4.31193 | 0.00109 | MB |
| Heap used for stored fields | | 10.5819 | 10.5693 | -0.01262 | MB |
| Segment count | | 165 | 176 | 11 | |
| Min Throughput | index-append | 60512.6 | 84928.4 | 24415.9 | docs/s |
| Median Throughput | index-append | 66679.2 | 88036 | 21356.8 | docs/s |
| Max Throughput | index-append | 68902.5 | 95821.3 | 26918.9 | docs/s |
| 50th percentile latency | index-append | 5610.93 | 4479.08 | -1131.85 | ms |
| 90th percentile latency | index-append | 7822.26 | 6624.56 | -1197.7 | ms |
| 99th percentile latency | index-append | 9950.89 | 9312.28 | -638.611 | ms |
| 99.9th percentile latency | index-append | 11278.8 | 11822.1 | 543.234 | ms |
| 99.99th percentile latency | index-append | 12525.4 | 12557.2 | 31.7495 | ms |
| 100th percentile latency | index-append | 12812 | 12771.4 | -40.6328 | ms |
| 50th percentile service time | index-append | 5610.93 | 4479.08 | -1131.85 | ms |
| 90th percentile service time | index-append | 7822.26 | 6624.56 | -1197.7 | ms |
| 99th percentile service time | index-append | 9950.89 | 9312.28 | -638.611 | ms |
| 99.9th percentile service time | index-append | 11278.8 | 11822.1 | 543.234 | ms |
| 99.99th percentile service time | index-append | 12525.4 | 12557.2 | 31.7495 | ms |
| 100th percentile service time | index-append | 12812 | 12771.4 | -40.6328 | ms |
| error rate | index-append | 0 | 0 | 0 | % |
| Min Throughput | index-stats | 100.05 | 99.9956 | -0.05439 | ops/s |
| Median Throughput | index-stats | 100.117 | 100.153 | 0.0361 | ops/s |
| Max Throughput | index-stats | 100.431 | 100.409 | -0.02195 | ops/s |
| 50th percentile latency | index-stats | 5.32167 | 5.04014 | -0.28154 | ms |
| 90th percentile latency | index-stats | 14.1983 | 7.06293 | -7.13536 | ms |
| 99th percentile latency | index-stats | 162.394 | 82.0803 | -80.3133 | ms |
| 100th percentile latency | index-stats | 185.119 | 107.025 | -78.0942 | ms |
| 50th percentile service time | index-stats | 5.1202 | 4.87297 | -0.24723 | ms |
| 90th percentile service time | index-stats | 6.53896 | 6.42834 | -0.11061 | ms |
| 99th percentile service time | index-stats | 10.3816 | 11.0737 | 0.69204 | ms |
| 100th percentile service time | index-stats | 160.134 | 106.893 | -53.2416 | ms |
| error rate | index-stats | 0 | 0 | 0 | % |
| Min Throughput | node-stats | 74.5094 | 99.4131 | 24.9037 | ops/s |
| Median Throughput | node-stats | 86.4015 | 99.9811 | 13.5795 | ops/s |
| Max Throughput | node-stats | 100.245 | 100.007 | -0.23856 | ops/s |
| 50th percentile latency | node-stats | 25.6097 | 10.4874 | -15.1223 | ms |
| 90th percentile latency | node-stats | 73.5485 | 27.8513 | -45.6972 | ms |
| 99th percentile latency | node-stats | 121.306 | 84.8256 | -36.4807 | ms |
| 100th percentile latency | node-stats | 123.617 | 87.3426 | -36.2746 | ms |
| 50th percentile service time | node-stats | 9.12567 | 8.95502 | -0.17064 | ms |
| 90th percentile service time | node-stats | 11.4099 | 10.9868 | -0.42316 | ms |
| 99th percentile service time | node-stats | 19.1537 | 16.0868 | -3.06691 | ms |
| 100th percentile service time | node-stats | 116.248 | 82.8752 | -33.3725 | ms |
| error rate | node-stats | 0 | 0 | 0 | % |
| Min Throughput | default | 29.8408 | 30.8769 | 1.03611 | ops/s |
| Median Throughput | default | 30.0673 | 31.2035 | 1.13622 | ops/s |
| Max Throughput | default | 30.959 | 31.4685 | 0.50948 | ops/s |
| 50th percentile latency | default | 113358 | 108187 | -5170.31 | ms |
| 90th percentile latency | default | 176614 | 171861 | -4752.97 | ms |
| 99th percentile latency | default | 190912 | 185794 | -5117.6 | ms |
| 99.9th percentile latency | default | 192868 | 187473 | -5395.41 | ms |
| 100th percentile latency | default | 193480 | 188330 | -5150.38 | ms |
| 50th percentile service time | default | 329.174 | 321.413 | -7.76143 | ms |
| 90th percentile service time | default | 393.63 | 375.3 | -18.33 | ms |
| 99th percentile service time | default | 481.852 | 447.837 | -34.0148 | ms |
| 99.9th percentile service time | default | 558.876 | 518.918 | -39.9582 | ms |
| 100th percentile service time | default | 669.889 | 614.75 | -55.1389 | ms |
| error rate | default | 0 | 0 | 0 | % |
| Min Throughput | term | 4882.63 | 3882.41 | -1000.22 | ops/s |
| Median Throughput | term | 5451.94 | 4039.54 | -1412.4 | ops/s |
| Max Throughput | term | 5660.88 | 4142.66 | -1518.22 | ops/s |
| 50th percentile latency | term | 3940.29 | 5632 | 1691.71 | ms |
| 90th percentile latency | term | 7364.53 | 9579.15 | 2214.62 | ms |
| 99th percentile latency | term | 7975.75 | 10352.6 | 2376.85 | ms |
| 99.9th percentile latency | term | 8274.33 | 10485.4 | 2211.06 | ms |
| 99.99th percentile latency | term | 8329.34 | 10567 | 2237.61 | ms |
| 100th percentile latency | term | 8342.35 | 10577.9 | 2235.54 | ms |
| 50th percentile service time | term | 6.40647 | 9.18781 | 2.78134 | ms |
| 90th percentile service time | term | 10.7888 | 13.0989 | 2.31005 | ms |
| 99th percentile service time | term | 21.9541 | 17.3925 | -4.56156 | ms |
| 99.9th percentile service time | term | 192.16 | 285.78 | 93.6194 | ms |
| 99.99th percentile service time | term | 424.427 | 416.389 | -8.03786 | ms |
| 100th percentile service time | term | 426.502 | 424.049 | -2.45351 | ms |
| error rate | term | 0 | 0 | 0 | % |
| Min Throughput | phrase | 54.5565 | 59.8114 | 5.25493 | ops/s |
| Median Throughput | phrase | 55.1897 | 61.0735 | 5.8838 | ops/s |
| Max Throughput | phrase | 57.7741 | 61.4302 | 3.65603 | ops/s |
| 50th percentile latency | phrase | 434220 | 389896 | -44323.4 | ms |
| 90th percentile latency | phrase | 695307 | 653045 | -42262.1 | ms |
| 99th percentile latency | phrase | 752904 | 713536 | -39367.3 | ms |
| 99.9th percentile latency | phrase | 758565 | 720462 | -38102.2 | ms |
| 99.99th percentile latency | phrase | 759755 | 722499 | -37255.8 | ms |
| 100th percentile latency | phrase | 760168 | 722878 | -37289.7 | ms |
| 50th percentile service time | phrase | 681.294 | 653.602 | -27.692 | ms |
| 90th percentile service time | phrase | 869.716 | 813.168 | -56.5479 | ms |
| 99th percentile service time | phrase | 1015.41 | 946.566 | -68.8423 | ms |
| 99.9th percentile service time | phrase | 1121.99 | 1115.74 | -6.25344 | ms |
| 99.99th percentile service time | phrase | 1365.07 | 1310.3 | -54.7704 | ms |
| 100th percentile service time | phrase | 1996.27 | 1427.16 | -569.108 | ms |
| error rate | phrase | 0 | 0 | 0 | % |
| Min Throughput | country_agg_uncached | 151.347 | 154.644 | 3.29641 | ops/s |
| Median Throughput | country_agg_uncached | 158.383 | 161.305 | 2.9224 | ops/s |
| Max Throughput | country_agg_uncached | 161.497 | 164.487 | 2.99012 | ops/s |
| 50th percentile latency | country_agg_uncached | 3180.58 | 3055.8 | -124.781 | ms |
| 90th percentile latency | country_agg_uncached | 5204.84 | 5190.12 | -14.7223 | ms |
| 99th percentile latency | country_agg_uncached | 5659.89 | 5629.04 | -30.8477 | ms |
| 99.9th percentile latency | country_agg_uncached | 5709.79 | 5676.18 | -33.6157 | ms |
| 100th percentile latency | country_agg_uncached | 5714.09 | 5680.6 | -33.488 | ms |
| 50th percentile service time | country_agg_uncached | 5.98006 | 5.74001 | -0.24005 | ms |
| 90th percentile service time | country_agg_uncached | 7.55047 | 7.04123 | -0.50924 | ms |
| 99th percentile service time | country_agg_uncached | 9.86873 | 10.2407 | 0.37198 | ms |
| 99.9th percentile service time | country_agg_uncached | 13.9543 | 73.3752 | 59.4209 | ms |
| 100th percentile service time | country_agg_uncached | 18.0607 | 78.7413 | 60.6806 | ms |
| error rate | country_agg_uncached | 0 | 0 | 0 | % |
| Min Throughput | country_agg_cached | 290.92 | 302.431 | 11.5104 | ops/s |
| Median Throughput | country_agg_cached | 293.239 | 313.174 | 19.9354 | ops/s |
| Max Throughput | country_agg_cached | 294.261 | 317.505 | 23.2441 | ops/s |
| 50th percentile latency | country_agg_cached | 1444.51 | 1322.29 | -122.218 | ms |
| 90th percentile latency | country_agg_cached | 2414.04 | 2149.01 | -265.035 | ms |
| 99th percentile latency | country_agg_cached | 2622.68 | 2321.08 | -301.597 | ms |
| 99.9th percentile latency | country_agg_cached | 2643.27 | 2341.95 | -301.317 | ms |
| 100th percentile latency | country_agg_cached | 2645.59 | 2343.51 | -302.086 | ms |
| 50th percentile service time | country_agg_cached | 3.18955 | 2.92881 | -0.26074 | ms |
| 90th percentile service time | country_agg_cached | 4.26382 | 3.86103 | -0.40279 | ms |
| 99th percentile service time | country_agg_cached | 6.16704 | 5.74578 | -0.42126 | ms |
| 99.9th percentile service time | country_agg_cached | 8.10998 | 9.59255 | 1.48257 | ms |
| 100th percentile service time | country_agg_cached | 38.2704 | 9.95657 | -28.3138 | ms |
| error rate | country_agg_cached | 0 | 0 | 0 | % |
| Min Throughput | scroll | 12.2239 | 12.5268 | 0.30296 | ops/s |
| Median Throughput | scroll | 12.2592 | 12.8011 | 0.54188 | ops/s |
| Max Throughput | scroll | 12.2881 | 12.948 | 0.65985 | ops/s |
| 50th percentile latency | scroll | 1.26197e+06 | 1.20837e+06 | -53600.8 | ms |
| 90th percentile latency | scroll | 1.55174e+06 | 1.48275e+06 | -68985.2 | ms |
| 100th percentile latency | scroll | 1.62458e+06 | 1.54164e+06 | -82944.7 | ms |
| 50th percentile service time | scroll | 80772.3 | 73913.7 | -6858.58 | ms |
| 90th percentile service time | scroll | 81415.8 | 76314 | -5101.83 | ms |
| 100th percentile service time | scroll | 81606.1 | 81817.2 | 211.018 | ms |
| error rate | scroll | 0 | 0 | 0 | % |
-------------------------------
[INFO] SUCCESS (took 8 seconds)
-------------------------------
从结果对比来看:
基于改进后的粒子群算法的ES集群调度后,机器数减少22%,CPU和heap使用率都有所降低。索引写入、phrase查询、聚合查询性能有所提高,scroll拉取时间有所降低。但 Young GC时间有所增加,term查询时间增加。
- 实验总结与展望
在实验过程中,索引分片耗时大约每次在十分钟左右。后续可以考虑增加分片数把索引分片切得更小一点以提高算法整体效果。因为是对线上环境进行测试,因此未使用循环压测脚本把压测时间拉长到一天甚至更久。
另外,本文只选取CPU、内存、磁盘三个维度作为给机器打分的依据。实际上,io,网络甚至是机器出厂时的指标数据都可以作为feature进行计算。
本文主要基于现有的实验资源和环境验证改进后的粒子群算法在集群调度中的可行性和有效性。后续在ES、HBase、HDFS等存储组件 在 k8s 运行后,希望能对机器的降本增效以及存储组件的热点等问题做进一步的探索。