Використання та розуміння параметрів системного планування в контексті робочого столу

У системних файлах служби можна встановити наступні параметри, пов’язані з плануванням (зі systemd.execсторінки man , виправте мене, якщо я помиляюся):

Nice Встановлює стандартний рівень за замовчуванням (пріоритет планування) для виконуваних процесів. Бере ціле число між -20 (найвищий пріоритет) та 19 (найнижчий пріоритет). Докладніше див. Setpriority (2) .

Який знайомий приємний рівень. Здається, його ефект дещо знижується завдяки функції "автогрупи" останніх ядер Linux. Тому наведені нижче варіанти можуть бути те, що я дійсно хотів би встановити, щоб процеси не дуже добре поводилися на моєму робочому столі.

CPUSchedulingPolicy Встановлює політику планування процесора для виконуваних процесів. Бере одну з інших, партії, простою, фіфо або rr. Детальніше див. У sched_setscheduler (2) .

CPUSchedulingPriority Встановлює пріоритет планування процесора для виконуваних процесів. Доступний діапазон пріоритетів залежить від обраної політики планування процесора (див. Вище). Для політик планування в режимі реального часу може бути використане ціле число від 1 (найнижчий пріоритет) до 99 (найвищий пріоритет). Детальніше див. У sched_setscheduler (2) .

CPUSchedulingResetOnFork Бере бульний аргумент. Якщо це правда, підвищені пріоритети і політики планування процесора будуть скинуті, коли виконані процеси розщеплюються, і, отже, не можуть просочуватися в дочірні процеси. Детальніше див. У sched_setscheduler (2) . Типово встановлено значення false.

Я розумію останній варіант. Я пояснюю з пояснення перших двох, що я можу вибрати політику планування, а потім, враховуючи цю політику, пріоритет. Мені не зовсім зрозуміло, що я повинен вибрати для того, який вид завдань. Наприклад, чи безпечно вибирати "в режимі очікування" для завдань резервного копіювання (відносно інтенсивно процесор, оскільки дедуплікація), або інший краще підходить?

Взагалі, я отримую зрозумілий огляд кожної політики, кожного її пріоритету та відповідності певним цілям. Також цікавить взаємодія з приємним рівнем.

Поруч з плануванням процесора є IO планування. Я думаю, це відповідає ionice(виправте мене, якщо я помиляюся).

IOSchedulingClass Встановлює клас планування вводу / виводу для виконаних процесів. Бере ціле число між 0 і 3 або один з рядків жоден, в режимі реального часу, найкращих зусиль або простою. Докладніше див. У ioprio_set (2) .

IOSchedulingPriority Встановлює пріоритет планування вводу / виводу для виконуваних процесів. Бере ціле число між 0 (найвищий пріоритет) і 7 (найнижчий пріоритет). Доступні пріоритети залежать від обраного класу планування вводу / виводу (див. Вище). Докладніше див. У ioprio_set (2) .

Ми бачимо ту саму структуру, що і для планування процесора. Я також шукаю таку ж інформацію.

Для всіх параметрів "Планування", вказані на мене сторінки недостатньо зрозумілі, переважно в перекладі речей на дещо технічно схильну точку зору користувача робочого столу.

Планування CPUS {Policy | Priority}

Посилання говорить вам, що CPUSchedulingPriorityслід встановлювати лише для fifoабо rr("в реальному часі") завдань. Ви не хочете змушувати планувати послуги в режимі реального часу.

CPUSchedulingPolicy=other є типовим.

То листя batchі idle. Різниця між ними актуальна лише в тому випадку, якщо у вас є кілька завдань з пріоритетним режимом, що споживають процесор одночасно. Теоретично batchдає більш високу пропускну здатність (в обмін на більш тривалі затримки). Але це не велика перемога, тому це не дуже актуально в цьому випадку.

idleбуквально голодує, якщо що-небудь ще хоче CPU. Пріоритет CPU є менш значущим, ніж раніше, для старих систем UNIX з одним ядром. Я був би щасливішим, починаючи nice, наприклад, з приємного рівня 10 або 14, перш ніж вдаватися до цього idle. Дивіться наступний розділ.

Однак більшість робочих столів більшість часу відносно простоюють. І коли у вас є свиня CPU, яка б попередньо зняла фонове завдання, для свиней звичайно використовувати лише один із ваших процесорів. Зважаючи на це, я не відчував би себе занадто ризикованим idleв контексті середнього робочого столу чи ноутбука. Якщо у нього немає процесора Atom / Celeron / ARM, розміром якого є приблизно 15 Вт ; тоді я хотів би подивитися на речі трохи уважніше.

Чи хороший рівень "підрив" функцією "автогрупи" ядра?

Так.

Автогрупування трохи дивно. Автор systemdне любив евристику, навіть для настільних комп'ютерів. Якщо ви хочете перевірити відключення автогрупування, ви можете встановити sysctl kernel.sched_autogroup_enabled на 0. Я думаю, що найкраще протестувати, встановивши sysctl у постійній конфігурації та перезавантажившись, щоб пересвідчитися від усіх автогруп.

Тоді ви зможете без жодних проблем мати приємні рівні для своїх послуг. Принаймні, у поточних версіях systemd - див. Наступний розділ.

Наприклад, хороший рівень 10 знизить вагу кожної нитки в планувальнику процесора Linux, приблизно до 10%. Хороший рівень 14 становить менше 5%. (Посилання: повна формула )

Додаток: хороший рівень "підривається" системними групами?

Поточні DefaultCPUAccounting= параметри за замовчуванням вимкнено, якщо їх не можна ввімкнути, не дозволяючи також керувати процесором на основі послуги. Тож має бути добре. Ви можете перевірити це у вашій поточній документації:man systemd-system.conf

Майте на увазі, що керування процесором по одній службі також буде включено, коли будь-яка служба встановлює CPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares.

Наступний витяг блогу застарілий (але все ще в Інтернеті). З часом змінилася поведінка за замовчуванням, і довідкова документація була відповідно оновлена.

Як хороший за замовчуванням, якщо в ядрі включений контролер процесора, systemd створить cgroup для кожної служби при її запуску. Без будь-якої подальшої конфігурації це вже має один приємний ефект: у системній системі кожна системна служба отримає рівну кількість процесора, незалежно від того, скільки процесів вона складається. Або іншими словами: на вашому веб-сервері MySQL отримає приблизно такий самий об'єм процесора, як і Apache, навіть якщо останній складається з 1000 процесів скриптів CGI, але перший лише з кількох робочих завдань. (Цю поведінку можна відключити, див. DefaultControllers = в /etc/systemd/system.conf.)

Крім цього за замовчуванням, можна чітко налаштувати спільні CPU, які отримує сервіс із налаштуванням CPUShares =. Значення за замовчуванням - 1024, якщо ви збільшите це число, ви присвоїте сервісу більше CPU, ніж незмінний на 1024, якщо зменшити його, менше.

http://0pointer.de/blog/projects/resources.html

Класична порада щодо налаштування - "Не оптимізуйте, Бенчмарк".

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

Сучасні настільні комп’ютери часто досить швидко працюють, без будь-якої настройки.