Настройка AIX и DB2 для повышения производительности DB2

Если вы используете DB2 на сервере AIX, то наверняка вы задумывались над тем, как настроить AIX чтобы DB2 работала быстрее. Эта статья затрагивает данный вопрос и, кроме того, рассматривает комбинирование параметров настройки DB2 и AIX для оптимальной производительности DB2. В статье объясняется, как спроектировать и реализовать базу данных в зависимости от нагрузки и требований, предъявляемых данными. Даны также рекомендации по оптимальному распределению базы данных на диске с точки зрения операционной системы, приведены оптимальные настройки как для операционной системы, так и для базы данных.

Артис Уолкер, консультант, IBM

Артис Уолкер (Artis Walker) является консультантом в IBM Solutions Development group. Он работает над портированием приложений и баз данных различных поставшиков на серверы pSeries с AIX. Артис имеет более чем десятилетний опыт работы как на Windows, так и на UNIX, включая AIX и Solaris. У него обширный опыт разработки программного обеспечения на DB2, ODBC, JDBC, C, C++ и Java. Он имеет степень бакалавра компьютерных наук университета St. Mary's University, San Antonio, штат Техас. С Артисом можно связаться по walkerar@us.ibm.com.



08.01.2009

Обзор

Если возникает проблема с производительностью, то скорее всего она связана с системными ресурсами или с приложением (или и с тем, и другим). Когда проблема связана с использованием системных ресурсов, AIX предоставляет возможность так настроить параметры производительности, чтобы достичь оптимального использования ресурсов согласно целям, поставленным бизнесом. C точки зрения прикладной программы DB2 является приложением промежуточного уровня, но в тоже время DB2 работает в пределах адресного пространства процесса приложения. Как и AIX, DB2 поддерживает возможность мониторинга производительности с точки зрения приложения и SQL-выражений, предоставляя большое количество параметров настройки. Некоторые параметры настройки могут рассматриваться по отдельности, и изменять их можно в зависимости от требований нагрузки, тогда как другие параметры должны анализироваться только как часть общей системы. Эта статья объясняет, как при помощи AIX и DB2 идентифицировать проблемы, проанализировать их и настроить производительность.


Производительность

Как часто бывает в среде DB2 AIX, производительность сильно зависит от двух систем - памяти и ввода/вывода дисков. С точки зрения операционной системы, избыточная подкачка страниц означает недостаток оперативной памяти. В большинстве случаев простейший способ исправить такое узкое место - это установка в сервер дополнительной оперативной памяти. Для улучшения производительности при низкой скорости вводом/выводом дисков в AIX можно применять ряд уникальных функций, которые отсутствуют в других ОС. Настройки ввода/вывода, которые можно сделать в AIX для увеличения производительности, будут дополнять улучшения производительности, полученные благодаря настройке DB2. В среде DB2 AIX можно значительно поднять производительность базы данных. C другой стороны, проблема с подсистемой ввода/вывода в DB2 может быть связана как с табличной областью, так и с неправильным использованием памяти. Но улучшение производительности табличной области в DB2 достаточно редко используется, поскольку оно требует перестройки схемы организации БД, что далеко не всегда возможно. Как будет показано далее, правильное управление памятью в DB2 увеличит производительность ввода/вывода дисков без необходимости перестройки табличной области.


Производительность DB2

Во многих случаях низкая производительность DB2 может быть вызвана интенсивным вводом/выводом данных с дисков, поэтому сокращение обращений DB2 к диску помогает увеличить производительность БД (некоторые операции ввода/вывода дисков, например журналирование, неизбежны). Следовательно, для увеличения производительности DB2 использует буферные пулы. Буферный пул - это конечная область памяти, которую DB2 использует как промежуточную область для обработки транзакций данных, а также для чтения и записи данных с диска. Конфигурационные параметры, используемые при настройке буферного пула:

  • BUFFPAGE
  • PREFETCHSIZE
  • NUM_IOCLEANERS
  • CHNGPGS_THRESH
  • NUM_IOSERVERS

