Конфигурирование серверов БД на платформе Sun
Оценить
(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 предусмотрен сложный планировщик, который практически всегда способен превосходно выполнять планирование среди доступных ЦП. Тем не менее,…
Оценить
(0 голоса)
Каждый процесс принадлежит к классу планирования, используемому Solaris для )пределения приоритетов разделяемого доступа к центральным процессорам. Стан-(артные классы процессора приведены на рисунке 15.4. Демоны ядра выполняются в классе SYS, а процессы пользователей - в классе TS. Сласс IA используется для приложений настольных систем ("рабочего стола"), гаран-ируя приоритет текущему окну с фокусом ввода. Вы можете просмотреть назначе-!ия классов для процессов, используя команду ps с флагом -с. Например, команда is -aefc перечисляет все процессы вместе со столбцом для класса планирования. Процессы, выполняемые в низкоприоритетных классах планирования, получат олько то время ЦП, которое останется от высокоприоритетных классов планирова-ия. Класс RT Класс RT (real-time…
Оценить
(0 голоса)
Для СУБД безопасной альтернативой классу RT является класс TS, который при необходимости также может быть модифицирован для повышения производительности. Пользовательские процессы обычно выполняются в классе TS (timeshare - с разделением времени). Чтобы определить способ изменения приоритета процесса во времени, класс TS использует диспетчерскую таблицу. Чтобы просмотреть эту таблицу, используйте команду dispadmin -с TS -д. Первая строка в таблице показывает, как интерпретировать кванты, используемые в таблице. По умолчанию принимается 1000 - кванты измеряются в миллисекундах (1/Ю00 секунды). Для каждого из 60 уровней приоритета, от 0 до 59, где 59 является самым высоким приоритетом, существует отдельная строка в таблице. Каждая строка имеет…
Оценить
(0 голоса)
В Solaris 7, но не в более поздних выпусках, ищите сценарий, называемый /etc/rc2.d/S99tsquantum. Этот сценарий автоматически управляет задачей на платформах Starfire; он представлен также и на других платформах, хотя диспетчерская таблица, которую он использует, /usr/lib/class/TS/TSbigquanta, присутствует только на Starfire. •             Повышение приоритетов процессов Даже без использования класса RT вполне возможно постоянно гарантировать некоторым процессам более высокий приоритет, чем другим. Метод включает искусственное продвижение приоритета этих процессов, поэтому они всегда выполняются с приоритетом 59 (самый высокий из допустимых), и модифицирование диспетчерской таблицы таким образом, что остальные процессы никогда не сумеют получить приоритет 59. Планирование процессов, которые всегда выполняются с приоритетом 59,…