Процеси Linux можуть мати різний пріоритет CPU та IO (nice та ionice).
Чому виникає необхідність мати різний пріоритет CPU та IO?
Чи є в реальному світі використання для того, щоб мати їх різні?
Які випадки використання в реальному світі ви знайшли, що потребують різних пріоритетів процесора та IO? Як і вище, ніж звичайний пріоритет CPU, але нижчий за звичайний пріоритет IO або навпаки.
Відповіді:
Типова поведінка 'nice' полягає у налаштуванні пріоритету 'io' програми також, коли мінливість змінюється.
Все, звичайно, залежить від вашої завантаженості, але одним із ключових аспектів будь-якої операційної системи є те, як вона розподіляє свій ресурс і як обробляє суперечки .
Насправді важливо зрозуміти, що таке приємність, тому що, коли під навантаженням конкуруючих процесів поведінка операційної системи може вплинути на решту вашої роботи.
Суперечність - це міра того, як різні програми змагаються за один і той же ресурс (наприклад, процесор).
Поводження з вантажем
З моменту запровадження цілком справедливого планувальника, приємне - це лише передумови до «вагового» пункту кожного процесу. Які можна переглянути в проц.
$ cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight : 1024
...
Зміна приємності просто змінює вагу:
$ nice -n 5 cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight : 335
...
Вимірювання вмісту CPU проводиться за допомогою цілком справедливого алгоритму планування. Кожній програмі присвоюється значення "ваги", і у випадку, коли суперечить час процесора, тоді час розподіляється між процесами, підсумовуючи всю обробку, що претендує на час процесора, і присвоює їм найменший час CPU загального номіналу, виходячи з їх вагового значення.
Якщо у мене є 3 програми, які хочуть використовувати час процесора, вони за замовчуванням отримують 1024 як звичайну вагу. Якщо у мене є один процес з хорошим рівнем +5, як вище, всі три ваги склали б у 2383, таким чином, розміщений процес отримає близько 15% процесорного часу за дану секунду, якби всі 3 процеси просили ЦП у цю секунду .
Чому виникає необхідність мати різний пріоритет CPU та IO?
Niceness насправді лише грає з тим, що робити, коли система перебуває під навантаженням, тобто - як операційна система розбиває час між конкуруючими процесами, як визначено будь-якими чинниками, необхідними.
Те, як це впливає на вас або є вільним для вас, залежить від того, які пріоритети доставки мають різні програми між собою та час доставки кожної заявки.
Niceness насправді робить щось лише тоді, коли ваша система перебуває під навантаженням (є більше речей, які бажають уваги, ніж CPU або Disk можуть впоратися). Він просто інструктує ядро, як розподілити ресурс за тих обставин.
Чи є в реальному світі використання для того, щоб мати їх різні?
Якщо у вас є чимало конкуруючих процесів або робота, яку потрібно виконати, це більше, ніж це може зробити CPU, приємність дає вам деякі відносно стабільні гарантії того, що робота закінчується першою. Це може бути важливим для вас, якщо висловитеся про створення звіту, який має бути наданий до завершення іншого звіту.
У настільній системі приємність може бути ще важливішою. Деякі програми мають поведінку в режимі реального часу, завдяки чому їх частіше прокидаються під час завантаження, запобігаючи застарілим даним. Наприклад, Pulseaudio потрапляє до цієї категорії.
Інші програми можуть знадобитися, щоб зменшити роботу залежних програм. Наприклад, багато запитів apache сказати, що такий сервер SQL, як MySQL, може блокуватись протягом тривалого періоду часу, оскільки SQL не працює досить швидко, тому що - скажімо, якийсь інший звіт конкурує за час процесора. Таким чином, SQL не тільки застопорився, але й Apache. SQL іноді тут може зашкодити, тому що зазвичай набагато менше робочих ниток, ніж потоки apache, що конкурують як група, яку планувальник сприймає більш сприятливо, тому надаючи більше процесорного часу для SQL вирівнюється.
UpdateDB (програма, що індексує файли) працює пізно вночі і дуже важкий на диску. Може бути корисним зменшити пріоритет планування вводу-виводу, щоб інші програми тоді мали пріоритет над тим, що не так важливо в порядку порядку.
Які випадки використання в реальному світі ви знайшли, що потребують різних пріоритетів процесора та IO?
Дуже мало. Приємність - це занадто великий підхід з найкращих зусиль. Як правило, я дбаю менше про те , як добре додатки працюють і більш про те , як погано вони могли виконати. Спочатку це може здатися зворотним, але у мене є гарантії надання послуг, які мені важливіше виконувати.
Я хочу, щоб впевненість сказала, що "ваші речі навіть у поганий день будуть зроблені за X часовий період". Якщо він піде швидше, це просто бонус.
Я, як правило, починаю з генерування узгоджених специфікацій, таких як:
І витягніть вимоги, які повинні відповідати таким чином:
Якщо технічні характеристики відповідають дійсності, то я виконую ці цілі, не роблячи віртуалізації, використовуючи набагато ефективніший підхід контрольних груп.
Контрольні групи дозволяють мені робити досить надійні гарантії рівня надання послуг для розподілу ресурсів, якщо програма веде себе у визначених межах. Це означає, що навіть у системі під навантаженням я можу гарантувати доступність ресурсів для відповідної програми та гарантувати простір для інших програм у тому ж полі.
Якщо ми візьмемо ваш приклад 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 секунди процесору.
Надання іншим конкуруючим групам не робити нічого нерозумно, знаходячись під навантаженням, є меншим фактором мого надання послуг, оскільки я знаю, як процесор кидається на кожну програму.
Такі контрольні групи все ще є найкращими зусиллями, але вони пропонують набагато більше контролю над цим зусиллям, ніж милість та іонічність.