Использование асинхронного ввода/вывода. СУБД Oracle полностью реализует преимущества асинхронного ввода/вывода (AIO) и логического управления томами (LVM) из ОС Solaris. AIO позволяет операциям ввода/вывода перекрывать друг друга, что улучшает пропускную способность систем; LVM сокращает нагрузку на диски, распределяя данные по нескольким физическим устройствам.
В операционной системе Solaris 2 режим AIO включен по умолчанию. Он поддерживается для файлов БД, созданных в файловой системе или на устройствах непосредственного доступа. В версиях Solaris 2.4 и 2.5 AIO на устройствах непосредственного доступа улучшен за счет размещения части кода в ядро ОС, что сокращает непроизводительные переключения контекстов.
Асинхронный режим используется СУБД Oracle для параллельной записи в БД. Этот режим включен по умолчанию (параметр файла init.ora ASYNC_WRITE=TRUE). Во время восстановления Oracle в среде Solaris использует режим асинхронного чтения файлов БД. Дополнительный выигрыш во времени достигается на многопроцессорных машинах установкой параметра RECOVERY_PARALLELISM=n в файле init.ora.
В зависимости от начальной конфигурации, распределения файлов БД, ограничений на системные ресурсы и, что наиболее важно, характера нагрузки выигрыш в производительности может составлять до 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/myoldUFSfile of=/dev/rdsk/mynewRAWdevice bs=32k.
Конечно, необходимо правильно выбрать размер областей, переименовать файлы БД и установить права доступа к областям непосредственного доступа.
Если объем ОП невелик, то может потребоваться изменение размеров буферов Unix. Для большей гибкости в среде Solaris рекомендуется использовать символические ссылки, так как имена устройств непосредственного доступа могут измениться, например, при замене периферийных дисковых устройств и их реконфигурации.
Операционная система Solaris предоставляет возможность выбрать файловую систему UFS для одних файлов данных и устройства непосредственного доступа для других. Если характер рабочей нагрузки можно предсказать заранее, то возможно спроектировать расположение файлов данных, соответствующих определенным объектам БД, либо в файлах UFS, либо в областях непосредственного доступа вместе с LVM. Выигрыш от правильного распределения составляет до 50%, хотя более точные результаты зависят от нагрузки и конфигурации дисковой и файловой систем.
Планирование работы процессора и приоритеты процессов
Привязка процессов в многопроцессорных системах. Связывание некоторых процессов с конкретными процессорами может значительно повысить производительность в среде Solaris. На многопроцессорной машине необходимо проделать это вручную, используя команду pbind. Рекомендуется связать различные фоновые процессы с разными процессорами и оставлять один процессор свободным. Общее правило состоит в том, чтобы обеспечить ПП с относительно большими затратами процессорного времени более высокими приоритетами для сохранения контекста на длительное время и равномерного распределения нагрузки от ПП между доступными процессорами.
В конфигурации клиент/сервер серверный процесс можно привязать к конкретному процессору (путем привязки к нему процесса listener). Тогда все серверные процессы, порождаемые процессом listener, будут выполняться на выбранном процессоре.
Пример. 100 клиентских приложений SQL*Forms соединяются через SQL*Net с сервером Oracle на 4-процессорной машине. Пусть приложения 1–10 имеют более высокий приоритет. Схема распределения нагрузки в этом случае заключается в привязке десяти высокоприоритетных приложений к процессору 0 и распределении остальных приложений между 1-м, 2-м и 3-м процессорами. Чтобы сделать это, необходимо сначала стартовать 4-м процессам orasrv на четырех различных портах.
%tcpctl port 1256 start &
(1)9807
%tcpctl port 1257 start &
(1)9812
%tcpctl port 1258 start &
(1)9833
%tcpctl port 1259 start &
(1)9850
Затем необходимо связать каждый «слухач» соответственно с 4-мя процессорами:
%pbind -b 0 9807
%pbind -b 0 9812
%pbind -b 0 9833
%pbind -b 0 9850
Приложения 1–10 будут соединяться с СУБД через порт 1256, приложения 11–40 – через порт 1257 и т.д. Например, для приложений 41–70
%setenv TWO_TASK. T:dragon/1258:oracle
%runform
Поскольку процесс orasrv на порте 1258 привязан ко 2-му процессору, все серверные процессы для приложений 41–70 будут автоматически связаны со 2-м процессором.
Планирование заданий для режима реального времени. В дополнение к стандартному планировщику Unix в среде Solaris для приложений реального времени существует специальный планировщик. При некоторых условиях, например, в случае интенсивной оперативной обработки коротких транзакций, повышение приоритетов некоторых процессов до уровня реального времени может резко повысить производительность. Следует быть очень осторожным при использовании этого приема, так как непродуманное вмешательство может снизить производительность системы. Только в тех случаях, когда работа в режиме реального времени существенна для приложения и длительность транзакции известна и может быть настроена, допустимо использовать приоритеты уровня реального времени.
Операционная система Solaris поддерживает три класса приоритетов: с разделением времени, системный и реального времени. По умолчанию все процессы реального времени имеют более высокий приоритет (уровни 100–159), чем все системные процессы (уровни 60–99), а последние имеют более высокий приоритет, чем процессы с разделением времени (уровни 0–59). Производительность СУБД можно повысить, если поместить, например, все процессы Oracle в класс процессов реального времени. При этом, если приложения SQL*Forms выполняются на том же компьютере, то и они должны быть помещены в тот же класс.
Необходимо учитывать, что помещение процессов СУБД в класс реального времени может сильно повлиять на выполнение системных процессов и привести к сбоям ОС.
Пример. Для переноса процессов из класса «с разделением времени» в класс «реального времени» можно использовать пользовательскую команду priocntl с привилегиями суперпользователя. Для того чтобы проверить, какому классу принадлежит процесс, можно применить команду ps -с.
Определите идентификатор процесса для текущего командного интерпретатора
% echo $$
Станьте суперпользователем и переведите командный интерпретатор в класс реального времени:
# priocntl -s -с RT -i pid 2427
Запустите экземпляр Oracle и процессы listener SQL*Net. Поскольку командный интерпретатор находится в классе реального времени, то все новые процессы Oracle и listener также будут иметь приоритет реального времени.
Труднее поместить в класс реального времени прикладные процессы, так как они не принадлежат коллективно родительскому процессу. Ниже приведены некоторые способы реализации процесса помещения.
Для процессов SQL*Plus с идентификаторами 3482 и 3483:
# priocntl -s -с RT -i pid 3482 3483
Для процессов Oracle, принадлежащих пользователю orausr с идентификатором 8888:
# priocntl -s -с RT -i uid 8888
Для процессов Oracle, принадлежащих пользователям в группе oragrp с идентификатором группы 435:
# priocntl -s -с RT -i gid 435
Для запуска процесса SQL*Plus:
# priocntl -с RT -e sqlplus
Для некоторых нагрузок типа оперативной обработки транзакций корректное распределение приоритетов дает повышение производительности на 10...15 %.