Простой вопрос

Как SQL Server Quantum (4 мс) синхронизируется с серверной ОС Quantum (обычно 187,5 мс)?

Простой вопрос объяснил

После использования 184 мс кванта ОС (что соответствует 46 полным квантам SQL) у кванты ОС есть 3,5 мс времени, прежде чем он должен будет передать расписание другому процессу. ОС SQL запускает квант (4 мс), и после 3,5 мс квант ОС решил остановить текущий поток ОС SQL, у которого все еще есть 0,5 мс, прежде чем он выдаст расписание. Что происходит сейчас?

---

Глубокое погружение на ОС Quantum

В следующих нескольких разделах я напишу то, что я нашел до сих пор относительно кванта ОС и как можно вычислить длительность кванта. Длительность «кванта» ОС основана на «тиках», а длительность самого «тика» - на «тактовом интервале», который обычно составляет 15,625000 мс. Но позвольте мне остановиться подробнее ...

Поставить галочку

В статье блога Know Thy Tick автор Джим объясняет основы тактовых интервалов (или «тиков») и для чего они нужны.

Когда я читаю что-то вроде «тактовый интервал… для большинства мультипроцессоров x86 составляет около 15 миллисекунд», я вынужден определить значение моего тактового интервала, или «тикового» интервала. К счастью, в книге, в которой я читал эту цитату, «Четвертое издание Windows Internals», есть справка, которая поможет мне справиться со своими проблемами. ... Автор вышеупомянутой книги Марк Руссинович любезно предоставил утилиту ClockRes на своем веб-сайте. Запустив эту утилиту, я смог определить, что тактовый интервал на моем многопроцессорном компьютере x86 составляет 15,625000 мс. Интересно, но мой любопытный ум хочет знать больше.

квант

Автор статьи продолжает объяснять в своей второй статье тот...

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

Хорошо, я знаю, что такое квант, но не знаю, как долго он будет работать.

А пока давайте просто рассмотрим квантовое значение по умолчанию для потока переднего плана в XPe. В этом случае планировщик Windows назначает такт из 18 или 6 интервалов тиков. (Да, чтобы преобразовать квантовые интервалы в тиковые, нужно делить на 3. ..., но причина для кратного состоит в том, чтобы планировщик мог «заряжать» поток за выполнение операции, которая вызывает его приостановку.)

Теперь мы знаем, что тактовый интервал (тик) должен составлять около 15,625000 мс, а в Windows Desktop OS, где квант по умолчанию равен 18, что приведет к 6 тикам или 93,750000 мс (18/3 * 15,625000 мс).

В ОС Windows Server квант по умолчанию отличается. Параметр «Планирование процессора» имеет значение «Фоновые службы»

^{Этот параметр можно найти в «Системных настройках | Дополнительно (вкладка) | Производительность (раздел) | Настройки ...», которые откроют «Параметры производительности | Расширенные (вкладка) | Планирование процессора»}

Квантовые настройки по умолчанию - от 36 (Фон) до 36 (Передний план). Квант больше и, следовательно, длиннее. Это вдвое больше, чем 93,750000 мс из 18 (6 тиковых) параметров квантового переднего плана в ОС Windows для настольных ПК, что в серверной ОС, настроенной для фоновых служб, составляет около 187,500000 мс.

Наблюдение / Объяснение

При изменении значения параметра «Фоновые службы» на «Приложения» на сервере или настольном компьютере ключ HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation в реестре изменяется с 0x18 на 0x02. Какое значение по умолчанию для 0x02? Это можно найти в комментарии:

Значение 0x02 означает, что поля «Короткий против длинного» и «Переменный против фиксированного» являются значениями по умолчанию для ОС.

Значения по умолчанию для этих полей для XPe & XP Pro: Short & Variable, что аналогично установке следующих битов в дополнительных битах: 0x24.

ИЛИ, добавив это значение в 0x02, вы получите 0x26, который вы найдете в таблице в статье.

^{Ссылка: Комментарий к "Освой свой квант" (блоги MSDN)}

Таблица, объясняющая квантовые настройки из той же статьи:

Win32PrioritySeparation   Foreground   Background
0x28, 0x29, 0x2A                  18           18
0x18, 0x19, 0x1A                  36           36
0x24                               6            6
0x25, 0x14                        12            6
0x26                              18            6
0x15                              24            6
0x16                              36            6

Краткое описание ОС Quantum

