linux factor 速度,Linux性能优化4

notes

Linux中一切皆文件

文件有两个数据结构,索引节点(index node)和目录项(directory entry),用来接入文件的元信息和目录结构。

索引节点是每个文件的唯一标志,而目录项维护的正是文件系统的树状结构。目录项和索引节点的关系是多对一,一个文件可以有多个别名。

VFS 内部又通过目录项、索引节点、逻辑块以及超级块等数据结构,来管理文件。

目录项,记录了文件的名字,以及文件与其他目录项之间的目录关系。

索引节点,记录了文件的元数据。

逻辑块,是由连续磁盘扇区构成的最小读写单元,用来存储文件数据。

超级块,用来记录文件系统整体的状态,如索引节点和逻辑块的使用情况等。

目录项是一个内存缓存;而超级块、索引节点和逻辑块,都是存储在磁盘中的持久化数据。

机械磁盘HDD,需要寻址。最小读单位512B。

固态硬盘SSD,不需要寻址。最小读单位是页,通常是4K,8K。

固态硬盘不需要寻址为什么随机IO也比连续IO慢很多

对固态磁盘来说,虽然它的随机性能比机械硬盘好很多,但同样存在“先擦除再写入”的限制。随机读写会导致大量的垃圾回收,所以相对应的,随机 I/O 的性能比起连续 I/O 来,也还是差了很多。

此外,连续 I/O 还可以通过预读的方式,来减少 I/O 请求的次数,这也是其性能优异的一个原因。很多性能优化的方案,也都会从这个角度出发,来优化 I/O 性能。

通过快:处在文件系统和磁盘驱动中间的一个块设备抽象层。

IO栈,由上到下分为三个层次,分别是文件系统层、通用块层和设备层。

98c00dbc3b49

image.png

文件系统层,包括虚拟文件系统和其他各种文件系统的具体实现。它为上层的应用程序,提供标准的文件访问接口;对下会通过通用块层,来存储和管理磁盘数据。通用块层,包括块设备 I/O 队列和 I/O 调度器。它会对文件系统的 I/O 请求进行排队,再通过重新排序和请求合并,然后才要发送给下一级的设备层。设备层,包括存储设备和相应的驱动程序,负责最终物理设备的 I/O 操作。

性能指标:

使用率,是指磁盘处理 I/O 的时间百分比。过高的使用率(比如超过 80%),通常意味着磁盘 I/O 存在性能瓶颈。

饱和度,是指磁盘处理 I/O 的繁忙程度。过高的饱和度,意味着磁盘存在严重的性能瓶颈。当饱和度为 100% 时,磁盘无法接受新的 I/O 请求。

IOPS(Input/Output Per Second),是指每秒的 I/O 请求数。

吞吐量,是指每秒的 I/O 请求大小。

响应时间,是指 I/O 请求从发出到收到响应的间隔时间。

mysql explain

# 切换到test库

mysql> use test;

# 执行explain命令

mysql> explain select * from products where productName='geektime';

+----+-------------+----------+------+---------------+------+---------+------+-------+-------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+----------+------+---------------+------+---------+------+-------+-------------+

| 1 | SIMPLE | products | ALL | NULL | NULL | NULL | NULL | 10000 | Using where |

+----+-------------+----------+------+---------------+------+---------+------+-------+-------------+

1 row in set (0.00 sec)

select_type 表示查询类型,而这里的 SIMPLE 表示此查询不包括 UNION 查询或者子查询;

table 表示数据表的名字,这里是 products;

type 表示查询类型,这里的 ALL 表示全表查询,但索引查询应该是 index 类型才对;

possible_keys 表示可能选用的索引,这里是 NULL;

key 表示确切会使用的索引,这里也是 NULL;

rows 表示查询扫描的行数,这里是 10000。

utility

有时候用df查看磁盘空间,发现剩余空间还有很多,却报空间不足。

可以尝试

$ df -i /dev/sda1

Filesystem Inodes IUsed IFree IUse% Mounted on

/dev/sda1 3870720 157460 3713260 5% /

可以发现索引结果空间不足,很可能是因为过多的小文件导致的。

内核使用 Slab 机制,管理目录项和索引节点的缓存。/proc/meminfo 只给出了 Slab 的整体大小。

