Назад | Перейти на главную страницу

Варианты использования для разных приоритетов процесса для ЦП и ввода-вывода?

Процессы Linux могут иметь разные приоритеты CPU и IO (nice и ionice).

Почему нужны разные приоритеты ЦП и ввода-вывода?

Есть ли какое-то реальное применение, чтобы они были разными?

Какие из реальных случаев использования, которые вы обнаружили, требуют разных приоритетов ЦП и ввода-вывода? Подобно более высокому, чем обычно, приоритету ЦП, но более низкому, чем нормальный приоритет ввода-вывода, или наоборот.

Поведение по умолчанию «nice» - это регулировка приоритета «io» приложения также при изменении удобства.

Конечно, все зависит от вашей рабочей нагрузки, но одним из ключевых аспектов любой операционной системы является то, как она распределяет свои ресурсы и как обрабатывает раздор.

На самом деле важно понимать, что делает приятность, потому что под нагрузкой от конкурирующих процессов поведение операционной системы может повлиять на остальную рабочую нагрузку.

Конкуренция - это мера того, как разные приложения конкурируют за один и тот же ресурс (например, ЦП).

Обработка нагрузки

С тех пор, как был введен полностью справедливый планировщик, nice - это просто интерфейс для предложения «веса» каждого процесса. Которые можно посмотреть в proc.

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

Изменение вежливости просто изменяет вес:

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

Мера конкуренции за ЦП выполняется с помощью полностью справедливого алгоритма планирования. Каждому приложению назначается «весовое» значение, и в случае конкурирующего процессорного времени оно распределяется между процессами путем суммирования всей обработки, соревнующейся за процессорное время, и присвоения им самого низкого общего номинала процессорного времени на основе их значения веса.

Если у меня есть 3 приложения, которые хотят использовать процессорное время, по умолчанию они получают 1024 как нормальный вес. Если бы у меня был один процесс с хорошим +5, как указано выше, все три веса были бы суммированы в 2383, таким образом, niced процесс получил бы около 15% времени ЦП в заданную секунду, если бы все 3 процесса запрашивали ЦП в эту секунду .

Почему нужны разные приоритеты ЦП и ввода-вывода?

На самом деле аккуратность заключается только в том, что делать, когда система находится под нагрузкой, то есть в том, как операционная система распределяет время между конкурирующими процессами в зависимости от любых необходимых факторов.

То, как это влияет на вас или имеет отношение к вам, зависит от того, какие приоритеты доставки разные приложения имеют друг с другом и сколько времени должно быть у каждого приложения.

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

Есть ли какое-то реальное применение, чтобы они были разными?

Если у вас есть множество конкурирующих процессов или работа, которую нужно выполнить, больше, чем может сделать ЦП, приятность дает вам относительно стабильные гарантии относительно того, какая работа завершится первой. Это может быть важно для вас, если вы говорите о создании отчета, который должен быть доставлен до завершения другого отчета.

На настольной системе удобство может быть еще важнее. Некоторые приложения работают в режиме реального времени, благодаря чему они чаще просыпаются во время загрузки, предотвращая устаревание данных. К этой категории относится, например, Pulseaudio.

Другие приложения могут потребоваться для выполнения работы для зависимых приложений. Например, множество запросов apache, чтобы сказать, что сервер SQL, такой как MySQL, может блокироваться в течение длительного периода времени, потому что SQL не обслуживает достаточно быстро, потому что - скажем, какой-то другой отчет конкурирует за время процессора. Таким образом, остановился не только SQL, но и Apache. SQL здесь иногда может повредить, потому что обычно гораздо меньше рабочих потоков, чем потоки apache, конкурирующие как группа, чтобы планировщик более благоприятно оценил их, поэтому выделение большего времени процессора для SQL выравнивает ситуацию.

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

Какие из реальных случаев использования, которые вы обнаружили, требуют разных приоритетов ЦП и ввода-вывода?

Очень мало. Вежливость - это слишком хороший подход. Как правило, меня меньше заботит, насколько хорошо работают приложения и Больше как плохо они мог выполнять. Поначалу это может показаться обратным, но у меня есть гарантии предоставления услуг, которые для меня важнее.

Я хочу с уверенностью сказать: «Ваши дела даже в плохой день будут выполнены в X промежуток времени». Если он пойдет быстрее, это просто бонус.

Обычно я начинаю с создания согласованных спецификаций, таких как:

  • Все веб-приложения гарантированно обрабатывают запросы за 0,3 секунды.
  • Все запросы SQL в системе гарантированно будут выполнены за 0,1 секунды.
  • Веб-приложение должно обрабатывать не более 50 операций ввода-вывода в секунду и доставлять файлы размером 1 КБ.
  • Общий объем памяти веб-приложений не превышает 250 МБ.

И сформулируйте требования, чтобы соответствовать следующим требованиям:

  • Все веб-запросы должны выполняться за 0,05 секунды.
  • Все запросы SQL должны выполняться за 0,02 секунды.
  • Для обработки всех запросов должно быть достаточно памяти.
  • Требования ввода-вывода должны быть выполнены.

Если спецификации верны, я достигну этих целей без виртуализации, используя гораздо более эффективный подход групп управления.

Группы управления позволяют мне делать довольно надежные гарантии уровня обслуживания для распределения ресурсов при условии, что приложение ведет себя в указанных границах. Это означает, что даже в системе под нагрузкой я могу гарантировать доступность ресурсов для рассматриваемого приложения и гарантировать место для других приложений в том же самом устройстве!

Если взять ваш пример с 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

Итак, 100 килобайт для чтения из 100 операций в секунду.

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

Из периода времени в 1 секунду дайте 0,06 секунды ЦП.

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

Из периода времени в 1 секунду дайте 0,02 секунды ЦП.

Предоставление других конкурирующих групп не делает ничего глупого, нахождение под нагрузкой - меньший фактор в предоставлении моих услуг, потому что я знать как загружается процессор для каждого приложения.

Контрольные группы такого характера по-прежнему наилучшим образом, но они предлагают гораздо больший контроль над этим усилием, чем это делают любезность и ионность.