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


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

Обзор

Если возникает проблема с производительностью, то скорее всего она связана с системными ресурсами или с приложением (или и с тем, и другим). Когда проблема связана с использованием системных ресурсов, 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 -Haulimit -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_bufcntlvm_bufcnt было 64. должно привести к увеличению объема буфера LVM и поднять производительность. На момент написания этой статьи максимально возможным значением для

Применение:

/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 CONSISTENCYWRITE 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 является параллельной. Если политика планирования последовательная, при каждой процедуре чтения, вместо того чтобы перейти к следующей незанятой копии, всегда будет проверяться (первым) главный диск. При параллельной политике планирования система обходит эту проверку и автоматически выбирает простаивающий том, с которого будет читать.

 по материалам ibm.com/developerworks

Оставьте комментарий