《LinuxSolairs 性能监控》由会员分享，可在线阅读，更多相关《LinuxSolairs 性能监控（49页珍藏版）》请在金锄头文库上搜索。
1、Linux 性能监控 一. Linux 性能监控的概述通常监测的子系统有以下这些：（1）CPU（2） Memory（3） IO（4） Network1.1 应用类型不同的系统用途也不同，要找到性能瓶颈需要知道系统的什么应用、有些什么特点，比如 web server 对系统的要求肯定和 file server 不一样，所以分清不同系统的应用类型很重要，通常应用可以分为两种类型：（1）IO 相关，IO 相关的应用通常用来处理大量数据，需要大量内存和存储，频繁 IO 操作读写数据，而对 CPU 的要求则较少，大部分时候 CPU 都在等待硬盘，比如，数据库服务器、文件服务器等。（2）CPU 相关，CP
2、U 相关的应用需要使用大量 CPU，比如高并发的 web/mail 服务器、图像/视频处理、科学计算等都可被视作 CPU 相关的应用。看看实际中的例子，第1个是文件服务器拷贝一个大文件时表现出来的特征：$ vmstat 1procs -memory- -swap- -io- -system- -cpu- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 4 140 1962724 335516 4852308 0 0 388 65024 1442 563 0 2 47 52 0 0 4 140 1961816 335516
3、4853868 0 0 768 65536 1434 522 0 1 50 48 0 0 4 140 1960788 335516 4855300 0 0 768 48640 1412 573 0 1 50 49 0 0 4 140 1958528 335516 4857280 0 0 1024 65536 1415 521 0 1 41 57 0 0 5 140 1957488 335516 4858884 0 0 768 81412 1504 609 0 2 50 49 0第2个是 CPU 做大量计算时表现出来的特征：$ vmstat 1procs -memory- -swap- -io-
4、 -system- -cpu- r b swpd free buff cache si so bi bo in cs us sy id wa st 4 0 140 3625096 334256 3266584 0 0 0 16 1054 470 100 0 0 0 0 4 0 140 3625220 334264 3266576 0 0 0 12 1037 448 100 0 0 0 0 4 0 140 3624468 334264 3266580 0 0 0 148 1160 632 100 0 0 0 0 4 0 140 3624468 334264 3266580 0 0 0 0 107
5、8 527 100 0 0 0 0 4 0 140 3624712 334264 3266580 0 0 0 80 1053 501 100 0 0 0 0上面两个例子最明显的差别就是 id 一栏，代表 CPU 的空闲率，拷贝文件时候 id 维持在 50 左右，CPU 大量计算的时候 id 基本为 0。1.2 底线事先建立一个底线，如果性能监测得到的统计数据跨过这条线，我们就可以说这个系统性能差，如果数据能保持在线内我们就说性能好。建立这样底线需要知道一些理论、额外的负载测试和系统管理员多年的经验。如果自己没有多年的经验，有一个简单划底线的办法就是：把这个底线建立在自己对系统的期望上。自己期望
6、这个系统有个什么样的性能，这是一个底线，如果没有达到这个要求就是性能差。1.3 监测工具工具简单介绍top查看进程活动状态以及一些系统状况vmstat查看系统状态、硬件和系统信息等iostat查看CPU 负载，硬盘状况sar综合工具，查看系统状况mpstat查看多处理器状况netstat查看网络状况iptraf实时网络状况监测tcpdump抓取网络数据包，详细分析mpstat 查看多处理器状况tcptrace数据包分析工具netperf网络带宽工具dstat综合工具，综合了 vmstat, iostat, ifstat, netstat 等多个信息二. CPUCPU 的占用主要取决于什么样的资
7、源正在 CPU 上面运行，比如拷贝一个文件通常占用较少 CPU，因为大部分工作是由 DMA（Direct Memory Access）完成，只是在完成拷贝以后给一个中断让 CPU 知道拷贝已经完成；科学计算通常占用较多的 CPU，大部分计算工作都需要在 CPU 上完成，内存、硬盘等子系统只做暂时的数据存储工作。要想监测和理解 CPU 的性能需要知道一些的操作系统的基本知识，比如：中断、进程调度、进程上下文切换、可运行队列等。这里用个例子来简单介绍一下这些概念和他们的关系，CPU每时每刻都有工作在做（进程、线程）并且自己有一张工作清单（可运行队列），由老板（进程调度）来决定他该干什么，他需要和老
8、板沟通以便得到老板的想法并及时调整自己的工作（上下文切换），部分工作做完以后还需要及时向老板汇报（中断），所以打工仔（CPU）除了做自己该做的工作以外，还有大量时间和精力花在沟通和汇报上。CPU 也是一种硬件资源，和任何其他硬件设备一样也需要驱动和管理程序才能使用，我们可以把内核的进程调度看作是 CPU 的管理程序，用来管理和分配 CPU 资源，合理安排进程抢占 CPU，并决定哪个进程该使用 CPU、哪个进程该等待。操作系统内核里的进程调度主要用来调度两类资源：进程（或线程）和中断，进程调度给不同的资源分配了不同的优先级，优先级最高的是硬件中断，其次是内核（系统）进程，最后是用户进程。每个 C
9、PU 都维护着一个可运行队列，用来存放那些可运行的线程。线程要么在睡眠状态（blocked 正在等待 IO）要么在可运行状态，如果 CPU 当前负载太高而新的请求不断，就会出现进程调度暂时应付不过来的情况，这个时候就不得不把线程暂时放到可运行队列里。可以从以下几个方面监控CPU的信息：（1）中断；（2）上下文切换；（3）可运行队列；（4）CPU 利用率。 （5）CPU 负载2.1 底线通常我们期望我们的系统能到达以下目标：（1）CPU 利用率，如果 CPU 有 100 利用率，那么应该到达这样一个平衡：6570 User Time，3035 System Time，05 Idle Time；（
10、2）上下文切换，上下文切换应该和 CPU 利用率联系起来看，如果能保持上面的 CPU 利用率平衡，大量的上下文切换是可以接受的；（3）可运行队列，每个可运行队列不应该有超过13个线程（每处理器），比如：双处理器系统的可运行队列里不应该超过6个线程。 （4）CPU负载均值CPU负载就是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息负载均值在 uptime 或者 top 命令中可以看到：load average: 0.09, 0.05, 0.01：三个数分别代表不同时间段的系统平均负载（一分钟、五 分钟、以及十五分钟），它们的数字当然是越小
11、越好。数字越高，说明服务器的负载越 大，这也可能是服务器出现某种问题的信号。为了便于理解CPU负载均值，我们先用最简单的例子说明， 一台只配备一块单核处理器的服务器。行车过桥一只单核的处理器可以形象得比喻成一条单车道。设想下，你现在需要收取这条道路的过桥 费 - 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息，例如车辆的载重、以及 还有多少车辆正在等待过桥。如果前面没有车辆在等待，那么你可以告诉后面的司机通过。 如果车辆众多，那么需要告知他们可能需要稍等一会。因此，需要些特定的代号表示目前的车流情况，例如：0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00
12、 之间是相同的，总而言之很通畅，过往的车辆可以丝毫不用等待的通过。 1.00 表示刚好是在这座桥的承受范围内。 这种情况不算糟糕，只是车流会有些堵，不过这种情况可能会造成交通越来越慢。 超过 1.00，那么说明这座桥已经超出负荷，交通严重的拥堵。 那么情况有多糟糕？ 例如 2.00 的情况说明车流已经超出了桥所能承受的一倍，那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了，说明这座桥基本上已经快承受不了，还有超出桥负载两倍多的车辆正在等待。 上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有
13、处理器内核的处理时间加上线程 在队列中等待的时间。和收过桥费的管理员一样，你当然希望你的汽车（操作）不会被焦急的等待。所以，理想状态 下，都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00，但长此以往保持这 个状态，就说明会有问题，这时候你应该会很焦急。“所以你说的理想负荷为 1.00 ？”嗯，这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ，有经验的系统管理员都会将这条线划在 0.70：在多处理器系统中，负载均值是基于内核的数量决定的。多核与多处理器先脱离下主题，我们来讨论下多核心处理器与多处理器的区别。从性能的角度上理解，一台主 机拥
14、有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际 情况会复杂得多，不同数量的缓存、处理器的频率等因素都可能造成性能的差异。但即便这些因素造成的实际性能稍有不同，其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则：“有多少核心即为有多少负荷”法则： 在多核处理中，你的系统均值不应该高于处理器核心的总数量。 “核心的核心”法则： 核心分布在分别几个单个物理处理中并不重要，其实两颗四核的处理器 等于 四个双核处理器 等于 八个单处理器。所以，它应该有八个处理器内核。 审视我们自己让我们再来看看 uptime 的输出 $ uptime23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36这是个双核处理器，从结果也说明有很多的空闲资源。实际情况是即便它的峰值会到 1.7，我也从来没有考虑过它的负载问题。那么，怎么会有三个数字的确让人困扰。我们知道，0.65、0.42、0.36 分别说明上一分钟、最后五分钟以及最后十五分钟的系统负载均值。那么这又带来了一个问题：我们以哪个数字为准？一分钟？五分钟？还是十五分钟？ 其实对于这些数字我们已经谈论了很多，我认为你应该着眼于五
