我最近一直x265在我的工作站上对一些视频进行编码，但我遇到了一个问题：即使我使用nice -n 20 x265降低其优先级来启动它，它仍然会在计算机运行时减慢计算机的速度。一切仍然有效，只是......慢！我什至在终端输入时看到字符出现之前的延迟。
我必须忍受这个吗？或者我可以尝试其他一些事情吗？
编辑：也许以下内容可以证明nice值确实被应用到了x265？看看NI专栏。
% ps -awux -O nice | egrep "x265|PID"
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND PID NI TT STAT TIME COMMAND
nobody 56654 789.3 3.7 785656 623384 11 SN+J 11:56PM 6:05.80 x265 --input-csp 56654 20 11 SN+J 6:05.80 x265 --input-csp i420 --bframes 5 -
答案1
FreeBSD 内核确实实现了类似 I/O 调度程序的东西，即调度调度。查看手册页，它似乎是一个特定于设备的 IO 调度程序。就我个人而言，我认为这是关于 FreeBSD 实时应用程序的一个很好的主题演讲，并且是坦率地搜索现有 FreeBSD 文档的一个很好的理由。
尽管是推测性的，也许根分区的块设备配置为使用rr调度程序，使用gsched，并且媒体文件存储在单独的块设备上，也许它可以允许操作系统在 I/O 方面更加响应地运行，甚至是否存在 I/O 瓶颈？
也许，与gsched处理器优先级的配置一起应用——应用诸如rtprio 和/或 idprio——即使在媒体文件处理的重负载下，它也可能有助于提高主操作系统的响应能力。
或者，也许可以通过在特定于 CPU 的优化下编译端口来获得更多的处理器带宽。为了达到这种效果，有 MACHINE_CPUARCH和CPUTYPE字段，可以在 中应用/etc/make.conf，并且可以在 ports 构建过程中应用 [手册页]。当然，该手册提供了许多有关使用 FreeBSD 构建端口的指导[第5章]。我自己一直在使用MACHINE_CPUARCH?=amd64一CPUTYPE?=core2台旧的东芝笔记本电脑。尽管我没有在处理器或块 I/O 功能的高负载下对它进行基准测试，但它作为 LAN 网关似乎运行良好。
答案2
有时，单个繁重的 I/O 操作可能会影响所有 I/O 任务的内核性能，包括那些不直接在第一个设备上操作的任务。
控制 I/O 调度优先级的第一个也是间接的方法是调整您已经提到的进程的良好级别。在现代 Linux 中，nice 值为 19（即最大值）的进程默认位于尽力类优先级等于 (19 + 20) / 5 = 7，这是该类中可用的最低优先级。更一般地，根据这样的映射函数，其范围在[0,7]内。
控制 I/O 调度的第二种直接且更强大的方法是手动干预分配给进程的 I/O 调度类。这允许我们将一个进程也放入两个附加类中： 实时课堂，优先级高于尽力而为级别 0，并且 空闲类，其优先级低于尽力而为级别 7。这最后一个理论上保证没有其他 I/O 操作可以等待空闲调度的进程操作。与该
nice命令类似，它ionice允许生成具有给定优先级的进程或更改现有进程的优先级。有关此工具以及 Linux 内核上的 I/O 调度的更多信息，请参阅ionice 手册页。
话虽这么说，您是否尝试过启动您的流程ionice -c 3 x265 ...？
PS 抱歉，在发布我的答案后，我注意到问题中的“FreeBSD”标签，该标签可能会折叠成以下内容。
我认为 FreeBSD 没有任何 I/O 调度程序。您可以考虑在 Linux 机器上执行您的工作，它具有该功能并且非常容易使用它。
答案3
你想要“rctl”
看：
man rctl
它允许您为每个用户、每个进程、jail 或登录类分配资源。例如
# user root, maximum reads of 400 transfers per sec (tps) per the whole user :
rctl -a user:root:readiops:throttle=400/user
# user root, maximum reads of 30Mb per sec (31,457,280 bytes) per the whole user :
rctl -a user:root:readbps:throttle=31457280/user