ГиперДиспетч
Эта статья нуждается в дополнительных цитатах для проверки . ( октябрь 2015 г. ) |
HiperDispatch — это функция диспетчеризации рабочей нагрузки, присутствующая в последних моделях мэйнфреймов IBM ( процессоры System z10 и IBM zEnterprise System и более поздние модели), работающих под управлением последних выпусков z/OS . HiperDispatch был представлен в феврале 2008 года. Поддержка была добавлена в z/VM в выпуске V6R3 26 июля 2013 года.
Одной из инженерных задач при проектировании больших SMP- серверов является поддержание почти линейной масштабируемости при увеличении количества процессоров . Производительность и пропускная способность не удваиваются при удвоении количества процессоров. Существует множество дополнительных факторов, включая конкуренцию за доступ к кэшу и основной памяти. Эти факторы накладных расходов становится все труднее смягчить по мере увеличения количества процессоров. Целью разработки для обеспечения максимальной производительности является минимизация этих накладных расходов. Каждая новая модель мэйнфрейма поддерживает большее максимальное количество ЦП (например, до 64 основных процессоров в одном мэйнфрейме System z10), поэтому эта инженерная задача становится все более важной.
HiperDispatch помогает решить эту проблему за счет сочетания аппаратных функций, диспетчеризации z/OS и диспетчера рабочей нагрузки z/OS . В z/OS могут существовать задачи, ожидающие обработки, например программы транзакций. Каждая задача требует частого доступа к памяти. В больших проектах SMP, таких как IBM Z , некоторые процессоры физически «ближе» и имеют более быстрый доступ к кэш-памяти, которая может хранить вспомогательные данные для определенных задач. HiperDispatch использует этот факт и направляет задачи на процессоры, которые, скорее всего, будут иметь самый быстрый доступ к соответствующим данным, уже находящимся в кэше. Если этот конкретный процессор занят, HiperDispatch сначала будет ждать, пока он завершит другую задачу, даже если другой, менее подходящий процессор, простаивает. Однако существуют ограничения на то, насколько терпеливым будет HiperDispatch, в соответствии с целями Workload Manager. Если z/OS Workload Manager обнаруживает, что существует риск того, что ожидающая задача не достигнет своего уровня обслуживания (например, отвечая в течение определенного количества миллисекунд на запрос пользователя), Workload Manager и HiperDispatch отправят задачу на простаивающий ЦП для обработки. , даже если этот процессор должен получать данные из более медленной основной памяти.
Выгода
[ редактировать ]HiperDispatch предлагает очень небольшую экономию ЦП на машинах с относительно небольшим количеством ЦП. Тем не менее, эта функция действительно помогает очень существенно по мере увеличения количества процессоров. Таблицы мощности мэйнфреймов IBM (и, следовательно, цены на программное обеспечение) основаны на предположении, что HiperDispatch активен.
Другое преимущество HiperDispatch — «парковка» логических ЦП, чтобы количество ЦП, на которых работает диспетчеризация z/OS, более точно соответствовало весу LPAR — применимо даже к небольшим конфигурациям компьютеров. (Преимуществом этого является уменьшение эффекта «короткого двигателя», что делает производительность системы более отзывчивой.
Выполнение
[ редактировать ]диспетчер рабочей нагрузки Чтобы HiperDispatch работал правильно, (WLM) должен быть правильно настроен. У некоторых пользователей мэйнфреймов есть скрытые проблемы с настройками целей WLM, которые обнаруживаются только с помощью HiperDispatch, поэтому существует возможность отключить HiperDispatch в тех случаях, когда пользователи мэйнфреймов не хотят исправлять эти проблемы сразу. Однако независимо от того, включен ли HiperDispatch или выключен, для установок важно соблюдать свою политику WLM. [1]