24 | 基础篇:Linux 磁盘I/O是怎么工作的(上)
24 | 基础篇:Linux 磁盘I/O是怎么工作的(上)
讲述:冯永吉
时长10:45大小9.82M
磁盘
通用块层
I/O 栈
小结
思考
赞 28
提建议
精选留言(38)
- coyang2019-01-151.用iostat看磁盘的await,utils,iops,bandwidth 2.用smartctl看磁盘的health status 3.用iotop/pidstat找出持续读写的进程做优化41
- JohnT3e2019-01-14工作中经常看到使用多线程读写单个磁盘中不同文件的实现,个人认为这种方法并不能有效地提高性能,因为每个线程读写磁盘的位置可能差异很大,且每个线程的数据的空间局部性和时间局部性存在差异,导致磁盘调度优化不足。不知道对不对
作者回复: 实际上这是可以提高性能的,一方面,文件的读写是有操作系统缓存的,每次文件读写调用并不是立刻对应一个磁盘IO操作,在文件系统和块设备层依然可以作很多优化(比如最基本的排序、合并)。另一方面,如果是逐个来写的话,多个线程的工作就有可能被这一系列的文件读写阻塞,而分开来每个线程就只需要阻塞自己所读写的文件(假设采用阻塞I/O)
29 - Utopia2019-10-27作为一个非科班出身,学习一年的程序员来说,看到这里,犹如打穿了任督二脉,叹为观止,太过瘾了。23
- 金波2019-01-14有个问题一直没弄明白,想借此机会请老师解答下, 大家经常用select来多路复用读写管道,socket等类型的文件, 请问select可否用于普通磁盘文件的读写? 不行的话为什么? 多谢
作者回复: 碰到这种问题最好的方法是查手册,比如在 select 的文档(https://linux.die.net/man/3/select)中你可以看到: File descriptors associated with regular files shall always select true for ready to read, ready to write, and error conditions. 也就是普通文件读、写总是 Ready 的,所以用 select 也就没有意义。当然,在编程接口上,你可以还是调用它的。
16 - DJH2019-01-14有一个纠正一下:ISCSI访问的是块设备,不是NAS。
作者回复: 是的,这里有些不准确,原来的意思是想表达网络存储,用 NAS 这样的专业术语就不准确了。谢谢指出。
共 2 条评论12 - 萨拉热窝的棒小伙儿2019-01-14老师,想问一下,如果申请的测试环境资源与生产环境资源是有差异的,那么在测试环境上做性能测试的话,是否可以按照资源差异同比例缩小,这个通过准则? 例如,生产环境10个cpu,5G 内存,期望能并发100用户,满足1秒响应。。。测试环境5个cpu,2.5G,,那么并发50用户,满足1秒响应就行了,,有这个说法嘛?
作者回复: 没有,性能跟资源之间的关系不是线性的
共 2 条评论10 - black_mirror2019-01-14倪老师,您好: 1.从内核版本2.6.32以后,磁盘io调度算法好像只有3种,文中提到的none算法系统层没看到: cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq] 2.在运行db的环境中,如MySQL,mysql的程序运行在机械硬盘上,mysql的数据目录是挂载在dell存储上(2个控制器有缓存),存储也是由机械硬盘组成,做的raid10/raid6 通过sysbench压测,其它环境保持一致,仅修改磁盘调度算法为noop/deadline: 进行只读、读写测试,分别测试3轮,每轮10分钟,求平均值比较,50个并发线程,50张表每张100w数据,oltp场景,每轮测试后,清空系统缓存和重启mysql程序 压测结果:只读场景noop比deadline好一点点,读写场景deadline比noop好一点点 请问老师这种场景下,应该选择noop 还是 deadline?因为看到下面一篇文章有些疑惑 Choosing a Disk Scheduling Algorithm The disk controller receives requests from the operating system and processes them in an order determined by a scheduling algorithm. Sometimes changing this algorithm can improve disk performance. For other hardware and workloads, it may not make a difference. The best way to decide is to test them out yourself on your workload. Dead‐ line and completely fair queueing (CFQ) both tend to be good choices. There are a couple of situations where the noop scheduler (a contraction of “no-op” is the best choice): if you’re in a virtualized environment, use the noop scheduler. The noop scheduler basically passes the operations through to the underlying disk controller as quickly as possible. It is fastest to do this and let the real disk controller handle any reordering that needs to happen. Similarly, on SSDs, the noop scheduler is generally the best choice. SSDs don’t have the same locality issues that spinning disks do. Finally, if you’re using a RAID controller with caching, use noop. The cache behaves like an SSD and will take care of propagating the writes to the disk efficiently. 选择磁盘调度算法 磁盘控制器接收来自操作系统的请求,并按调度算法确定的顺序处理它们。有时更改此算法可以提高磁盘性能。对于其他硬件和工作负载,它可能没有什么区别。决定的最佳方法是自己测试工作量。deadline和CFQ往往都是不错的选择。 有几种情况下,noop调度程序是最佳选择:如果您处于虚拟化环境中,请使用noop调度程序。 noop调度程序基本上将操作尽快传递到底层磁盘控制器。这样做最快,让真正的磁盘控制器处理需要发生的任何重新排序。同样,在SSD上,noop调度程序通常是最佳选择。 SSD没有与旋转磁盘相同的位置问题。 最后,如果您使用带有缓存的RAID控制器,请使用noop。缓存的行为类似于SSD,并且会有效地将写入传播到磁盘。展开
作者回复: 1. none 主要用在虚拟机中,跟发行版有关系 2. noop和deadline都可以,不过简单的测试跟应用程序的访问模式很可能不一致,建议拿应用程序的逻辑来测试(或者使用I/O重放的方法) https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-diskio.html 有一些优化的建议
6 - Cranliu2019-01-14最最常用的是iostat了吧?还有pidstat,sar等
作者回复: 是的 这三个都是最常用的
5 - 我来也2019-01-14[D24打卡] 以前其实并没太注意到磁盘I/O的性能. 平常就正常存储下程序的日志,程序的日志量也不大. 但是有一次在某云上,生产环境中的程序卡了持续3分多钟. 后来才发现是程序中有人打了一个超级大(其实也就2-3M)的日志,😁. 然后程序就在这里阻塞了几分钟.展开共 2 条评论4
- 小老鼠2019-01-14固态硬盘有扇区和磁道吗?
作者回复: 没有,SSD读写的基本单位是页
4 - 腾达2019-01-16系统从上到下一级级都有缓存,如果另外一个进程更新了数据,如何做到缓存失效的?
作者回复: 这就是内存回收的逻辑了,比如 LRU 算法
3 - Adrian2021-09-03感觉读法是否有问题,RAID10,是RAID1和RAID0组合起来的,我觉得应该读作RAID一零 而不是读作RAID十共 1 条评论2
- 划时代2019-01-14打卡总结2
- Podman2021-12-16请教: 所以进程的I/O请求进入文件系统后,会先访问buffer,如果buffer中存在请求内容,则直接返回请求 如果没有,那么才会从通用块层陷入磁盘设备做I/O,并返回结果给到buffer,进而返回给进程。 这样理解对么展开共 2 条评论1
- 肘子哥2019-02-23smartctl工具有缺陷,对于虚拟机和做了raid的机器是失效的
作者回复: 嗯嗯,谢谢指出
共 2 条评论1 - nestle2022-11-04 来自广东每种类型的存储设备都有各自的接口协议,需要一套特定的代码进行控制,这个代码就是设备驱动程序,是包含在内核代码中的。通用块层向下就是和驱动程序打交道,真正控制物理设备的是设备驱动程序。 请问这样的理解对吗?
- 陌兮2022-06-23这一章看的是真的舒服,太过瘾了
- Sudouble2022-03-27工程师们为了速度够,还真是想了各种各样的办法。一点点造就了现在的操作系统,向以前的工程师们致敬!
- allen2021-11-05老师,我今天遇到个问题,有个oracle数据库服务器,用dd命令写磁盘时,分别用直接落盘 闲着缓存再落盘的方式,发现写缓存的方式时,前段应用服务器就出现延时,不经过缓存直接写硬盘事就一切正常,服务器配置全新,256G没错,请问是啥原因?共 1 条评论
- 言十年2021-08-29其中,通用块层是 Linux 磁盘 I/O 的核心。向上,它为文件系统和应用程序,提供访问了块设备的标准接口;向下,把各种异构的磁盘设备,抽象为统一的块设备,并会对文件系统和应用程序发来的 I/O 请求进行重新排序、请求合并等,提高了磁盘访问的效率。 不是文件系统层提供向上的接口么?怎么是通用块层?块层在文件系统层下面呢呀......共 2 条评论