Сколько переключений контекста является «нормальным» (как функция ядер ЦП (или других))?

34

Привет Повелители Linux / UNIX,

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

Мой колледж здесь поднял это, и он видит 16K на 8-ядерном x86_64 компьютере.

Вот некоторые статистические данные sarface за последние несколько дней ...

альтернативный текст http://src.autonomy.net.au/imagebin/81895e338fae67d3d205c09db44a81e6-Picture_10.png

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

альтернативный текст http://src.autonomy.net.au/imagebin/7481f7e52bead4effc90248fc23c72fe-Picture_11.png

И 8 ядер скучно до смерти ...

альтернативный текст http://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f-Picture_12.png

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

альтернативный текст http://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306-Picture_13.png

Больше бесполезной информации на случай, если кто-нибудь спросит ..

  • Хранилище, на котором работает сервер, - это 0,5 ТБ SAN через FC
  • Там 8 ГБ ОЗУ, в основном кеш - без подкачки.
linux performance context-switch Ксеркс
источник
1
В какой-то конкретный период?
dmckee
Можете ли вы быть более конкретным в отношении рабочей нагрузки?
dmo
1
Как вы сделали этот график? Выглядит действительно красиво!
Антуан Бенкемун
Привет Антуан - Графики сделаны из sarface ( projects.autonomy.net.au/sarface )
Ксеркс
графические ссылки мертвы на данный момент. @ Ксеркс, ты можешь туда добраться?
törzsmókus

Ответы:

25

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

Системные звонки

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

Когда мы посмотрим на определение системного вызова write (2) из ​​Linux, это становится очень ясным:

НАЗВАНИЕ
       write - записать в дескриптор файла

СИНТАКСИС
       #включают 

       запись ssize_t (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, а затем запустите burnMMX (или любой другой тест из пакета cpuburn) для каждого ядра ЦП, имеющегося в системе. К тому времени у вас должно быть полное использование системы, но вряд ли какое-либо усиление переключения контекста. Затем попробуйте запустить еще несколько процессов. Вы увидите, что скорость переключения контекста увеличивается, когда процессы начинают конкурировать за ядра ЦП. Количество переключений зависит от соотношения процессов / ядра и многозадачного разрешения вашего ядра.

дальнейшее чтение

У linfo.org есть хорошая статья о переключениях контекста и системных вызовах . В Википедии есть общая информация и хороший набор ссылок на системные вызовы.

Майкл Реннер
источник
1
Это было полезно - вы дали мне отличную идею! =)
Ксеркс
1
Ваше утверждение System calls cause context switches by their very own natureкажется неправильным. Системные вызовы вызывают переключение режимов, как указано в linfo.org/context_switch.html
Nicolas Labrot
6

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

Высокие скорости переключения контекста сами по себе не являются проблемой, но они могут указать путь к более серьезной проблеме.

редактировать: переключение контекста является симптомом, а не причиной. Что вы пытаетесь запустить на сервере? Если у вас многопроцессорная машина, вы можете попробовать установить привязку к процессору вашего основного сервера.

В качестве альтернативы, если вы используете X, попробуйте перейти в режим консоли.

Снова отредактируйте: при 16 тыс. с / с каждый процессор усредняет два переключателя в миллисекунду, что составляет от половины до шестой части нормального временного интервала. Может ли он запустить много потоков, связанных с IO?

Редактировать снова опубликовать графики: Конечно, выглядит IO привязанным. система проводит большую часть своего времени в SYS, когда переключатели контекста высоки?

отредактируйте еще раз: высокий iowait и система в этом последнем графике - полностью затмевая пространство пользователя. У вас проблемы с IO.
Какую карту FC вы используете?

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

редактировать: я думал об этом на выходных, и я видел похожие шаблоны использования, когда Бонни делает проход «записать байт за раз». Это может объяснить большое количество происходящих переключений, поскольку каждая запись потребует отдельного системного вызова.

jay_dubya
источник
Я до сих пор не убежден, что высокая скорость переключения контекста не является проблемой, я говорю о высокой, как в 4K-16K, а не 100-150.
Ксеркс
Ни один из наших серверов не работает под управлением X. Я согласен с вами относительно проблемы ожидания ввода-вывода и взаимосвязи между этим и CS. Карта HBA не является подозрительной, потому что мы используем одну и ту же карту на других сотнях или около того серверов ... Вывод заключается в том, что я обвиняю команды SAN в дурацком EVA SAN, что они отчаянно пытаются защищать все время. Обратите внимание, что высокое ожидание ввода-вывода не всегда является причиной для беспокойства. Если большинство процессов на машине связаны с вводом-выводом, ожидается, что серверу не будет ничего лучше, чтобы выполнять эти простоя.
Ксеркс
На втором же месте - приложенный 4-й график показывает, что на самом деле он не так близок, как на первый взгляд. Не совсем затмение любыми средствами. Я все еще обвиняю SAN все же. =)
Ксеркс
1

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


источник
1

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

Тем не менее, у меня есть работающие серверы (в основном, не очень загруженные серверы Oracle), которые устойчивы около 2 тыс. С некоторыми пиками 4 тыс. Для моих серверов это нормально, для серверов других людей, которые могут быть слишком низкими или слишком высокими.

Как далеко вы можете вернуться в ваших данных?

Какую информацию о процессоре вы можете дать нам?

wzzrd
источник
Я определенно согласен с сохранением базового уровня, и у нас есть данные nagios, возвращающиеся в течение длительных периодов - проблема с этим сервером в том, что он является новой кровью - существовал только в течение короткого времени. Кроме того, он запускает корпоративное программное обеспечение (читай: дерьмо) - Teamsite - просто для добавления в список неопределенных переменных. Я все еще предпочитаю sar (персональные настройки), поэтому я настрою его так, чтобы он оставлял больше, чем по умолчанию (2 недели), и посмотрю, как это будет происходить.
Ксеркс
Использование sar в сочетании с rrdtool (откуда, похоже, ваши графики) может быть простым способом хранения ваших данных (или, по крайней мере, их абстракций) в течение длительного времени.
wzzrd
0

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

Алекс Дж
источник
6
На самом деле стоимость переключения контекста стоит дорого . Это даже хуже на виртуальных машинах - несколько месяцев назад мы провели некоторое тестирование, которое показало, что одной из главных причин производительности виртуальных машин является переключение контекста.
Ксеркс
Фактически, в любой современной (многозадачной) операционной системе минимизация переключения контекста является очень важной задачей оптимизации. Есть ли у вас источники, подтверждающие ваши утверждения о том, что стоимость небольшая?
Ксеркс
Извините, вы говорите о минимизации переключений контекста с точки зрения разработки ОС? Не имея ничего общего с такой разработкой, у меня нет мнения о преимуществах разработки системы для минимизации CS :). Если вы говорите о минимизации переключений контекста на сервере, проблема заключается в том, что уменьшение переключений контекста приводит к задержке в других местах. Например, сокращение количества процессов на машине означает, что вы должны перенести эти процессы на другую машину, что означает, что связь происходит по сети, что намного медленнее!
Алекс Дж
Я считаю, что ваше определение переключения контекста неверно; они также происходят при выполнении системного вызова, даже если он возвращается в тот же поток. Приложения оптимизируются против этого, выполняя различные трюки. Например, Apache нужно очень часто получать системное время; для этого поток неоднократно вызывает localtime и сохраняет результат в разделяемой памяти. Другие потоки должны только читать из ОЗУ и не выполнять переключение процессов при этом.
niXar