Основываясь на приведенной выше информации и цитатах из статей, мы знаем, что квант не является фиксированным размером, а скорее получен из настройки ОС в Свойствах системы. Квант изменяется в зависимости от Win32PrioritySeparationпараметра в реестре, который обычно соответствует одному из параметров в «Свойствах системы» («Фоновые службы» или «Приложения»).

Квант на уровне ОС

• для настройки «Приложения»
  • 18 (что составляет 6 тиков) для приложений переднего плана (93,75 мс)
  • 6 (что составляет 2 галочки) для фоновых приложений (31,25 мс)
• для настройки «Фоновые службы»
  • 36 (что составляет 18 тиков) для приложений переднего плана (187,5 мс)
  • 36 (что составляет 18 тиков) для фоновых приложений (187,5 мс)

Итак, теперь мы знаем, что квант ОС при настройке Windows Server для оптимизации для фоновых служб ...

36 / 3 * 15.625000 ms = 187.5 ms

---

SQL OS Quantum

В этом разделе перечислены то, что я нашел на квантовой ОС SQL ...

SOS_SCHEDULER_YIELD Тип ожидания

Из описания Пола Рэндалла о типе ожидания SOS_SCHEDULER_YIELD:

Это тип ожидания, когда поток мог выполнить для своего полного потока (4 миллисекунды во всех версиях SQL Server, неизменяемый ) и поэтому добровольно выдал планировщик, переместившись в конец Runnable Queue в своем планировщике.

^{Ссылка: SOS_SCHEDULER_YIELD (Типы ожидания SQLSkills.com)}

Планировщики в SQL Server DMV

В пояснении к DMV для SQL Server для DMV sys.dm_os_schedulers.

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

В противоположность этому, SQL Server использует механизм совместного планирования, когда потоки могут добровольно выдавать свой квант времени (вы можете увидеть это поведение, когда у вас есть тип ожидания SOS_SCHEDULER_YIELD). Это позволяет SQL Server оптимизировать загрузку ЦП, поскольку, когда поток получает сигнал о выполнении, но не готов к запуску, он может дать свой квант времени в пользу других потоков .

^{Ссылка: Понимание планировщиков SQL Server, рабочих и задач (MSSQLTips.com)}

Определить нагрузку на процессор SQL Server

Это очень маленький раздел статьи, касающейся нагрузки на процессор в SQL Server.

Происходит, когда задача добровольно дает планировщик для выполнения других задач. Во время этого ожидания задача ожидает обновления кванта .

^{Справка: определение нагрузки на процессор SQL Server (MSSQLTips.com)}

sys.dm_os_schedulers (Документы Microsoft)

Я предполагаю, что следующая цитата - самый важный фрагмент информации о квантах SQL OS, который я мог найти:

quantum_length_us bigint  Identified for informational purposes only. 
                          Not supported. Future compatibility is not guaranteed. 
                          Exposes the scheduler quantum used by SQLOS.

^{Ссылка: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Документы)}

---

Моя загадка

Серверная ОС Quantum регулирует, сколько времени предоставляется службе SQL Server для выполнения «задач». Операционная система SQL Server Quantum определяется как 4 мс. Если я разделю 187,5 мс на 4 мс, то у меня останется 3,5 мс.

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

Простой вопрос

Как SQL Server Quantum (4 мс) синхронизируется с серверной ОС Quantum (обычно 187,5 мс)?

Простой вопрос объяснил

После использования 184 мс кванта ОС (что соответствует 46 полным квантам SQL) у кванты ОС есть 3,5 мс времени, прежде чем он должен будет передать расписание другому процессу. ОС SQL запускает квант (4 мс), и после 3,5 мс квант ОС решил остановить текущий поток ОС SQL, у которого все еще есть 0,5 мс, прежде чем он выдаст расписание. Что происходит сейчас?

Хотя планировщик не имеет преимуществ, планировщик SQL Server по-прежнему придерживается концепции кванта. Вместо того, чтобы задачи SQL Server были вынуждены отказаться от ЦП операционной системой, они могут периодически запрашивать постановку в очередь ожидания, и если они превысили внутренний 4-миллисекундный квант и не находятся в середине операции это не может быть остановлено, они добровольно отказываются от процессора.

- « Внутренние компоненты Microsoft SQL Server 2012 », Kalen Delaney et. и др. PP38

Глава 2 «SQLOS» Джонатан Кехайяс

Таким образом, понятие «квант» внутри SQL Server - это скорее «руководство» для задач программирования. То есть, когда вы пишете задачу, например, задачу, которая выполняет сканирование таблицы, если вы не нажали какое-либо время защелки страницы, защелки ввода-вывода или блокировки, вы должны остановить то, что вы делаете, и попросить об этом. вернуть в работоспособную очередь, если ожидают другие задачи.

