如何查询每个用户的IO使用情况(Linux) (查询每个用户的io使用linux)

在Linux操作系统中,IO(Input/Output)使用情况是非常重要的一项系统资源。IO的使用情况将直接影响系统的性能和稳定性,因此必须定期进行监控和管理。本文将介绍如何在Linux系统中查询每个用户的IO使用情况,以便于进行性能分析和优化。

一、使用iostat命令查询

iostat是一个可以查询磁盘IO情况的命令。使用该命令可以查看系统中每个用户的IO使用情况。具体操作步骤如下:

1.打开终端窗口,输入以下命令:

iostat -x 1 | awk ‘{if($1 ~ /Device:/) {flag=0};if(flag) {print}};{if($1 ~ /avg-cpu:/) {flag=1}}’

2.按回车键,等待命令执行完毕后,系统将会显示每个用户的IO使用情况。

该命令将显示每个用户的IO使用情况,包括IO速率、块读写、平均等待时间和平均服务时间等信息。您可以根据这些信息来评估每个用户的IO使用情况,进而进行性能优化。

二、使用iotop命令查询

iotop是一个可以查询IO的命令,它比iostat更加详细,可以查看每个进程的IO使用情况。具体操作步骤如下:

1.打开终端窗口,输入以下命令:

iotop -b -n 1 | awk ‘{if(NR>7) {print}}’

2.按回车键,系统将会显示每个用户的IO情况。

与iostat不同,iotop可以查看到每个进程的IO信息。您可以根据这些信息来评估每个用户的IO使用情况和进程的IO使用情况,进而进行性能优化。

三、使用pidstat命令查询

pidstat是一个可以查询进程ID的命令,它可以用于查询每个进程的IO使用情况。具体操作步骤如下:

1.打开终端窗口,输入以下命令:

pidstat -d 1 | awk ‘{if($1 ~ /[0-9]/) {print}}’

2.按回车键,系统将会显示每个用户的IO情况。

与iotop不同,pidstat可以查看到每个进程的IO使用情况和当前用户的IO使用情况。您可以根据这些信息来评估每个用户的IO使用情况和进程的IO使用情况,进而进行性能优化。

四、使用sar命令查询

sar是一个可以查询系统活动信息的命令,它可以用于查询每个用户的IO使用情况。具体操作步骤如下:

1.打开终端窗口,输入以下命令:

sar -d 1 | awk ‘{if(NR>2) {print}}’

2.按回车键,系统将会显示每个用户的IO情况。

与其他命令不同,sar可以查看所有用户的IO使用情况,您可以根据这些信息来评估系统的性能和稳定性,进而进行性能优化。

在Linux操作系统中,IO的使用情况是一个非常重要的指标。通过查询每个用户的IO情况,您可以评估系统的性能和稳定性,并提升系统的性能。在本文中,我们介绍了四种查询每个用户的IO使用情况的方法,您可以根据实际情况选择适合自己的方法。希望本文能够帮助您更好地了解Linux系统中的IO使用情况。

相关问题拓展阅读:

如何找出Linux系统高IO的思路总结

前言

I/O Wait是一个需要使用高级的工具来debug问题原因,当然也有许多基本工具的高级用法。I/O wait的问题难以定位的原因是:因为我们有很多工具可以告诉你I/O 受限了,但是并没有告诉你具体是哪个进程引起的。

1. 如何确认,是否是I/O问题导致系统缓慢

确认是否是I/O导致的系统缓慢我们可以使用多个命令,但是,最简单的是unix的命令 top

# top

top – 14:31:20 up 35 min, 4 users, load average: 2.25, 1.74, 1.68

Tasks: 71 total, 1 running, 70 sleeping, 0 stopped, 0 zombie

Cpu(s): 2.3%us, 1.7%sy, 0.0%ni, 0.0%id, 96.0%wa, 0.0%hi, 0.0%si, 0.0%st

Mem:k total,k used, 4436k free, 496k buffers

Swap:k total, 5436k used,k free,k cached

从CPU这行,可以发现CPU的io wait;这里是96.0%。越高就代表CPU用于io wait的资源越多。

2. 找出哪个磁盘正在被写入

上边的top命令从一个整体上说明了I/O wait,但是并没有说明是哪块磁盘影响的,想知道是哪块磁盘引发的问题,可以使用另外一个命令 iostat 命令

