<<
>>

Настройка СУБД в среде Solaris

Дисковые операции ввода/вывода

Использование асинхронного ввода/вывода. СУБД Oracle полностью реализует преимущества асинхронного ввода/вывода (АЮ) и логического управления томами (LVM) из ОС Solaris.

АЮ позволяет операциям ввода/вывода перекрывать друг друга, что улучшает пропускную способность систем; LVM сокращает нагрузку на диски, распределяя данные по нескольким физическим устройствам.

В операционной системе Solaris 2 режим АЮ включен по умолчанию. Он поддерживается для файлов БД, созданных в файловой системе или на устройствах непосредственного доступа. В версиях Solaris 2.4 и 2.5 АЮ на устройствах непосредственного доступа улучшен за счет размещения части кода в ядро ОС, что сокращает непроизводительные переключения контекстов.

Асинхронный режим используется СУБД Oracle для параллельной записи в БД. Этот режим включен по умолчанию (параметр файла init.ora ASYNC_WRITE=TRUE). Во время восстановления Oracle в среде Solaris использует режим асинхронного чтения файлов БД.

Дополнительный выигрыш во времени достигается на многопроцессорных машинах установкой параметра RECOVERY_PARALLELISM=n в файле initora.

В зависимости от начальной конфигурации, распределения файлов БД, ограничений на системные ресурсы и, что наиболее важно, характера нагрузки выигрыш в производительности может составлять до 50 %.

Использование логического управления томами. Средства логического управления томами (LVM), такие, как Online DiskSuite и Veritas Volume Manager, обеспечивают возможность распределения данных между несколькими физическими устройствами для сокращения нагрузки на диски. Обычно бывает трудно определить характеристики заранее. Таким образом, эффективно используя LVM, можно более равномерно распределить данные, что даст общее повышение производительности. Большое влияние на производительность СУБД оказывает размер областей (stripes), на которые делится дисковое пространство.

Рекомендуемые размеры 32 Кб и 64 Кб обычно подходят для большинства видов работы СУБД.

При разбиении физического дискового пространства необходимо соблюдать некоторые простые правила.

1. Не следует использовать области на одном физическом диске, если СУБД будет обращаться к ним одновременно.

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

3. Для того чтобы компенсировать последствия сокращения среднего времени работы без сбоев логического диска, рекомендуется использовать дополнительные возможности LVM. Эти возможности включают «зеркали- зацию» или использование дисковых массивов RAID с уровнем больше единицы на виртуальных/логических дисках, а также использование средств журнализации файловой системы и тома для более быстрого восстановления после сбоев.

4. Используя служебные программы, такие, как ОС Solaris, как sar, iostat и другие, необходимо убедиться, что операции ввода/вывода равномерно распределены между несколькими физическими дисками.

Выигрыш от эффективного распределения операций ввода/вывода с помощью LVM зависит от конкретного программного средства и характера рабочей нагрузки.

Использование системного вызова readv(). Системный вызов readv() увеличивает пропускную способность операций ввода/вывода для последовательного чтения, сокращая время работы процессора, связанное с копированием буферов. В среде Solaris наблюдается повышение производительности при использовании вызова readv() для БД, созданных в файловой системе UFS. Однако этот системный вызов ухудшает производительность, если файлы БД созданы на дисковых областях непосредственного доступа.

В СУБД Oracle по умолчанию readv() не используется. Чтобы использовать этот системный вызов необходимо установить параметр USE_READV=TRUE в файле init.ora. Ожидаемое улучшение производительности для файлов БД в файловой системе UFS составит 10...20%.

Возможное ухудшение при использовании областей непосредственного доступа — 30... 50%.

Использование параметра DB FILE MULTIBLOCK READ COUNT.

Этот параметр в файле init.ora обычно дает улучшение пропускной способности ввода/вывода. В среде Solaris его значение меняется от 1 до 512. Данный параметр должен быть установлен так, чтобы произведение значений параметров DB_BLOCK_SIZE и DB_FILE_MULTIBLOCK_READ_COUNT было больше, чем размер области (stripe), установленной LVM, что вовлекает в обработку запроса на ввод/вывод большее число физических устройств.