想要查看各种Slab缓存,需要查看/proc/slabinfo

$ cat /proc/slabinfo | grep -E '^#|dentry|inode'

# name : tunables : slabdata

xfs_inode 0 0 960 17 4 : tunables 0 0 0 : slabdata 0 0 0

...

ext4_inode_cache 32104 34590 1088 15 4 : tunables 0 0 0 : slabdata 2306 2306 0hugetlbfs_inode_cache 13 13 624 13 2 : tunables 0 0 0 : slabdata 1 1 0

sock_inode_cache 1190 1242 704 23 4 : tunables 0 0 0 : slabdata 54 54 0

shmem_inode_cache 1622 2139 712 23 4 : tunables 0 0 0 : slabdata 93 93 0

proc_inode_cache 3560 4080 680 12 2 : tunables 0 0 0 : slabdata 340 340 0

inode_cache 25172 25818 608 13 2 : tunables 0 0 0 : slabdata 1986 1986 0

dentry 76050 121296 192 21 1 : tunables 0 0 0 : slabdata 5776 5776 0

lsof 命令加上 -i 选项,找出 TCP socket 对应的 TCP 连接信息

# 由于这两个容器共享同一个网络命名空间,所以我们只需要进入app的网络命名空间即可

$ PID=$(docker inspect --format {{.State.Pid}} app)

# -i表示显示网络套接字信息

$ nsenter --target $PID --net -- lsof -i

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

redis-ser 9085 systemd-network 6u IPv4 15447972 0t0 TCP localhost:6379 (LISTEN)

redis-ser 9085 systemd-network 8u IPv4 15448709 0t0 TCP localhost:6379->localhost:32996 (ESTABLISHED)

python 9181 root 3u IPv4 15448677 0t0 TCP *:http (LISTEN)

python 9181 root 5u IPv4 15449632 0t0 TCP localhost:32996->localhost:6379 (ESTABLISHED)

strace观察系统调用情况,加-e

$ strace -f -p 9085 -T -tt -e fdatasync

strace: Process 9085 attached with 4 threads

[pid 9085] 14:22:52.013547 fdatasync(7) = 0 <0.007112>

[pid 9085] 14:22:52.022467 fdatasync(7) = 0 <0.008572>

[pid 9085] 14:22:52.032223 fdatasync(7) = 0 <0.006769>

...

[pid 9085] 14:22:52.139629 fdatasync(7) = 0 <0.008183>

strace 对于多线程程序,需要加-f,这样不会漏掉所有线程的的数据

$ strace -f -p 27458

[pid 28014] read(38, "934EiwT363aak7VtqF1mHGa4LL4Dhbks"..., 131072) = 131072

[pid 28014] read(38, "hSs7KBDepBqA6m4ce6i6iUfFTeG9Ot9z"..., 20480) = 20480

[pid 28014] read(38, "NRhRjCSsLLBjTfdqiBRLvN9K6FRfqqLm"..., 131072) = 131072

[pid 28014] read(38, "AKgsik4BilLb7y6OkwQUjjqGeCTQTaRl"..., 24576) = 24576

[pid 28014] read(38, "hFMHx7FzUSqfFI22fQxWCpSnDmRjamaW"..., 131072) = 131072

[pid 28014] read(38, "ajUzLmKqivcDJSkiw7QWf2ETLgvQIpfC"..., 20480) = 20480

mysql : show full processlist命令就可以看到正在执行的SQL语句

98c00dbc3b49

image.png

98c00dbc3b49

image.png

tools

iostat 是最常用的磁盘 I/O 性能观测工具,它提供了每个磁盘的使用率、IOPS、吞吐量等各种常见的性能指标,当然,这些指标实际上来自 /proc/diskstats。

# -d -x表示显示所有磁盘I/O的指标

$ iostat -d -x 1

Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util

loop0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

loop1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

98c00dbc3b49

image.png

这些指标中,要注意:

%util ,就是我们前面提到的磁盘 I/O 使用率;

r/s+ w/s ,就是 IOPS;

rkB/s+wkB/s ,就是吞吐量;

r_await+w_await ,就是响应时间。

在观测指标时,也别忘了结合请求的大小( rareq-sz 和 wareq-sz)一起分析。

