性能案例分析 | 查看哪些进程在大量读写磁盘-I/O很高问题排查

作者:布丁缘 https://www.ddkiss.com/archives/68.html

Linux 有很多运维诊断工具,有些用起来很简单,有些功能很强大用起来就有些麻烦。比如I/O等待问题,原因可能有很多种,也很难用某一种工具就能定位。特别是如何找到到底是哪个进程读写了哪个文件引起的?

最近,从监控上看总是在上午10点左右I/O负载突然就升起来了,连远程SSH都卡住。因为ECS服务器内存有限,我启用了SWAP,内存不足时不至于会崩溃,系统性能肯定有所下降。

说明:在Centos7中,top ps等是系统自带的工具,iostat iotop lsof等都是需要自行安装的。

确实系统负载上升是否由于I/O异常导致

最简单的是用top命令,比如

1234
Tasks: 102 total,   1 running, 101 sleeping,   0 stopped,   0 zombie%Cpu(s):  0.7 us,  0.2 sy,  0.0 ni, 0.2 id,  98.9 wa,  0.0 hi,  0.0 si,  0.0 stKiB Mem :  1016396 total,    62276 free,   891072 used,    63048 buff/cacheKiB Swap:  1048572 total,   804428 free,   244144 used.     8100 avail Mem

其中wa也就是iowait参数所表示的,有多少比例的CPU在等待I/O

找到具体读写的是哪个磁盘

最简单的是iostat命令,比如

12345678
$ iostat -x 2 5avg-cpu: %user %nice %system %iowait %steal %idle 3.66 0.00 47.64 48.69 0.00 0.00

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilsda 44.50 39.27 117.28 29.32 11220.94 13126.70 332.17 65.77 462.79 9.80 2274.71 7.60 111.41dm-0 0.00 0.00 83.25 9.95 10515.18 4295.29 317.84 57.01 648.54 16.73 5935.79 11.48 107.02dm-1 0.00 0.00 57.07 40.84 228.27 163.35 8.00 93.84 979.61 13.94 2329.08 10.93 107.02

其中-x知指明输出更加详细的信息。2 5表示间隔2秒统计一次总共输出5次。第一行结果是自系统启动以来的统计值,通常排查突发的I/O异常时可忽略。重点看%util列,表示进程使用I/O的比例。

找出引起高I/O的进程

最简单的是iotop命令,比如

1234
Total DISK READ: 404.95 K/s | Total DISK WRITE: 9.91 M/s  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                                3153 be/3 root        0.00 B/s    3.78 K/s  0.00 %  6.23 % [jbd2/sda5-8]10287 be/4 mysql     253.57 K/s 1858.24 K/s  0.00 %  3.73 % mysqld --defaults-file=/etc/my.cnf --basedir=/opt/my~--pid-file

iotop命令确实是一个很好用的工具,但是很多Linux发行版中默认并没有安装。如果系统里没有这个命令,又不想安装时,怎么办?有没有更简单的方式?

能够实现iotop类型功能的ps命令

首先看下进程状态编码

12345678
PROCESS STATE CODES D uninterruptible sleep (usually IO) R running or runnable (on run queue) S interruptible sleep (waiting for an event to complete) T stopped, either by a job control signal or because it is being traced. W paging (not valid since the 2.6.xx kernel) X dead (should never be seen) Z defunct ("zombie") process, terminated but not reaped by its parent.

注意到,如果进程正在等待I/O,进行的状态码经常为D。通过这个信息,我们可以大概估算出哪些进程在I/O等待中,比如

123456789101112
[[email protected] ~]# for x in `seq 1 1 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done------------D 27456 php-fpm: pool www----------------------------

这里就发现进行 27456 可能有问题。但等待I/O也不一定说明它在疯狂读写磁盘。为了确定它确实读写很多,可以用/proc目录下的信息来定位,比如

12345678
[[email protected] ~]# cat /proc/27456/iorchar: 42857442wchar: 35657666syscr: 44932syscw: 9744read_bytes: 1530859520write_bytes: 13824000cancelled_write_bytes: 1249280

需要注意的是,不同的线程参考值不一样。这个得具体问题具体分析。

原文地址:https://www.cnblogs.com/wyf0518/p/12213790.html

时间: 2024-10-14 03:39:03

性能案例分析 | 查看哪些进程在大量读写磁盘-I/O很高问题排查的相关文章

性能测试学习第十天-----性能案例分析之数据库性能问题

一.现象 /pinter/case/slow?userName=xxx tps很低,响应时间很长,数据库服务器cpu很高(接近100%),应用服务器负载比较低 索引 索引是对数据库表中一列或多列的值进行排序的一种结构,存储了表中的关键字段,使用索引可快速访问数据库表中的特定信息.类似于书籍中的目录.二.分析 数据库服务器CPU高,一般都是因为SQL执行效率低导致的,可能有三方面原因 1.数据库表缺少必要的索引: 2.索引不生效 3.SQL不够优化 三.慢查询 在MySQL中,可以监控SQL语句的

