Неблокирующие контрольные точки в Informix Dynamic Server

Настройка сервера данных Informix Dynamic Server для использования неблокирующих контрольных точек и параметра RTO_SERVER_RESTART в среде оперативной обработки транзакций

Являетесь ли вы опытным или начинающим администратором баз данных, вы, вне всякого сомнения, захотите получить максимальную производительность при обработке транзакций с помощью сервера данных IBM® Informix Dynamic Server (IDS). Из этой статьи вы узнаете о новой функциональности сервера IDS версии V11.1 (условное наименование Cheetah) – в том числе о неблокирующих контрольных точках (non-blocking checkpoint) и о параметре RTO_SERVER_RESTART файла ONCONFIG - которая помогает администратору баз данных настраивать серверы для достижения максимальной производительности при обработке транзакций в OLTP-среде.

Введение

Для кэширования обновлений в транзакциях приложений (результатов операций INSERT/UPDATE/DELETE) сервер IBM Informix Dynamic Server (IDS) использует специальную область памяти – т.н. буферный пул (bufferpool). Это существенно повышает производительность, поскольку после фиксации транзакций серверу не приходится «сбрасывать» их в стабильное (дисковое) хранилище. Обновления также записываются в стабильное хранилище, но «логическим» образом (в журнал logical log или в журнал redo log), что позволяет в случае внезапного сбоя восстановить все зафиксированные транзакции. Если такой сбой произошел, сервер IDS по журналу redo log осуществляет логическое обновление транзакций с целью восстановления транзакционно-согласованного состояния системы на момент прерывания ее работы.

Буферный пул

В этом документе термином «буферный пул» (bufferpool) обозначается один или несколько буферных пулов, сконфигурированных для данной системы.

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

Моменты времени, в которые сервер IDS осуществляет периодический сброс содержимого буферного пула на диск, называются контрольными точками (checkpoint). В предыдущих версиях IDS применялся алгоритм с блокирующими контрольными точками, который заставлял систему блокировать все обновления транзакций на период сброса содержимого буферного пула на диск. В версии IDS Version 9 был реализован дополнительный алгоритм контрольной точки под названием Fuzzy Checkpoint (нечеткая контрольная точка). Предполагалось, что этот алгоритм ограничит количество обновлений, подлежащих сбросу на диск в процессе обработки контрольной точки. К сожалению, этот алгоритм не устранил полностью такое явление, как блокирование транзакций на период сброса содержимого буферного пула на диск. Более того, этот алгоритм внес элемент непредсказуемости в процесс восстановления базы данных после внезапного сбоя.

Выбор метода настройки контрольных точек является важнейшей проблемой для многих администраторов баз данных. Приложения, чувствительные ко времени отклика, нуждаются в весьма «жестких» настройках сброса на диск по принципу LRU (далее в тексте – LRU-сброс), чтобы ограничить блокирование транзакций, связанное с контрольными точками. Приложения, нуждающиеся в гарантированном целевом времени восстановления (RTO), стремятся регулировать частоту формирования контрольных точек с целью ограничения времени, затрачиваемого сервером IDS на восстановление при сбоях. Приложения, нуждающиеся одновременно в обеих политиках, обнаруживают, что они действуют «друг против друга». Избыточная частота контрольных точек приводит к нежелательной блокировке транзакций; недостаточная частота контрольных точек может увеличить продолжительность восстановления. Попытка настроить сервер на одновременное соблюдение обеих политик может оказаться безнадежным делом, особенно при переменной рабочей нагрузке приложений.

В версии IDS Version 11.10 реализован новый алгоритм контрольной точки, который практически не является блокирующим. При использовании этого алгоритма транзакционные обновления блокируются на очень короткий промежуток времени (как правило, на доли секунды), в течение которого осуществляется запуск контрольной точки. После этого транзакциям разрешается осуществлять очередные обновления, а буферный пул, содержащий все предшествующие транзакционные обновления, сбрасывается на диск. Отсутствие блокирования транзакций на период сброса буферного пула на диск позволяет применить менее "жесткие" настройки алгоритма LRU и, соответственно, предоставить приложению больше процессорных ресурсов для обработки транзакций. Кроме того, поскольку контрольные точки не блокируют транзакционные обновления, можно повысить частоту инициирования контрольных точек и обеспечить тем самым соответствие критерию RTO.

