Ю. А. Григорьев, Г. И. Ревунков - Банки данных
.pdf14. Проблемы обеспечения высокой производительности
рые делится дисковое пространство. Рекомендуемые размеры 32 Кб и 64 Кб обычно подходят для большинства видов работы СУБД.
При разбиении физического дискового пространства необходимо со блюдать некоторые простые правила.
1. Не следует использовать области на одном физическом диске, если СУБД будет обращаться к ним одновременно.
2.При создании виртуальных/логических дисков следует использо вать физические области одного размера. В логических дисках размеры областей ограничены размером минимальной физической области, поэтому большие физические области будут использоваться неэффективно.
3.Для того чтобы компенсировать последствия сокращения среднего времени работы без сбоев логического диска, рекомендуется использовать дополнительные возможности LVM. Эти возможности включают «зеркализацию» или использование дисковых массивов RAID с уровнем больше единицы на виртуальных/логических дисках, а также использование средств журнализации файловой системы и тома для более быстрого восстановле ния после сбоев.
4.Используя служебные программы, такие, как ОС Solaris, как sar, iostat и другие, необходимо убедиться, что операции ввода/вывода равно мерно распределены между несколькими физическими дисками.
Выигрыш от эффективного распределения операций ввода/вывода с помощью LVM зависит от конкретного программного средства и характера рабочей нагрузки.
Использование системного вызова readvQ. Системный вызов readv() увеличивает пропускную способность операций ввода/вывода для последовательного чтения, сокращая время работы процессора, связанное с копированием буферов. В среде Solaris наблюдается повышение производи тельности при использовании вызова readv() для БД, созданных в файловой системе UFS. Однако этот системный вызов ухудшает производительность, если файлы БД созданы на дисковых областях непосредственного доступа.
В СУБД Oracle по умолчанию readv() не используется. Чтобы ис пользовать этот системный вызов необходимо установить параметр USE_READV=TRUE в файле init.ora. Ожидаемое улучшение производи тельности для файлов БД в файловой системе UFS составит 10...20%. Воз можное ухудшение при использовании областей непосредственного доступа — 30...50%.
Использование параметра DB_^FILE__MULTffiLOCK__READ COUNT.
Этот параметр в файле init.ora обычно дает улучшение пропускной способ ности ввода/вывода. В среде Solaris его значение меняется от 1 до 512. Дан ный параметр должен быть установлен так, чтобы произведение значений параметров DB_BLOCK_SIZE и DB_FILE_MULTIBLOCK__READ__COUNT было больше, чем размер области (stripe), установленной LVM, что вовле кает в обработку запроса на ввод/вывод большее число физических уст ройств.
310
14.3. Настройка СУБД в среде Solaris
Использование файловой системы 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. Рекоменду-
311
14. Проблемы обеспечеигт высокой производительности
ется связать различные фоновые процессы с разными процессорами и ос тавлять один процессор свободным. Общее правило состоит в том, чтобы обеспечить ПП с относительно большими затратами процессорного времени более высокими приоритетами для сохранения контекста на длительное время и равномерного распределения нагрузки от ПП между доступными процессорами.
В конфигурации клиент/сервер серверный процесс можно привязать к конкретному процессору (путем привязки к нему процесса listener). Тогда все серверные процессы, порождаемые процессом listener, будут выпол няться на выбранном процессоре.
Пример. 100 клиентских приложений SQL*Forms соединяются через SQL*Net с сервером Oracle на 4-процессорной машине. Пусть приложения 1—10 имеют бо лее высокий приоритет. Схема распределения нагрузки в этом случае заключается в привязке десяти высокоприоритетных приложений к процессору О и распределении остальных приложений между 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-мя процессорами:
%pbinci -b О 9807 %pbind-b0 9812 %pbind -b О 9833 %pbind -b 0 9850
Приложения 1—10 будут соединяться с СУБД через порт 1256, приложения 11—40 — через порт 1257 и т.д. Например, для приложений 41—70
%setenv TWO_TASK T:dragon/1258:oracle %runfonn
Поскольку процесс orasrv на порте 1258 привязан ко 2-му процессору, все серверные процессы для приложений 41—70 будут автоматически связаны со 2-м процессором.
Планирование заданий для режима реального времени. В допол нение к стандартному планировщику Unix в среде Solaris для приложений реального времени существует специальный планировщик. При некоторых
312
14.3. Настройка СУБД в среде Solaris
условиях, например, в случае интенсивной оперативной обработки коротких транзакций, повышение приоритетов некоторых процессов до уровня ре ального времени может резко повысить производительность. Следует быть очень осторожным при использовании этого приема, так как непродуманное вмешательство может снизить производительность системы. Только в тех случаях, когда работа в режиме реального времени существенна для прило жения и длительность транзакции известна и может быть настроена, допус тимо использовать приоритеты уровня реального времени.
Операционная система Solaris поддерживает три класса приоритетов: с разделением времени, системный и реального времени. По умолчанию все процессы реального времени имеют более высокий приоритет (уровни 100—159), чем все системные процессы (уровни 60—^99), а последние име ют более высокий приоритет, чем процессы с разделением времени (уровни О—59). Производительность СУБД можно повысить, если поместить, на пример, все процессы Oracle в класс процессов реального времени. При этом, если приложения SQL*Forms выполняются на том же компьютере, то и они должны быть помещены в тот же класс.
Необходимо учитывать, что помещение процессов СУБД в класс ре ального времени может сильно повлиять на выполнение системных процес сов и привести к сбоям ОС.
Пример. Для переноса процессов из класса «с разделением времени» в класс «реального времени» можно использовать пользовательскую команду priocntl с привилегиями суперпользователя. Для того чтобы проверить, какому классу при надлежит процесс, можно применить команду ps -с.
Определите идентификатор процесса для текущего командного интерпретатора
% echo $$ 2427
Станьте суперпользователем и переведите командный интерпретатор в класс реального времени:
# 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:
313
14.Проблемы обеспечения высокой производительности
#priocntl -S -с RT -i uid 8888
Для процессов Oracle, принадлежащих пользователям в группе oragrp с иден тификатором группы 435:
#priocntl -S -с RT -i gid 435 Для запуска процесса SQL*Plus:
#priocntl -с RT -е sqlplus
Для некоторых нагрузок типа оперативной обработки транзакций корректное распределение приоритетов дает повышение производительности на 10... 15 %.
Память и страничный обмен
Управление страничным обменом в буферах. Избыточный стра ничный обмен значительно снижает производительность, что особенно важно для БД, созданных на файловой системе. В этом случае большому числу буферов SGA могут соответствовать аналогичные буфера файловой системы UFS, содержащие наиболее часто используемые данные. Сбрасы вание измененных буферов на диск замедляет работу системы из-за высокой частоты этих сбросов и большого объема выполняемых операций, что явля ется «узким» местом, снижающим пропускную способность всей системы.
Пример. В ОС Solaris параметры ядра системы TUNETFSFLUSHR и AUTOUP управляют поведением процесса fsflushr, так называемого «демона». Через регуляр ные промежутки времени он просматривает часть страничных структур каждые TUNETFSFLUSHR секунд и циклически обходит все страничные структуры через AUTOUP секунд. Если параметр TUNE_T_FSFLUSHR равен 60 и AUTOUP равен 180, то fsflushr будет просматривать 1/3 буфера каждые 60 с и проверять весь буфер через 180 с. Правильная настройка этих параметров позволяет повысить производи тельность до 15 %.
Конфигурация свопа. Недостаточный размер области свопа приво дит к зависаниям системы или медленной реакции. В ОС Solaris своп может быть динамически сконфигурирован на файлах UFS или областях непосред ственного доступа. Его размер должен быть в 2—3 раза больше объема опе ративной памяти.
Установка размера блоков БД. В ОС Solaris логический размер блока файловой системы обычно составляет 2 Кбайт, 4 Кбайт или 8 Кбайт. Для облас тей непосредственного доступа размер блока равен 512 байт. Параметр DBBLOCKSIZE в любом случае должен быть кратным размеру блока ОС.
Для приложений типа оперативной обработки транзакций рекомен дуются небольшие размеры блоков БД — 2 Кбайт или 4 Кбайт, для систем поддержки принятия решений — 8 Кбайт.
314
14.3. Настройка СУБД в среде Solaris
Сокращение очереди к блокированным журнальным буферам.
Уменьшить очередь к блокированным журнальным буферам можно за счет сокращения времени существования блокировок или увеличения их допус тимого количества. Это достигается установкой параметров LOGSMALL ENTRY_MAX_SIZE и LOG_SIMULTANEUOS_COPlES в файле init.ora.
Настройка буферов архиватора. Увеличение размера и числа этих буферов повышает скорость архивации журналов транзакций БД на 20% и более. Однако слишком большие значения параметров LOG_ARCHIVE BUFFER_SIZE и LOG_ARCHIVR_^BUFFERS в файле init.ora могут снизить производительность системы в целом.
Использование разделяемой памяти. На платформах Sun с архитек турой Sun-4m и Sun-4d существует возможность для различных процессов, относящихся к одному адресу разделяемой памяти, совместно использовать одну страничную таблицу. Эта опция, называемая Intimate Shared Memory (ISM), повышает производительность СУБД. Она включена в ядро ОС и по умолчанию активизирована, однако ПП должна явно ее использовать. В Oracle использованием ISM управляет параметр USE_ISM=TRUE в файле init.ora.
Настройка размеров SGA. Максимальный размер сегмента разде ляемой памяти ограничен типом данных, представляющих этот параметр (это целое), и поэтому сегмент не превосходит 2 Гбайт. Другим ограничени ем является размер виртуальной памяти, адресуемой на машине конкретной архитектуры. Для большого числа одновременно работающих пользовате лей рекомендуется большой размер SGA. Параметры файла init.ora DB_BLOCK_BUFFERS и SHARED_POOL_SIZE оказывают наибольшее влияние на размер SGA.
Настройка кэш-буфера Unix. Размер буфера ввода/вывода в Solaris определяется параметром bufhwm ядра, равным максимальному объему физической памяти в килобайтах, которая может использоваться для буфе ризации. По умолчанию используется 2 % памяти, но в случае необходимо сти может использоваться до 20 %. Показатель buffer hit ratio характеризует удачный поиск затребованных данных в буфере.
Контрольные вопросы
1.Охарактеризуйте проблему обеспечения высокой производительности в системах распределенной обработки данных.
2.Назовите рекомендации по уменьшению времени обслуживания заявок ресурсами системы.
3.Опишите процесс настройки СУБД в среде Solaris.
4.Как выполняется планирование заданий для режима реального времени в среде Solaris?
315
Список литературы
1.Алеев В. Настройка Oracle в среде Solaris // Мир «Oracle». М., 1996. № 2.
С.34—37.
2.Базы и банки данных и знаний / Г. И. Ревунков, Э.Н. Самохвалов, В.В. Чис тов', Под ред. В.Н. Четверикова. М.: Высшая школа, 1992.
3.Григорьев Ю.А., Плутенко А.Д. Жизненный цикл проектов распределенных баз данных. Благовещенск, АмГУ, 1999.
4.Дадли К. Хеширование в Oracle // Мир «Oracle». М., 1996. № 5/6. С. 36—39.
5.Дунаев С.С. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования. М.: Диалог—МИФИ, 1999.
6.Длс. Ульман, Дэю. Уидом. Введение в системы баз данных: Пер. с англ. М.: «Лори», 2000.
7.МейерД, Теория реляционных баз данных: Пер. с англ. М.: Мир, 1987.
8.Фаронов В.В., Шумаков П.В. Delphi 5. Руководство разработчика баз дан ных. М.: «Нолидж», 2000.
9.Калиниченко Л.А., Когаловский М.Р. Стандарты OMG: Язык определения интерфейсов IDL в архитектуре COREA // Системы управления базами данных. М., 1996. №2. С. 115—129.
10.Шолл Ф.В. Планирование нагрузки // Lan magazine/Русское издание. М., 1996. Т. 2, №8. С. 38—43.
Учебное пособие
Григорьев Юрий Алексеевич Ревунков Георгий Иванович
Банки данных
Редактор Н.Е. Овчеренко Корректор О.В. Калашникова Художник Я Я. Константинов
Компьютерная верстка С. Ч. Соколовского
Изд. лиц. № 020523 от 25.04.97 г.
Подписано в печать 05.11.2001. Формат 70x100/16. Печать офсетная. Бумага офсетная. Усл. печ. л. 25,38. Уч.-изд. л. 26. Тираж 3000 экз.
Издательство МГТУ им. Н.Э. Баумана. 107005, Москва, 2-я Бауманская ул., д. 5.
Отпечатано с оригинал-макета в ППП «Типография «Наука». 121099, Москва, Шубинский пер., 6.
Заказ № 5249