从 iostat 并不能直接得到磁盘饱和度。事实上,饱和度通常也没有其他简单的观测方法,不过可以把观测到的,平均请求队列长度或者读写请求完成的等待时间,跟基准测试的结果(比如通过 fio)进行对比,综合评估磁盘的饱和情况。

pidstat 加上 -d 参数,你就可以看到进程的 I/O 情况

$ pidstat -d 1

13:39:51 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command

13:39:52 102 916 0.00 4.00 0.00 0 rsyslogd

内容有:

用户 ID(UID)和进程 ID(PID) 。

每秒读取的数据大小(kB_rd/s) ,单位是 KB。

每秒发出的写请求数据大小(kB_wr/s) ,单位是 KB。

每秒取消的写请求数据大小(kB_ccwr/s) ,单位是 KB。

块 I/O 延迟(iodelay),包括等待同步块 I/O 和换入块 I/O 结束的时间,单位是时钟周期。

iotop。它是一个类似于 top 的工具,你可以按照 I/O 大小对进程排序,然后找到 I/O 较大的那些进程。

$ iotop

Total DISK READ : 0.00 B/s | Total DISK WRITE : 7.85 K/s

Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s

TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND

15055 be/3 root 0.00 B/s 7.85 K/s 0.00 % 0.00 % systemd-journald

filetop

# 切换到工具目录

$ cd /usr/share/bcc/tools

# -C 选项表示输出新内容时不清空屏幕

$ ./filetop -C

TID COMM READS WRITES R_Kb W_Kb T FILE

514 python 0 1 0 2832 R 669.txt

514 python 0 1 0 2490 R 667.txt

514 python 0 1 0 2685 R 671.txt

514 python 0 1 0 2392 R 670.txt

514 python 0 1 0 2050 R 672.txt

...

TID COMM READS WRITES R_Kb W_Kb T FILE

514 python 2 0 5957 0 R 651.txt

514 python 2 0 5371 0 R 112.txt

514 python 2 0 4785 0 R 861.txt

514 python 2 0 4736 0 R 213.txt

514 python 2 0 4443 0 R 45.txt

filetop 输出了 8 列内容,分别是线程 ID、线程命令行、读写次数、读写的大小(单位 KB)、文件类型以及读写的文件名称。

opensnoop

$ opensnoop

12280 python 6 0 /tmp/9046db9e-fe25-11e8-b13f-0242ac110002/650.txt

12280 python 6 0 /tmp/9046db9e-fe25-11e8-b13f-0242ac110002/651.txt

12280 python 6 0 /tmp/9046db9e-fe25-11e8-b13f-0242ac110002/652.txt

可以动态跟踪内核中的 open 系统调用。

log

io问题一般都是先top发展iowait比较高,然后iostat看是哪个进程比较高,然后再通过strace,lsof找出进程在读写的具体文件,然后对应的分析

应用程序优化

第一,可以用追加写代替随机写,减少寻址开销,加快 I/O 写的速度。

第二,可以借助缓存 I/O ,充分利用系统缓存,降低实际 I/O 的次数。

第三,可以在应用程序内部构建自己的缓存,或者用 Redis 这类外部缓存系统。这样,一方面,能在应用程序内部,控制缓存的数据和生命周期;另一方面,也能降低其他应用程序使用缓存对自身的影响。比如,在前面的 MySQL 案例中,我们已经见识过,只是因为一个干扰应用清理了系统缓存,就会导致 MySQL 查询有数百倍的性能差距(0.1s vs 15s)。再如, C 标准库提供的 fopen、fread 等库函数,都会利用标准库的缓存,减少磁盘的操作。而你直接使用 open、read 等系统调用时,就只能利用操作系统提供的页缓存和缓冲区等,而没有库函数的缓存可用。

第四,在需要频繁读写同一块磁盘空间时,可以用 mmap 代替 read/write,减少内存的拷贝次数。

第五,在需要同步写的场景中,尽量将写请求合并,而不是让每个请求都同步写入磁盘,即可以用 fsync() 取代 O_SYNC。

第六,在多个应用程序共享相同磁盘时,为了保证 I/O 不被某个应用完全占用,推荐你使用 cgroups 的 I/O 子系统,来限制进程 / 进程组的 IOPS 以及吞吐量。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值