$ iostat -x 2 5

avg-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 %util

sda 44.50 39.27 117.28 29…70 332.17 65.77 462.79 9..71 7.60 111.41

dm-0 0.00 0.00 83.25 9…29 317.84 57.01 648.54 16..79 11.48 107.02

dm-1 0.00 0.00 57.07 40.84 228.27 163.35 8.00 93.84 979.61 13..08 10.93 107.02

iostat 会每2秒更新一次,一共打印5次信息, -x 的选项是打印出扩展信息

之一个iostat 报告会打印出系统最后一次启动后的统计信息,这也就是说,在多数情况下,之一个打印出来的信息应该被忽略,剩下的报告,都是基于上一次间隔的时间。举例子来说,这个命令会打印5次,第二次的报告是从之一次报告出来一个后的统计信息,第三次是基于第二次 ,依次类推

所以,一定记住:之一个忽略!

在上面的例子中,sda的%utilized 是111.41%,这个很好的说明了有进程正在写入到sda磁盘中。

除了%utilized 外,我们可以从iostat得到更加丰富的资源信息,例如每毫秒读写请求(rrqm/s & wrqm/s)),每秒读写的((r/s & w/s)。在上边的例子中,我们的项目看起来正在读写非常多的信息。这个对我们查找相应的进程非常有用。

3. 找出导致高IO的进程

# iotop

Total DISK READ: 8.00 M/s | Total DISK WRITE: 20.36 M/s

  TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND

be/4 root 7.99 M/s 8.01 M/s 0.00 % 61.97 % bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

最简单的方法就是用iotop找出哪个进程用了最多的存储资源,从上面可以看到是bonnie++。

iotop很好用,但是不是默认安装的。

如果没有iotop,下面的方式也可以让你有种方法缩小范围,尽快找到是哪个进程。

ps 命令对内存和CPU有一个统计,但是他没有对磁盘I/O的统计,虽然他没有显示磁盘I/O,但是它显示进行的状态,我们可以用来知道一个进程是否正在等待I/O

主要的进程状态有:

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的进程的状态一般是“uninterruptible sleep”,或者“D”,我们可以很容易的查找到正在等待I/O的进程

# for x in `seq`; do ps -eo state,pid,cmd | grep “^D”; echo “—-“; sleep 5; done

D 248

Dbonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

—-

D 22

Dbonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

—-

D 22

Dbonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

—-

D 22

Dbonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

—-

Dbonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

上边的例子会循环的输出状态是D的进程,每5秒一次,一共10次

从输出我们可以知道 bonnie++ 的pid是16528 ,在waiting,bonnie++看起来就是我们想找到的进程,但是,只是从它的状态,我们没有办法证明就是bonnie++引起的I/O等待。

为了证明,我们可以可以查看/proc,每个进程目录下都有一个叫io的文件,里边保存这和iotop类似的信息。

# cat /proc/16528/io

rchar:

wchar:

syscr: 5967

syscw: 67138

read_bytes:

write_bytes:

cancelled_write_bytes: 0

read_bytes和write_bytes是这个进程从磁盘读写的字节,在这个例子中,bonnie++进程读取了46M的数据并且写入了524MB的数据到磁盘上。

4. 找出哪个文件正在被大量写入

lsof 命令可以展示一个进程打开的所有文件。从这个列表中,我们可以找到哪个文件被写入。

# lsof -p 16528

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

bonnie++root cwd DIR 252,/tmp

bonnie++root 8u REG 252,1869 /tmp/Bonnie.16528

bonnie++root 9u REG 252,1869 /tmp/Bonnie.16528

bonnie++root 10u REG 252,1869 /tmp/Bonnie.16528

bonnie++root 11u REG 252,1869 /tmp/Bonnie.16528

/tmp/Bonnie.16528

# df /tmp

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/mapper/workstation-root% /

# pvdisplay

Physical volume —

  PV Name /dev/sda5

  VG Name workstation

  PV Size 7.76 GiB / not usable 2.00 MiB

  Allocatable yes

  PE Size 4.00 MiB

  Total PE 1986

  Free PE 8

  Allocated PE 1978

  PV UUID CLbABb-GcLB-l5z3-TCj3-IOK3-SQ2p-RDPW5S

使用pvdisplay可以看到,pv设备就是/dev/sda5,正是我们前面找到的sda。

参考文档:

Linux 磁盘IO

磁盘结构与数据存储方式, 数据是如何存储的,又通过怎样的方式被访问?

机械硬盘主要由磁盘盘片、磁头、主轴与传动轴等组成;数据就存放在磁盘盘片中

现代硬盘寻道都是采用CHS( Cylinder Head Sector )的方式,硬盘读取数据时,读写磁头沿径向移动,移到要读取的扇区所在磁道的上方,这段时间称为

寻道时间(seek time)

因读写磁头的起始位置与目标位置之间的距离不同,寻道时间也不同

。磁头到达指定磁道后,然后通过盘片的旋转,使得要读取的扇区转到读写磁头的下方,这段时间称为

旋转延迟时间(rotational latencytime)

。然后再读写数据,读写数据也需要时间,这段时间称为

传输时间(transfer time)

固态硬盘主要由主控芯片、闪存颗粒与缓存组成;数据就存放在闪存芯片中

通过主控芯片进行寻址, 因为是电信号方式, 没有任何物理结构, 所以寻址速度非常快且与数据存储位置无关

如何查看系统IO状态

查看磁盘空间

调用 open , fwrite 时到底发生了什么?

在一个IO过程中,以下5个API/系统调用是必不可少的

Create 函数用来打开一个文件,如果该文件不存在,那么需要在磁盘上创建该文件

Open 函数用于打开一个指定的文件。如果在 Open 函数中指定 O_CREATE 标记,那么 Open 函数同样可以实现 Create 函数的功能

Clos e函数用于释放文件句柄

Write 和 Read 函数用于实现文件的读写过程

O_SYNC (先写缓存, 但是需要实际落盘之后才返回, 如果接下来有读请求, 可以从内存读 ), write-through

O_DSYNC (D=data, 类似O_SYNC, 但是只同步数据, 不同步元数据)

O_DIRECT (直接写盘, 不经过缓存)

O_ASYNC (异步IO, 使用信号机制实现, 不推荐, 直接用aio_)

O_NOATIME (读取的时候不更新文件 atime(access time))

sync() 全局缓存写回磁盘

fsync() 特定fd的sync()

fdatasync() 只刷数据, 不同步元数据

mount noatime(全局不记录atime), re方式(只读), sync(同步方式)

一个IO的传奇一生 这里有一篇非常好的资料,讲述了整个IO过程;

下面简单记录下自己的理解的一次常见的Linux IO过程, 想了解更详细及相关源码,非常推荐阅读上面的原文

Linux IO体系结构

Superblock

超级描述了整个文件系统的信息。为了保证可靠性,可以在每个块组中对superblock进行备份。为了避免superblock冗余过多,可以采用稀疏存储的方式,即在若干个块组中对superblock进行保存,而不需要在所有的块组中都进行备份

GDT 组描述符表

组描述符表对整个组内的数据布局进行了描述。例如,数据块位图的起始地址是多少?inode位图的起始地址是多少?inode表的起始地址是多少?块组中还有多少空闲块资源等。组描述符表在superblock的后面

数据块位图

数据块位图描述了块组内数据块的使用情况。如果该数据块已经被某个文件使用,那么位图中的对应位会被置1,否则该位为0

Inode位图

Inode位图描述了块组内inode资源使用情况。如果一个inode资源已经使用,那么对应位会被置1

Inode表

(即inode资源)和数据块。这两块占据了块组内的绝大部分空间,特别是数据块资源

一个文件是由inode进行描述的。一个文件占用的数据块block是通过inode管理起来的

。在inode结构中保存了直接块指针、一级间接块指针、二级间接块指针和三级间接块指针。对于一个小文件,直接可以采用直接块指针实现对文件块的访问;对于一个大文件,需要采用间接块指针实现对文件块的访问

最简单的调度器。它本质上就是一个链表实现的

fifo

队列,并对请求进行简单的

合并

处理。

调度器本身并没有提供任何可以配置的参数

读写请求被分成了两个队列, 一个用访问地址作为索引,一个用进入时间作为索引,并且采用两种方式将这些request管理起来;

在请求处理的过程中,deadline算法会优先处理那些访问地址临近的请求,这样可以更大程度的减少磁盘抖动的可能性。

只有在有些request即将被饿死的时候,或者没有办法进行磁盘顺序化操作的时候,deadline才会放弃地址优先策略,转而处理那些即将被饿死的request

deadline算法可调整参数

read_expire

: 读请求的超时时间设置(ms)。当一个读请求入队deadline的时候,其过期时间将被设置为当前时间+read_expire,并放倒fifo_list中进行排序

write_expire

:写请求的超时时间设置(ms)

fifo_batch

:在顺序(sort_list)请求进行处理的时候,deadline将以batch为单位进行处理。每一个batch处理的请求个数为这个参数所限制的个数。在一个batch处理的过程中,不会产生是否超时的检查,也就不会产生额外的磁盘寻道时间。这个参数可以用来平衡顺序处理和饥饿时间的矛盾,当饥饿时间需要尽可能的符合预期的时候,我们可以调小这个值,以便尽可能多的检查是否有饥饿产生并及时处理。增大这个值当然也会增大吞吐量,但是会导致处理饥饿请求的延时变长

writes_starved

:这个值是在上述deadline出队处理之一步时做检查用的。用来判断当读队列不为空时,写队列的饥饿程度是否足够高,以时deadline放弃读请求的处理而处理写请求。当检查存在有写请求的时候,deadline并不会立即对写请求进行处理,而是给相关数据结构中的starved进行累计,如果这是之一次检查到有写请求进行处理,那么这个计数就为1。如果此时writes_starved值为2,则我们认为此时饥饿程度还不足够高,所以继续处理读请求。只有当starved >= writes_starved的时候,deadline才回去处理写请求。可以认为这个值是用来平衡deadline对读写请求处理优先级状态的,这个值越大,则写请求越被滞后处理,越小,写请求就越可以获得趋近于读请求的优先级

front_merges

:当一个新请求进入队列的时候,如果其请求的扇区距离当前扇区很近,那么它就是可以被合并处理的。而这个合并可能有两种情况,一个是向当前位置后合并,另一种是向前合并。在某些场景下,向前合并是不必要的,那么我们就可以通过这个参数关闭向前合并。默认deadline支持向前合并,设置为0关闭

在调度一个request时,首先需要选择一个一个合适的cfq_group。Cfq调度器会为每个cfq_group分配一个时间片,当这个时间片耗尽之后,会选择下一个cfq_group。每个cfq_group都会分配一个vdisktime,并且通过该值采用红黑树对cfq_group进行排序。在调度的过程中,每次都会选择一个vdisktime最小的cfq_group进行处理。

一个cfq_group管理了7棵service tree,每棵service tree管理了需要调度处理的对象cfq_queue。因此,一旦cfq_group被选定之后,需要选择一棵service tree进行处理。这7棵service tree被分成了三大类,分别为RT、BE和IDLE。这三大类service tree的调度是按照优先级展开的

通过优先级可以很容易的选定一类Service tree。当一类service tree被选定之后,采用service time的方式选定一个合适的cfq_queue。每个Service tree是一棵红黑树,这些红黑树是按照service time进行检索的,每个cfq_queue都会维护自己的service time。分析到这里,我们知道,cfq算法通过每个cfq_group的vdisktime值来选定一个cfq_group进行服务,在处理cfq_group的过程通过优先级选择一个最需要服务的service tree。通过该Service tree得到最需要服务的cfq_queue。该过程在 cfq_select_queue 函数中实现

一个cfq_queue被选定之后,后面的过程和deadline算法有点类似。在选择request的时候需要考虑每个request的延迟等待时间,选择那种等待时间最长的request进行处理。但是,考虑到磁盘抖动的问题,cfq在处理的时候也会进行顺序批量处理,即将那些在磁盘上连续的request批量处理掉

cfq调度算法的参数

back_seek_max

:磁头可以向后寻址的更大范围,默认值为16M

back_seek_penalty

:向后寻址的惩罚系数。这个值是跟向前寻址进行比较的

fifo_expire_async

:设置异步请求的超时时间。同步请求和异步请求是区分不同队列处理的,cfq在调度的时候一般情况都会优先处理同步请求,之后再处理异步请求,除非异步请求符合上述合并处理的条件限制范围内。当本进程的队列被调度时,cfq会优先检查是否有异步请求超时,就是超过fifo_expire_async参数的限制。如果有,则优先发送一个超时的请求,其余请求仍然按照优先级以及扇区编号大小来处理

fifo_expire_sync

:这个参数跟上面的类似,区别是用来设置同步请求的超时时间

slice_idle

:参数设置了一个等待时间。这让cfq在切换cfq_queue或service tree的时候等待一段时间,目的是提高机械硬盘的吞吐量。一般情况下,来自同一个cfq_queue或者service tree的IO请求的寻址局部性更好,所以这样可以减少磁盘的寻址次数。这个值在机械硬盘上默认为非零。当然在固态硬盘或者硬RAID设备上设置这个值为非零会降低存储的效率,因为固态硬盘没有磁头寻址这个概念,所以在这样的设备上应该设置为0,关闭此功能

group_idle

:这个参数也跟上一个参数类似,区别是当cfq要切换cfq_group的时候会等待一段时间。在cgroup的场景下,如果我们沿用slice_idle的方式,那么空转等待可能会在cgroup组内每个进程的cfq_queue切换时发生。这样会如果这个进程一直有请求要处理的话,那么直到这个cgroup的配额被耗尽,同组中的其它进程也可能无法被调度到。这样会导致同组中的其它进程饿死而产生IO性能瓶颈。在这种情况下,我们可以将slice_idle = 0而group_idle = 8。这样空转等待就是以cgroup为单位进行的,而不是以cfq_queue的进程为单位进行,以防止上述问题产生

low_latency

:这个是用来开启或关闭cfq的低延时(low latency)模式的开关。当这个开关打开时,cfq将会根据target_latency的参数设置来对每一个进程的分片时间(slice time)进行重新计算。这将有利于对吞吐量的公平(默认是对时间片分配的公平)。关闭这个参数(设置为0)将忽略target_latency的值。这将使系统中的进程完全按照时间片方式进行IO资源分配。这个开关默认是打开的

target_latency

:当low_latency的值为开启状态时,cfq将根据这个值重新计算每个进程分配的IO时间片长度

quantum

:这个参数用来设置每次从cfq_queue中处理多少个IO请求。在一个队列处理事件周期中,超过这个数字的IO请求将不会被处理。这个参数只对同步的请求有效

slice_sync

:当一个cfq_queue队列被调度处理时,它可以被分配的处理总时间是通过这个值来作为一个计算参数指定的。公式为: time_slice = slice_sync + (slice_sync/5 * (4 – prio)) 这个参数对同步请求有效

slice_async

:这个值跟上一个类似,区别是对异步请求有效

slice_async_rq

:这个参数用来限制在一个slice的时间范围内,一个队列最多可以处理的异步请求个数。请求被处理的更大个数还跟相关进程被设置的io优先级有关

通常在Linux上使用的IO接口是同步方式的,进程调用 write / read 之后会阻塞陷入到内核态,直到本次IO过程完成之后,才能继续执行,下面介绍的异步IO则没有这种限制,但是当前Linux异步IO尚未成熟

目前Linux aio还处于较不成熟的阶段,只能在 O_DIRECT 方式下才能使用(glibc_aio),也就是无法使用默认的Page Cache机制

正常情况下,使用aio族接口的简要方式如下:

io_uring 是 2023 年 5 月发布的 Linux 5.1 加入的一个重大特性 —— Linux 下的全新的异步 I/O 支持,希望能彻底解决长期以来 Linux AIO 的各种不足

io_uring 实现异步 I/O 的方式其实是一个生产者-消费者模型:

逻辑卷管理

RAID0

RAID1

RAID5(纠错)

条带化

Linux系统性能调整:IO过程

Linux的IO调度

一个IO的传奇一生

理解inode

Linux 文件系统是怎么工作的?

Linux中Buffer cache性能问题一探究竟

Asynchronous I/O and event notification on linux

AIO 的新归宿:io_uring

查询每个用户的io使用linux的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于查询每个用户的io使用linux,如何查询每个用户的IO使用情况(Linux),如何找出Linux系统高IO的思路总结,/tmp/Bonnie.16528,Linux 磁盘IO的信息别忘了在本站进行查找喔。


数据运维技术 » 如何查询每个用户的IO使用情况(Linux) (查询每个用户的io使用linux)