我最近一直在使用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 -
小智 5
FreeBSD 内核确实实现了类似 I/O 调度程序的功能，即gsched。查看手册页，它似乎是一个特定于设备的 IO 调度程序。就我个人而言，我认为这是关于 FreeBSD 实时应用程序的一个很好的主题演讲，并且是坦率地搜索现有 FreeBSD 文档的一个很好的理由。
尽管是推测性的，也许根分区的块设备配置为使用rr调度程序，使用gsched，并且媒体文件存储在单独的块设备上，也许它可以允许操作系统在 I/O 方面更加响应地运行，甚至是否存在 I/O 瓶颈？
也许，与gsched处理器优先级的配置一起应用——应用诸如rtprio和/或idprio——它可能有助于提高主操作系统的响应能力，即使在媒体文件处理的重负载下也是如此。
或者，也许可以通过在特定于 CPU 的优化下编译端口来获得更多的处理器带宽。为了达到这种效果，有 MACHINE_CPUARCH和CPUTYPE字段，可以在 中应用/etc/make.conf，并且可以在 ports 构建过程中应用 [手册页]。当然，该手册提供了许多有关使用 FreeBSD 构建端口的指南 [ ch.5 ]。我自己一直在使用MACHINE_CPUARCH?=amd64一CPUTYPE?=core2台旧的东芝笔记本电脑。尽管我没有在处理器或块 I/O 功能的高负载下对它进行基准测试，但它作为 LAN 网关似乎运行良好。
有时，单个繁重的 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 机器上执行您的工作，它具有该功能并且非常容易使用它。
| 归档时间： |
|
| 查看次数： |
1844 次 |
| 最近记录： |