Привет Повелители Linux/UNIX,
У кого-нибудь из вас есть практическое правило относительно того, сколько переключателей контекста (на ядро процессора) Нормально на сервере Linux?
Мой колледж здесь поднял это, и он видит 16K на 8-ядерном x86_64
машина.
Вот некоторые статистические данные sarface за последние несколько дней ...
И чтобы увидеть статистику создания процесса, вот логарифмическое представление того же графика ...
И 8 ядер скучно до смерти ...
CS против IOwait (масштаб x10000)
Больше бесполезной информации на случай, если кто-нибудь спросит ..
Это очень сильно зависит от типа приложения, которое вы запускаете. Если у вас есть приложения, которые очень хорошо запускают системные вызовы WRT, вы можете ожидать большого количества переключения контекста. Если большинство ваших приложений бездействуют и просыпаются только тогда, когда что-то происходит в сокете, вы можете ожидать низкой скорости переключения контекста.
Системные вызовы вызывают переключение контекста по своей собственной природе. Когда процесс выполняет системный вызов, он в основном говорит ядру взять на себя управление с его текущего момента времени и памяти для выполнения действий, которые процесс не имеет привилегий, и вернуться в то же место, когда оно выполнено.
Когда мы посмотрим на определение системного вызова write (2) из Linux, это становится очень ясным:
ИМЯ Запись - запись в дескриптор файла ОПИСАНИЕ #Include 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 есть хорошая статья о том, что контекстные переключатели и системные вызовы . Wikipedia содержит общую информацию и коллекцию ссылок Nice на системные вызовы.
мой умеренно загруженный веб-сервер работает со скоростью 100-150 переключателей в секунду большую часть времени с пиками в тысячи.
Высокие скорости переключения контекста сами по себе не являются проблемой, но они могут указать путь к более серьезной проблеме.
редактирование: переключение контекста является симптомом, а не причиной. Что вы пытаетесь запустить на сервере? Если у вас многопроцессорная машина, вы можете попробовать установить привязку к процессору вашего основного сервера.
В качестве альтернативы, если вы используете X, попробуйте перейти в режим консоли.
снова отредактируйте: при 16 тыс. с/с каждый процессор усредняет два переключателя в миллисекунду, что составляет от половины до шестой части нормального временного интервала. Может ли он запустить много IO связанных тем?
снова отредактируйте пост-графики: Конечно, выглядит IO связанный). Проводит ли система большую часть своего времени в SYS, когда переключатели контекста высоки?
отредактируйте еще раз: высокий iowait и система в этом последнем графике - полностью затмевая пространство пользователя. У вас IO проблемы.
Какую карту FC вы используете?
Правка: хммм есть ли шанс получить некоторые тесты на вашем SAN доступе с bonnie ++ или dbench в мертвый период? Мне было бы интересно узнать, имеют ли они схожие результаты.
Правка: я думал об этом на выходных, и я видел похожие шаблоны использования, когда Бонни делает проход "записать байт за раз". Это может объяснить большое количество происходящих переключений, поскольку каждая запись потребует отдельного системного вызова.
Именно поэтому вы должны стараться поддерживать базовые показатели производительности для своих серверов. Таким образом, вы можете сравнить вещи, которые вы заметили внезапно, с вещами, которые вы записали в прошлом.
Тем не менее, у меня есть работающие серверы (в основном, не очень загруженные серверы Oracle), которые устойчивы около 2К с некоторыми пиками 4К. Для моих серверов это нормально, для серверов других людей, которые могут быть слишком низкими или слишком высокими.
Как далеко вы можете вернуться в ваших данных?
Какую информацию о процессоре вы можете дать нам?
Я больше склонен беспокоиться о загруженности процессора состоянием системы. Если она близка к 10% или выше, это означает, что ваша ОС тратит слишком много времени на переключение контекста. Хотя перемещение некоторых процессов на другую машину происходит намного медленнее, это заслуживает этого.
Там нет эмпирического правила. Переключение контекста - это просто процессор, переходящий от обработки одного потока к другому. Если вы запустите много процессов (или несколько многопоточных), вы увидите больше переключателей. К счастью, вам не нужно беспокоиться о количестве переключений контекста - стоимость небольшая и более или менее неизбежна.