linux – 用于为CPU和IO提供不同进程优先级的用例?

前端之家收集整理的这篇文章主要介绍了linux – 用于为CPU和IO提供不同进程优先级的用例?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
Linux进程可以具有不同的cpu和IO优先级(nice和ionice).

为什么需要具有不同的cpu和IO优先级?

让它们与众不同,有没有真正的世界用法

您发现哪些实际用例需要不同的cpu和IO优先级?像高于正常的cpu优先级但低于正常IO优先级或反之亦然.

解决方法

‘nice’的默认行为是在niceness更改时调整应用程序的’io’优先级.

当然,一切都取决于您的工作量,但任何操作系统的关键方面之一是它如何分配其资源,以及它如何处理争用.

理解什么样的好处实际上很重要,因为当竞争过程负载不当时,操作系统的行为方式会对其余的工作负载产生影响.

争用是衡量不同应用程序如何竞争相同资源(如cpu)的指标.

处理负荷

自从完全公平的调度程序被引入以来,nice只是每个进程的“权重”子句的前端.哪个可以在proc中查看.

$cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight                     :                 1024
...

改变好感只会改变体重:

$nice -n 5 cat /proc/self/sched 
---------------------------------------------------------
...
se.load.weight                     :                 335
...

cpu争用的度量由完全公平的调度算法完成.每个应用程序都分配了一个“权重”值,在争用cpu时间的情况下,通过总计所有处理争用cpu时间并根据其权重值为它们分配最低公用面额cpu时间,在进程之间分配时间.

如果我有3个应用程序都想要使用cpu时间,默认情况下它们接收1024作为正常权重.如果我有一个像上面一样好的5个进程,那么所有三个权重将在2383处总计,如果所有3个进程在该秒内都要求cpu,那么niced进程将在给定的秒内接收大约15%的cpu时间.

Why is there a need to have different cpu and IO priority?

当系统处于负载状态时,Niceness实际上只是在做什么,即操作系统如何在竞争过程之间切换时间,这些过程由任何必要的因素定义.

这对您有何影响或与您相关,受到不同应用程序之间的交付优先权以及交付每个应用程序的时间的约束.

当您的系统处于负载状态时,Niceness确实只会执行某些操作(需要注意的内容cpu或磁盘可以处理的更多).它只是指示内核如何在这些情况下分配资源.

Is there any real world usage for having them different?

如果你有许多竞争过程或工作要完成,而不是由cpu完成,那么很好地为你提供了一些相对稳定的保证,即首先完成哪些工作.
如果您说生成应在另一个报告完成之前交付的报告,这对您来说可能很重要.

在桌面系统上,好处可能更重要.某些应用程序具有实时行为,因此在加载期间更频繁地唤醒它们会阻止数据过时.例如,Pulseaudio属于这一类.

可能需要其他应用程序来完成相关应用程序的工作.例如,许多apache请求说像MysqL这样的sql服务器可能会长时间阻塞,因为sql不能足够快地服务,因为 – 比如说其他一些报告正在争夺cpu时间.所以sql不仅停滞不前,而且Apache也是如此.
sql有时会受到伤害,因为工作线程通常比作为一个组竞争的apache线程要少得多,因此调度程序可以更好地权衡,因此给sql提供了更多的cpu时间.

UpdateDB(一个索引文件的程序)在晚上运行得很晚,并且非常耗费磁盘.减少其IO调度优先级可能是有用的,以便当时的其他应用程序优先于事物顺序不重要的事物.

What real world use cases have you found that need different cpu and IO priority?

很少.善意是一种尽力而为的方法.根据经验,我不太关心应用程序的执行情况,也不关心它们执行得多么糟糕.这可能听起来有点倒退,但我有服务交付保证,以满足哪些对我来说更重要.

我希望有信心说“即使在糟糕的一天,你的东西也会在X时期完成”.如果它变得更快,它只是一个奖金.

我通常会通过生成商定的规范开始,例如:

>所有Web应用程序都保证在0.3秒内完成请求.
>系统上的所有sql请求都保证在0.1秒内完成.
> Web应用程序应处理不超过50 IOPS并提供1k文件.
> Web应用程序内存占用总量不超过250Mb.

并提出满足要求:

>所有网络请求应在0.05秒内完成.
>所有sql请求应在0.02秒内完成.
>应该有足够的内存处理所有请求.
>应满足IO要求.

提供规范是正确的,然后我使用控制组的更有效的方法,在不进行虚拟化的情况下实现这些目标.

控制组允许我为资源分配提供非常可靠的服务级别保证,只要应用程序在指定的边界内运行.这意味着即使在负载下的系统上,我也可以保证相关应用程序的资源可用性,并为同一个盒子上的其他应用程序保证空间!

如果我们以你的cpu和IO为例.我设置了满足这些要求的限制:

# cd /sys/fs/cgroup/blkio/apache
# echo "253:0 100" >blkio.throttle.read_iops_device 
# echo "253:0 50" >blkio.throttle.write_iops_device 
# echo "253:0 102400" >blkio.throttle.read_bps_device

所以100k字节读取100个iops.

# cd /sys/fs/cgroup/cpu/apache
# echo 1000000 >cpu.cfs_period_us
# echo 60000 >cpu.cfs_quota_us

在1秒的时间段内,给出0.06秒的cpu.

# cd /sys/fs/cgroup/cpu/sql
# echo 1000000 >cpu.cfs_period_us
# echo 20000 >cpu.cfs_quota_us

在1秒的时间段内,给出0.02秒的cpu.

提供其他竞争cgroup不做任何愚蠢的事情,负载不足是我服务交付的一个因素,因为我知道如何为每个应用程序抛出cpu.

这种性质的控制组仍然是最好的努力,但它们提供了更多的控制力,而不是漂亮和电离.

猜你在找的Linux相关文章