Скільки контекстних комутаторів є "нормальними" (як функція ядер процесора (або інших))?


34

Привіт, Linux / UNIX Overlords,

У кого-небудь з вас є правило, скільки контекстних комутаторів (на ядро ​​процесора) є нормальним на сервері Linux?

У моєму коледжі тут його вивели, і він бачить 16K на 8-ядерній x86_64машині.

Ось кілька статистичних даних щодо sarface за останні кілька днів ...

alt text http://src.autonomy.net.au/imagebin/81895e338fae67d3d205c09db44a81e6-Picture_10.png

А щоб побачити статистику створення процесу, ось логарифмічний вигляд того ж графіку ...

alt text http://src.autonomy.net.au/imagebin/7481f7e52bead4effc90248fc23c72fe-Picture_11.png

І 8 ядер нудьгують до смерті ...

alt text http://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f-Picture_12.png

CS проти IOwait (масштаб x10000)

alt text http://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306-Picture_13.png

Більше марної інформації на випадок, коли хтось запитає.

  • Зберігання, на якому працює сервер, - 0,5 ТБ SAN через FC
  • Там є 8 Гб оперативної пам’яті, в основному кеш-пам'ять.

1
У якийсь конкретний період?
dmckee

Чи можете ви бути більш конкретними щодо навантаження?
dmo

1
Як ти склав цей графік? Виглядає насправді приємно!
Антуан Бенкемун

Привіт Антуан - графіки зроблені з sarface ( projects.autonomy.net.au/sarface )
Xerxes

графічні посилання на даний момент мертві. @Xerxes ти можеш звідкись дістатися?
törzsmókus

Відповіді:


25

Це дуже залежить від типу запущеної програми. Якщо у вас є програми, які дуже задовольняють тривалість систематичних викликів WRT, ви можете очікувати, що ви побачите велику кількість комутації контексту. Якщо більшість ваших програм простоюють і прокидаються лише тоді, коли в сокеті відбуваються речі, ви можете сподіватися на низькі темпи переключення контексту.

Системні дзвінки

Системні виклики викликають переключення контексту за своєю суттю. Коли процес виконує системний виклик, він, в основному, каже ядру взяти на себе з його поточного моменту часу і пам'яті, щоб виконати те, що процес не має права, і повернутися на те саме місце, коли це буде зроблено.

Коли ми дивимось на визначення syscall write (2) з Linux, це стає дуже зрозумілим:

ІМ’Я
       write - записати в дескриптор файлу

СИНОПИС
       #включати 

       ssize_t write (int fd, const void * buf, size_t count);

ОПИС
       write () записує до підрахунку байтів із буфера, вказаного в буфі, до файлу
       посилається на дескриптор файлу fd. [..]

ПОВЕРНЕННЯ ЦІННОСТІ
       Після успіху повертається кількість записаних байтів (нуль вказує
       нічого не було написано). При помилці повертається -1, і встановлюється errno
       відповідним чином.
       [..]

Це, в основному, каже ядру взяти на себе операцію з процесу, перейти до countбайтів, починаючи з адреси пам'яті, на яку вказує *bufдескриптор файлу fdпоточного процесу, а потім повертається назад до процесу і повідомляє йому, як він пройшов.

Гарний приклад, щоб показати це, - це спеціалізований ігровий сервер для ігор на базі Valve Source, hlds . http://nopaste.narf.at/f1b22dbc9 показує одну секунду ваших системних дзвінків, зроблених одним екземпляром ігрового сервера, на якому не було гравців. Цей процес займає приблизно 3% часу процесора на Xeon X3220 (2,4 ГГц), просто щоб ви відчули, наскільки це дорого.

Багатозадачність

Іншим джерелом комутації контексту можуть бути процеси, які не роблять системні виклики, але їх потрібно відсунути від заданого процесора, щоб звільнити місце для інших процесів.

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

Візьміть машину, що працює в режимі очікування, запустіть vmstat, а потім запустіть BurMMX (або будь-який інший тест із пакета cpuburn) для кожного ядра процесора, який має система. Ви повинні мати повне використання системи до того часу, але навряд чи будь-яке посилене переключення контексту. Потім спробуйте почати ще кілька процесів. Ви побачите, що швидкість переключення контексту збільшується, коли процеси починають конкурувати за ядра CPU. Кількість комутацій залежить від співвідношення процесів / ядер та багатозадачності розділення вашого ядра.

Подальше читання

На linfo.org є приємне опис того, що таке контекстні комутатори та системні виклики . У Вікіпедії є загальна інформація та приємна колекція посилань на системні дзвінки.


1
Це було корисно - ви дали мені чудову ідею! =)
Xerxes

1
Ваше твердження System calls cause context switches by their very own natureздається неправильним. Системні дзвінки викликають перемикання режиму, як зазначено в linfo.org/context_switch.html
Ніколяс Лаброт

6

мій середньо завантажений веб-сервер сидить біля 100-150 комутаторів секунду більшу частину часу з піками в тисячі.