Кроме того, в версии IDS Version 11.10 в конфигурационном файле ONCONFIG введен новый параметр RTO_SERVER_RESTART. Название RTO_SERVER_RESTART расшифровывается как Recovery Time Objective Server Restart (перезапуск сервера в соответствии с критерием RTO). Посредством этого конфигурационного параметра администратор базы данных задает целевой промежуток времени в секундах, который предоставляется серверу IDS для выполнения процедуры быстрого восстановления, предназначенной для возвращения сервера в рабочий режим после сбоя. При активированном параметре RTO_SERVER_RESTART сервер IDS управляет частотой контрольных точек – включая ее автоматическую подстройку при изменениях рабочих нагрузок – гарантируя тем самым соблюдение критерия RTO при быстром восстановлении.

Использование конфигурационного параметра RTO_SERVER_RESTART ONCONFIG

При осуществлении транзакционных обновлений в нормальных условиях (см. Рис. 2: "Анатомия транзакции") средства управления транзакциями IDS сохраняют исходные образы (before images) обновляемых страниц в физическом журнале (physical log), а транзакционные обновления записывают в логический журнал (logical log). Процедура восстановления физического журнала – этап процедуры быстрого восстановления, предшествующий этапу логического восстановления (log replay) – восстанавливает базу данных до физически согласованного состояния. Этап log replay применяет журнальные записи, приводя базы данных в транзакционно согласованное состояние на момент сбоя.

В ходе логического восстановления может возникнуть проблема, связанная с тем, что каждая из логических записей может порождать запросы ввода/вывода. Если при этом потребуется чтение какой-либо страницы с жесткого диска, производительность логического восстановления может значительно снизиться. Незнание того, сколько операций ввода/вывода может произойти в ходе быстрого восстановления, не позволяет прогнозировать его продолжительность.

Для повышения предсказуемости этого показателя серверу IDS необходимо контролировать количество операций ввода/вывода, которые могут произойти в процессе быстрого восстановления. Если система настроена на использование конфигурационного параметра RTO_SERVER_RESTART, то сервер IDS – в рамках текущего управления транзакциями – сохраняет в физическом журнале дополнительные before image-образы. Это позволяет исключить произвольные запросы ввода/вывода в процессе быстрого восстановления, поскольку все страницы, необходимые для логического восстановления, заранее помещаются в буферный пул в процессе восстановления физического журнала.

Для вступления конфигурационного параметра RTO_SERVER_RESTART в силу он должен быть активирован до начала соответствующих действий сервера IDS. Так, активация параметра RTO_SERVER_RESTART не повлияет на текущую процедуру быстрого восстановления, а только на быстрое восстановление после следующего сбоя.

Конфигурационный параметр PHYSFILE – размер физического журнала

Для версии IDS Version 11.10 конфигурационный параметр PHYSFILE (размер физического журнала) в файле ONCONFIG рекомендуется установить равным 110% от совокупного объема всех буферных пулов. Это позволит процедуре быстрого восстановления использовать все ресурсы буферного пула для максимально быстрого восстановления базы данных в соответствии с политикой RTO_SERVER_RESTART. Хотя такое значение параметра PHYSFILE не является обязательным условием для корректности транзакций, оно обеспечивает оптимальные ресурсы для максимальной производительности быстрого восстановления вне зависимости от активации параметра RTO_SERVER_RESTART.

Если система сконфигурирована с очень большим буферным пулом, только часть которого заполнена обновлениями, то вполне допустимы меньшие размеры физического журнала. Завышенный размер физического журнала не влияет на производительность. Как правило, достаточно иметь физический журнал в диапазоне от 1 до 4 ГБ – в зависимости от транзакционной нагрузки и скорости жестких дисков.

Влияние дополнительных операций с физическим журналом на производительность транзакций

