Конфигурирование ЦП

Оценить
(0 голоса)
Операционная среда Solaris эффективно управляет рабочими нагрузками, выполняемыми на множестве центральных процессоров, без необходимости вмешательства системного администратора. Однако для тех, кто желает провести некоторое исследование, открывается большой соблазн в области конфигурирования центральных процессоров с целью достижения оптимальной производительности. А изощренные технологии сейчас доступны для помощи в решении задач управления рабочими нагрузками. В этом разделе мы обсудим аспекты, относящиеся к управлению рабочими нагрузками: домены, наборы процессоров, а также управление ресурсами с помощью SRM (Solaris Resource Manager - менеджера ресурсов Solaris). Способность разбивки Starfire (Enterprise 10000) на отдельные системы, или домены, оказалась, без сомнений, одним из факторов, способствующих успеху этого сервера. С…
Оценить
(0 голоса)
Функции домена в качестве отдельного сервера заключаются в том. что он запускает свой собственный экземпляр операционной системы и внутри домена "видит" только память и диски. Домен даже электрически изолирован от остальных доменов. Тем не менее, благодаря динамической реконфигурации, центральные процессоры, память, диски и сети могут быть перемещены в другой домен, что позволяет добиться степени гибкости, недостижимой в отдельных серверах. Динамическая реконфигурация позволяет системным администраторам более эффективно управлять пиковыми этапами обработки путем временной пересылки ресурсов системы из менее критичного домена или домена с низким уровнем использования, такого как обучающий. В доменах часто используются отдельные рабочие нагрузки различного типа, такие как OLTP…
Оценить
(0 голоса)
Процессорные наборы еще проще, чем домены, и допускают активное разделение системы только в отношении ЦП. В системах с шестью центральными процессорами, например, для оперативных транзакций может быть создан процессорный набор с четырьмя ЦП, в то время как два оставшихся ЦП закрепляются за пакетными приложениями. Процессы приложений, ограниченные конкретным процессорным набором, будут ограничены расходованием ресурсов лишь тех ЦП, что принадлежат этому набору. Дочерние процессы наследуют связку процессорного набора и потому остаются внутри этого же процессорного набора. Выделение рабочей нагрузки OLTP дает возможность защитить время отклика пользователей, работающих в оперативном режиме, от пакетной рабочей нагрузки, не включающей время на раздумывание, предупреждая потребление…
Оценить
(0 голоса)
Другое ключевое отличие между доменами и процессорными наборами состоит в том, что единый образ операционной системы совместно используется всеми процессорными наборами. Следовательно, активность ЦП на уровне ядра обусловлена всеми активными процессами и не может быть распределена среди процессорных наборов. Тем не менее, процессорные наборы очень эффективны при разделении рабочих нагрузок приложений. Следующий пример основан на комбинированном тесте TPC-C/TPC-D, опубликованном компанией Sun в ноябре 1997 года. Как ТРС-С, так и ТРС-D (описываются в главе 26) были запущены одновременно и на одной и той же системе (Е6000 с 16 ЦП, Solaris 2.6); впервые в отрасли достигнутые результаты никогда еще не были повторены,…
Оценить
(0 голоса)
SRM 1.x вплоть до Solaris 9 представлял наиболее эффективный метод динамического разделения ресурсов ЦП среди пользователей и приложений. Для Solaris 2.6 необходим SRM 1.0, для Solaris 7 - SRM 1.1, а для Solaris 8 - SRM 1.2. Каждый пользователь описывается в файле /etc/passwd (плюс активные пользователи, подключенные посредством NIS или другим способом) как Inode (1-узел - логический узел). При помощи 1-узла расширяются свойства, связанные с пользователем, путем добавления распределений ресурсов ЦП, виртуальной памяти и ряда активных процессов. Распределение виртуальной памяти и количество активных процессов для 1-узла может контролироваться только верхним пределом, который устанавливается. Предел виртуальной памяти защищает приложения от потери…
Оценить
(0 голоса)
Бывают случаи, когда приложения совместно используют один и тот же идентификатор пользователя UNIX (например, несколько экземпляров БД). Вы можете запустить первый экземпляр с одним выделением share (долей ресурсов) и стартовать второй экземпляр под тем же идентификатором пользователя с отличающейся share, присоединяя его к другому 1-узлу и используя для этого команду srmuser. В результате два экземпляра управляются независимо с помощью SRM. Для иллюстрации использования SRM с базами данных рассмотрим пример, в котором администратор БД желает запустить два экземпляра Oracle под одним и тем же именем пользователя, oracle, и при этом осуществить для каждого экземпляра различное выделение ресурсов. Одним из возможных решений…
Оценить
(0 голоса)
Выделение разделяемых ресурсов гарантирует пользователям минимальное использование ЦП в случае, если система занята. Однако если остальные пользователи не заняты, то активные пользователи могут "красть" ресурсы ЦП у остальных пользователей внутри или за пределами их группы. Преимущество SRM по сравнению с процессорными наборами состоит в том, что группа приложений может захватить больше, чем положенные ей ресурсы, если остальные группы, разделяющие ресурсы, используют их не полностью. Например, часто приходится ограничивать пакетные приложения, чтобы предотвратить их доминирующие позиции в системных ресурсах за счет активных пользователей, работающих в оперативном режиме. Если другие группы используют свои разделяемые ресурсы полностью, то пакетные приложения могут быть ограничены…
Оценить
(0 голоса)
Использование SRM может порождать проблемы, связанные с производительностью, хотя, исходя из результатов проведенных тестов, для большинства рабочих нагрузок самым плохим вариантом является ухудшение производительности до 5% даже при 24 полностью используемых процессорах. В некоторых случаях мы даже наблюдали улучшение производительности при использовании SRM, которое проявлялось в большем кванте для процесса (110 мсек), чем принятый по умолчанию высокоприоритетный квант (20 мсек), применяемый в обычной Solaris TimeShare dispatch table (в диспетчерской таблице режима разделения времени в Solaris) на системах Enterprise с ЕЗхОО по ЕбхОО. Более подробно о Solaris TimeShare dispatch table см. в разделе "Диспетчерская таблица разделения времени на Starfire" данной главы.…
Оценить
(0 голоса)
В Solaris 9 была разработана совершенно новая и более мощная инфраструктура управления ресурсами. Эта реализация была построена на концепции project (проекта), введенной в Solaris 8 и разрешающей такой же тип контроля, включая полномочия, мониторинг и учет ресурсов, который в настоящее время доступен для пользователей. С проектом могут быть связаны задачи, а задача может быть группой процессов, таких как экземпляр БД. Управление ресурсами, включая управление ЦП и физической памятью, может быть выполнено на уровне проекта, а не только на уровне пользователя (или 1-узла), как в SRM 1.x. Расширенные особенности учета в Solaris 9 включают проекты также, как и учет на уровне…
Оценить
(0 голоса)
Поскольку процессы могут быть привязаны к процессорным наборам, то и с помощью команды pbind(lM) процессы можно привязать к одному ЦП. После привязки процесс может выполняться только на этом ЦП, даже если он занят, а остальные остаются свободными. Для достижения оптимальной производительности привязка обычно не рекомендуется в силу следующих причин: •             Привязка является жесткой, а любая заданная стратегия привязки не всегда может быть в равной степени эффективной. •             Если к каждому ЦП привязано более одного процесса, то могут возникать периоды несбалансированной нагрузки ЦП. В Solaris предусмотрен сложный планировщик, который практически всегда способен превосходно выполнять планирование среди доступных ЦП. Тем не менее,…
«ПерваяПредыдущая12СледующаяПоследняя»
Навигация