Мы пытаемся понять, как работает Планировщик Windows CPU, чтобы оптимизировать наши приложения для достижения максимально возможного соотношения инфраструктуры/реальной работы. В xperf есть некоторые вещи, которые мы не понимаем, и хотели бы попросить сообщество пролить свет на то, что действительно происходит. Мы изначально начали исследовать эти проблемы, когда получили отчеты о том, что некоторые серверы были «медленными» или «не отвечающими».Планировщик Windows CPU - очень высокое время ядра
Справочная информация
У нас есть R2 сервер для Windows 2012, который запустит нашу промежуточную инфраструктуру со следующими характеристиками.
Мы обнаружили, что 30% CPU теряется в ядре, поэтому мы начали копать глубже.
Сервер выше прогонов «хозяина» ~ 500 процессов (как услуги окон), каждый из этих процессов «хозяина» имеет внутренний в то время как цикл с задержкой ~ 250 мс (фу!), И каждый из тех процессов «хозяина» могут иметь ~ 1..2 «дочерние» процессы, которые выполняют фактическую работу.
Имея бесконечный цикл с задержкой 250 мс между итерациями, фактическая полезная работа для приложения «хозяин» для выполнения может появляться только каждые 10,15 секунды. Таким образом, существует много циклов, потраченных на ненужные петли.
Мы знаем, что дизайн приложения «хозяин» является, по меньшей мере, оптимальным, применимым к нашему сценарию. Приложение меняется на модель, основанную на событиях, которая не требует цикла, и поэтому мы ожидаем значительного сокращения времени ядра на графике использования ЦП.
Однако, хотя мы изучали эту проблему, мы сделали некоторый анализ xperf, который вызвал несколько общих вопросов о Планировщике процессора Windows, для которого мы не смогли найти четких/кратких объяснений.
То, что мы не понимаем
Ниже приведен скриншот одного из XPERF сессий.
Вы можете видеть из "Использование CPU (Precise)", что
Там в 15 мс время дольки, из которых большинство из них в полной мере. Использование этих срезов составляет ~ 35-40%. Поэтому я предполагаю, что это, в свою очередь, означает, что процессор используется примерно в 35-40% случаев, но производительность системы (скажем, наблюдаемая при случайном перетаскивании по системе) равна действительно вялой.
С этим у нас есть эта «загадочная» 30-минутная стоимость ядра, судя по графику использования процессора диспетчера задач.
Некоторые процессоры, очевидно, используются для всего 15 мс среза и за его пределами.
Вопросы
Что касается Windows, планирования CPU на многопроцессорных системах обеспокоены:
- Что вызывает 30% от стоимости ядра? Контекстное переключение? Что-то другое? Какое внимание следует уделить написанию приложений для снижения этой стоимости? Или даже - добиться идеального использования с минимальными затратами на инфраструктуру (на многопроцессорных системах, где количество процессов выше, чем количество ядер)
- Что это за 15 мс?
- Почему загрузка процессора имеет пробелы в этих срезах?
Это * Вопрос и ответ * сайт, что означает один конкретный вопрос за сообщение в качестве общего правила. В некоторых случаях может быть приемлемо несколько связанных вопросов. Шесть вопросов о таком широком спектре, который связан с ОС, а не связанный с ним, действительно толкают вещи. MS документировала дизайн планировщика, и это обсуждалось на многих сообщениях в блогах MS. Ничто из того, что вы просили, связано с программированием в каком-то определенном смысле, кроме * программ, запущенных на ОС *. –
Вы не пишете программное обеспечение отдельно от операционной системы. –
Это зависит от того, что на самом деле делают «рабочие» процессы. Если не так много работы с процессором (если вы в основном ожидаете ввода-вывода или что-то еще), то ожидаемый процессор будет ожидаться. Точно так же, если большая часть вашего времени потрачена на выполнение вызовов ОС - особенно простоя циклов - 30% времени ядра не кажется необоснованным. Для * оптимальной * производительности вам нужно гораздо меньше процессов. Предпочтительно только один. Вы не говорите, создаете ли вы рабочие процессы «на лету», но если это так, вы должны заметить, что запуск процесса очень медленный. –