Использование файловой системы UFS и областей непосредственного доступа. В среде Solaris производительность СУБД очень сильно зависит от характеристик рабочей нагрузки. Например, в системах с небольшой нагрузкой, не приводящей к перегрузке буферов Unix, последовательные операции чтения (особенно повторяющиеся) быстрее выполняются в файловой системе UFS. Причиной является то, что при обнаружении больших последовательных доступов на чтение включается механизм чтения с опережением (readahead); данные остаются в буфере Unix, что ускоряет последующее сканирование того же объекта. При более высокой нагрузке ввода/вывода начинают сказываться последствия двойной буферизации данных (в буферах SGA и буферах Unix), при которой данные постоянно переносятся между этими двумя буферами во время выполнения операций ввода/вывода. В целом, на платформе Sun использование устройств непосредственного доступа дает высокую производительность и лучшую масштабируемость при повышении рабочей нагрузки на БД.

При необходимости перехода с файловой системы на устройства непосредственного доступа можно упростить процедуру перегрузки данных за счет использования команды dd:

$ dd if=/home/myoldUFSfïle of=/dev/rdsk/mynewRAWdevice bs=32k.

Конечно, необходимо правильно выбрать размер областей, переименовать файлы БД и установить права доступа к областям непосредственного доступа.

Если объем ОП невелик, то может потребоваться изменение размеров буферов Unix. Для большей гибкости в среде Solaris рекомендуется использовать символические ссылки, так как имена устройств непосредственного доступа могут измениться, например, при замене периферийных дисковых устройств и их реконфигурации.

Операционная система Solaris предоставляет возможность выбрать файловую систему UFS для одних файлов данных и устройства непосредственного доступа для других. Если характер рабочей нагрузки можно предсказать заранее, то возможно спроектировать расположение файлов данных, соответствующих определенным объектам БД, либо в файлах UFS, либо в областях непосредственного доступа вместе с LVM. Выигрыш от правильного распределения составляет до 50 %, хотя более точные результаты зависят от нагрузки и конфигурации дисковой и файловой систем.

<< | >>
Источник: Григорьев Ю.А., Ревунков Г.И.. Банки данных. 2002

Еще по теме Настройка СУБД в среде Solaris:

  1. 7.1.3. Истоки миграции в журналистской среде
  2. ВЫ В КОНКУРЕНТНОЙ СРЕДЕ И ВАМ ДЫШАТ В СПИНУ
  3. НАСТРОЙКА ОПЕРАТИВНАЯ
  4. Настройка программы
  5. Проверка и настройка.
  6. СПТ не требует предварительной настройки
  7. 6. Ребенок проходит многие ступени своей социализации через разрешение противоречий в среде своих сверстников
  8. Самоопределение и рефлексивная настройка.
  9. ТЕЛО КАК ИНСТРУМЕНТ НАСТРОЙКИ
  10. Пример настройки и реабилитации в футбольной команде
  11. 1. С развитием рыночных отношений возникает опасность усиления безнравственных и даже преступных явлений в среде детей и молодежи
  12. Особенно важные звуки для настройки тонких тел
  13. ГРАФИЧЕСКАЯ НУМЕРОЛОГИЧЕСКАЯ МАНДАЛА - СПОСОБ НАСТРОЙКИ ПОДСОЗНАНИЯ ДЛЯ РАДИЭСТЕЗИЧЕСКОЙ РАБОТЫ
  14. 2. Ребенок мыслит образами. Его самосознание предметно и образно. Он видит себя в среде других таким, каким сложился его «Я-образ»
  15. КЛЮЧ НУЖЕН ДЛЯ РАЗГРУЗКИ И ПЕРЕЗАГРУЗКИ МОЗГА – ЭТО «ОТЦИКЛИВАНИЕ» ОТ СТРЕССА И ПРОБЛЕМ, ЭТО РАЗГИПНОТИЗАЦИЯ, ОСВОБОЖДЕНИЕ СОЗНАНИЯ И НАСТРОЙКА НА БУДУЩЕЕ.
  16. ВРАБАТЫВАНИЕ
  17. Нептун