es 逐个节点更新 es节点掉线

转载

mob64ca13fbd761 2024-02-13 21:13:59

文章标签 es 逐个节点更新 ci 服务器 UX 文章分类 架构后端开发

理解%IOWAIT

# man mpstat

Linux:
%iowait
Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.

HP-UX:
%wio
idle with some process waiting for I/O (only block I/O, raw I/O, or VM pageins/swapins indicated).


# man top
us, user    : time running un-niced user processes
sy, system  : time running kernel processes
ni, nice    : time running niced user processes
id, idle    : time spent in the kernel idle handler
wa, IO-wait : time waiting for I/O completion
hi : time spent servicing hardware interrupts
si : time spent servicing software interrupts
st : time stolen from this vm by the hypervisor

%IOWAIT的正确认识

表示在系统有未完成的磁盘I/O请求期间，一个或多个CPU空闲的时间百分比。
空闲，有一些进程在等待I/O（仅块I/O，原始I/O，或指示的VM pageins/swapins。
对%IOWAIT的误解有两个：一是误以为%IOWAIT表示CPU不能工作的时间；二是误以为%IOWAIT表示有I/O瓶颈。
第一种误解太低级了，%iowait 的首要条件就是CPU空闲，既然空闲当然就可以接受运行任务，只是因为没有可运行的进程，CPU才进入空闲状态的。那为什么没有可运行的进程呢？因为进程都处于休眠状态、在等待某个特定事件：比如等待定时器、或者来自网络的数据、或者键盘输入、或者等待I/O操作完成，等等。
第二种误解更常见，为什么人们会认为 %iowait 偏高是有I/O瓶颈的迹象呢？他们的理由是：“%iowait 的第一个条件是CPU空闲，意即所有的进程都在休眠，第二个条件是仍有未完成的I/O请求，意味着进程休眠的原因是等待I/O，而%iowait升高则表明因等待I/O而休眠的进程数量更多了、或者进程因等待I/O而休眠的时间更长了。” 听上去似乎很有道理，但是不对：
首先%iowait升高并不能证明等待I/O的进程数量增多了，也不能证明等待I/O的总时间增加了。为什么呢？看看下面两张图就明白了。第一张图演示的是，在I/O完全一样的情况下，CPU忙闲状态的变化就能够影响 %iowait 的大小。下图我们看到，在CPU繁忙期间发生的I/O，无论有多少，%iowait 的值都是不受影响的（因为%iowait的第一个前提条件就是CPU必须空闲）；当CPU繁忙程度下降时，有一部分I/O落入了CPU空闲的时间段内，这就导致了 %iowait 升高。可见，I/O并没有变化，%iowait 却升高了，原因仅仅是CPU的空闲时间增加了。请记住，系统中有成百上千的进程数，任何一个进程都可以引起CPU和I/O的变化，因为 %iowait、%idle、%user、%system等这些指标都是全局性的，并不是特指某个进程。

es 逐个节点更新 es节点掉线_ci

再往下看第二张图，它描述了另一种情形：假设CPU的繁忙状况保持不变的条件下，即使 %iowait 升高也不能说明I/O负载加重了。如果2个I/O请求依次提交、使得整个时段内始终有I/O在进行，那么 %iowait 是100%；如果3个I/O请求同时提交，因为系统有能力同时处理多个I/O，所以3个并发的I/O从开始到结束的时间与一个I/O一样，%iowait 的结果只有50%。 2个I/O使 %iowait 达到了100%，3个I/O的 %iowait 却只有50%，显然 %iowait 的高低与I/O的多少没有必然关系，而是与I/O的并发度相关。所以，仅凭 %iowait 的上升不能得出I/O负载增加 的结论。

es 逐个节点更新 es节点掉线_UX_02