linux性能监测2.docVIP

Linux 性能监测：入门 看了某某教程、读了某某手册，按照要求改改某些设置、系统设定、内核参数就认为做到系统优化的想法很傻很天真：）系统优化是一项复杂、繁琐、长期的 工作，优化前需要监测、采集、测试、评估，优化后也需要测试、采集、评估、监测，而且是一个长期和持续的过程，不是说现在优化了，测试了，以后就可以一劳 永逸了，也不是说书本上的优化就适合眼下正在运行的系统，不同的系统、不同的硬件、不同的应用优化的重点也不同、优化的方法也不同、优化的参数也不同。性 能监测是系统优化过程中重要的一环，如果没有监测、不清楚性能瓶颈在哪里，优化什么呢、怎么优化呢？所以找到性能瓶颈是性能监测的目的，也是系统优化的关 键。系统由若干子系统构成，通常修改一个子系统有可能影响到另外一个子系统，甚至会导致整个系统不稳定、崩溃。所以说优化、监测、测试通常是连在一起的， 而且是一个循环而且长期的过程，通常监测的子系统有以下这些： CPU Memory IO Network 这些子系统互相依赖，了解这些子系统的特性，监测这些子系统的性能参数以及及时发现可能会出现的瓶颈对系统优化很有帮助。 应用类型 不同的系统用途也不同，要找到性能瓶颈需要知道系统跑的是什么应用、有些什么特点，比如 web server 对系统的要求肯定和 file server 不一样，所以分清不同系统的应用类型很重要，通常应用可以分为两种类型： IO 相关，IO 相关的应用通常用来处理大量数据，需要大量内存和存储，频繁 IO 操作读写数据，而对 CPU 的要求则较少，大部分时候 CPU 都在等待硬盘，比如，数据库服务器、文件服务器等。 CPU 相关，CPU 相关的应用需要使用大量 CPU，比如高并发的 web/mail 服务器、图像/视频处理、科学计算等都可被视作 CPU 相关的应用。 看看实际中的例子，第1个是文件服务器拷贝一个大文件时表现出来的特征，第2个是 CPU 做大量计算时表现出来的特征： $ vmstat 1 procs 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 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 $ vmstat 1 procs memory swap-- io --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 1078 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。 底线 我们如何知道系统性能是好还是差呢？这