Linux 性能优化实战
倪朋飞
资深 Linux 专家,Kubernetes 项目维护者
87256 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 65 讲
结束语 (1讲)
Linux 性能优化实战
15
15
1.0x
00:00/00:00
登录|注册

31 | 套路篇:磁盘 I/O 性能优化的几个思路

检测磁盘的硬件问题
调整磁盘队列的长度
增大磁盘的预读数据
对应用程序的数据进行磁盘级别的隔离
选择最适合的 I/O 调度算法
使用 RAID
换用性能更好的磁盘
使用内存文件系统 tmpfs
优化文件系统的缓存
优化文件系统的配置选项
选择最适合的文件系统
使用 ionice 调整进程的 I/O 调度优先级
使用 cgroups 的 I/O 子系统
合并写请求
使用 mmap 代替 read/write
构建自己的缓存
缓存 I/O
追加写代替随机写
测试报告示例
常见场景的测试方法
安装方法
磁盘优化
文件系统优化
应用程序优化
I/O 的重放
Flexible I/O Tester
I/O 性能优化
I/O 基准测试
I/O 性能优化的几个思路

该思维导图由 AI 生成,仅供参考

你好,我是倪朋飞。
上一节,我们一起回顾了常见的文件系统和磁盘 I/O 性能指标,梳理了核心的 I/O 性能观测工具,最后还总结了快速分析 I/O 性能问题的思路。
虽然 I/O 的性能指标很多,相应的性能分析工具也有好几个,但理解了各种指标的含义后,你就会发现它们其实都有一定的关联。
顺着这些关系往下理解,你就会发现,掌握这些常用的瓶颈分析思路,其实并不难。
找出了 I/O 的性能瓶颈后,下一步要做的就是优化了,也就是如何以最快的速度完成 I/O 操作,或者换个思路,减少甚至避免磁盘的 I/O 操作。
今天,我就来说说,优化 I/O 性能问题的思路和注意事项。

I/O 基准测试

按照我的习惯,优化之前,我会先问自己, I/O 性能优化的目标是什么?换句话说,我们观察的这些 I/O 性能指标(比如 IOPS、吞吐量、延迟等),要达到多少才合适呢?
事实上,I/O 性能指标的具体标准,每个人估计会有不同的答案,因为我们每个人的应用场景、使用的文件系统和物理磁盘等,都有可能不一样。
为了更客观合理地评估优化效果,我们首先应该对磁盘和文件系统进行基准测试,得到文件系统或者磁盘 I/O 的极限性能。
fio(Flexible I/O Tester)正是最常用的文件系统和磁盘 I/O 性能基准测试工具。它提供了大量的可定制化选项,可以用来测试,裸盘或者文件系统在各种场景下的 I/O 性能,包括了不同块大小、不同 I/O 引擎以及是否使用缓存等场景。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了磁盘I/O性能优化的重要性和方法。首先介绍了使用Flexible I/O Tester(fio)进行基准测试的重要性,以及如何结合blktrace实现对应用程序I/O模式的基准测试。接着从应用程序、文件系统和磁盘角度分别探讨了优化思路。在应用程序优化方面,提到了追加写、缓存I/O、内部缓存、mmap、合并写请求等方法。文件系统优化方面,强调了选择适合负载场景的文件系统、调整文件系统配置选项、优化文件系统缓存等。而在磁盘优化方面,强调了使用SSD替代HDD、RAID、选择适合的I/O调度算法、磁盘级别的隔离等方法。总结指出,优化I/O性能需要综合考虑整个系统的不同层面,同时提出了在实际操作中应该先找出最重要的问题,然后再进行优化的建议。文章内容详实,为读者提供了优化磁盘I/O性能的实用思路和工具,对技术人员具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Linux 性能优化实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(36)

  • 最新
  • 精选
  • ninuxer
    打卡day32 找io问题,有了一定的套路,但是针对这节写的优化的东西,吸收起来还是比较费劲,比如:为什么要调这个参数,而不是其他参数?为什么参数设置这个值而不是其他值? 关于设置值可以通过fio去测试,io性能提升了,满足要求,就可以了,但是io好了,会不会带来其他方面的影响? 综上所述,还是基础不牢,最近已经开始啃《深入Linux内核架构》,不忘初心,砥砺前行!

    作者回复: 嗯嗯,是的,并且这些东西也没法在这儿展开来讲,每一块涉及的东西都比较多。实际在操作之前,还需要去了解背后的原理,特别是要注意会不会带来其他不好的影响(比如优化了I/O,CPU和内存使用可能上升)。

    2019-01-30
    3
    22
  • JohnT3e
    现在越来越多系统使用SSD,它和HDD相比还是有较大差异的。经常看到某某系统针对于SSD优化,那这边的有哪些优化点?之前看过一个系列的文章(http://codecapsule.com/2014/02/12/coding-for-ssds-part-1-introduction-and-table-of-contents/),从硬件架构到编程设计比较详细的介绍了如何优化,配合这里的思路看,加深了理解。

    作者回复: 赞,谢谢分享

    2019-01-30
    12
  • 我来也
    [D31打卡] 平常没机会从系统层面优化磁盘性能参数。 能做的就是减少磁盘写入,以及错峰操作磁盘。 比如在凌晨或业务低谷时,压缩备份日志,减少对正常业务的影响。 文中的这么多底层参数,只能望而生叹。😄

    作者回复: 嗯嗯,一般来说,从应用层优化可以满足大部分需求了

    2019-01-31
    7
  • 风动草
    老师好!我们最近发生了一件非常诡异的问题,mysql从普通票迁移到ssd后,内存使用一直飙升,迁回普通票又正常,mysql内存配置是操作系统的20%。希望老师能给个分析建议,给你发个大红包,实在没办法了。

    作者回复: 飙升到多少?超过20%吗?可以考虑检查buffer的配置项、临时表大小等看看内存都耗费在哪里了 https://dev.mysql.com/doc/refman/5.7/en/memory-summary-tables.html

    2019-04-29
    4
  • xfan
    谢谢@ninuxer推荐 《深入Linux内核架构》,我也去补一补

    作者回复: 👍

    2019-01-30
    2
    4
  • 梁中华
    针对Ssd 的特性和注意事项可以考虑单开一章

    作者回复: 嗯嗯,其实抠细节的话,每一条都可以单独开一章了。篇幅有限,只能大略介绍一下

    2019-01-30
    3
  • 2xshu
    老师好,如何修改磁盘的io调度算法哇?

    作者回复: 修改 /sys/block/{DEVICE-NAME}/queue/scheduler

    2019-01-30
    3
    3
  • 小橙子
    slat指的是II从创建到提交到内核的时间吧 clat的指的是每个收到到完成的时间吧 感觉这里解释的有点没看明白 请教下同步IO为啥ClAT为0

    作者回复: 看英文注释,一个是Submission,一个是Completion。 同步ClAT为0是因为两个操作算作是一个(第一个),第二个当然数值上就是0了

    2019-02-22
    1
  • 麋鹿在泛舟
    所以请问如何安全的使用fio呢, 是单独使用一个device用来测试fio么?

    作者回复: 安全的使用fio是什么意思?一般来说,测试时别在系统盘或者存有重要的磁盘中来操作

    2019-01-30
    3
    1
  • 李明华
    大神好: 我在生产的一台新上架的服务器上,测试了随机读的磁盘指标 sudo fio -name=randread -direct=1 -iodepth=64 -rw=randread -ioengine=libaio -bs=4k -size=2G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/sda --------------------------------------------------------------------------- 结果 slat (usec): min=2, max=151, avg=13.73, stdev= 7.29 clat (usec): min=37, max=948718, avg=20301.72, stdev=27583.37 lat (usec): min=44, max=948725, avg=20315.79, stdev=27583.38 clat percentiles (usec): | 1.00th=[ 109], 5.00th=[ 2040], 10.00th=[ 3163], 20.00th=[ 5080], | 30.00th=[ 6783], 40.00th=[ 8455], 50.00th=[ 10552], 60.00th=[ 14222], | 70.00th=[ 19268], 80.00th=[ 28181], 90.00th=[ 47449], 95.00th=[ 70779], | 99.00th=[137364], 99.50th=[170918], 99.90th=[252707], 99.95th=[287310], | 99.99th=[367002] bw ( KiB/s): min=10184, max=17664, per=99.73%, avg=12564.09, stdev=1256.26, samples=332 iops : min= 2546, max= 4418, avg=3141.02, stdev=314.09, samples=332 从而可以看出 ,随机读的极限也就在 iops:4418 读吞吐量在 17.25M IO使用率也差不多极限了 同时iostat 也观察了磁盘的指标 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 sda 3876.00 0.00 15504.00 0.00 0.00 0.00 0.00 0.00 16.48 0.00 55.94 4.00 0.00 0.26 100.00 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 sda 3846.00 5.00 15384.00 1064.00 0.00 0.00 0.00 0.00 16.46 2521.40 68.18 4.00 212.80 0.26 100.00 读IOPS在3800-3900 吞吐量在15.5M IO使用率已经100% 而我生产(大量小文件场景,应该是随机IO)使用promethes的node_exporter采集的指标中 读吞吐量 可以达到73M+ 这个感觉差的有点大 ??? 这个是哪里不对吗??? iops 不高 最多两千多 +++++++++++++++++++++++++++++++++++++++++++++++++++ 另外就是 我通过监控发现 IO使用率 有时候iops和吞吐量不多 范围100% 而多的反问不到100% cpu也正常 不搞 我还能通过其他方面查看问题吗

    作者回复: 检查一下是不是指标的计算方法有问题?

    2019-10-18
收起评论
显示
设置
留言
36
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部