Буферный пул

Перед настройкой буферного пула необходимо сначала проанализировать, какие действия выполняются в нем и сохранить соответствующие значения. В результате этих действий появится индикатор для измерения результатов производительности, достигнутых изменением параметров буферного пула. В DB2 имеется утилита мониторинга, в заданный момент времени собирающая информацию об использовании буферного пула (snapshot monitor). Данная утилита отображает все процессы, связанные со страницами, которые записывались и читались из памяти. Перед тем как делать "мгновенный снимок" буферного пула, необходимо активировать саму утилиту мониторинга, выполнив команду:

db2 update monitor switches using BUFFERPOOL on

которая выведет:

db2mn@:/home/db2mn> db2 get monitor switches
           
    Monitor Recording Switches
Switch list for node 0
Buffer Pool Activity Information   (BUFFERPOOL) = OFF
Lock Information               (LOCK) = OFF
Sorting Information             (SORT) = OFF
SQL Statement Information       (STATEMENT) = OFF
Table Activity Information       (TABLE) = OFF
Unit of Work Information         (UOW) = OFF

db2mn@:/home/db2mn> db2 update monitor switches using buffer pool on
DB20000I  The UPDATE MONITOR SWITCHES command completed successfully. 
db2mn@:/home/db2mn> db2 get monitor switches            

              Monitor Recording Switches
Switch list for node 0
Buffer Pool Activity Information  (BUFFERPOOL) = ON  10-03-2003 
   14:26:40.173684
Lock Information                  (LOCK) = OFF
Sorting Information               (SORT) = OFF
SQL Statement Information      (STATEMENT) = OFF
Table Activity Information        (TABLE) = OFF
Unit of Work Information        (UOW) = OFF

Db2mn@:/home/db2mn>

Заметим, что перед выполнением команды update monitor switches была выполнена команда для получения текущих настроек переключателя монитора:

db2 get  monitor switches

После выполнения команды update monitor switches параметр BUFFERPOOL устанавливается в ON с текущей отметкой о дате и временным ярлыком. В таком состоянии он будет оставаться до тех пор, пока его явно не отключат командой update или до тех пор, пока командами db2stop и db2start не будет остановлена и перезапущена база данных.

Чтобы команда get snapshot могла работать, необходимо соединение с базой данных:

db2 get snapshot for all bufferpools

Необходимо иметь подключение к базе данных, чтобы использовать команду get snapshot.

db2mn@:/home/db2mn> db2 'get snapshot for all bufferpools'

             Bufferpool Snapshot
             
Bufferpool name           = IBMDEFAULTBP
Database name             = SAMPLE
Database path             = /home/db2mn/db2mn/NODE0000/SQL00001/
Input database alias          =
Buffer pool data logical reads      = 22
Buffer pool data physical reads     = 7
Buffer pool data writes             = 0
Buffer pool index logical reads      = 41
Buffer pool index physical reads    = 20
Total buffer pool read time (ms)     = 24
Total buffer pool write time (ms)    = 0
Asynchronous pool data page reads    = 0
Asynchronous pool data page writes    = 0
Buffer pool index writes               = 0
Asynchronous pool index page reads     = 0
Asynchronous pool index page writes    = 0
Total elapsed asynchronous read time   = 0
Total elapsed asynchronous write time  = 0
Asynchronous read requests            = 0
Direct reads                          = 0
Direct writes                       = 0
Direct read requests                = 0
Direct write requests               = 0
Direct reads elapsed time (ms)      = 0
Direct write elapsed time (ms)      = 0
Database files closed                = 0
Data pages copied to extended storage     = 0
Index pages copied to extended storage    = 0
Data pages copied from extended storage  = 0
Index pages copied from extended storage  = 0

Для оценки использования буферного пула можно рассмотреть следующие элементы данных:

  • Buffer pool data logical reads (запросы на логическое чтение данных буферного пула): общее количество запросов на чтение, которые прошли через буферный пул.
  • Buffer pool data physical reads (запросы на физическое чтение данных буферного пула): количество выполненных запросов на чтение; при выполнении этих запросов для размещения страниц данных в буферных пулах необходима подсистема ввода/вывода.
  • Buffer pool index logical reads (запросы логического чтения индекса буферного пула): общее количество запросов на чтение индексных страниц, прошедших через буферный пул.
  • Buffer pool index physical reads (запросы на физическое чтение индекса буферного пула): количество запросов на чтение индексных страниц, для которых требуется подсистема ввода/вывода (чтобы поместить индексную страницу в буферный пул).

Ключевым аспектом при настройке буферного пула является максимальное увеличение результативности буферного и индексного пулов. Под результативностью понимается процент времени, в течение которого менеджеру базы данных для удовлетворения запроса станицы НЕ НУЖНО подгружать страницу с диска:

BufferPoolHitRatio= LogicalReads – Physical Reads  x 100
                    ----------------------------- 
                         Logical Reads

Та же самая формула подойдет и для подсчета коэффициента удачных выборок индексного пула (Index Pool Hit Ratio):

IndexPoolHitRatio= IndexLogicalReads –IndexPhysical Reads  x 100
                         --------------------------------
                               IndexLogical Reads

Для наилучшей производительности эти значения должны быть максимально близки к 75%. Коэффициент 100% означает, что база данных целиком загружена в оперативную память, но это в большинстве случаев недостижимо. Чтобы увеличить процент результативности в буферном или индексном пуле, необходимо экспериментировать с размером буферного пула (BUFFPAGE). Однако при увеличении этого значения, возможно, придется отслеживать использование системной памяти (это нужно для того чтобы после изменения BUFFPAGE не производилась страничная подкачка файлов). Для мониторинга системной памяти используется vmstat.

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

Упреждающая выборка

Упреждающая выборка - это извлечение данных (одной или более страницы) с диска в ожидании того, что эти страницы будут использоваться. Такой подход может значительно увеличить производительность SELECT-запросов путем уменьшения времени ожидания завершения запроса ввода/вывода. Параметр PREFETCHSIZE указывает DB2 поместить некоторое количество страниц (определенное в PREFETCHSIZE) в буферный пул на случай их дальнейшего использования. Значение по умолчанию - 32, но производительность улучшается в том случае, если это значение вычисляется по формуле (EXTENTSIZE * number of containers). Для агрессивной выборки и лучшей производительности значение PREFETCHSIZE может быть увеличено в 2 раза по сравнению с (EXTENTSIZE * number of containers). Вне зависимости от того, большое это число или маленькое, оно должно быть кратным EXTENTSIZE.

При настройке PREFETCHSIZE также надо изменить значение параметра NUM_IOSERVERS. Это значение должно быть следующим:

N+ ( PREFETCHSIZE/EXTENTSIZE)

где N - один или более дополнительных серверов. NUM_IOSERVERS представляет число серверов ввода/вывода, которые выполняют предварительную выборку из базы данных. Наличие дополнительных серверов ввода/вывода не снизит производительность, поскольку страницы памяти неиспользуемого сервера ввода/вывода будут выгружены из оперативной памяти. Для оптимального параллельного ввода/вывода NUM_IOSERVERS должно по меньшей мере равняться количеству физических дисков или контейнеров в базе данных.

Удаление неиспользуемых страниц

Буферный пул состоит из двух типов страниц - страницы, которые используются (т.е. страницы, которые читаются или обновляются) и "грязные страницы", которые еще не выгружены на диск. Как только грязные страницы будут выгружены на диск, они все равно останутся в буферном пуле. Однако их статус для других транзакций базы данных изменится на "очистить для повторного использования" (clean for reuse), или на "дальнейшее использование" (continual use). Здесь начинается работа утилиты по удалению страниц (page cleaner, NUM_IOCLEANERS). Такая ситуация удобна для DB2-агентов, поскольку в противном случае удаление грязных страниц из буферного пула выполняли бы они. Утилиты для удаления страниц (page cleaners) переписывают измененные (грязные) страницы из буферного пула на диск. И, как результат, транзакции приложений выполняются быстрее, поскольку DB2-агенты не должны ждать ввода/вывода. Если база данных работает только для запросов, для параметра NUM_IOCLEANERS можно оставить значение по умолчанию 1. Но если приложение будет делать обновления, добавление данных и другие транзакции, то рекомендуется установить это значение хотя бы равным количеству физических дисков в базе данных.

С NUM_IOCLEANERS также используется конфигурационный параметр CHNGPGS_THRESH. Он указывает NUM_IOCLEANERS, когда проводить поиск грязных страниц в буферном пуле. Когда процент измененных страниц в буферном пуле превысит пороговую величину (CHNGPGS_THRESH), DB2 запустит утилиты удаления страниц (page cleaners) в количестве, указанном в NUM_IOCLEANERS. Эти утилиты выгрузят грязные страницы на диск. Для большинства приложений хватит процентного значения по умолчанию (60), но для баз данных с небольшим количеством больших таблиц увеличение этого значения до 75% (CHNGPGS_THRESH) поможет увеличить производительность.


Производительность AIX

Одно из самых важных решений, которые администратор базы данных должен сделать при проектировании БД - определить, как данные будут расположены на физических разделах. Ошибки на этом важном этапе могут значительно повлиять на производительность ввода/вывода. С точки зрения операционной системы, DB2 настолько эффективна, насколько эффективна файловая система, на которой она работает. Файловая система в AIX управляется диспетчером логических томов (Logical Volume Manager, далее LVM). LVM является подсистемой AIX, которая контролирует дисковые ресурсы и обеспечивает логическое соответствие между физическими и логическими дисками. Чтобы извлечь максимальные выгоды из LVM для производительности ввода/вывода, важно правильно спроектировать размещение базы данных на физических дисках. Далее представлены некоторые рекомендованные варианты разбиения файловой системы и соответствующие параметры настройки, которые помогут извлечь максимальную производительность из LVM и DB2.

Настройки операционной системы

Чтобы DB2 мог максимально эффективно использовать ресурсы AIX, рекомендуется использовать следующие настройки:

maxuproc
Присвойте параметру устройства AIX maxuproc (максимально возможное количество процессов для пользователя) значение 4096, введя следующую команду:
chdev –l sys0 –a maxuproc=’4096’

Значение по умолчанию, присваиваемое AIX (500), слишком мало для крупных баз данных и приводит к тому, что DB2 генерирует SQL-сообщение об ошибке "SQL1402N - Unable to authenticate user due to unexpected system error" ("Невозможно аутентифицировать пользователя из-за неожиданной системной ошибки"). Для среды распределенного сервера DB2 (DB2 Partitioned Server) это значение (maxuproc) должно быть определено. Чтобы проверить значение maxuproc, выполните команду:

lsattr –l sys0 –E | grep maxuproc
ulimit и большие файлы в AIX
Чтобы в AIX можно было создавать файлы размером более 2 GB, для файловой системы должна быть установлена в истину опция "Large file enabled", и параметр fsize для владельца экземпляра DB2 должен быть установлен в -1 (соответствует бесконечной величине). Чтобы проверить сделанные установки, используя утилиту smit, выберите (из-под учетной записи ROOT):
  1. System storage management (управление памятью системы).
  2. File systems (файловые системы).
  3. Add/change/show/delete file systems (добавление/изменение/просмотр/удаление файловых систем).
  4. Journaled file systems (журналируемые файловые системы).
  5. Change/show characteristics of a journaled file system (изменение/просмотр характеристик журналируемой файловой системы (выберите файловую систему, в которой находятся данные DB2).
  6. Разрешить использование больших файлов (установить значение опции Large file enabled в TRUE).
Чтобы снять аппаратные и программные ограничения на fsize, выполните следующие две команды (из-под учетной записи ROOT):
ulimit –Hf unlimited  ( Hard Limit)
ulimit –Sf unlimited ( Soft Limit )

Для вывода значений аппаратного и программного ограничений можно использовать ulimit -Ha и ulimit -Sa соответственно. ulimit выполняет для системы конфигурацию файла /etc/security/limits.

Если не изменять значения по умолчанию в AIX, может возникнуть следующая ошибка:

SQL0968C – The file system is full.

"Нарезка" данных

"Нарезка" данных (data stripping), известная также как RAID 0, является технологией, которая была разработана для достижения максимальной производительности ввода/вывода. Основная концепция этой технологии состоит в том, что данные записываются и читаются из файловой системы "кусками" (обычно именуемыми блоками) параллельно по всей ширине пространства физических дисков. Под шириной пространства понимается число жестких дисков в RAID-массиве, а распределение данных имеет вид непрерывного размещения данных по всей ширине пространства из отдельных дисков. Однако "нарезка" RAID 0 предназначена исключительно для повышения производительности и не обеспечивает избыточности данных, поэтому сбой на одном физическом диске приведет к потере данных. Если требуется избыточность, то AIX поддерживает "нарезку" с зеркаливанием (mirroring). Несколько общих рекомендаций, приведенных далее, помогут увеличить производительность на уровне распределения данных.

max_coalesce
max_coalesce отражает максимальное количество байтов, которые драйвер SSA-устройства пытается записать и считать с логического диска SSA за одну операцию. Значение max_coalesce следует устанавливать либо равной, либо кратной размеру страйп-элемента (stripe unit), но не меньше. Этот параметр доступен только для SSA-конфигурации. Чтобы проверить текущее значение max_coalesce, выполните следующую команду:

lsattr –El hdiskN | grep max_coalesce ….

где hdiskN - номер физического тома.

Чтобы изменить значение max_coalesce, используйте команду

chdev –l hdisk# -a max_coalesce=<new value>

Например, для RAID 5 ( 5+P ) мы установили значение max_coalesce в 0x50000, которое соответствует 5x64kb:

chdev –l hdisk# -a max_coalesce=0x50000

queue_depth
queue_depth отображает максимальное число команд для одного диска hdisk, которые может координировать драйвер дискового устройства SSA. Для массива N+P установите это значение в 2*N или даже 3*N. При изменении этого значения увеличиваются шансы параллельного чтения отдельных компонентов из массива. Синтаксис для изменения этого значения такой же, как и для max_coalesce:

chdev –l hdisk# -a queue_depth=<new value>

Например, для RAID 5 ( 5+P ) queue_depth присвоено значение 15, которое найдено из 3 *N = 15

chdev –l hdisk# -a queue_depth=15

Стоит отметить, что эти значения могут быть также изменены через smit при помощи команды smitty chgssardsk.

minpgahead and maxpgahead
Первое обращение к файлу приводит к чтению первой страницы. При выборке второй страницы читается minpgahead число страниц. Последующее обращение к первой странице из группы страниц для опережающего чтения приводит к увеличению вдвое подгружаемых страниц в этой группе, вплоть до maxpgahead. Высокие значения maxpgahead необходимы для систем, в которых важна последовательная производительность, как в логических томах, организованных в RAID 0. Для minpgahead лучше оставить значение по умолчанию 2. Используя команду AIX vmtune, следует присвоить maxpgahead значение, равное 16 * количество жестких дисков (при перезагрузке значения vmtune сбрасываются в значения по умолчанию; чтобы сделать изменения постоянными, необходимо добавить эту команду в сценарий запуска AIX).

Всякий раз при увеличении maxpgahead следует убедиться, что значение maxfree также было увеличено; при этом разница между maxfree и minfree по меньшей мере должна равняться maxpgahead. Эти настройки влияют только на ввод/вывод, который осуществляется через уровень AIX LVM; непреобразованный ввод/вывод с устройств не подвергается изменениям.

Применение:

/usr/samples/kernel/vmtune  –R <new value minpgahead>

На AIX 5.2 и более поздних версий, /usr/samples/kernel/vmtune заменено на vmo.

lvm_bufcnt
Этот параметр следует настраивать при использовании приложений, которые выполняют большое количество операций ввода/вывода в обход файловой системы [как делает DB2 при использовании непреобразованных логических разделов с Database Managed System (DMS)]. Сделать это можно при помощи флага vmtune -u. Значение по умолчанию для этого параметра 9; сам параметр соответствует размеру буфера LVM (9*128k). В большинстве случаев при выполнении физического ввода/вывода большого количества данных (т.е. более 1.125 MB) узкое место может возникнуть на уровне буфера LVM, который ждет освобождения буферов оперативной памяти [pin memory buffers (pbufs)], поскольку имеющееся количество свободных pbufs-буферов было бы недостаточным. Увеличение lvm_bufcnt должно привести к увеличению объема буфера LVM и поднять производительность. На момент написания этой статьи максимально возможным значением для lvm_bufcnt было 64.

Применение:

/usr/samples/kernel/vmtune –u <new value lvm_bufcnt'

Интенсивное использование контейнера
При создании логического тома для DB2-контейнера, который будет интенсивно использоваться и обновляться, постарайтесь НЕ помещать его на диск с распределенными логическими разделами (организованными в RAID 0). Для большей производительности, в зависимости от возможных ресурсов, каждый контейнер должен помещаться на собственный диск.

Зеркалирование

Зеркалирование, известное также как RAID 1, является функциональной возможностью AIX, которая может быть полезна для DB2 на уровне размещения данных. Зеркалирование обеспечивает избыточность для высокой доступности данных. Наличие двух или более копий данных весьма существенно для сокращения времени простоя. Если одна копия оказывается неисправной, система автоматически будет использовать другую копию. AIX может обеспечить до трех копий одних данных в зеркалированной среде. Для правильного использования AIX LVM надо понимать, что зеркаливание происходит только на уровне логического тома, а не уровне физического диска. Пользователи часто ошибочно полагают, что зеркалированная разметка диска увеличит производительность в системах OLTP-типа, в которых требуется совершать много операций чтения из базы данных. Если в зеркалированной конфигурации при выполнении процедуры чтения сегмент, с которого читают данные, занят, то обычно система (за счет параллельного ввода/вывода) автоматически выполнит чтение с его незанятой копии. Однако так бывает не всегда, что будет объяснено в подразделе Накладные расходы при чтении данных.

Политика планирования записи
При использовании зеркалированных логических томов для контейнеров базы данных следует убедиться, что применяется параллельная политика планирования (Parallel) (политика по умолчанию для вновь созданных логических томов). При выполнении операций записи с последовательной (Sequential) политикой, начиная с записи в главную копию, процедуры записи выполняются последовательно; при этом процедура записи не будет полностью завершена, пока не будет выполнена запись в последнюю копию. При параллельной политике все копии обрабатываются одинаково, и запись в них осуществляется параллельно, поэтому время записи ограничено только временем, которое необходимо для выполнения записи на самом медленном диске.

Чтобы проверить используемую политику планирования, можно использовать SMIT или команду lslv. Интересующий нас параметр - SCHED POLICY:

root@isvfin-art1 /: > lslv db2lv
LOGICAL VOLUME:   db2lv            VOLUME GROUP:   db2vg
LV IDENTIFIER: 0004651700004c00000000e7bccbb849.8   PERMISSION: read/write
VG STATE:        active/complete     LV STATE:      opened/syncd
TYPE:            jfs               WRITE VERIFY:    off
MAX LPs:         512               PP SIZE:         32 megabyte(s)
COPIES:          1                 SCHED POLICY:    parallel
LPs:             3                 PPs:             3
STALE PPs:       0                 BB POLICY:       relocatable
INTER-POLICY:    minimum           RELOCATABLE:     yes
INTRA-POLICY:    center            UPPER BOUND:     32
MOUNT POINT:     /home              LABEL:          /home
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes

В приведенном выше примере также можно заметить, что опции MIRROR WRITE CONSISTENCY (непротиворечивость зеркальной записи) и WRITE VERIFY (проверка записи) отключены (OFF). Ниже будет объяснено, что случится с производительностью, если включить эти опции (ON).

WRITE VERIFY
Опция WRITE VERIFY - особенность AIX LVM, добавляющая дополнительный уровень целостности к данным. Если опция активирована (ON), для каждой выполненной процедуры записи будет выполнена процедура чтения, чтобы проверить, что запись прошла успешно. При каждой процедуре записи диск перечитывает данные и выполняет для них контроль по четности IOCC (I/O Channel Controller; командный протокол SCSI); таким образом выполняется проверка того, что данные на жестком диске в точности соответствуют данным в буфере записи. Очевидно, что эти проверки влияют на производительность записи для рассматриваемого логического тома, поскольку увеличивают время, необходимое для завершения процедуры записи. Если эта опция отключена, то AIX LVM не проверяет сделанную запись; по умолчанию опция WRITE VERIFY отключена.

MIRROR WRITE CONSISTENCY
MIRROR WRITE CONSISTENCY (MWC, непротиворечивость зеркальной записи) гарантирует, что данные непротиворечивы на ВСЕХ зеркалированных копиях. В том случае, если система сломается или аварийно отключится, MWC определит, какие копии противоречивы, промаркировав их как "stale" ("испорченные"). Если опция MWC включена, то когда система снова начнет работать, AIX прочитает log-файл MWC и сделает все копии непротиворечивыми. Хотя эта опция гарантирует целостность данных, она снижает производительность записи. Каждая процедура записи будет состоять из двух операций - одна операция для записи данных, а другая - для обновления кэша MWC. Однако на некоторых устройствах, таких как SSA-адаптеры, можно использовать встроенный кэш, что уменьшит влияние рассматриваемой опции на производительность.

Чтобы проверить, установлены ли на используемом SSA-устройстве быстрые кэш-модули, можно выполнить следующую команду: lsfg –vl <adapter name>

root@db2system /: > lscfg -vl ssa0  
  ssa0      P2-I4/Q1  IBM SSA 160 SerialRAID Adapter (14109100)
  
   Part Number................. 09L5695        
   FRU Number.................. 34L5388        
   Serial Number...............S0104160        
   EC Level.................... F23699        
   Manufacturer................IBM053        
   ROS Level and ID............7600    0000        
   Loadable Microcode Level....05        
   Device Driver Level.........00        
   Displayable Message.........SSA-ADAPTER        
   Device Specific.(Z0)........SDRAM=064        
   Device Specific.(Z1)........CACHE=32        
   Device Specific.(Z2)........UID=000008005AEBAA9C        
   Device Specific.(YL)........P2-I4/Q1

SSA-адаптер на этой системе имеет 32-мегабайтный модуль быстрого кэша (Fast Cache Module) (Device ID: Z1).

С точки зрения DB2 и AIX, задачами зеркалированного окружения являются избыточность и доступность данных и, следовательно, MWC-кэш и SSA-кэш весьма важны. Предпочтительным методом является использование SSA-кэша, а MWC следует отключить. Если требуется использовать MWC, попробуйте поместить логические тома на внешние края диска, где находится MWC-кэш. Это поможет минимизировать количество перемещений головки диска при выполнении записи.

Накладные расходы при чтении данных
Помимо преимущества, заключающегося в высокой работоспособности данных в зеркалированной среде, зеркалирование увеличивает производительность процедуры чтения. Чтобы воспользоваться этим увеличением производительности, необходимо убедиться, что политика планирования LVM является параллельной. Если политика планирования последовательная, при каждой процедуре чтения, вместо того чтобы перейти к следующей незанятой копии, всегда будет проверяться (первым) главный диск. При параллельной политике планирования система обходит эту проверку и автоматически выбирает простаивающий том, с которого будет читать.


Итоги

В продукционной среде настройка производительности базы данных является весьма сложным процессом и никогда не должна выполняться только ради дополнительного увеличения производительности. Сначала надо определить, есть ли проблема с производительностью. Если таковая присутствует, нужно идентифицировать ее и заняться ее разрешением соответствующим образом. При проектировке базы данных следует знать ее ожидаемую производительность. Неудачное проектирование базы данных может уменьшить ее производительность на 60% по сравнению с удачным проектом. Независимо от того, проводится ли создание новой базы данных или попытка улучшения производительности уже использующейся производственной базы данных, чтобы улучшить производительность подсистемы ввода/вывода с точки зрения DB2, к каждому используемому контейнеру данных следует добавить по крайней мере один буферный пул. Далее для каждого контейнера настройте параметр BUFFPAGE так, чтобы результативность стала удовлетворительной. После того как результативность была увеличена, надо настраивать PREFETCHSIZE, NUM_IOCLEANERS, CHNGPGS_THRESH и NUM_IOSERVERS вплоть до получения ожидаемых результатов (используйте утилиты snapshot monitor для создания мгновенных снимков системы и iostat для наблюдения за производительностью ввода/вывода.)

С точки зрения AIX, планирование и удачное расположение дисков являются ключевыми факторами для наилучшей производительности DB2. При проектировании базы данных эти две области игнорируются наиболее часто. В статье я рассматривал зеркалирование (mirroring) и "нарезку" данных (striping) - две наиболее популярные схемы распределения данных. Если нужно поднять производительность, следует использовать распределение данных. Если важна высокая доступность данных, нужно применять зеркалирование. Каждая схема распределения имеет свои минусы. Например, хотя "нарезка" данных и позволяет достичь наилучшей производительности при параллельном чтении и записи, отказ одного диска приведет к потере данных. Другой пример: зеркалирование обеспечит избыточность данных, однако запись данных на диск будет медленной, поскольку в ходе этого процесса фактически будет выполняться до трех процедур записи (в зависимости от того, сколько создано копий). Но благодаря гибкости LVM в AIX, настроив следующие параметры, можно минимизировать накладные расходы для каждой из этих двух конфигураций:

  • Распределение данных
    • max_coalesce
    • queue_depth
    • minpgahead
    • maxpgahead
    • lvm_bufcnt
  • Зеркалирование
    • Write scheduling policy
    • Mirror write consistency
    • Write verify

В AIX Version 4.3.3 представлена новая функция зеркалирования и распределения данных (известная также как технология RAID 0+1 или RAID 10). С позиции DB2 данная конфигурация безусловно является идеальной. В эту конфигурацию включены наиболее удачные решения из ранее рассматриваемых конфигураций (зеркалирования и "нарезки" данных) - производительность с возможностью параллельного ввода/вывода и доступность данных с возможностью иметь до трех копий. Большим недостатком этой конфигурации является стоимость физических дисков. При использовании зеркалирования и функции "нарезки" данных может понадобиться тройное или двойное количество (и объем) физических дисков.


Заключение

В этой статье были подробно рассмотрены параметры настройки AIX и DB2 для оптимальной производительности DB2. По ходу рассуждения были затронуты размещение файловой системы с позиции AIX и управление буферными пулами с позиции DB2. Также были рассмотрены несколько утилит для мониторинга в DB2 и AIX; кроме того, были показаны некоторые особенные настройки операционной системы, при помощи которых можно добиться максимального использования ресурсов DB2.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=361883
ArticleTitle=Настройка AIX и DB2 для повышения производительности DB2
publish-date=01082009