31 | 套路篇：磁盘 I/O 性能优化的几个思路
该思维导图由 AI 生成，仅供参考
I/O 基准测试
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了磁盘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-30322 - JohnT3e现在越来越多系统使用SSD，它和HDD相比还是有较大差异的。经常看到某某系统针对于SSD优化，那这边的有哪些优化点？之前看过一个系列的文章（http://codecapsule.com/2014/02/12/coding-for-ssds-part-1-introduction-and-table-of-contents/），从硬件架构到编程设计比较详细的介绍了如何优化，配合这里的思路看，加深了理解。
作者回复: 赞，谢谢分享
2019-01-3012 
我来也[D31打卡] 平常没机会从系统层面优化磁盘性能参数。 能做的就是减少磁盘写入，以及错峰操作磁盘。 比如在凌晨或业务低谷时，压缩备份日志，减少对正常业务的影响。 文中的这么多底层参数，只能望而生叹。😄作者回复: 嗯嗯，一般来说，从应用层优化可以满足大部分需求了
2019-01-317
风动草老师好！我们最近发生了一件非常诡异的问题，mysql从普通票迁移到ssd后，内存使用一直飙升，迁回普通票又正常，mysql内存配置是操作系统的20%。希望老师能给个分析建议，给你发个大红包，实在没办法了。作者回复: 飙升到多少？超过20%吗？可以考虑检查buffer的配置项、临时表大小等看看内存都耗费在哪里了 https://dev.mysql.com/doc/refman/5.7/en/memory-summary-tables.html
2019-04-294
xfan谢谢@ninuxer推荐 《深入Linux内核架构》，我也去补一补作者回复: 👍
2019-01-3024
梁中华针对Ssd 的特性和注意事项可以考虑单开一章作者回复: 嗯嗯，其实抠细节的话，每一条都可以单独开一章了。篇幅有限，只能大略介绍一下
2019-01-303- 2xshu老师好，如何修改磁盘的io调度算法哇？
作者回复: 修改 /sys/block/{DEVICE-NAME}/queue/scheduler
2019-01-3033 
小橙子slat指的是II从创建到提交到内核的时间吧 clat的指的是每个收到到完成的时间吧 感觉这里解释的有点没看明白 请教下同步IO为啥ClAT为0作者回复: 看英文注释，一个是Submission，一个是Completion。 同步ClAT为0是因为两个操作算作是一个（第一个），第二个当然数值上就是0了
2019-02-221
麋鹿在泛舟所以请问如何安全的使用fio呢， 是单独使用一个device用来测试fio么？作者回复: 安全的使用fio是什么意思？一般来说，测试时别在系统盘或者存有重要的磁盘中来操作
2019-01-3031- 李明华大神好： 我在生产的一台新上架的服务器上，测试了随机读的磁盘指标 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
