Методы оптимизации, описанные в данном разделе, может быть, несколько сложнее и менее удобны для выполнения, чем те, что было описаны выше. Некоторые из них могут быть при этом нецелесообразными, если ваша база данных очень велика или если ваша система не обладает достаточными ресурсами. Выполнение работ может потребовать более длительного останова базы, чем вы можете себе позволить.
Поскольку данная монография посвящена настройке баз данных, мы не станем касаться написания приложений, но это аспект, о котором не следует забывать. Правильная конфигурация базы данных может оказать существенное влияние на производительность, но правильная архитектура приложения и программирование могут оказать еще большее влияние. Например, если ваше приложение использует запросы, которые требуют сканирования таблиц, повышение скорости сканирования таблиц никогда не будет столь же эффективным, как устранение сканирования вовсе.
Каждая таблица в базе данных имеет шаблон записи, в которой содержатся значения по умолчанию для столбцов таблицы. При создании новых записи, они инициируются за счет создания копии шаблона записи. Это происходит каждый раз, когда в 4GL выполняется оператор CREATE. Большинство приложений присваивает значения столбцам чуть позже. После создания строки следует немедленно присвоить значения всем столбцам, и это должно быть сделано в одном операторе ASSIGN. В этом случае при размещении новой записи будет учитываться ее размер, включающий значения всех столбцов. В противном случае, если при создании строки будут заполнены только некоторые значения столбцов, а остальные примут значения по умолчанию, пространство будет зарезервировано под текущий более короткий размер строки. А позднее, при заполнении остальных значений столбцов, строка будет обновлена. Если размер строки сильно изменяется между созданием строки и ее обновлением, то в отведенном для нее блоке данных может оказаться недостаточно свободного места для хранения более длинной строки. В этом случае, строка будет разделена на два или более фрагментов, и все они будут храниться в различных блоках данных, что увеличит время чтения этой записи.
Никакая настройка баз данных или ее реконфигурирование не помогут при плохо написанном приложении, поэтому не забывайте о нем. Если вам необходимо немедленно увеличить производительность любыми способами, сделайте сначала очевидное конфигурирование и настройку для базы данных, а затем вернитесь к приложению. Другой связанный с приложением фактор, который может оказывать колоссальное влияние на производительность – использование правильных индексов, способных выполнить запросы вашего приложения без необходимости полного сканирования индекса.
Вы можете определить, использует ли ваше приложение 4GL полное сканирование индекса, откомпилировав 4GL код с параметром компиляции XREF. Компилятор сообщит обо всех обращениях к базе данных и укажет к каким таблицам осуществлялся доступ и какой индекс (индексы) при этом использовались. Когда будет выполняться полное сканирование индекса, в листинге появится обозначение WHOLE-INDEX.
Для SQL-запросов, вы можете посмотреть планы выполнения, которые генерируются для конкретных запросов приложения. Заметим, что обработка SQL-запросов зачастую выигрывает от применения дополнительных индексов, помимо тех, что обычно используются в ваших хорошо написанных приложениях 4GL. Это объясняется тем, что многие SQL-запросы являются незапланированными (ad-hoc) и их сложность и объем данных, к которым они получают доступ, меняются от раза к разу.
Во многих случаях, создание дополнительных индексов может значительно улучшить производительность SQL-запросов. Если вы выполняете SQL-запрос с параметром NO-EXECUTE, вы сможет изучить план запросов, не выполняя их в действительности.
Жесткие диски вращаются с постоянной угловой скоростью, поэтому дорожки у внешнего края существенно длиннее, чем те, что расположены у внутреннего края. Это означает, что на внешних дорожках содержится больше данных и скорость передачи данных выше примерно на 20%. Создав разделы диска соответствующим образом и храня тома данных (data extents) на самом внешнем (удаленном от центра диска) разделе, можно дополнительно выжать из системы еще несколько процентов производительности.
Если контроллеры ваших дисков или операционная система не поддерживают страйпинг, можно использовать метод так называемого ручного страйпинга. Идея состоит в создании многих томов данных одинакового размера, каждый из которых будет содержать небольшой кусок всей базы данных. Затем эти тома циклически распределяются по всем дискам. Например, если у вас есть 4 жестких диска, можно создать 32 тома и поместить по 8 на каждый диск. Поместите том 1 на первый жесткий диск, том 2 на второй, том 3 на третий, том 4 на четвертый, том 5 на первый и т.д. Если ваша база данных содержит 10 ГБ данных и у вас есть 4 жестких диска, при использовании размера тома 250 МБ, вам понадобится 40 томов, по 10 на каждом диске.
Недостатками подобного ручного страйпинга являются:
Все предлагаемые сейчас компьютеры Sun, IBM и HP, работающие под UNIX, имеют 64-разрядные процессоры. В течение нескольких лет 32-разрядные процессоры уже не выпускаются. Эти системы могут использовать и 32-разрядные, и 64-разрядные версии OpenEdge.
Если для вашей системы имеется 64-разрядная версия OpenEdge, вам следует рассмотреть возможность ее использования вместо 32-разрядной версии. Основное преимущество замены – возможность использования для баз данных намного бoльших пулов буферов. В 32-разрядных версиях, область совместно используемой памяти не может быть больше примерно 2 ГБ, а для 64-разрядных версий она может составлять до 116 ГБ.
В большинстве операционных систем область совместно используемой памяти создается таким образом, что она делится на страницы механизмом страничной организации операционной системы. Если область совместно используемой памяти действительно будет делиться на страницы (из-за недостатка физической памяти), производительность базы данных будет постепенно снижаться из-за того, что доступ к буферу данных и чтение данных из базы будет вызывать дополнительные операции ввода-вывода из-за разделения области совместно используемой памяти.
Вы можете избежать подобной ситуации, заблокировав область совместно используемой памяти в оперативной памяти при помощи параметра конфигурации -pinshm.
Использование параметра -pinshm может улучшить производительность, но может и привести к ухудшению ситуации. Если у вас недостаточно физической памяти, множество экземпляров баз данных, запущенных на одном сервере, и один или более из этих экземпляров редко используется, то блокирование всех совместно используемых областей в оперативной памяти, может вызвать рост пейджинга для оставшейся виртуальной памяти, используемой приложениями и другими программами.
В системах Solaris нет необходимости использования параметра –pinshm, т.к. база данных всегда использует параметр Solaris ISM (”Initmate Shared Memory”), который также вызывает блокировку совместно используемых областей в оперативной памяти.
Параметр -pinshm недоступен в системах Windows и AIX.
Обычно OpenEdge RDBMS осуществляет операции чтения и записи в UNIX с использованием буферизованного ввода-вывода с применением системных вызовов pread()и pwrite(), в сочетании с вызовами fdatasync()(или вызовами sync() в версиях, предшествующих 10.0) в конце каждого цикла проверки для обеспечения того, что данные, записанные в буфера файловой системы будут сброшены на диск. В некоторых файловых и операционных системах, когда база данных использует буферизацию ввода-вывода, общая нагрузка на операции ввода-вывода может быть значительной. Так происходит потому, что когда процессы записи страниц записывают блоки базы на диск, данные помещаются в буферы файловой системы и записываются на диск позднее, возможно не раньше следующего вызова fdatasync (). Поэтому вся тщательная работа процессов записи страниц по планированию их активности для сглаживания процессов записи оказывается неэффективной.
При использовании параметра конфигурации -directio, база данных выполняет так называемый синхронный ввод-вывод и использует параметр O DSYNC или O SYNC при открытии файлов тома данных. В этом режиме все операции чтения и записи блоков данных используют буферы операционной системы обычным образом7, а системный вызов pwrite()не возвращает значения до тех пор, пока данные не будут посланы на диск. В результате процессы записи страниц (page writers) будут осуществлять запись несколько медленнее, но в целом скорость ввода-вывода будет более равномерной и число пиков нагрузки на диск будет меньше.
Если база данных использует синхронный ввод-вывод, можно избежать использования fdatasync(), требующих много времени вызовов8, что может блокировать поток вызовов до тех пор, пока все буферы, связанные с файлом не будут выгружены на диск.
При использовании параметра конфигурации -directio можно получить следующие преимущества:
При использовании –directio можно также увеличить число процессов записи страниц по сравнению с обычно необходимыми 1-2 процессами. Заметим, что применение параметра -directio в некоторых операционных системах дает незначительный эффект и может оказаться бесполезным в вашей ситуации. Было обнаружено, что наибольший эффект этот параметр дает в AIX-системах.
Параметр -directio может оказаться полезным и в Linux-системах, в ситуациях, когда возникает периодическое «замирание» системы под большой нагрузкой. Эти ситуации можно выявить с помощью программы vmstat,выполняющей мониторинг операций ввода-вывода на диск. Если имеются периоды высокой скорости операций ввода-вывода, после которых в течение нескольких секунд на диске операции ввода-вывода отсутствуют вовсе при большой нагрузке на систему, эту ситуацию можно исправить применением параметра -directio.
База данных OpenEdge использует имеющиеся в операционной системе семафоры для различных целей, например для управления некоторыми внутренними блокировками и для блокировки процессов, которые должны ждать снятии блокировки строки, таблицы или схемы. В некоторых UNIX-системах производительность семафоров можно повысить, используя параметр -semsets. По умолчанию, OpenEdge RDBMS использует один большой набор семафоров для каждого экземпляра базы данных. Размер этого набора семафоров определяется максимальным числом пользователей, которые могут подсоединиться к базе данных. Параметр -semsets заставляет базу данных использовать указанное число более мелких наборов семафоров. Группам пользователей выделяются отдельные наборы семафоров. Это может повысить производительность, если в ядре системы имеется внутреннее разрешение конфликта, когда несколько пользователей одновременно выполняют операции на одном наборе семафоров. Повышение производительности будет наиболее заметным в системах с числом пользователей более 150 и может составить до 5%9.
Оптимальное число семафоров зависит от конкретной нагрузки и используемой операционной системы. Мы предлагаем попытаться использовать по одному семафору на каждые 20–50 пользователей. В Linux-системах, использование параметра конфигурации -semsets не дает эффекта. Операционные системы Windows не используют наборы семафоров.
Цель журналирования after-image – дать возможность восстановления данных, если произойдет сбой диска (дисков), на которых размещена ваша база данных. Поэтому НЕЛЬЗЯ хранить никакие тома after-image на тех же физических дисках, что и тома данных.
Чередуйте тома журналов after-image между двумя дисками, поместив первый на диск 1, второй – на диск 2, третий на диск 1 и т.д. Чередование томов между двумя дисками позволяет читать и архивировать заполненные тома, не замедляя запись новых данных в текущий том. Если у вас нет недостаточного количества дисков, чтобы отвести два из них для журналирования after-image, разместите все тома after-image на одном диске.
Большинство операционных систем может работать с различными файловыми системами. Во многих случаях выбор файловой системы практически не влияет на производительность базы данных, поскольку системы баз данных обычно не создают и не стирают файлов в большом количестве. Многие файловые системы достаточно хорошо подходят для хранения баз данных, но есть и некоторые исключения. Ниже в таблице для различных операционных систем приведены некоторые файловые системы, которые хорошо работают с базами данных.
| Операционная система | Файловая система |
| Linux | ext3 или JFS |
| AIX | JFS или JFS2 |
| Solaris | UFS или VxFS |
| Tru64 | AFS |
| Windows | NTFS |
Ниже в таблице указаны некоторые файловые системы, которые никогда не следует использовать.
| Операционная система | Файловая система |
| Windows | FAT16 и FAT32 |
| HP-UX | HFS |
| Linux | ReiserFS |
Файловые системы, используемые в Linux и UNIX, имеют множество параметров, которые можно указать во время монтирования файловой системы. Один из таких параметров noatime.
Он позволяет не обновлять время последнего доступа для файлов. Указав во время монтирования системы этот параметр, можно несколько снизить дополнительные расходы при работе файловой системы. Ваши показатели могут различаться, в зависимости от операционной системы.
Во многих операционных системах, максимальный размер сегмента совместно используемой памяти устанавливается меньше, чем максимальный размер, который может использовать OpenEdge RDBMS. В этом случае база данных будет создавать много более мелких сегментов. Следует установить максимальный размер равным 128 МБ (134,217,728 байт).
В тестах под Linux, это тоже привело к увеличению производительности на скромные 2%.
В Linux-системах на ядре 2.6 вы можете выбирать из нескольких имеющихся планировщиков ввода-вывода. Тесты показывают, что некоторых из них следует избегать. Мы рекомендуем использовать планировщик ”deadline”. Избегайте использования планировщиков CFQ и опережающих планировщиков (anticipatory schedulers). Планировщик CFQ показывает особенно слабые результаты в тестах. Планировщик deadline дает производительность примерно на 10% выше, чем опережающий планировщик. Выбор планировщика производится добавлением строки в конфигурационный файл загрузки (boot loader configuration file). Например, для использования планировщика deadline, добавьте строку "elevator=deadline".
Чем больше задач вы запускаете на машине, на которой расположена база данных, тем больше ресурсов вы отнимаете у базы, снижая ее производительность. Это означает, что не следуе использовать программы печати, программы, работающие с файлами, почтовые программы, экранные заставки, Microsoft Office и т.д.
7 Вы могли слышать утверждение, что параметр -directio позволяет обойти буферы операционной системы, но это неверно
8 или вызовы sync()в версиях, предшествующих 10-й
9 Ваши показатели могут отличаться.