网站运维技术与实践之服务器监测常用命令
一、监测的意义 不论是网站运维还是系统管理,服务器本身的运行状况都是我们需要掌控的基础资料。在《打造FaceBook》一书中,王淮介绍FaceBook的工程师文化中有一句“Move Fast and Monitor Closely”。这个"Closely"有两层意义,其一是“即时”的,要从系统开发初期,就有意识地设计好配套的监测,并逐步改善;其二是“深入”,监控不能仅仅停留在监测主机负载、网卡流量的表面层次,而要尽可能地细化,以贴近系统的业务特性。 在系统运行和发展的过程中,监测的重要性得到更进一步的提高。运维人员总是倾向于为了保证稳定性而不轻易对系统做任何改动,所以,运维人员对稳定运行中的系统一举一动都必须要有监测数据的支持。所有的大规模集群运作,包括近年来流行的自动化管理、弹性控制等理念,都要求我们首先对自己的系统的细节有足够的了解。 1.通过命令了解系统的性能概况 1.1 ifconfig命令 ? ?结果包含服务器的网卡数目、IP地址、MAC地址、MTU的大小、网卡收发包的情况(丢包和错误包),这些一般是服务器排除故障时需要检查的数据。 ? 1.2 w命令 结果中包含服务器的运行时间、当前用户及其运行程序,以及1分钟、5分钟、10分钟的平均负载。 或许有人会很疑惑,什么是平均负载? 平均负载是反映服务器当前运行状态最直观和简洁的数据。 单核时代,平均负载有如下的经验准则: (1)如果平均负载大于0.70,趁着事情没有向糟糕的方向发展,赶紧开始找原因(关注原则); (2)如果负载高于1.00,立刻扔掉其他非重要紧急的事项,先把这个问题修复(针对运维人员,毕竟维护服务器24x7x365稳定运行是运维人员的职责,没有什么是比这个更重要的,因为一旦服务器出问题,公司的业务也会受到很大的影响)(立刻修复原则); (3)如果负载超过5.00,机器随时可能挂掉,尽可能别出现这种情况,如果出现了,要想尽一切办法解决,不过更好的解决方案是,前期做了充足的监控准备,防止此类事件出现,用一句成语来形容,防微杜渐。 多核时代,新增两条准则: (1)多核系统上,负载不要高过设备的核心数; (2)核心如何在CPU分布,这并不重要。两个四核心,四个双核心,八个单核心,效果是一样的。对于计算平均负载来说,它们都是八核心。 当然了,以上的准则,只是在一定条件的情况下总结出的,每个运维人员所面对的服务器情况不一样,需要从实际出发。 比如当核心数多到好几十时,Linux轮询各核心来统计单核负载的耗时长到足以让某些任务状态变化,这时候平均负载会普遍比实际情况低。针对这种情况,Linux内核社区以及有些补丁尽量调整算法。 ? 1.3 df df -h ? ? df -Ti ? ?分别查找挂载盘的目录、总容量和使用量、Inode的总量和使用量,以及磁盘文件系统的类型。 ? 1.4 ps ps的用法太多了 比如我经常用的 ps -ef|grep tomcat 查看tomcat的进程 或者是ps -A查看所有进程等等 ? 1.5 vmstat 通常会使用free命令查看机器的内存使用情况,如 ? ?或者free -m(以"兆"的形式显示内存的容量) ? vmstat 1 可以用来观察swap的I/O情况,如图: ? 1.6 netstat netstat 是查看网络相关数据的常用命令,可以用来查看服务器所有的网络层连接状况。 netstat -plnt 命令 ? 1.7 iostat iostat -x 命令 ? 其中磁盘设备的数据含义如下: rrqm/s:合并后每秒发送到设备的读入请求数。 wrqm/s:合并后每秒发送到设备的写入请求数。 r/s:每秒发送到设备的读入请求数。 w/s:每秒发送到设备的写入请求数。 rsec/s:每秒从设备读入的扇区数。 wsec/s:每秒从设备写入的扇区数。 rkB/s:每秒从设备读入的数据量,单位为KB。 wkB/s:每秒向设备写入的数据量,单位为KB。 avgrq-sz:发送到设备的请求的平均大小,单位是扇区。 avgqu-sz:发送到设备的请求的平均队列长度。 await:I/O请求平均执行时间,包括发送请求和执行时间,单位是毫秒。 svctm:发送到设备的I/O请求的平均执行时间。单位是毫秒。 $util:在I/O请求发送到设备期间,占用CPU时间的百分比。 一般来说,我们关心每秒的读入请求数、队列长度、请求执行时间和I/O时间占CPU的百分比。 对于磁盘I/O,我们必须要明确一件事情,那就是: I/O性能的优化是不可能无限提高的。所有机械磁盘的IOPS都在最根本上受限于其机械转动的原理。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |