Настройка сервера базы данных Oracle и Linux

Берт Скалзо , Oracle Magazine
(Tuning Oracle Database Server and Linux,
by Bert Scalzo)

Источник: Oracle Magazine, articles online only, http://otn.oracle.com/oramag/webcolumns/2002/techarticles/scalzo_linux01.html

Часть 1: Некоторые простые способы повышения производительности Oracle 8i под Linux

Использованные средства

Сервер базы данных Oracle8i, Выпуск 3 (8.1.7); Linux 6.2 Red Hat и Quest Software's Benchmark Factory 3.0. Чтобы использовать эти технологии, вы должны обладать достаточными знаниями как в администрировании базы данных Oracle, и в управлении операционной системой Linux (или родственной ей UNIX). Но независимо от того, являетесь ли Вы официальным АБД и сисадмином UNIX, или просто АБД и "новичком" в Linux, основные советы и методы, приведенные здесь, сэкономят вам много времени. К числу рассматриваемых вопросов относятся установки файла параметров базы данных Oracle, версии ядра Linux, установки ядра и ключи трансляции, а также опции расширенной файловой системы и компилятора.

Сегодня меня, как и многих людей, приводит в восторг продвижение Linux, не только потому, что я в основном являюсь администратором базы данных на UNIX, но также и из-за той удивительной скорости, с какой такие основные производители, как Dell, HP/Compaq, IBM и Oracle, ухватились за эту открытую в исходных кодах операционную систему. В прошлом июле на выставке LinuxWorld Ларри Эллисон объявил, что к концу года все внутренние бизнес-системы в корпорации Oracle будут эксплуатироваться на Linux-кластерах (http://otn.oracle.com/techblast/archive/june2002.html) , что доказывает, что Linux – не просто преходящее увлечение.

Но что, если вы все еще эксплуатируете Oracle8i, и не совсем готовы к RAC (http://otn.oracle.com/products/oracle9i/pdf/rac_building_ha_rel2.pdf) (Real Application Clusters)? Должно удостовериться, что "выжали из репы все – до последней капли", когда мы развертываем Intel-серверы с Linux, особенно в тех случаях, когда базы данных Oracle эксплуатируются в промышленном режиме. Верите вы этому или нет, но весьма просто добиться повышения производительности базы данных на 1 000 процентов, если надлежащим образом настроить и сконфигурировать базу данных для Linux.

В этой статье я сделаю обзор некоторых подходов, обеспечивающих высокую окупаемость инвестиций (ROI - return-on-investment). Вы увидите, что по ставшему промышленным стандартом эталонному тесту от TPC (Transaction Processing Performance Council - Совет по средствам обработки транзакций) время загрузки тестовой базы данных улучшилось на 1 015 процентов, а число выполняемых за секунду транзакций увеличилось больше, чем на 45 процентов. Это в 10 раз быстрее по загрузке данных, и почти вдвое выше по скорости транзакций – на тех же самых аппаратных средствах. В части 2 этой серии мы углубимся в более “темные” и трудные методы. [От редакции OM/RE: перевод второй статьи этой серии будет опубликован в следующем номере нашего журнала. ]

Установка эталонного теста

Ниже я приведу методы настройки управляемой среды, для которой я смог построить базовую конфигурацию, идентифицировать все поддающиеся изменению релевантные переменные, а также менять каждый раз по одной переменной и получать надежное измерение эффекта этого одиночного изменения.

В качестве тестовой среды я использовал четырехпроцессорный сервер Compaq с 512 МБ памяти и восемью ультра-широкими SCSI-дисками со скоростью 7 200 оборотов в минуту. Затем я провел точно те же самые испытания с однопроцессорной системой Athlon с тем же самым объемом памяти, но всего лишь с одним ультра 100 IDE-диском со скоростью 7 200 оборотов в минуту. Хотя полученные в результате опытов (сырые – raw) цифры и проценты не были идентичными, наблюдавшаяся мной модель усовершенствования была следующей: каждое испытание делало каждую систему лучше в том же самом общем направлении и на подобные величины.

Серверы Linux чрезвычайно гибки и просты в использовании в качестве Web-серверов, серверов приложений, баз данных, электронной почты, для работы с файлами и печати, а также как маршрутизаторы, экраны межсетевой защиты и комбинаций перечисленных выше функций. Для того, чтобы удовлетворить мое требование об изменении одной переменной за раз, я ограничусь только одним использованием. В следующей статье, я рассмотрю и другие использования.

Для простоты при моих испытаниях я использовал эталонный тест TPC-C. Он широко признан как надежный эталонный тест рабочей нагрузки при онлайновой обработке транзакций (online transaction processing – OLTP). Этот тест справляется и с онлайновыми, и с отсроченными транзакциями, он неоднороден по природе, и его можно применять для множества баз данных – в том числе для всех выпусков баз данных Oracle. Вдобавок, вы можете конфигурировать TPC-C так, чтобы подчеркнуть все аспекты аппаратных средств: центральный процессор, память, шина и диск. И, чтобы быть до конца искренним, я – администратор базы данных в Quest Software, а наша компания производит полезную утилиту Benchmark Factory, которая определяет, выполняет и измеряет результаты испытаний TPC столь же простым образом, как если бы это была посылка электронной почты. На Рисунке 1 показан интерфейс Benchmark Factory: вы создаете проект эталонного теста TPC-C, определяете параметры, например, размер базы данных и число параллельно работающих пользователей, копируете тесты, которые хотите измерить для выполнения очереди, выполняете испытания в очереди и наблюдаете результаты.

Рисунок 1: Интерфейс Benchmark Factory

Я говорил, что буду рассматривать некоторые подходы с высоким коэффициентом окупаемости инвестиций. Это означает, что я буду искать элементы, настолько простые и очевидные в терминах применимости и воздействия, что мне достаточно будет всего лишь увидеть различия во времени выполнения TPC-C, чтобы понять, что я нахожусь на верном пути. Так что я буду рассматривать только то, что я называю низко висящими яблоками (low-hanging fruit) операционной системы и базы данных. В последующих статьях мы углубимся в изменения, для которых будут требоваться такие инструментальные средства Linux, как, например, команды free, iostat, ipcs, mpstat, sar, top и vmstat.

Для многих АБД следующий раздел будет просто освежением некоторых очевидных (или, возможно, "не слишком очевидных") вопросов, связанных с конфигурацией и настройкой базы данных.

Легкое достижение высокой производительности сервера базы данных (низко висящие яблоки)

Я начну с рассмотрения типичного создания базы данных. Люди часто начинают с задаваемой по умолчанию базы данных, созданной при помощи Oracle Installer, или с базы данных, которая была создана Database Configuration Assistant. Как бы то ни было, параметры по умолчанию, вообще говоря, довольно не оптимальны. Но АБД-новичок или консультант, выдающий себя за АБД, может выбрать такие значения, которые сделают ситуацию еще хуже. Дело в том, что базы данных, созданные с плохими параметрами инициализации и использующие табличные пространства для словаря данных подобно тому, как это показано в Таблице 1, встречаются не так уж редко.

Таблица 1: Типичные начальные параметры настройки базы данных

Размер блока базы данных	2 КБ
Буферный кэш SGA	64 МБ
Разделяемый пул SGA	64 МБ
Журнальный буфер в SGA	4 МБ
Файл журнала регистации событий	4 МБ
Табличные пространства	Управление по словарю

Результаты TPC-C (первичные значения)

Время загрузки (сек)	49,41
Транзакций/сек	8,152

Очевидно, что самым первым должно стать увеличение размера SGA. Поэтому я увеличиваю буферный кэш и разделяемый пул, как показано в Таблице 2.

Таблица 2: Увеличение размера буферного кэша и разделяемого пула

Размер блока базы данных	2 КБ
Буферный кэш SGA	128 МБ
Разделяемый пул SGA	128 МБ
Журнальный буфер в SGA	4 МБ
Файл журнала регистации событий	4 МБ
Табличные пространства	Управление по словарю

Результаты TPC-C

Время загрузки (сек)	48,57
Транзакций/сек	9,15

Это не совсем то, на что я не надеялся, так как улучшение времени загрузки произошло всего лишь на 1,73 процента, а увеличение скорости транзакций (transactions per seconds – TPS) на 10,88 процента. Возможно, я должен был увеличить и журнальный буфер в SGA, но я не хочу, чтобы журнал регистации событий был меньше, чем память, распределенная под SGA, так что я должен увеличить размер файла журнала регистации, как показано в Таблице 3.

Таблица 3: Увеличение размера журнального кэша SGA и файла журнала регистации

Размер блока базы данных	2 КБ
Буферный кэш SGA	128 МБ
Разделяемый пул SGA	128 МБ
Журнальный буфер в SGA	16 МБ
Файл журнала регистации событий	16 МБ
Табличные пространства	Управление по словарю

Результаты TPC-C

Время загрузки (сек)	41,39
Транзакций/сек	10,09

Похоже, что теперь я что-то нащупал. Обратите внимание, время загрузки улучшилось на 17,35 процента. А скорость транзакций улучшилась примерно на такую же величину, как и прежде – на 9,33 процента. В этом есть смысл, так как для загрузки и одновременных вставок, обновления и удаления нужно намного больше памяти, чем 8 МБ. Похоже, что увеличение выделения памяти приводят к очень малым усовершенствованиям. Кажется, проблема возникает из-за ввода/вывода, так что несмотря на то, что я работаю с системой OLTP, я буду пробовать увеличить размер блока, как показано в Таблице 4.

Таблица 4: Увеличение размера блока до 4 КБ

Размер блока базы данных	4 КБ
Буферный кэш SGA	128 МБ
Разделяемый пул SGA	128 МБ
Журнальный буфер в SGA	16 МБ
Файл журнала регистации событий	16 МБ
Табличные пространства	Управление по словарю

Результаты TPC-C

Время загрузки (сек)	17,35
Транзакций/сек	10,18

Вот теперь у меня все кипит! Даже на PC с его ограниченными возможностями шины и ввода/вывода, можно пожинать огромные выгоды от большего размера блока. Время загрузки улучшилось больше чем на 138 процентов без вреда для TPS. Предположим, мне не хочется снова увеличить размер блока. Тогда следующая простая идея, которая приходит на ум, это переключиться с табличных пространств, управляемых по словарю, на локально управляемые табличные пространства, потому что Oracle довольно интенсивно рекламировал их. Я заканчиваю с результатом, показанным в Таблице 5.

Таблица 5: Использование локальных табличных пространств

Размер блока базы данных	4 КБ
Буферный кэш SGA	128 МБ
Разделяемый пул SGA	128 МБ
Журнальный буфер в SGA	16 МБ
Файл журнала регистации событий	16 МБ
Табличные пространства	Локальное управляение

Результаты TPC-C

Время загрузки (сек)	15,07
Транзакций/сек	10,43

Итак, Oracle прав – локально управляемые табличные пространства – это, определенно, правильное направление. Я получил более чем 15-процентное улучшение времени загрузки, и приблизительно на 2 процента выросла TPS. Но в действительности я хотел бы получить результаты, которые больше похожи на результаты для размера блока 4 КБ. Я попробую 8 КБ, как в Таблице 6.

Таблица 6: Увеличение размера блока до 8 КБ

Размер блока базы данных	8 КБ
Буферный кэш SGA	128 МБ
Разделяемый пул SGA	128 МБ
Журнальный буфер в SGA	16 МБ
Файл журнала регистации событий	16 МБ
Табличные пространства	Локальное управляение

Результаты TPC-C

Время загрузки (сек)	11,42
Транзакций/сек	10,68

Не так уж плохо. Как и прежде, больший размер блока привел к улучшению времени загрузки (почти на 32 процента) без вреда для TPS. На самом деле TPS улучшилась больше, чем на 2 процента. Но заметьте, что я достиг критического положения дел с увеличением размера блока. Улучшение времени загрузки значительно уменьшилось (от 138 до 32 процентов), а увеличение TPS было почти в три раза больше, чем для размера блока 4 КБ. Дальнейшие увеличения размера блока вряд ли будут хорошим источником очевидных (настолько очевидных, что мне не нужно было использовать другие средства измерения производительности) достижений.

Так что у меня быстро подходят к концу низко висящие яблоки базы данных. Единственная другая мысль, которая приходит на ум: у меня ведь имеется несколько центральных процессоров, так, может быть, я могу создать подчиненные процессы ввода/вывода, чтобы использовать их, как в Таблице 7.

Таблица 7: Использование подчиненных процессов ввода/вывода

Размер блока базы данных	8 КБ
Буферный кэш SGA	128 МБ
Разделяемый пул SGA	128 МБ
Журнальный буфер в SGA	16 МБ
Файл журнала регистации событий	16 МБ
Табличные пространства	Локальное управляение
dbwr_io_slaves	4
Lgwr_io_slaves (вторичных)	4

Результаты TPC-C

	Время загрузки (сек)	Улуч-шение	Транзак-ций/сек	Улуч-шение
Результаты теста 1	49,41	N/A	8,15	N/A
Результаты теста 2	48,57	1,73	9,15	10,88
Результаты теста 3	41,39	17,35	10,09	9,33
Результаты теста 4	17,35	138,56	10,18	0,89
Результаты теста 5	15,07	15,13	10,43	2,36
Результаты теста 6	11,42	31,96	10,68	2,42
Результаты теста 7	10,48	8,97	10,72	0,32
Общий результат	19,48	371,47	10,72	23,93

Низко висящие яблоки Linux

Теперь давайте посмотрим на повышение производительности операционной системы Linux, которая является достаточно интеллектуальной, чтобы распознать и адаптироваться к аппаратным проблемам, типа фирмы-изготовителя, скорости и числа центральных процессоров, количества системной памяти, а также типа, скорости и количества дисковых устройств. Тем не менее, остаются пригодными для использования многие неочевидные возможности повышения производительности. В данном случае я начну с типичной инсталляции Red Hat Linux 6.2. (Примечание: я начну работу с ядра 2.2.14-5smp, которое поставляется с Linux 6.2.)

Первым заданием после установки Linux должно быть создание монолитного ядра (то есть повторная компиляция ядра для статического включения библиотек, которые вы намереваетесь использовать и отключения динамически загружаемых модулей). Идея заключается в том, что маленькое ядро, куда включены только те опции, в которых вы нуждаетесь, превосходит “жирное” ядро, поддерживающее функции, которыми вы все равно не пользуетесь. Так что я собираюсь использовать команду cd для изменения каталога на /usr/src/Linux и издам команду очистки xconfig (загрузившись для этого в интерфейс командной строки вместо системы X-Windows).

Теперь я должен установить буквально сотни параметров. Я могу рекомендовать для использования любую из дюжины хороших книг или Web-сайтов по этой теме. Тот сайт, которым я пользовался чаще других, называется Securing and Optimizing Linux: Red Hat Edition (Обеспечение безопасности и оптимизация Linux: редакция Red Hat) Герхарда Моурани (Gerhard Mourani). (Вы можете также загрузить более старую версию книги Моурани в формате PDF (PDF version http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3.pdf ). Можно также посетить список OTN Members Booklist on Amazon (http://www.amazon.com/otn\), где можно найти другие рекомендованные книги по Linux).

К числу немногих установок параметров, которые задержались в моей памяти, относятся тип центрального процессора, поддержка симметричной многопроцессорной обработки (SMP), поддержка APIC (Advanced Peripheral Interrupt Controller – усовершенствованного программируемого контроллера прерываний), поддержка DMA (прямого доступа к памяти), активация значения по умолчанию IDE DMA и поддержка квот. Мой совет – нужно пройти их все, а если у вас возникли какие-то сомнения – читать справочный файл xconfig,.

Поскольку я знаю, что я собираюсь перекомпилировать ядро, я мог бы также исправить установки параметров взаимодействия процессов (IPC), как это записано в руководстве по установке базы данных Oracle. Для ядра 2.2, установки параметров общей памяти расположены в каталоге /usr/src/Linux/include/asm/shmparam.h. Я предлагаю установить значение параметра SHMMAX не менее 0x13000000. Параметры настройки семафора расположены в каталоге /usr/src/Linux/include/Linux/sem.h. Я рекомендую установить SEMMNI, SEMMSL и SEMOPN, равными, по крайней мере, 100, 512 и 100, соответственно.

Теперь я перекомпилирую ядро, используя команду make dep clean bzImage, скопирую карту ссылок и образ ядра в мой каталог начальной загрузки, отредактирую /etc/lilo.conf, выполню lilo и перезагружусь. Если я все сделал правильно, машина загрузится, используя мое новое (более экономное и более скромное) ядро.

Применение монолитного ядра с должным образом выставленными установками параметров IPC улучшает загрузку почти на 10 процентов, а TPS – почти на 7 процентов, как показано в Таблице 8.

Таблица 8: Результаты TPC для монолитного ядра с должным образом выставленными установками параметров IPC

Время загрузки (сек)	9,54
Транзакций/сек	11,51

Если простая перекомпиляция определенной версии ядра может привести к таким улучшениям, то, наверное, стоит задуматься, а не может ли обеспечить новые усовершенствования более свежая версия ядра из того же самого семейства. На Linux Interactive я нашел исходный код последней стабильной версии ядра того же самого семейства (в моем случае, 2.2.16-3smp). Но в результате я получил совершенно несерьезные усовершенствования – 1,5 процента для загрузки и фактически ничего для TPS, как показано в Таблице 9.

Таблица 9: Результаты TPC-C для более новой (младшей) версии ядра

Время загрузки (сек)	9,40
Транзакций/сек	11,52

Поскольку многие дистрибутивы Linux теперь используют в качестве основы ядро 2.4.x, следующим я попробовал именно его. Я загрузил исходный текст ядра 2.4.1smp (сегодня наиболее устойчивый выпуск – 2.4.7). Новое ядро стоило времени, потраченного на ожидание. Оно привело к усовершенствованию времени загрузки почти на 13 процентов и больше, чем на 10 процентов увеличило TPS, как показано в Таблице 10.

Таблица 10: Результаты TPC-C для новейшей главной версии ядра

Время загрузки (сек)	8,32
Транзакций/сек	12,82

Эти результаты не плохи, но настройка ОС должна обеспечить намного больший успех, типа того, что было, когда я настроил базу данных. Когда я настроил различные параметры базы данных, я выяснил, что те элементы, благодаря которым уменьшился ввод/вывод, скажем, размеры блоков и локальное управление табличными пространствами, обеспечили большие усовершенствования. Так что, моя цель состоит в том, чтобы найти методику сокращения ввода/вывода в Linux. По умолчанию Linux обновляет для любого файла атрибут last-time-read (время последнего чтения), если с ним выполняется операция чтения, и делает это же при операциях чтения. На самом деле, меня совершенно не волнует, когда база данных Oracle в последний раз читала свои файлы данных, так что я могу выключить эту опцию. Это известно как установка атрибута файла noatime (подобная установка существует для Windows NT, 2000 и XP; используйте команду regedit, чтобы установить HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate).

Если вы хотите сделать это только для файлов данных Oracle, задайте команду - chattr +A file_name. Если вы хотите сделать это для всего каталога, команда должна иметь вид - chattr-R +A directory_name. Но лучший метод состоит в том, чтобы отредактировать файл /etc/fstab, и для каждого его входа добавить к списку параметров файловой системы ключевое слово noatime (четвертый столбец). Ниже приводится пример файла /etc/fstab с этим изменением:

LABEL=/   /      ext2  defaults,noatime 1 1
LABEL=/boot /boot    ext2  defaults,noatime 1 2
none    /dev/pts  devpts gid=5,mode=620  0 0
none    /proc    proc  defaults     0 0
none    /dev/shm  tmpfs  defaults     0 0
/dev/hda2  swap    swap  defaults     0 0
/dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro  0 0
/dev/fd0  /mnt/floppy auto  noauto,owner   0 0

Это гарантирует, что полный набор файловых систем выиграет от этой методики и, что более важно, эти установки будут сохранены в период между перезагрузками. Результаты весьма впечатляют – улучшения времени загрузки почти на 50 процентов и 8 процентов для TPS, как показано в Таблице 11.

Таблица 11: Результаты TPC-C для атрибута файла noatime

Время загрузки (сек)	5,58
Транзакций/сек	13,884

Другая область, имеющая отношение к вводу/выводу – это подсистема виртуальной памяти Linux, которая, как и многое другое в Linux, слишком управляема. Для повышения производительности файловой системы мне достаточно отредактировать файл /ect/sysctl.cong и добавить в него следующий вход:

vm.bdflush = 100 1200 128 512 15 5000 500 1884 2

где, согласно /usr/src/Linux/Documentation/sysctl/vm.txt:

• Первый параметр полностью управляет максимальным количеством грязных буферов в буферном кэше. “Грязный” здесь означает, что содержимое буфера еще должно быть записано на диск, в противоположность “чистому” буферу, о котором вы можете уже забыть. Установка этого параметра на высокое значение означает, что Linux может задержать запись на диск на долгое время, но это также означает, что он должен будет сделать за один раз большой объем ввода/вывода, когда системе станет не хватать памяти. Низкое значение разбрасывает дисковый ввод/вывод более равномерно.
• Второй параметр – 1200 ndirty, который дает максимальное количество грязных буферов, которые bdflush может записать на диск за один раз. Высокое значение означает отсроченный, пульсирующий ввод/вывод, тогда как маленькое значение может вести к нехватке памяти, когда bdflush не “просыпается” достаточно часто.
• Третий параметр – 128 nrefill, который определяет количество буферов, которые bdflush добавит в список свободных буферов при вызыве refill_freelist (). Необходимо заранее распределить свободные буфера, потому что буфера часто имеют другой размер, чем страницы памяти, и какая-то “бухгалтерия” должна быть проделана заранее. Чем больше их число, тем больше памяти будет потрачено впустую, и тем реже нужно будет выполнять refill_freelist ().
• Четвертый параметр – это 512 refill_freelist (). Когда оказывается, что он становится больше, чем nref_dirt грязных буферов, “пробуждается” (или, если угодно, запускается – прим. пер.) процесс bdflush.

Усовершенствования производительности – 26 процентов для времени загрузки и 7 процентов для TPS – показаны в Таблице 12.

Таблица 12: Результаты TPC-C при установке bdflush

Время загрузки (сек)	4,43
Транзакций/сек	14,99

Итак, вот каковы мои заключительные результаты – теперь требуется меньше 5 секунд, чтобы загрузить то, на что раньше требовалось 50 секунд, а вдобавок, я почти удвоил TPS. И помните, я не вел никакого мониторинга – все это были, главным образом, очевидные (как те яблоки, что низко висят) усовершенствования.

Вот полная итоговая таблица полученных мной результатов

	Время загрузки (сек)	Улуч-шение	Тран-закций/сек	Улуч-шение
Тест 1	49,41	N/A	8,15	N/A
Общий результат настройки базы данных	10,48	371,47	10,72	23,93
Результаты теста 8	9,54	9,85	11,51	6,9
Результаты теста 9	9,40	1,49	11,52	0,10
Результаты теста 10	8,32	12,98	12,82	10,09
Результаты теста 11	5,58	49,10	13,88	7,70
Результаты теста 12	4,43	25,96	14,99	7,37
Общий результат	4,43	70,97	14,99	17,09
Окончательный результат	4,43	1.015,35	14,99	45,61

Это значит: Linux + База данных Oracle8i = скорость

Подведем итоги

Linux и сервер базы данных Oracle хорошо согласованы по мощности и конфигурируемости. Чтобы получить от ваших аппаратных средств оптимальную возможную производительность, вы должны настроить их до хорошо сбалансированного состояния, что не является слишком трудным делом, если использовать правильные инструментальные средства и методологию. И эти усовершенствования могут заставить ваши приложения выполняться на несколько порядков величины быстрее. Так что никогда не используйте Linux или базу данных Oracle “прямо из коробки” (не используйте при установке значения по умолчанию) – вы можете заставить ваши системы мурлыкать от удовольствия, затратив на это всего несколько минут усилия.

Берт Скалзо (Bert.Scalzo@Quest.com) – архитектор программных продуктов компании Quest Software (http://www.quest.com/ ) (Ирвин, шт. Калифорния), которая предлагает решения для управления приложениями, чтобы максимизировать доступность критичных бизнес-приложений и немедленную окупаемость инвестиций (ROI). Берт имеет степени бакалавра наук, магистра наук и доктора философии в области информатики. Он работал АБД Oracle, начиная с Oracle 4, а в настоящее время он работает с базой данных Oracle9i.