细数SMR硬盘上装系统的坑
最近在办公用的电脑上装了双系统(Deepin),由于默认内核不识别板载的固态硬盘(NVMe),所以只能把Deepin放在机械硬盘(SATA)上。本来以为只是慢一点,结果用的时候才发现IO负载稍微高一点就会卡成狗。查了一下硬件型号后秒懂:这货居然是希捷的叠瓦盘(ST2000DM008)。。。无奈这不是个人电脑不好换硬件,所以只能硬着头皮跟它死磕了。
先声明一下:此处的操作纯属实验,目的就是为了检验叠瓦盘上跑系统到底能比非叠瓦盘(CMR)差多少。各位如果有条件不用叠瓦盘的,就不要自虐了,赶紧换个靠谱的固态或者非叠瓦盘,毕竟数据无价,数据备份和恢复也很费时间。
由于叠瓦盘在覆盖写入时存在写入放大的问题,而系统分区(一般是根分区)又常常存放了各类需要频繁更新的临时文件和日志文件,所以首先要考虑的就是降低这两类文件的读写频率。因此修改 /etc/fstab ,挂载 tmpfs 至 /tmp ,并且修改根分区的挂载参数为 discard,noatime ;叠瓦盘上的其他分区的挂载参数也可改为 discard,noatime ,但如果访问不频繁的话也可不修改。此外,在日志服务的守护进程(journald)的配置文件(/etc/systems/journald.conf)中,将 System MaxUse 一行的数值设为 64M (或者更小的值),并将MaxLevelStore 一行的值设为 notice,这样可以减小日志文件的体积和写入日志的频率。 另一个就是禁用不必要的后台服务。目前各大Debian系的发行版普遍启用了自动更新服务,这个服务在后台运行时也会产生频繁IO,有时还会阻碍关机,所以干脆直接禁用它,需要的时候再手动检查更新。具体操作:执行命令
sudo systemctl disable apt-daily.timer
和
sudo systemctl disable apt-daily-upgrade.timer
即可。
关于软件安装和更新,这里也有一个隐藏的坑:部分dpkg软件包在安装时的postinst阶段会申请更新MIME数据库,此时系统会执行 update-mime-database 这个命令。此命令会频繁调用 fsync 函数并产生大量琐碎的IO,导致安装阶段系统假死。此时若用htop等进程管理器查看IO时会发现它的IO量并不大(~50 KB/s),但由于它更新的对象都是零散的小文件,加上叠瓦盘的写入放大效应,实际落到硬盘磁头上的负荷可能非常重,以至于其他进程的IO被完全阻塞(因apt/dpkg一般是以root权限运行的)。因此,在软件作者提供靠谱的解决方案之前,可以在系统的环境变量列表中添加一项 PKGSYSTEM_ENABLE_FSYNC=0 ,使得软件包管理器将fsync指令推迟到所有软件包安装完成之后执行。这样一来可以避免安装多个软件包时多次调用 update-mime-database 导致的硬盘高负载问题。
最后一个就是Linux饱受诟病的OOM机制,对于内存较小的机器来说问题尤其突出。为了避免因内存不足导致的高IO(源自频繁换页)卡死用户界面,建议安装 earlyoom 这个软件,在内存即将耗尽之时主动终止占用内存最多的进程。
先声明一下:此处的操作纯属实验,目的就是为了检验叠瓦盘上跑系统到底能比非叠瓦盘(CMR)差多少。各位如果有条件不用叠瓦盘的,就不要自虐了,赶紧换个靠谱的固态或者非叠瓦盘,毕竟数据无价,数据备份和恢复也很费时间。
由于叠瓦盘在覆盖写入时存在写入放大的问题,而系统分区(一般是根分区)又常常存放了各类需要频繁更新的临时文件和日志文件,所以首先要考虑的就是降低这两类文件的读写频率。因此修改 /etc/fstab ,挂载 tmpfs 至 /tmp ,并且修改根分区的挂载参数为 discard,noatime ;叠瓦盘上的其他分区的挂载参数也可改为 discard,noatime ,但如果访问不频繁的话也可不修改。此外,在日志服务的守护进程(journald)的配置文件(/etc/systems/journald.conf)中,将 System MaxUse 一行的数值设为 64M (或者更小的值),并将MaxLevelStore 一行的值设为 notice,这样可以减小日志文件的体积和写入日志的频率。 另一个就是禁用不必要的后台服务。目前各大Debian系的发行版普遍启用了自动更新服务,这个服务在后台运行时也会产生频繁IO,有时还会阻碍关机,所以干脆直接禁用它,需要的时候再手动检查更新。具体操作:执行命令
sudo systemctl disable apt-daily.timer
和
sudo systemctl disable apt-daily-upgrade.timer
即可。
关于软件安装和更新,这里也有一个隐藏的坑:部分dpkg软件包在安装时的postinst阶段会申请更新MIME数据库,此时系统会执行 update-mime-database 这个命令。此命令会频繁调用 fsync 函数并产生大量琐碎的IO,导致安装阶段系统假死。此时若用htop等进程管理器查看IO时会发现它的IO量并不大(~50 KB/s),但由于它更新的对象都是零散的小文件,加上叠瓦盘的写入放大效应,实际落到硬盘磁头上的负荷可能非常重,以至于其他进程的IO被完全阻塞(因apt/dpkg一般是以root权限运行的)。因此,在软件作者提供靠谱的解决方案之前,可以在系统的环境变量列表中添加一项 PKGSYSTEM_ENABLE_FSYNC=0 ,使得软件包管理器将fsync指令推迟到所有软件包安装完成之后执行。这样一来可以避免安装多个软件包时多次调用 update-mime-database 导致的硬盘高负载问题。
最后一个就是Linux饱受诟病的OOM机制,对于内存较小的机器来说问题尤其突出。为了避免因内存不足导致的高IO(源自频繁换页)卡死用户界面,建议安装 earlyoom 这个软件,在内存即将耗尽之时主动终止占用内存最多的进程。
转载本站文章请注明,转载自:WTZ的小博[ http://wiblog.net/]
本作品采用知识共享署名 4.0 国际许可协议进行许可。