Проверка правильности применения милости

Question

Я пытаюсь расставить приоритеты одних процессов над другими.Вот основной сценарий, который я использую, для моделирования процесса, интенсивно использующего процессор:

simple_app.py

import os
from multiprocessing import Pool, cpu_count

def f(x):
    while True:
        x*x

if __name__ == '__main__':

    cpu = cpu_count()
    pid = os.getpid()

    print('-' * 20)
    print('pid: {}'.format(pid))
    print('Utilizing {} cores'.format(cpu))
    print('Current niceness: {}'.format(os.nice(0)))
    print('-' * 20)

    pool = Pool(cpu)
    pool.map(f, range(cpu))

Мой следующий шаг - много порождать (точнее, 9, вв данном случае) процессов, выполняющих этот код:

simple_runner.sh

# Start with lowest priority
nice -19 python3 simple_app.py &
# Much higher priority
nice -0 python3 simple_app.py &
# Lower priority spawned
nice -10 python3 simple_app.py &
# Higher priority again
nice -7 python3 simple_app.py &
# Highest priority yet
nice -1 python3 simple_app.py &
# Highest priority yet
nice -0 python3 simple_app.py &
# Highest priority yet
nice -0 python3 simple_app.py &
# Highest priority yet
nice -0 python3 simple_app.py &
# Highest priority yet
nice -0 python3 simple_app.py

Затем я наблюдаю за каждым процессом, сообщая об использовании дочернего процессора, здесь:

process_reporting_server.py

import os
import time
import argparse
import pprint
from multiprocessing import Pool, cpu_count

import psutil

def most_recent_process_info(pid, interval=0.5):
    while True:
        proc = psutil.Process(pid)
        children_cpu_percent = [child.cpu_percent(interval) for child in proc.children()]
        children_cpu_percent_mean = sum(children_cpu_percent) / len(children_cpu_percent) if children_cpu_percent else -1.
        print('Time: {}, PID: {}, niceness: {}, average child CPU percent: {:.2f}'.format(
            time.ctime(),
            pid,
            proc.nice(),
            children_cpu_percent_mean)
        )

if __name__ == '__main__':

    parser = argparse.ArgumentParser()
    parser.add_argument('-p', '--pids', type=str, help='Whitespace-delimited string containing PIDs', dest='pids')
    parser.add_argument('-s', '--seconds', type=int, help='Seconds to sleep', default=10, dest='seconds')
    args = parser.parse_args()

    pids = list(map(int, args.pids.split()))

    pool = Pool(len(pids))
    pool.map(most_recent_process_info, pids)

Я хочу посмотреть, являются ли процессы, которым дано более низкое значение добротности, на самом деле приоритетными.Итак, вот что я делаю:

Выполнить simple_app_runner.sh:

$ ./simple_app_runner.sh 
--------------------
pid: 45036
Utilizing 8 cores
Current niceness: 0
--------------------
--------------------
pid: 45030
Utilizing 8 cores
Current niceness: 19
--------------------
--------------------
pid: 45034
Utilizing 8 cores
Current niceness: 1
--------------------
--------------------
pid: 45032
Utilizing 8 cores
Current niceness: 10
--------------------
--------------------
pid: 45033
Utilizing 8 cores
Current niceness: 7
--------------------
--------------------
pid: 45037
Utilizing 8 cores
Current niceness: 0
--------------------
--------------------
pid: 45038
Utilizing 8 cores
Current niceness: 0
--------------------
--------------------
pid: 45031
Utilizing 8 cores
Current niceness: 0
--------------------
--------------------
pid: 45035
Utilizing 8 cores
Current niceness: 0
--------------------

Затем вот отчет:

$ python3 process_reporting_server.py -p '45036 45030 45034 45032 45033 45037 45038 45031 45035'

Очистить вещи немного и проанализировать с помощью пандмы видим, что в течение пятиминутного интервала заданная милость не выглядит как :

>>> df.groupby('nice')['mean_child_cpu'].max()
nice
0.0     10.50
1.0      9.75
7.0      8.28
10.0     8.50
19.0    21.97

Я что-то здесь упускаю полностью?Почему указанная мной доброта не влияет на расстановку приоритетов ресурсов ЦП?

Answer 1

Я не думаю, что вы что-то упускаете.Мой опыт показывает, что первостепенное значение имеет первостепенный процесс, а все остальные борются за то, что осталось.Вы бы, вероятно, получили бы те же результаты (для чистого процесса, связанного с процессором, как этот), если бы только обрабатывали один процесс до -1 и оставляли остальное на -0.

И причина этого в том, что люди обычнона самом деле не хотим, чтобы расстановка приоритетов была такой жесткой, как мы иногда ожидаем.Как и сейчас, я публикую это, в то время как средняя загрузка превышает 200, и происходит множество процессов с более высоким приоритетом.Если бы все эти процессы были поистине свиньями, то это было бы не "хорошо".Мне нравится, что я все еще могу использовать свой браузер при всей загрузке процессора.

В какой-то момент у меня сложилось впечатление, что вы можете изменить приоритетную очередность, по крайней мере, в некоторых Unix-системах.Я смутно помню, что некоторые мои клиенты требовали, чтобы мы делали именно это, мы (команда сисадмина) говорили «не очень хорошая идея», клиент требовал, чтобы мы это делали, мы делаем это », а затем клиент требовал, чтобы мы отменили это.хитрое дело.

Вот введение в то, что происходит под одеялом: http://www.cs.montana.edu/~chandrima.sarkar/AdvancedOS/SchedulingLinux/index.html Обратите особое внимание на нижнюю часть - «Алгоритм плохо масштабируется», который идет рука об рукус моим первым абзацем.