问题:调度程序似乎不支持交互式进程:
在具有自动 cron 计划备份的桌面系统上,从一个 ( btrfs
) 磁盘到另一个 ( ext4
)。备份过程会挂载空闲磁盘 ( /dev/sda<X>
),将数据备份到该磁盘,最后将其卸载。
每次启动备份进程时,系统都会变得不可用。调度程序似乎无法完成其最基本的工作,即优先处理交互式进程而不是批处理进程。在备份进程运行时,会进行大量 IO,其他一切都会冻结。键盘和鼠标指针停止响应。在任何终端/shell 中按下按键时,回显都会延迟几秒钟。
一旦备份完成,交互式响应就会恢复正常。
有关设置和配置的更多详细信息:
备份过程使用rsnapshot
(调用rsync
和cp -al
)并以较低优先级运行(备份作业在之前nice
),如下所示:
nice /usr/bin/rsnapshot -VD -c /etc/my-rsnapshot.conf daily
在 下运行备份nice
似乎没有帮助。在备份期间,所有交互进程似乎都因 和 进程的繁重 CPU 和 IO 而rsync
挨饿cp
。
这是一个 IA-64、iCore-7 系统,应该能够并行运行 8 个进程。内存为 16GB,其中一部分是空闲的。精简后的mount
输出(当安装了额外的磁盘时)为:
/dev/sdb2 on / type btrfs (rw,relatime,subvol=@,thread_pool=4)
/dev/sdb3 on /home type btrfs (rw,relatime,subvol=@home,thread_pool=4)
/dev/sda2 on /media/idisk/root ext4 (rw,relatime)
/dev/sda3 on /media/idisk/home ext4 (rw,relatime)
none on /sys/fs/cgroup type tmpfs (rw)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuset,clone_children)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu,release_agent=/run/cgmanager/agents/cgm-release-agent.cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory,release_agent=/run/cgmanager/agents/cgm-release-agent.memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices,release_agent=/run/cgmanager/agents/cgm-release-agent.devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer,release_agent=/run/cgmanager/agents/cgm-release-agent.freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio,release_agent=/run/cgmanager/agents/cgm-release-agent.blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event,release_agent=/run/cgmanager/agents/cgm-release-agent.perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,relatime,hugetlb,release_agent=/run/cgmanager/agents/cgm-release-agent.hugetlb)
这是最新的 14.04 LTS 系统。默认情况下,调度程序设置为完全公平队列 ( cfq
):
# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
# cat /sys/block/sdb/queue/scheduler
noop deadline [cfq]
我找到了一个相关的问题。调度程序使进程挨饿建议使用nice
,但我已经这样做了。
另一个与相关信息相关的问题是:如何更改调度noop
程序
当备份运行时,如何使键盘,鼠标和交互式外壳更加灵敏?
提前致谢。
答案1
只是部分答案,自从询问哪些解决了我的问题以来,做了更多的研究和实验,并且看到没有回应
截至 2016 年初,Linux 内核调度程序中存在已知问题/错误。
简而言之,在不同情况下,即使进程队列中有可运行的进程,核心仍然保持空闲状态。
参考:
从 btrfs 切换到 ext4 可以缓解这些问题:
我个人从 btrfs 切换回了 ext4。I/O 性能明显改善。
切换到 SSD 可以进一步缓解 IO 性能
SSD 的价格和可靠性已大幅下降。2TB 三星 SSD(EVO 850)现在售价略高于 600 美元。将系统(根目录和主目录)切换到 SSD 后,密集的备份活动完全不引人注意(在同一系统上对常规 ext4 格式的磁盘进行大量写入时,系统 SSD 非常灵敏)。
最后:对于 SSD,内核中复杂调度程序的好处似乎变得值得怀疑。我将默认设置更改为 noop,性能没有明显下降。事实上,使用 noop 调度程序,我看到系统负载减少、CPU 扩展数量减少、硬件温度降低。
$ cat /sys/block/sda/queue/scheduler
[noop] deadline cfq
$ cat /proc/cpuinfo | grep Hz
model name : Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz
cpu MHz : 836.308
model name : Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz
cpu MHz : 990.253
... similar low actual frequency scaling for all cores ...
2021 年 12 月更新
迈克尔·拉拉贝尔@Phoronix已经运行了一些基准测试确认底线:
虽然某些 Linux 发行版仍然默认使用 MQ-Deadline 或 Kyber 作为 NVMe SSD 存储,但不使用 I/O 调度程序仍然往往能获得最佳的整体性能......
- 20.04 注意:
noop
Linux 内核 5.x 中的调度程序已更名。现在它被称为none
,因此如果您的系统没有旋转磁盘并且您想要切换到noop
调度程序,您可以使用它(必须在 root shell 中运行,并且必须确保您拥有正确的设备):
# NOTE: 'sda' in the path below is just an example
# Your SSD may be on a different device
echo none > /sys/block/sda/queue/scheduler