Новый алгоритм контрольной точки повышает активность работы с физическим журналом. Это обусловлено отказом от алгоритма Fuzzy Checkpoint. Приложения, сконфигурированные для работы с сервером IDS версии Version 7.x, отметят лишь незначительное повышение активности физического журнала (или вообще не заметят никаких изменений). Приложения, оптимизированные для работы с алгоритмом Fuzzy Checkpoint (который появился в версии IDS Version 9.x), в зависимости от типа транзакций могут ощутить увеличение частоты обращений к физическому журналу.

Если сервер сконфигурирован с активированным параметром RTO_SERVER_RESTART, то частота обращений к физическому журналу будет еще выше. В свою очередь, это повышает частоту инициирования контрольных точек. Эти проблемы могут быть легко решены увеличением размеров физического журнала. В версии IDS Version 11.10 реализована возможность изменения размеров физического журнала и/или его размещения с использованием команды onparams – без перехода в режим покоя и без перезагрузки системы.

В самом худшем случае число обращений к физическому журналу может резко возрасти. Это было наглядно продемонстрировано в тесте TPCC, транзакции которого обновляют преимущественно записи данных и избегают обновления индексов. Однако после того как размеры физического журнала были увеличены, имело место лишь незначительное ухудшение производительности транзакций (менее 5%), обусловленное дополнительными операциями с физическим журналом. Включение контрольных точек в оценку производительности показало, что применение алгоритма Non-Blocking Checkpoint и исключение блокирования в процессе обработки контрольных точек с избытком компенсируют это снижение производительности и обеспечивают более высокую итоговую производительность транзакций.


Настройка контрольных точек

В предыдущих версиях IDS инициировать контрольную точку могут следующие четыре условия:

  1. Административные события, например: архивирование, добавление пространства базы данных (dbspace), начальная загрузка или выключение сервера и т.д.
  2. 75-процентное заполнение физического журнала.
  3. Наличие всего одной контрольной точки в пространстве логического журнала (сервер IDS не может перезаписать логический журнал, содержащий текущую контрольную точку, поэтому IDS сначала инициирует контрольную точку и лишь затем перемещает данные в этот логический журнал).
  4. Активированный конфигурационный параметр CKPTINTVL в файле ONCONFIG

В версии IDS Version 11.10 появилась новая функция, которая позволяет серверу IDS автоматически переключать контрольные точки – или на соблюдение политики RTO_SERVER_RESTART, или на соблюдение политики поддержания высокой производительности контрольных точек, или на одновременное соблюдение обеих политик вне зависимости от колебаний транзакционной нагрузки.

Сравнение параметров CKPTINTVL и RTO_SERVER_RESTART

Параметр CKPTINTVL, устанавливающий частоту контрольных точек, позволяет администратору БД сконфигурировать сервер IDS на инициирование контрольных точек с нужными временными интервалами. Этот конфигурационный параметр является основным инструментом для управления продолжительностью быстрого восстановления, однако он не позволяет учесть интенсивность рабочей нагрузки и вследствие этого является весьма негибким, что часто приводит к непредсказуемым результатам.

При активированном конфигурационном параметре RTO_SERVER_RESTART сервер IDS сопоставляет показатели прошлого быстрого восстановления с текущей транзакционной активностью и на этом основании автоматически инициирует контрольные точки с целью соблюдения обеих политик – политики RTO_SERVER_RESTART и политики прогнозируемого времени отклика транзакций.

Конфигурационные параметры RTO_SERVER_RESTART и CKPTINTVL являются взаимно исключающими; в текущий момент времени активным может быть только какой-либо один из этих параметров. Если сервер сконфигурирован с параметром RTO_SERVER_RESTART, параметр CKPTINTVL игнорируется.

Когда в процессе выполнения контрольной точки может произойти блокировка транзакций?

В ходе выполнения контрольной точки транзакции продолжают потреблять ресурсы и физического, и логического журналов. IDS не разрешает транзакциям перезаписывать содержимое физического журнала (эта ситуация известна под названием «переполнение физического журнала») или логического журнала, поэтому обновляемые транзакции блокируются до момента завершения контрольной точки. Будущие контрольные точки будут учитывать показатели прошлой контрольной точки, а частота инициирования контрольных точек будет повышена во избежание блокировки транзакций. Если контрольные точки инициируются по причине исчерпания системой ресурсов физического или логического журналов, рассмотрите возможность наращивания этих ресурсов с целью уменьшения частоты контрольных точек.