Но программист должен реализовать это, и это может быть не ровно 4 мс для каждого вида задач. Например, задача проверки таблицы может использовать простую эвристику, основанную на количестве отсканированных страниц, для реализации пределов текучести.

Так

ОС SQL запускает квант (4 мс), и после 3,5 мс квант ОС решил остановить текущий поток ОС SQL, у которого все еще есть 0,5 мс, прежде чем он выдаст расписание. Что происходит сейчас?

Если поток SQL Server переопределяется Windows во время выполнения задачи, он будет приостановлен, а когда следующий поток запланирован на ЦП, он продолжит с того места, на котором остановился. Предположительно, он продолжит поглощать баланс своего кванта 4 мс, поскольку он не будет знать никакой разницы. Но опять же, поведение yield - это деталь реализации задачи, а не поведение SQLOS, поэтому разные задачи могут вести себя по-разному.

_{Отвечать на взносы, первоначально оставленные как комментарии}

Как SQL Server Quantum (4 мс) синхронизируется с серверной ОС Quantum (обычно 187,5 мс)?

Это не так, и SQL Server не использует упреждающее планирование. Ожидается, что рабочие элементы будут достигать предела доходности, а если нет, вы получите такие вещи, как NONYIELDINGпланировщики. Здесь нет паритета. SQL Server не распределяет время. Это делает определенные потоки привлекательными для Windows по расписанию, а Windows - по расписанию. Квант - это просто номенклатура на отрезок времени. Вот и все. SQL Server не является преимущественным, он несет ответственность за то, что работает, чтобы привести себя в коде. - Шон Галларди

Когда квант ОС истекает, поток принудительно отменяется. Это прозрачно для SQL Server. SQLOS не может определить, когда это происходит. Для этого не существует Win32 API. Планирование прозрачно для потоков пользовательского режима. Планировщик Windows не знает и не заботится о том, что делают потоки пользовательского режима. Windows видит только потоки, которые могут быть запущены, и позволяет им работать до конца своей операционной системы или до их блокировки. - usr

В статье «Как обрабатывать чрезмерные значения типа ожидания SOS_SCHEDULER_YIELD в SQL Server » Николая Димитриевича термин «квант» используется для обозначения, по существу, «времени, которое задача фактически тратит, назначенного работнику», но это не то же самое, что квант Windows, это период времени, после которого ОС удалит поток из процессора. Это просто разные концепции. Если ОС вынуждает поток завершить выполнение, потому что квант ОС достигнут, происходит переключение контекста. Поток SQL Server приостановлен, как и любая другая программа. - Дэвид Браун - Microsoft и Джордж . Паласиос .

---

Выдержки из документации: Внутри планировщика пользовательских режимов SQL Server 2000 (написано для SQL Server 2000, но все еще актуально):

Упреждающая и совместная работа

UMS, напротив, полагается на потоки, чтобы добровольно уступать. UMS использует такой подход, чтобы удерживать ядро ​​Windows больше, чем это абсолютно необходимо. В системе, где рабочие потоки могут рассчитывать на результат, когда они должны, кооперативный планировщик может фактически быть более эффективным, чем упреждающий, потому что процесс планирования может быть приспособлен к конкретным потребностям приложения. Как я уже говорил ранее, UMS знает, что потребности SQL Server в планировании лучше, чем можно ожидать от операционной системы.

Как UMS берет на себя планирование

Если UMS должна обрабатывать потребности планирования SQL Server, а не позволять Windows делать это, UMS должна каким-то образом препятствовать тому, чтобы ОС делала то, что она делает с любым другим процессом: планировать потоки на процессоре (ах) системы и выключать их по своему усмотрению. Как вы это делаете в упреждающей ОС? UMS справляется с этим с помощью хитрых трюков с объектами событий Windows. Каждый поток в UMS имеет связанный объект события. В целях планирования Windows игнорирует потоки, которые она не считает жизнеспособными - потоки, которые не могут работать, потому что находятся в состоянии бесконечного ожидания. Зная это, UMS переводит потоки в спящий режим, который он не хочет планировать, заставляя их вызывать WaitForSingleObject для соответствующего объекта события и передавая INFINITE для значения тайм-аута.

Чтобы запретить Windows планировать несколько потоков на одном и том же процессоре и, таким образом, нести накладные расходы и затраты на переключение контекста, UMS пытается сохранить жизнеспособным только один поток, то есть не в состоянии бесконечного ожидания, на каждый процессор.