0%

linux_monitor_commands

发表于 更新于 分类于 阅读次数： 评论数：

uptime

1
16:45pm  up 614 days  1:31,  1 user,  load average: 2.53, 2.79, 3.18
  • 16:45pm : 当前系统时间
  • up 614 days 1:31 : 主机已运行时间,时间越大，说明你的机器越稳定
  • 1 user: 用户连接数，是总连接数而不是用户数
  • load average: 2.53, 2.79, 3.18 : 系统平均负载，统计最近1，5，15分钟的系统平均负载

vmstat

  • -V：显示vmstat版本信息。
  • -n：只在开始时显示一次各字段名称。
  • -a：显示活跃和非活跃内存
  • -d：显示磁盘相关统计信息。
  • -p：显示指定磁盘分区统计信息
  • -s：显示内存相关统计信息及多种系统活动数量。
  • -m：显示slabinfo
  • -S：使用指定单位显示。参数有 k 、K 、m 、M ，分别代表1000、1024、1000000、1048576字节（byte）。默认单位为K（1024 bytes）
  • -f：显示从系统启动至今的fork数量 。
  • delay：刷新时间间隔。
  • count：刷新次数。如果不指定刷新次数，但指定了刷新时间间隔，这时刷新次数为无穷。
1
2
3
vmstat 1 10 | column -t
r   b   swpd    free       buff        cache       si  so  bi  bo  in  cs  us  sy  id  wa  st
5   0   0       10974608   1048212     29509940    0   0   0   2   0   0   6   4   89  0   0
  • r: 等待运行的进程数
  • b: 处在非中断睡眠状态的进程数
  • swpd: 虚拟内存使用大小
  • free： 空闲的内存
  • buff: 用作缓冲的内存大小
  • cache: 用作缓存的内存大小
  • si: Amount of memory swapped in from disk (/s).从交换区写到内存的大小
  • so: Amount of memory swapped to disk (/s).每秒写入交换区的内存大小
  • bi: Blocks received from a block device (blocks/s).每秒读取的块数
  • bo: Blocks sent to a block device (blocks/s).每秒写入的块数
  • in: 每秒中断数，包括时钟中断
  • cs: 每秒上下文切换数
  • us: 用户进程执行时间(user time)
  • sy: 系统进程执行时间(system time)
  • id: 空闲时间(包括IO等待时间),中央处理器的空闲时间 。以百分比表示。
  • wa: 等待IO时间
  • st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown.

load average(平均负载,系统平均活跃进程数)

一、查看系统负荷
  • 如果你的电脑很慢，你或许想查看一下，它的工作量是否太大了。在Linux系统中，我们一般使用uptime命令查看（w命令和top命令也行）。（另外，它们在苹果公司的Mac电脑上也适用。）
  • 你在终端窗口键入uptime，系统会返回一行信息。这行信息的后半部分，显示”load average”，它的意思是”系统的平均负荷”，里面有三个数字，我们可以从中判断系统负荷是大还是小。
  • 为什么会有三个数字呢？你从手册中查到，它们的意思分别是1分钟、5分钟、15分钟内系统的平均负荷。
  • 如果你继续看手册，它还会告诉你，当CPU完全空闲的时候，平均负荷为0；当CPU工作量饱和的时候，平均负荷为1。
  • 那么很显然，”load average”的值越低，比如等于0.2或0.3，就说明电脑的工作量越小，系统负荷比较轻。
  • 但是，什么时候能看出系统负荷比较重呢？等于1的时候，还是等于0.5或等于1.5的时候？如果1分钟、5分钟、15分钟三个值不一样，怎么办？
二、一个类比
  • 判断系统负荷是否过重，必须理解load average的真正含义。下面，我根据”Understanding Linux CPU Load”这篇文章，尝试用最通俗的语言，解释这个问题。
  • 首先，假设最简单的情况，你的电脑只有一个CPU，所有的运算都必须由这个CPU来完成。
  • 那么，我们不妨把这个CPU想象成一座大桥，桥上只有一根车道，所有车辆都必须从这根车道上通过。（很显然，这座桥只能单向通行。）
    • 系统负荷为0，意味着大桥上一辆车也没有。
    • 系统负荷为0.5，意味着大桥一半的路段有车。
    • 系统负荷为1.0，意味着大桥的所有路段都有车，也就是说大桥已经”满”了。但是必须注意的是，直到此时大桥还是能顺畅通行的。
    • 系统负荷为1.7，意味着车辆太多了，大桥已经被占满了（100%），后面等着上桥的车辆为桥面车辆的70%。以此类推，系统负荷2.0，意味着等待上桥的车辆与桥面的车辆一样多；系统负荷3.0，意味着等待上桥的车辆是桥面车辆的2倍。总之，当系统负荷大于1，后面的车辆就必须等待了；系统负荷越大，过桥就必须等得越久。
  • CPU的系统负荷，基本上等同于上面的类比。大桥的通行能力，就是CPU的最大工作量；桥梁上的车辆，就是一个个等待CPU处理的进程（process）。
  • 如果CPU每分钟最多处理100个进程，那么系统负荷0.2，意味着CPU在这1分钟里只处理20个进程；系统负荷1.0，意味着CPU在这1分钟里正好处理100个进程；系统负荷1.7，意味着除了CPU正在处理的100个进程以外，还有70个进程正排队等着CPU处理。
  • 为了电脑顺畅运行，系统负荷最好不要超过1.0，这样就没有进程需要等待了，所有进程都能第一时间得到处理。很显然，1.0是一个关键值，超过这个值，系统就不在最佳状态了，你要动手干预了。