Самонастройка сервера IDS

Как указывалось выше, сервер IDS Version 11.10 автоматически инициирует контрольные точки для поддержания оптимальной производительности. Кроме того, сервер IDS поддерживает несколько дополнительных функций автоматической настройки. Некоторые администраторы могут отказаться от использования этих функций – как и от большинства остальных функций IDS. По указанной причине в файле ONCONFIG сервера IDS реализованы дополнительные параметры, предназначенные для контроля над использованием указанных функций.

Автоматическое инициирование контрольных точек

С помощью конфигурационного параметра AUTO_CKPTS в файле ONCONFIG можно задать игнорирование показателей последней контрольной точки, следствием чего будет отключение автоматического инициирования контрольных точек. В результате сервер будет инициировать контрольные точки только по четырем условиям, перечисленным выше (см. раздел Настройка контрольных точек.

Автоматическими контрольными точками также можно управлять с помощью команды onmode с параметром –wm или –wf. По умолчанию автоматическое инициирование контрольных точек активировано.

Настройка сброса на диск по принципу LRU

В предыдущих версиях IDS для приложений, чувствительных ко времени отклика, требовались «жесткие» настройки LRU-сброса, позволяющие ограничить блокирование транзакций на период работы контрольной точки. В версии IDS Version 11.10 в процессе выполнения контрольной точки транзакции не блокируются, вследствие чего настройки LRU-сброса можно «ослабить». LRU-сброс занимается только заменой страниц; другими словами, новая страница, не находящаяся в буферном пуле, заменяет страницу, к которой не было обращений на протяжении некоторого периода. Если сервер сталкивается с ситуацией, когда ему приходится заменять страницы, активно используемые только для чтения, то для поддержания высокой производительности он автоматически повышает интенсивность LRU-сброса.

Для начала рекомендуется задать следующие значения параметров LRU-сброса:

  • lru_min_dirty=70
  • lru_max_dirty=80

С помощью конфигурационного параметра AUTO_LRU_TUNING можно включить/выключить автоматический LRU-сброс. Кроме того, для этой цели (а также для указания минимальных и максимальных значений параметров LRU) можно использовать команду onmode –wm.

Автоматическая настройка LRU-сброса и политика RTO

В некоторых ситуациях процедура выполнения контрольной точки не успевает своевременно сбросить буферный пул на диск. Это может произойти в том случае, когда транзакционная активность порождает так много данных (столько буферов с "мусором"), что подсистема ввода/вывода просто не способна обеспечить все потребности сброса. В результате создается ситуация, когда при выполнении контрольной точки сброс буферного пула на диск занимает больше времени, чем установлено параметром RTO_SERVER_RESTART. Когда это происходит, сервер выдает следующую рекомендацию по повышению производительности (performance advisory).

Листинг 1. Performance advisory (Рекомендация по повышению производительности) – Bufferpool flushing (Сброс содержимого буферного пула на жесткий диск)
Performance advisory: 
                The time to flush the bufferpool ## is longer than 
RTO_SERVER_RESTART ##.
Results: The IDS server can't meet the RTO policy
Action: Automatically adjusting LRU flushing to be more aggressive.
Adjusting LRU for bufferpool - id ## size ##k
    Old max ## min ##    New max ## min ##

Продолжительность сброса буферного пула ## на диск превышает значение
RTO_SERVER_RESTART ##.
Результаты: Сервер IDS не в состоянии соблюдать политику RTO
Действие: Автоматическая повышение интенсивности LRU-сброса.
Настройка LRU для буферного пула - id ## размером ## КБ
    Прежние значения max ## min ##    Новые значения max ## min ##

Если параметр AUTO_LRU_TUNING имеет значение «on», сервер IDS повысит интенсивность LRU-сброса на 10%. Если параметр AUTO_LRU_TUNING имеет значение «off», поле Action данной рекомендации будет иметь следующий вид:

Action:
                 Automatic LRU tuning is off.
                 Either turn on automatic LRU tuning or 
change LRU flushing to be more aggressive.

Автоматическая настройка LRU-сброса отключена.
 Или включите автоматическую 
настройку LRU, или увеличьте интенсивность LRU-сброса.

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

Виртуальные процессоры ввода/вывода (AIO VP)

Все более широкое распространение получает использование готовых участков файлов (cooked file chunks). Конфигурирование сервера с нужным количеством виртуальных процессоров AIO VP может оказаться трудной задачей. В версии IDS Version 11.10 мониторинг производительности виртуальных процессоров AIO VP осуществляется автоматически. Когда сервер IDS обнаруживает, что имеющегося количества AIO VP недостаточно, он добавляет новый AIO VP. Кроме того, сервер IDS контролирует количество процессов-«чистильщиков» (cleaner thread) и при необходимости увеличивает его. Включение/отключение этой функции осуществляется с помощью конфигурационного параметра AUTO_AIO_VPS и параметров –wm и –wf команды onmode.

Конфигурационные параметры RAS_PLOG_SPEED и RAS_LLOG_SPEED

Конфигурационные параметры RAS_PLOG_SPEED и RAS_LLOG_SPEED служат для хранения скоростей восстановления физического и логического журналов в ходе процедуры быстрого восстановления. Первоначальное значение параметра RAS_PLOG_SPEED задается при инициализации физического журнала. Значение параметра RAS_LLOG_SPEED задается на уровне 1/8 от значения параметра RAS_PLOG_SPEED. При каждом быстром восстановлении сервер IDS корректирует эти значения в соответствии с реальной скоростью восстановления. Значения указанных параметров задаются в «страницах в секунду».

Зачем нужны параметры файла ONCONFIG?

Использование параметров файла ONCONFIG позволяет заказчикам, встраивающим сервер IDS в свои приложения, пользоваться готовыми рассчитанными значениями настроек, избавляя от необходимости проводить настройку на оптимальную производительность. Администраторам баз данных не следует менять эти значения, если только они не получили соответствующих указаний от службы технической поддержки IBM.

Дополнительные рекомендации по настройке

Ниже приведен перечень параметров файла ONCONFIG, для которых в версии IDS Version 11.10 может потребоваться дополнительная настройка.

PHYSBUFF

По умолчанию размер буфера физического журнала составляет 128 КБ. Если конфигурационный параметр RTO_SERVER_RESTART активирован, размер буфера физического журнала по умолчанию составляет 512 КБ. Если вы уменьшите это значение, сервер IDS выдаст сообщение о том, что оптимальная производительность может быть недостижима. Использование буфера физического журнала меньшего размера, чем принято по умолчанию, снижает производительность, но не влияет на целостность транзакций.

LOGBUFF

По умолчанию размер буфера логического журнала составляет 64 КБ. Если вы решите уменьшить это значение, IDS выдаст сообщение о том, что оптимальная производительность может быть недостижима. Использование буфера логического журнала размером менее 64 КБ ухудшает производительность, но не влияет на целостность транзакций. Если для базы данных или для приложения предписано использование буфера при операциях с логическим журналом, увеличение параметра LOGBUFF свыше 64 КБ повысит производительность.

LOGFILES и LOGSIZE

Оптимальный объем пространства журнала (LOGFILES * LOGSIZE) определить трудно, поскольку этот показатель зависит от требований приложения и от характера его использования. На практике объем пространства журнала зависит от нескольких факторов:

  • Объем и интенсивность обновлений. При более высокой интенсивности обновлений требуется больше пространства журнала.
  • Целевая точка восстановления (Recovery Point Objective, RPO). Какой объем потерянных данных является допустимым в случае чрезвычайной ситуации? Повышение частоты резервного копирования журнала уменьшает риск потери транзакций.
  • Применение технологий репликации Enterprise Replication (ER) и High-Availability Data Replication (HDR). Обе упомянутые технологии оказывают влияние на количество и размеры файлов журнала. Если в вашей системе используется какая-либо из указанных технологий репликации, необходимо обратиться к разделам Руководства пользователя IDS, в которых рассматривается вопрос о выборе размеров логического журнала.

Некоторые рекомендации

  • С небольшим числом больших файлов журнала работать проще, чем с большим числом малых файлов журнала. Слишком большое пространство журнала не влияет на производительность, однако недостаточное количество файлов журнала и пространства журнала может ухудшить производительность вследствие частого инициирования контрольных точек.
  • Blob-объекты в пространстве blobspace не регистрируются в журнале, однако включаются в резервную копию пространства, в котором был создан соответствующий blob-объект. Другими словами, blob-объекты не высвобождаются до тех пор, пока журнал, в котором они созданы, не будет подвергнут резервному копированию. Вследствие этого, если blob-данные в пространстве blobspace обновляются часто, тогда для увеличения свободного пространства в blobspace может потребоваться повышение частоты резервного копирования.
  • Для приложений, генерирующих небольшой объем данных журнала , достаточно десяти файлов журнала объемом по 10 МБ каждый. Для приложений, генерирующих большой объем данных журнала, рекомендуется иметь 10 файлов журнала объемом по 100 МБ каждый.
  • В прошлом пользователи зачастую стремились сконфигурировать размеры файла журнала в соответствии с политикой RPO. В установившемся режиме при определенной интенсивности транзакций файл журнала со временем заполнится, после чего будет автоматически создана резервная копия журнала. Если нет необходимости в соблюдении какой-либо политики RPO, этот метод будет работать достаточно хорошо. Однако при необходимости соблюдения политики RPO предпочтительнее использовать инструмент Scheduler, предназначенный для управления исполнением плановых операций технического обслуживания, мониторинга и администрирования. Для соблюдения требуемой политики этот инструмент запускает задание, исполняющееся с нужной частотой. Этот инструмент также впервые появился в версии IDS Version 11.10.

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

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

Рекомендации по повышению производительности (Performance advisory)

IDS Version 11.10 сопоставляет конфигурацию сервера с рабочими нагрузками и на этой основе оценивает оптимальность настройки системы. Если при этом обнаруживается, что серверная конфигурация не является оптимальной, генерируется соответствующая рекомендация по повышению производительности (performance advisory), помещаемая в журнал сообщений (MSGPATH). Каждая рекомендация содержит предложения по изменению конфигурации, направленные на повышение производительности сервера.

Ниже приведены примеры таких рекомендаций и даны соответствующие пояснения:

Листинг 2. Performance advisory – Physical log too small for RTO_SERVER_RESTART (Физический журнал слишком мал для применения параметра RTO_SERVER_RESTART)
Performance advisory:
                 The physical log size is
                  smaller than the recommended size 
for a server configured with RTO_SERVER_RESTART.
Results: Fast recovery 
performance may not be optimal.
Action: For best fast recovery performance when
 RTO_SERVER_RESTART is enabled, 
increase the physical log size to at least ## Kb. 
For servers configured with a 
large bufferpool, this may not be necessary.
 Refer to the IBM Informix 
Administration Guide for more information.

Размер физического журнала меньше 
рекомендованного значения для сервера, 
сконфигурированного с параметром 
RTO_SERVER_RESTART.
Результаты: Производительность
 быстрого восстановления может оказаться неоптимальной.
Действие: Для максимальной 
производительности быстрого восстановления при 
активированном параметре 
RTO_SERVER_RESTART 
увеличьте размер физического журнала не 
менее чем до ## КБ. Для серверов с 
большими буферным пулом это может не потребоваться. 
Более подробную информацию см. в 
Руководстве по администрированию IBM Informix.

Как правило, размер физического журнала должен составлять 110% от совокупного размера всех буферных пулов. Такие размеры позволяют гарантировать, что процедура быстрого восстановления в процессе своей работы будет совершать незначительное число операций ввода/вывода (или вообще не потребует таких операций). В реальных условиях необходимые размеры могут оказаться несколько меньше рекомендованных значений, особенно в системах с большим буферным пулом. В настоящем документе приводится несколько рекомендаций по выбору размеров физического журнала.

Листинг 3. Performance advisory – IDS server boot time too long (Время начальной загрузки сервера IDS слишком велико)
Performance advisory:
                 Boot Time ‘##’ is 50 percent more than 
RTO_SERVER_RESTART ##
Results: Server initialization is
 taking a long time and IDS is unable to meet the 
RTO_SERVER_RESTART policy. Increase
 RTO_SERVER_RESTART to at least ## seconds.
Action: Disabling 
RTO_SERVER_RESTART.

Время загрузки ‘##’ на 50% превышает
 значение параметра RTO_SERVER_RESTART ##
Результаты: Инициализация сервера
 происходит слишком медленно; IDS не способен 
соблюдать политику RTO_SERVER_RESTART.
 Увеличьте значение RTO_SERVER_RESTART 
не менее, чем до ## секунд.
Действие: Отключение параметра 
RTO_SERVER_RESTART.

Это сообщение появляется в том случае, когда произошел нормальный перезапуск сервера, и по каким-либо причинам продолжительность его перезагрузки было настолько велика, что соблюдение политики RTO_SERVER_RESTART оказалось невозможным.

Листинг 4. Performance advisory – Physical log too small (Физический журнал слишком мал)
Performance advisory: Physical log is running out of room.
Results: Blocking transactions until checkpoint is complete.
Action: Increase physical log size.

Физическому журналу не хватает места.
Результаты: Блокирование транзакций до момента завершения контрольной точки.
Действие: Увеличьте размеры физического журнала.

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

Листинг 5. Performance advisory – Logical log too small (Логический журнал слишком мал)
Performance advisory: Logical log is running out of room.
Results: Blocking transactions until checkpoint is complete.
Action: Increase logical log size.

Логическому журналу не хватает места.
Результаты: Блокирование транзакций до момента завершения контрольной точки.
Действие: Увеличьте размеры логического журнала.

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

Листинг 6. Performance advisory – Long transactions blocking checkpoints (Длинные транзакции, приводящие к блокирующим контрольным точкам)
Performance advisory: 
                Long transactions are triggering blocking checkpoints.
Results: Blocking transactions until checkpoint is complete.
Action: Increase logical log size.

Длинные транзакции инициируют блокирующие контрольные точки.
Результаты: Блокирование транзакций до момента завершения контрольной точки.
Действие: Увеличьте размеры логического журнала.

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

Листинг 7. Performance advisory – Physical log too small to accommodate bufferpool flushing (Физический журнал слишком мал, чтобы обеспечивать сброс буферного пула)
Performance advisory: The physical log is
                 too small to accommodate the time
it takes to flush the bufferpool.
Results: Transactions may block during checkpoints.
Action: Increase the size of the physical to at least ## Kb.

Физический журнал слишком мал, чтобы обеспечить продолжительность работы, 
необходимую для сброса буферного пула.
Результаты: Возможно блокирование транзакций в ходе обработки контрольной точки.
Действие: Увеличьте размеры физического журнала не менее, чем до ## КБ.

Сервер IDS начал обработку контрольной точки, но не в состоянии сбросить буферный пул на диск своевременно, пока транзакционная активность потребляет оставшиеся 25% ресурсов физического журнала. Эта проблема может быть устранена увеличением размеров физического журнала до рекомендованного значения.

Листинг 8. Performance advisory – Logical log too small to accommodate bufferpool flushing (Логический журнал слишком мал, чтобы обеспечивать сброс буферного пула)
Performance advisory: 
                The logical log space is too small to accommodate the time
it takes to flush the bufferpool.
Results: Transactions may block during checkpoints.
Action: Increase the size of the logical log space to at least ## Kb.

Логический журнал слишком мал, чтобы обеспечить продолжительность работы, 
необходимую для сброса буферного пула.
Результаты: Возможно блокирование транзакций в ходе обработки контрольной точки.
Действие: Увеличьте размеры логического журнала не менее, чем до ## КБ.

Сервер IDS начал обработку контрольной точки, но не в состоянии сбросить буферный пул на диск, пока транзакционная активность потребляет оставшиеся ресурсы логического журнала. Эта проблема может быть устранена увеличением размеров логического журнала до рекомендованного значения.

Листинг 9. Performance advisory – Physical log too small to accommodate automatic checkpoints (Физический журнал слишком мал для применения автоматических контрольных точек)
Performance advisory: 
                The physical log is too small for automatic 
checkpoints.
Results: Automatic checkpoints are disabled.
Action: Increase the physical log size to at least ## Kb.

Физический журнал слишком мал для применения автоматических контрольных точек.
Результаты: Автоматические контрольные точки отключены.
Действие: Увеличьте размеры физического журнала не менее, чем до ## КБ.

Если сервер способен вызывать операции с физическим журналом быстрее, чем позволяют обработать автоматические контрольные точки, необходимо отключить автоматическое инициирование контрольных точек. Если размеры физического журнала менее 10 МБ (10000 КБ) или сервер способен вызывать операции с физическим журналом настолько быстро, что контрольные точки генерируются примерно каждые 35 секунд, то автоматическое инициирование контрольных точек отключается. Во многих случаях это происходит, если тонкая настройка сервера IDS не производилась и в файле ONCONFIG.std используются значения по умолчанию. Эта проблема может быть устранена увеличением размеров физического журнала до рекомендованного значения.

Листинг 10. Performance advisory – Logical log too small to accommodate automatic checkpoints (Логический журнал слишком мал для применения автоматических контрольных точек)
Performance advisory:
                 The logical log space is too small for automatic 
checkpoints.
Results: Automatic checkpoints are disabled.
Action: Increase the logical log space to at least ## Kb.

Логический журнал слишком мал для применения автоматических контрольных точек.
Результаты: Автоматические контрольные точки отключены.
Действие: Увеличьте размеры логического журнала не менее, чем до ## КБ.

Если сервер способен вызывать операции с логическим журналом быстрее, чем позволяют обработать автоматические контрольные точки, необходимо отключить автоматическое инициирование контрольных точек. Если размеры логического журнала менее 20 МБ (20000 КБ), или сервер способен вызывать операции с логическим журналом настолько быстро, что контрольные точки генерируются примерно каждые 35 секунд, то автоматическое инициирование контрольных точек отключается. Во многих случаях это происходит, если тонкая настройка сервера IDS не производилась и в файле ONCONFIG.std используются значения по умолчанию. Эта проблема может быть устранена увеличением размеров логического журнала до рекомендованного значения.

Мониторинг производительности контрольных точек

Сервер IDS версии V11.1 постоянно следит за функционированием контрольных точек. Информация о контрольной точке может быть получена с помощью команды onstat или извлечена из служебной базы данных sysmaster.

Дополнительная информация по мониторингу контрольных точек с помощью команды onstat -ckp и базы данных sysmaster приведена в Табл. 1 и Табл. 2.


Как работают неблокирующие контрольные точки

Рис. 1 иллюстрирует принципы работы неблокирующей рабочей точки в IDS. Для наглядности на рисунке изображен некий «поток записи» (log stream), который служит в качестве временной шкалы. На Рис. 2 показано, что каждая транзакция внедряет в этот поток определенные логические записи.Поток никогда не возвращается обратно во времени, он всегда только возрастает.

Рис. 1. Анатомия неблокирующей контрольной точки
Анатомия неблокирующей контрольной точки.

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

Смысл термина «неблокирующая контрольная точка»

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

Рис. 2. Анатомия транзакции
Анатомия транзакции

Заключение

До появления версии IDS V11.1 администрирование производительности контрольных точек могло быть сопряжено с утомительной настройкой. Стремясь достичь максимальной производительности при обработке транзакций, администраторы баз данных тратили бесконечные часы на тонкую настройку файла ONCONFIG. Некоторым администраторам IDS может быть психологически трудно разрешить серверу IDS производить автоматическую настройку под переменные рабочие нагрузки. Надеюсь, эта статья убедила вас в том, что эта проблема наконец решена традиционным для IDS образом – эффективно и просто.

Ресурсы

Научиться

Получить продукты и технологии

  • Бета-версия Cheetah: Загрузите бесплатную пробную версию продукта Cheetah и внесите свой вклад в дальнейшее развитие Informix Dynamic Server.
  • Informix Dynamic Server: Загрузите бесплатную пробную версию Informix Dynamic Server Enterprise Edition V10.0.
  • Создайте свой следующий проект с использованием пробного программного обеспечения IBM, которое можно загрузить непосредственно с Web-сайта developerWorks.

Обсудить

Комментарии

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=Information Management
ArticleID=219525
ArticleTitle=Неблокирующие контрольные точки в Informix Dynamic Server
publish-date=05112007