linux网络分析、性能分析、文本格式化、文件读写操作之利器

好的工具能够让我们工作更加高效,结合工作中的情况,今天分享下linux下比较好用的几个工具. 网络分析工具 mtr mtr是网络链路检测判断问题非常好用的工具,集成了tracert和ping这两个命令的功能,动态的输出检测结果.mtr 默认发送icmp数据包进行链路探测,会对链路上的相关节点做持续探测并给出相应的统计信息,mtr 能避免节点波动对测试结果的影响其中中间线路丢包严重但是目标地址不丢包,可能是因为某些主机路由对icmp协议不做处理或者只分配固定限额的资源处理,所以是正常情况.因为ic

SQL性能优化案例分析

这段时间做一个SQL性能优化的案例分析, 整理了一下过往的案例,发现一个比较有意思的,拿出来给大家分享. 这个项目是我在项目开展2期的时候才加入的, 之前一期是个金融内部信息门户, 里面有个功能是收集各个上市公司的财报, 然后做各种分析, 数据图表展示, 使用的人数并不多, 仅百人左右. 2期打算面向行外用户, 刚开始预计同时在线人数不超过50, 就以50访问用户/秒的性能测试, 结果在把1期的图表类数据展示响应基本在5分钟左右, 属于严重不可用, 说说我们的服务器配置, 有2台网站前端承载用户

查看w3wp进程占用的内存及.NET内存泄露,死锁分析

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方式运行w3wp进程.这个可以通过查看IIS Application Pool 的高级选项进行设置: 好了,接下打开Windbg看看这个w3wp进程占用了376M内存,启动的54个线程. 1. 加载 WinDbg SOS 扩展命令 .load C:\Windows\Microsoft.NET\Fram

(转)一个MySQL 5.7 分区表性能下降的案例分析

一个MySQL 5.7 分区表性能下降的案例分析 原文:http://www.talkwithtrend.com/Article/216803 前言 希望通过本文,使MySQL5.7.18的使用者知晓分区表使用中存在的陷阱,避免在该版本上继续踩坑.同时通过对源码的分享,升级MySQL5.7.18时分区表性能下降的根本原因,向MySQL源码爱好者展示分区表实现中锁的运用. 问题描述 MySQL 5.7版本中,性能相关的改进非常多.包括临时表相关的性能改进,连接建立速度的优化和复制分发相关的性能改进

查看w3wp进程占用的内存及.NET内存泄露,死锁分析--转载

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方式运行w3wp进程.这个可以通过查看IIS Application Pool 的高级选项进行设置: 好了,接下打开Windbg看看这个w3wp进程占用了376M内存,启动的54个线程. 1. 加载 WinDbg SOS 扩展命令 .load C:\Windows\Microsoft.NET\Fram

分析案例:应用服务器W3WP进程CPU持续超过百分之九十(Oracle客户端Bug)

问题描述: 项目反馈应用负载的其中一台服务器业务操作的响应非常慢,登录该服务器发现W3WP进程CPU持续超过90%,哪怕在业务低峰期也是如此?远程查看后发现该应用服务器承载的请求确实很低,why??? 原因分析: 抓取w3wp进程的dump发现,正在运行的线程都没有我们系统的堆栈代码.并且长时间运行的工作线程的栈顶基本都是Oracle.DataAccess.Client.OracleTuningAgent.DoScan() ---->Oracle.DataAccess.Client.Oracle

《大型网站技术架构:核心原理与案例分析》笔记

目录 · 大型网站软件系统的特点 · 大型网站架构演化发展历程 · 初始阶段的网站架构 · 需求/解决问题 · 架构 · 应用服务和数据服务分离 · 需求/解决问题 · 架构 · 使用缓存改善网站性能 · 需求/解决问题 · 架构 · 使用应用服务器集群改善网站的并发处理能力 · 需求/解决问题 · 架构 · 数据库读写分离 · 需求/解决问题 · 架构 · 使用反向代理和CDN加速网站响应 · 需求/解决问题 · 架构 · 使用分布式文件系统和分布式数据库系统 · 需求/解决问题 · 架构 ·

2-4-RHEL6.3搭建samba服务器案例分析与总结(Red Hat Enterprise Linux Server6.3)@树袋飘零

本节介绍内容: 1.  samba概述 2.  samba服务器的搭建 3.  samba服务主配置文件的详解 4.  samba服务器搭建案例分析 1.  samba概述 samba是linux以及UNIX和windows完美交互的工具.我们首先来说下samba的由来,那要先从SMB说起.SMB即(Server Message Block )服务器消息块,SMB主要是Microsoft的网络通讯协议,后来应用在了linux上,形成了samba,这是一个能让linux系统应用Microsoft网