三、系统负荷的经验法则

1.0是系统负荷的理想值吗？

  • 不一定，系统管理员往往会留一点余地，当这个值达到0.7，就应当引起注意了。经验法则是这样的：
  • 当系统负荷持续大于0.7，你必须开始调查了，问题出在哪里，防止情况恶化。
  • 当系统负荷持续大于1.0，你必须动手寻找解决办法，把这个值降下来。
  • 当系统负荷达到5.0，就表明你的系统有很严重的问题，长时间没有响应，或者接近死机了。你不应该让系统达到这个值。
四、多处理器
  • 上面，我们假设你的电脑只有1个CPU。如果你的电脑装了2个CPU，会发生什么情况呢？
  • 2个CPU，意味着电脑的处理能力翻了一倍，能够同时处理的进程数量也翻了一倍。
  • 还是用大桥来类比，两个CPU就意味着大桥有两根车道了，通车能力翻倍了。
  • 所以，2个CPU表明系统负荷可以达到2.0，此时每个CPU都达到100%的工作量。推广开来，n个CPU的电脑，可接受的系统负荷最大为n.0。
五、多核处理器
  • 芯片厂商往往在一个CPU内部，包含多个CPU核心，这被称为多核CPU。
  • 在系统负荷方面，多核CPU与多CPU效果类似，所以考虑系统负荷的时候，必须考虑这台电脑有几个CPU、每个CPU有几个核心。然后，把系统负荷除以总的核心数，只要每个核心的负荷不超过1.0，就表明电脑正常运行。
  • 怎么知道电脑有多少个CPU核心呢？
  • “cat /proc/cpuinfo”命令，可以查看CPU信息。”grep -c ‘model name’ /proc/cpuinfo”命令，直接返回CPU的总核心数。
六、最佳观察时长
  • 最后一个问题，”load average”一共返回三个平均值—-1分钟系统负荷、5分钟系统负荷，15分钟系统负荷，—-应该参考哪个值？
  • 如果只有1分钟的系统负荷大于1.0，其他两个时间段都小于1.0，这表明只是暂时现象，问题不大。
  • 如果15分钟内，平均系统负荷大于1.0（调整CPU核心数之后），表明问题持续存在，不是暂时现象。所以，你应该主要观察”15分钟系统负荷”，将它作为电脑正常运行的指标。

context switch(上下文交换)

  • 又称环境切换，计算机术语，是一个存储和重建CPU的状态 (内文)，因此令多个进程(process)可以分享单一CPU资源的计算过程。要交换CPU上的进程时，必需先行存储当前进程的状态，再将欲运行的进程之状态读回CPU中。
开销
  • 上下文交换通常是计算密集型的，操作系统中的许多设计都是针对上下文交换的优化。在进程间切换需要消耗一定的时间进行相关的管理工作——包括寄存器和内存映射的保存与读取、更新各种内部的表等等。处理器或者操作系统不同，上下文交换时所涉及的内容也不尽相同。比如在Linux内核中，上下文交换需要涉及寄存器、栈指针、程序计数器的交换，但和地址空间的交换无关（虽然进程在进行上下文交换时也需要做地址空间的交换）[2][3]。用户态线程之间也会发生类似的上下文交换，但这样的交换非常轻量。
何时交换

有三种可能的情况会发生上下文交换，分别为：
多任务

  • 最常见的，在一些调度(scheduling)算法内，其中行程有时候需要暂时离开CPU，让另一个行程进来CPU运作。
  • 在先占式多任务系统中，每一个行程都将轮流运行不定长度的时间，这些时间段落称为时间片。
  • 如果行程并非自愿让出CPU(例如运行I/O操作时，行程就需放弃CPU使用权)，当时限到时，系统将产生一个定时中断，操作系统将排定由其它的行程来运行。
  • 此机制用以确保CPU不致被较依赖处理器运算的行程垄断。若无定时中断，除非行程自愿让出CPU，否则该行程将持续运行。
  • 对于拥有较多I/O指令的行程，往往运行不了多久，便需要让出CPU；而较依赖处理器的行程相对而言I/O操作较少，反而能一直持续使用CPU，便形成了垄断现象。

中断处理

  • 在接受到中断（Interrupt）的时候，CPU必须要进行上下文交换。

用户态或者内核态的交换

  • 当用户态和内核态交换发生的时候，并不需要进行上下文交换；
  • 并且用户态和kernel mode的交换本身并不是一个上下文交换。
  • 不过，根据操作系统的不同，有时候会在此时进行一次上下文交换的步骤。
上下文交换：具体步骤
  • 在一次交换中，第一个行程的状态要被纪录在某个地方，这样当调度器(scheduler)要回到这个行程时，才可以重建这个行程并且继续运算。
  • 这里所谓“行程的状态”，包含了这个行程使用的所有寄存器(register)，特别是程序计数器；加上所有操作系统可能需要的特定数据。
  • 这些数据一般以名为行程控制表(process control block，PCB)的数据结构存储起来。
上下文交换：由软件或硬件实现
  • 上下文交换可分为主要由软件实现或由硬件实现。部分中央处理器，比如Intel 80386[4]或同系列更高端的处理器，就具备支持上下文交换的硬件设计。