|
Linux性能监控之绪论篇
性能调优的目的是找到
系统的瓶颈,并且调节系统来设法消除这些瓶颈．我们在监控性能的时候重点在于监视一下子系统：
１．ＣＰＵ ２．Ｍｅｍｏｒｙ ３．ＩＯ ４．Ｎｅｔｗｏｒｋ 但这些系统都是彼此依赖,不能单独只看其中一个.当一个系统负载过重时往往会引起其它子系统的问题,比如说: ->大量的读入内存的IO请求(page-in IO)会用完内存队列; ->大量的网络流量会造成CPU的过载; ->CPU的高使用率可能正在处理空闲内存队列; ->大量的磁盘读写会消耗CPU和IO资源. 我们 测试的系统,总的来说可分为二类: 第一, IO Bound, 这类系统会大量消耗内存和底层的存储系统,它并不消耗过多的CPU和网络资源(除非系统是网络的).IO bound系统消耗CPU资源用来接受IO请求,然后会进入休眠状态. 数据库通常被认为是IO bound系统. 第二, CPU Bound,这类系统需要消耗大量的CPU资源.他们往往进行大量的数学计算. 高吞吐量的Web server, Mail Server通常被认为是CPU Bound系统. 在 性能测试中首先要做的是建立基线(Baseline),这样后续的调整才会有一个参考标准.值得注意的是,在测试基线的时候,一定要保证系统工作在正常的状态下. 在Linux上,监视系统的性能的常用工具有: Tool Description Base Repository vmstat all purpose performance tool yes yes mpstat provides statistics per CPU no yes sar all purpose performance monitoring tool no yes iostat provides disk statistics no yes netstat provides network statistics yes yes dstat monitoring statistics aggregator no in most distributions iptraf traffic monitoring dashboard no yes ethtool reports on Ethernet interface configuration yes yes 这些工具在Linux的安装过程中都可以选择进行安装。 下面是一个vmstat产生的baseline的例子： # vmstat 1 procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy wa id 1 0 138592 17932 126272 214244 0 0 1 18 109 19 2 1 1 96 0 0 138592 17932 126272 214244 0 0 0 0 105 46 0 1 0 99 0 0 138592 17932 126272 214244 0 0 0 0 198 62 40 14 0 45 0 0 138592 17932 126272 214244 0 0 0 0 117 49 0 0 0 100 0 0 138592 17924 126272 214244 0 0 0 176 220 938 3 4 13 80 0 0 138592 17924 126272 214244 0 0 0 0 358 1522 8 17 0 75 1 0 138592 17924 126272 214244 0 0 0 0 368 1447 4 24 0 72 0 0 138592 17924 126272 214244 0 0 0 0 352 1277 9 12 0 79 # vmstat 1 procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy wa id 2 0 145940 17752 118600 215592 0 1 1 18 109 19 2 1 1 96 2 0 145940 15856 118604 215652 0 0 0 468 789 108 86 14 0 0 3 0 146208 13884 118600 214640 0 360 0 360 498 71 91 9 0 0 2 0 146388 13764 118600 213788 0 340 0 340 672 41 87 13 0 0 2 0 147092 13788 118600 212452 0 740 0 1324 620 61 92 8 0 0 2 0 147360 13848 118600 211580 0 720 0 720 690 41 96 4 0 0 2 0 147912 13744 118192 210592 0 720 0 720 605 44 95 5 0 0 2 0 148452 13900 118192 209260 0 372 0 372 639 45 81 19 0 0 2 0 149132 13692 117824 208412 0 372 0 372 457 47 90 10 0 0 CPU篇 正如我们之前讨论的任何系统的性能比较都是基于基线的，并且监控CPU的性能就是以上3点，运行队列、CPU使用率和上下文切换。以下是一些对于CPU很普遍的性能要求： 常用的监视工具有，vmstat, top,dstat和mpstat. r表示运行队列的大小， dstat可以给出每一个设备产生的中断数： mpstat可以显示每个CPU的运行状况，比如系统有4个CPU。我们可以看到： 总结的说，CPU性能监控包含以下方面： 首先说说虚拟内存和物理内存： 虚拟内存就是采用硬盘来对物理内存进行扩展，将暂时不用的内存页写到硬盘上而腾出更多的物理内存让有需要的进程来用。当这些内存页需要用的时候在从 硬盘读回内存。这一切对于用户来说是透明的。通常在Linux系统说，虚拟内存就是swap分区。在X86系统上虚拟内存被分为大小为4K的页。 每一个进程启动时都会向系统申请虚拟内存（VSZ），内核同意或者拒就请求。当程序真正用到内存时，系统就它映射到物理内存。RSS表示程序所占的物理内存的大小。用ps命令我们可以看到进程占用的VSZ和RSS。 # ps –aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND daemon 2177 0.0 0.2 3352 648 ? Ss 23:03 0:00 /usr/sbin/atd dbus 2196 0.0 0.5 13180 1320 ? Ssl 23:03 0:00 dbus-daemon-1 --sys root 2210 0.0 0.4 2740 1044 ? Ss 23:03 0:00 cups-config-daemon root 2221 0.3 1.5 6108 4036 ? Ss 23:03 0:02 hald root 2231 0.0 0.1 2464 408 tty1 Ss+ 23:03 0:00 /sbin/mingetty tty1 内核会定期将内存中的数据同步到硬盘，这个过程叫做Memory Paging。同时内核也要负责回收不用的内存，将他们分给其他需要的进程。PFRA算法（Page Frame. reclaim algorithm）负责回收空闲的内存。算法根据内存页的类型来决定要释放的内存页。有下列4种类型： 1． Unreclaimable – 锁定的，内核保留的页面； 2． Swappable – 匿名的内存页； 3． Syncable – 通过硬盘文件备份的内存页； 4． Discardable – 静态页和被丢弃的页。 除了第一种（Unreclaimable）之外其余的都可以被PFRA进行回收。与之相关的进程是kswapd。在kswapd中，有2个阀值， pages_hige和pages_low。当空闲内存页的数量低于pages_low的时候，kswapd进程就会扫描内存并且每次释放出32个 free pages，直到free page的数量到达pages_high。具体kswapd是如何回收内存的呢？有如下原则： 1. 如果页未经更改就将该页放入空闲队列； 2. 如果页已经更改并且是可备份回文件系统的，就理解将内存页的内容写回磁盘； 3. 如果页已经更改但是没有任何磁盘上的备份，就将其写入swap分区。 # ps -ef | grep kswapd root 30 1 0 23:01 ? 00:00:00 [kswapd0] 在回收内存过程中还有两个重要的方法，一是LMR（Low on memory reclaiming），另一个是OMK(Out of Memory Killer)。当分配内存失败的时候LMR将会其作用，失败的原因是kswapd不能提供足够的空闲内存，这个时候LMR会每次释放1024个垃圾页知 道内存分配成功。当LMR不能快速释放内存的时候，OMK就开始其作用，OMK会采用一个选择算法来决定杀死某些进程。当选定进程时，就会发送信号 SIGKILL，这就会使内存立即被释放。OMK选择进程的方法如下： 1. 进程占用大量的内存； 2. 进程只会损失少量工作； 3. 进程具有低的静态优先级； 4. 进程不属于root用户。 进程管理中另一个程序pdflush用于将内存中的内容和文件系统进行同步，比如说，当一个文件在内存中进行修改，pdflush负责将它写回硬盘。 # ps -ef | grep pdflush root 28 3 0 23:01 ? 00:00:00 [pdflush] root 29 3 0 23:01 ? 00:00:00 [pdflush] 每当内存中的垃圾页（dirty page）超过10%的时候，pdflush就会将这些页面备份回硬盘。这个比率是可以调节的，通过参数vm.dirty_background_ratio。 # sysctl -n vm.dirty_background_ratio 10 Pdflush同PFRA是独立运行的，当内核调用LMR时，LMR就触发pdflush将垃圾页写回硬盘 IO篇 接下来我们分析一些具体的情况，在这些情况下I/O会成为系统的瓶颈。我们会用到工具top，vmstat，iostat，sar等。每一个工具的输出都从不同的方面反映除系统的性能情况。
情况1：同一时间进行大量的I/O操作 在这种情况时我们会发现CPU的wa时间百分比会上升，证明系统的idle时间大部分都是在等待I/O操作。 # vmstat 1 procs -----memory----- ---swap---io---- --system--cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 3 2 0 55452 9236 1739020 0 0 9352 0 2580 8771 20 24 0 57 2 3 0 53888 9232 1740836 0 0 14860 0 2642 8954 23 25 0 52 2 2 0 51856 9212 1742928 0 0 12688 0 2636 8487 23 25 0 52
从这个输出我们可以看到CPU有50%的时间都在等待I/O操作，我们还可以看到系统的bi值很大，证明系统有大量的I/O请求将磁盘内容读入内存。 没有很好的工具能看到到底是哪个进程在进行I/O读写。但我们可以通过top命令的输出来猜测
# top -d 1 top - 19:45:07 up 1:40, 3 users, load average: 6.36, 5.87, 4.40 Tasks: 119 total, 3 running, 116 sleeping, 0 stopped, 0 zombie Cpu(s): 5.9% us, 87.1% sy, 0.0% ni, 0.0% id, 5.9% wa, 1.0% hi, 0.0% si Mem: 2075672k total, 2022668k used, 53004k free, 7156k buffers Swap: 2031608k total, 132k used, 2031476k free, 1709372k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND 3069 root 5 -10 450m 303m 280m S 61.5 15.0 10:56.68 4562 vmware-vmx 3016 root 5 -10 447m 300m 280m S 21.8 14.8 12:22.83 3978 vmware-vmx 3494 root 5 -10 402m 255m 251m S 3.0 12.6 1:08.65 3829 vmware-vmx 3624 root 5 -10 401m 256m 251m S 1.0 12.6 0:29.92 3747 vmware-vmx
将top的输出通过faults进行排序。我们可以看到vmware产生最多的page faults。也就是说它进行了大量的IO操作。
情况2：管道太小 任何I/O操作都需要一定的时间，而且这些时间对于硬盘来说是确定的，它包含磁盘旋转的延时RD（rotation delay）和磁头搜索时间DS（disk seek）。RD由磁盘转速（RPM）决定。RD是磁盘旋转一周所需时间的一半。如RPM为10000. RPS=RPM/60=166 1/166=0.0006=6ms 磁盘旋转一周要6毫秒 RD=6ms/2=3ms 磁盘平均搜索时间是3ms，数据传输的平均延时是2ms，这样一次I/O操作的平均时间是： 3ms+3ms+2ms=8ms IOPS=1000/8=125 这块磁盘的每秒IO数（IOPS）为125。所以对于10000RPM的磁盘来说它所能承受的IO操作在IOPS在120～150之间。如果系统的I/O请求超过这个值，就会使磁盘成为系统的瓶颈。 对与系统而言有两种不同种类的I/O压力，连续I/O和随机I/O。 连续I/O常常出现在企业级数据库这样的应用中，需要连续的读取大量数据。这种系统的性能依靠它读取和移动数据的大小和快慢。我们用iostat来监控，会发现rKB/s,wKB/s会很高。 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util /dev/sda 0.00 12891.43 0.00 105.71 0.00 106080.00 0.00 53040.00 1003.46 1099.43 3442.43 26.49 280.00 从输出我们看到w/s=105,wKB/s=53040.所以53040/105=505KB per I/O. 对于随机I/O的系统来说性能的关注点不在搜传输数据的大小和速度，而是在磁盘的IOPS。这类系统的I/O请求比较小但是数量很大，如Web服务器和Mail服务器。他们的性能主要依赖每秒钟可处理的请求数： # iostat -x 1 avg-cpu: %user %nice %sys %idle 2.04 0.00 97.96 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util /dev/sda 0.00 633.67 3.06 102.31 24.49 5281.63 12.24 2640.82 288.89 73.67 113.89 27.22 50.00 从输出我们看到w/s=102,wKB/s=2640.所以2640/102=23KB per I/O. 因此对于连续I/O系统来说我们要关注系统读取大量数据的能力即KB per request.对于随机I/O系统我们注重IOPS值. Network篇 大部分的以太网络都是自适应速度的，因为一个网络中可能有不同的网络设备采用不同的速率和工作模式（全双工或半双工）。大部分企业网络都工作在100到1000BaseTX。ethtool命令可以设置网卡的工作速率和模式。 # ethtool eth0 我们可以看到网卡工作在10Mb/s，模式为半双工，并且打开了自适应开关。我们通过下列命令强制设置网卡工作在100Mb/s全双工模式，并关闭自适应功能。 # ethtool -s eth0 speed 100 duplex full autoneg off 再次运行ethtool显示如下： # ethtool eth0 用iptraf工具可以清楚的看到每个网卡的工作情况。 # iptraf –d eth0
利用iptraf还可以监听固定TCP端口的流量，如对于Web服务器我们希望监听80端口的流量，对于邮件服务器我们关注25端口的流量。
网络中最常见的错误就是冲突，由于网络中目前基本采用交换机环境，因此冲突问题已被消除。但是当网络流量不断增大的时候，就会出现丢包，网卡过载等情况。在网络流量很大的时候我们用sar命令来给出网络中可能的错误: # sar -n FULL 5 100 rxerr/s是接受错误率；txerr/s是发送错误率；coll/s冲突率；rxdrop/s接受帧丢失率；txdrop/s发送帧丢失率； txcarr/s载波错误率；rxfram/s帧排列错误；rxfifo/s接受FIFO错误；txfifo/s发送FIFO错误。从上面输出看出各种错 误为零，证明网络工作良好。 总的来说监视网络性能，我们有遵循一下几点： 1. 检查所有网络接口确保他们都运行在正确的速率； 2. 检查每块网卡的吞吐量确保没有造成过载； 3. 检查流量的类型确保正确的数据流在传送。 |
Linux性能监控
2009-08-21
1076
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《
阿里云开发者社区用户服务协议》和
《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写
侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：
转自 http://hi.baidu.com/ccex/blog/item/f613f9d3d5e401d6a8ec9af8.html
Linux性能监控
Linux性能监控之绪论篇性能调优的目的是找到系统的瓶颈,并且调节系统来设法消除这些瓶颈．...
Linux性能监控
目录
相关文章
|
1月前
|
缓存
算法
Linux
深入理解Linux内核调度器：公平性与性能的平衡####
真知灼见
本文将带你深入了解Linux操作系统的核心组件之一——完全公平调度器（CFS），通过剖析其设计原理、工作机制以及在实际系统中的应用效果，揭示它是如何在众多进程间实现资源分配的公平性与高效性的。不同于传统的摘要概述，本文旨在通过直观且富有洞察力的视角，让读者仿佛亲身体验到CFS在复杂系统环境中游刃有余地进行任务调度的过程。
####
49
6
6
|
4月前
|
缓存
监控
网络协议
|
6天前
|
运维
监控
Linux
BPF及Linux性能调试探索初探
BPF技术从最初的网络数据包过滤发展为强大的系统性能优化工具，无需修改内核代码即可实现实时监控、动态调整和精确分析。本文深入探讨BPF在Linux性能调试中的应用，介绍bpftune和BPF-tools等工具，并通过具体案例展示其优化效果。
35
14
14
|
12天前
|
存储
缓存
网络协议
Linux操作系统的内核优化与性能调优####
本文深入探讨了Linux操作系统内核的优化策略与性能调优方法，旨在为系统管理员和高级用户提供一套实用的指南。通过分析内核参数调整、文件系统选择、内存管理及网络配置等关键方面，本文揭示了如何有效提升Linux系统的稳定性和运行效率。不同于常规摘要仅概述内容的做法，本摘要直接指出文章的核心价值——提供具体可行的优化措施，助力读者实现系统性能的飞跃。
####
36
1
1
|
24天前
|
缓存
Ubuntu
Linux
Linux环境下测试服务器的DDR5内存性能
通过使用 `memtester`和 `sysbench`等工具，可以有效地测试Linux环境下服务器的DDR5内存性能。这些工具不仅可以评估内存的读写速度，还可以检测内存中的潜在问题，帮助确保系统的稳定性和性能。通过合理配置和使用这些工具，系统管理员可以深入了解服务器内存的性能状况，为系统优化提供数据支持。
31
4
4
|
1月前
|
监控
网络协议
算法
Linux内核优化：提升系统性能与稳定性的策略####
本文深入探讨了Linux操作系统内核的优化策略，旨在通过一系列技术手段和最佳实践，显著提升系统的性能、响应速度及稳定性。文章首先概述了Linux内核的核心组件及其在系统中的作用，随后详细阐述了内存管理、进程调度、文件系统优化、网络栈调整及并发控制等关键领域的优化方法。通过实际案例分析，展示了这些优化措施如何有效减少延迟、提高吞吐量，并增强系统的整体健壮性。最终，文章强调了持续监控、定期更新及合理配置对于维持Linux系统长期高效运行的重要性。
####
98
2
2
|
1月前
|
人工智能
安全
Linux
|
2月前
|
存储
缓存
监控
|
2月前
|
存储
监控
固态存储
|
4月前
|
传感器
缓存
Prometheus
热门文章
最新文章
1
常用LINUX软件，下载后解压出来ISO文件，直接挂载到LINUX使用即可
2
如何在Linux下使用TCP封装器来加强网络服务安全
3
【Linux网络服务】Centos7搭建nfs文件共享服务器
4
Linux内核管理--进程（一）
5
Linux 清空登录信息
6
linux查看文件
7
Windows Linux 删除N天之前文件脚本
8
linux--nfs 网络文件共享
9
AIX下配置NFS共享给LINUX
10
Linux教程【一】
1
使用Performance API进行性能监控
103
2
《Linux 简易速速上手小册》第10章: 性能监控与优化（2024 最新版）
59
3
微信小程序全栈开发中的性能监控与调优
226
4
Java项目jar性能监控工具CPU内存等
212
5
常见的磁盘 I/O 性能监控指标
166
6
性能监控之 Linux 命令 top、vmstat、iostat、free、iftop 基础
187
7
web服务性能监控方案
128
8
使用Java进行性能监控可能会遇到的问题以及解决方案
105
9
性能监控之国产时序库TDengine TDinsight dashboard 指标解析
730
10
Rust中的系统性能监控与调优：提升应用效能的关键实践
191