Високі темпи комутації контексту самі по собі не є проблемою, але вони можуть вказувати шлях до більш значної проблеми.

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

Якщо ви працюєте з X, спробуйте перейти в консольний режим.

відредагуйте ще раз: при 16 кс в секунду кожен процесор в середньому по два комутатори на мілісекунд - це половина до шостої частини нормального часового відрізка. Чи може він виконувати багато потоків, пов'язаних з IO?

редагувати ще раз розмістити графіки: звичайно виглядає зв'язаний IO. чи система проводить більшу частину свого часу в SYS, коли контекстні комутатори високі?

редагуйте ще раз: Високий вміст і система в останньому графі - повністю затьмарює простору користувачів. У вас проблеми з ІО.
Яку FC-карту ви використовуєте?

правка: хммм. будь-який шанс отримати якісь орієнтири, що надходять на ваш доступ до SAN через bonnie ++ або dbench під час мертвого часу? Мені було б цікаво побачити, чи мають вони подібні результати.

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


Я досі не впевнений, що висока швидкість переключення контексту не є проблемою, я говорю про високу, як у 4K до 16K, а не 100-150.
Ксеркс

Жоден із наших серверів не працює жодним X. Я погоджуюся з вами щодо проблеми очікування IO та взаємозв’язку між цим та CS. Картка HBA не є підозрюваною, хоча тому, що ми використовуємо ту саму карту на інших сотнях серверів ... Висновок полягає в тому, що я звинувачую команду SAN в дурному EVA SAN команді, що вони відчайдушно намагаються захищати весь час. Зауважте, що високий IO-чекання не завжди є підставою для занепокоєння, якщо більшість процесів на машині пов'язані з IO, очікується, що сервер не матиме нічого кращого для того, щоб зробити це непрацюючі обертання.
Xerxes

На другому ж - доданий четвертий графік показує, що він насправді не такий близький, як я, хоча спочатку. Не зовсім затемнення будь-якими способами. Я все ще звинувачую SAN. =)
Xerxes

1

Я більше схильний турбуватися щодо завантаженості процесора в системі. Якщо вона близька до 10% або вище, це означає, що ваша ОС витрачає занадто багато часу, роблячи контекстні комутатори. Хоча переміщення деяких процесів на іншу машину відбувається набагато повільніше, це заслуговує на це.


1

Такі речі, тому ви повинні спробувати зберегти основні показники продуктивності для своїх серверів. Таким чином, ви можете порівняти речі, які ви раптом помітили, з речами, які ви зафіксували в минулому.

Однак, у мене працюють сервери (в основному не дуже зайняті сервери Oracle), які стійкі близько 2 к, з деякими піками 4 к. Для моїх серверів це нормально, для серверів інших людей, які можуть бути занадто низькими або занадто високими.

Як далеко ви можете повернутися до своїх даних?

Яку інформацію про процесор ви можете нам надати?


Я, безумовно, згоден із збереженням базової лінії, і у нас є дані нагіоси, які тривалий час повертаються назад - проблема цього сервера полягає в тому, що це нова кров - лише на короткий час. Крім того, це працює програмне забезпечення для підприємства (читай: crap) - Teamsite - лише для додання до списку невизначених змінних. Я все ще віддаю перевагу sar (особисті переваги), тому я налаштую його на те, щоб він зберігався більше, ніж за замовчуванням (2 тижні), і подивіться, як це відбувається.
Xerxes

Використання sar у поєднанні з rrdtool (який, схоже, походить від ваших графіків), може бути простим засобом збереження ваших даних (або принаймні тез) на тривалий час.
wzzrd

0

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


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

Насправді, у будь-якій сучасній (багатозадачній) операційній системі мінімізація переключення контексту є дуже важливим завданням оптимізації. Чи є у вас джерела для підтвердження вашої заяви про те, що вартість невелика?
Xerxes

Вибачте, ви говорите про мінімізацію контекстних комутаторів з точки зору розвитку ОС? Не маючи нічого спільного з таким розвитком, я не маю думки щодо переваг розробки системи для мінімізації CS :) Якщо ви говорите про мінімізацію контекстних комутаторів на сервері, проблема полягає в пом'якшенні контекстних комутаторів і вводить затримку в інших місцях. EG зменшення кількості процесів на машині означає, що вам потрібно перенести ці процеси на іншу машину, а значить, зв’язок відбувається через мережу, що набагато повільніше!
Alex J

Я вважаю, що ваше визначення контекстних комутаторів є помилковим; вони також трапляються, коли виконується системний виклик, навіть якщо він повертається в ту саму нитку. Програми оптимізують це, роблячи різні трюки. Наприклад, Apache дуже часто потребує системного часу; для цього нитка повторно викликає локальний час і зберігає результат у спільній пам'яті. Інші потоки повинні читати лише з оперативної пам’яті і не здійснювати перемикання процесів при цьому.
niXar
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.