|
Тюнинг механизма Before-Imaging
В этой статье я расскажу как можно улучшить производительность за счет небольшого тюнинга механизма Before-Imaging.
Before-Imaging это механизм, который всегда активируется для того чтобы PROGRESS мог восстановить изменения незавершенных транзакций, в случае если произошел системный сбой. Он чрезвычайно важен для обеспечения надежности базы данных, но между тем, он так же генерирует высокую нагрузку дискового ввода/вывода (I/O), которая значительно снижает общую производительность системы. И обычно, именно на BI сначала необходимо обращать внимание при поиске узких мест, когда наблюдается высокая дисковая активность (I/O). PROGRESS, перед тем как внести изменения в базу данных и after-image файлы, всегда сначала записывает их в BI файл. Таким образом, если BI I/O активность является узким местом, то это коснется любой деятельности в базе. Чтобы уменьшить влияние Before-Image I/O необходимо выполнить следующие действия:
- Переместите BI файл на отдельный диск
- Запустите фоновый процесс BIW (Before-Image Writer)
- Выделите больше BI буферов
- Увеличьте размер BI кластера
- Увеличьте размер BI блока
- Обеспечьте замедление BI записи (-Mf)
Мониторинг BI активности. Для мониторинга активности использования диска, на котором размещен BI файл, используются обычные утилиты операционной системы. А для мониторинга конкретно BI активности базы данных, используется утилита PROMON. Для этого воспользуйтесь опцией R&D и экраном BI Log Activity:
promon -> R&D -> 2. Activity Displays -> 5. BI Log
Обратить внимание необходимо на следующие поля этого экрана:
- Busy buffer waits
- Empty buffer waits
- Высокое количество записей в секунду
- Partial writes, высокое количество частичных записей.
Причем частичная запись возникает когда PROGRESS вынужден записывать данные в BI файл до того как BI буфер будет заполнен. Это происходит в следующих случаях:
- APW пытается писать DB-блок, изменения которого записаны в BI буфер, который в свою очередь еще не записан в BI файл. Поскольку BI заметки должны быть сброшены на диск перед AI заметками, то APW записывает данные из BI буфера не дожидаясь его заполнения, чтобы обеспечить AI запись.
- Процесс AIW работает с опережением процесса BIW. Поскольку BI заметки должны быть сброшены на диск перед записью AI заметок, то AIW записывает BI буфер, не дожидаясь пока он заполнится, тем самым обеспечивая запись AI.
- Таймер параметра Suppress BI File Write (-Mf) истекает прежде чем буфер будет заполнен.
Перемещение BI файла. Известно, что размещая файлы базы данных на множестве различных дисков, можно увеличить производительность. Поэтому, разместив BI экстенты на отдельных дисках, вы можете балансировать BI I/O нагрузку на диски. Если такой возможности нет, то можно просто разместить один BI экстент на отдельном, от экстентов базы данных, диске. Перемещение BI файла, так же поможет вам освободить дисковое пространство для дальнейшего роста других экстентов базы данных. Расположение экстентов базы данных можно определить по структурному файлу (.st)
Использование BIW. BIW это фоновый процесс, который непрерывно записывает заполненные BI буферы на диск. Поскольку запись в BI файл выполняется в фоновом режиме, то процессы клиентов и сервера редко вынуждены дожидаться завершения записи заполненного буфера на диск. BIW это не обязательный, но очень рекомендуемый процесс для улучшения производительности.
PROGRESS сервер записывает текущую информацию в BI файл через текущий output-буфер. Когда это буфер становится заполненным, сервер помещает его в цепочку заполненных буферов. Затем, он берет следующий буфер из цепочки пустых буферов, и использует его как текущий output – буфер. Если же в цепочке пустых буферов (empty buffers) больше буферов нет, то процесс вынужден ожидать, пока заполненные буфера не будут сброшены на диск.
BIW записывает заполненные буфера на диск и размещает их в цепочке пустых буферов. Тем самым, BIW гарантирует наличие пустых буферов для клиентских процессов и серверов.
Для одной базы данных можно запустить только один BIW процесс. Его запуск и останов можно осуществлять вручную без остановки самой базы данных.
Обеспечение достаточного количества BI буферов. Для увеличения количества буферов в буферном пуле before-image, вы можете воспользоваться параметром запуска базы данных Before-Image Buffers (-bibufs). Это позволит увеличить количество пустых буферов (empty buffers) для клиентских процессов и серверов. Первоначально, значение этого параметра равно 20. Увеличьте его если в поле Empty buffers waits имеются не нулевые значения (PROMON, экран Activity или R&D BI Log Activity).
Увеличение размера BI кластера. На диске BI файл состоит из кластеров. Поскольку PROGRESS записывает данные в BI файл, эти кластера имеют свойство заполняться. Когда кластер заполнен, PROGRESS должен гарантировать, что все измененные блоки базы данных, связанные с заметками в кластере, будут записаны на диск. Этот процесс мы знаем под названием “контрольная точка” (checkpoint). Использование контрольных точек, позволяет уменьшить время восстановления, а так же позволяет PROGRESS`у многократно использовать BI пространство на диске. Увеличение размера BI кластера позволяет уменьшить время между контрольными точками. Это так же позволяет снизить I/O нагрузку во время записи измененных буферов базы данных на диск. А так же позволяет задерживать запись, собирая большее количество измененных буферов перед их записью на диск, т.е. больше изменений будет записано на диск во время одной операции записи. Большие размеры кластеров могут существенно увеличить производительность, но имейте ввиду, что они также имеют и значительные недостатки, а именно:
- Увеличивается использование дискового пространства для BI файла
- Увеличивается период аварийного восстановления (crash recovery)
- Увеличивается время выполнения контрольной точки (запуск большего количества APW может уменьшить это время)
Для изменения размера BI кластера вам необходимо остановить базу данных, например утилитой PROSHUT, и ввести следующую команду: proutil db-name -C truncate bi –bi size
где,
db-name, это имя базы данных,
size, это размер кластера в килобайтах.
Значение должно быть кратно 16, и может находиться между 16 и 262 128, т.е. от 16Кб до 256Мб. Размер кластера по умолчанию равен 512Кб. Обычно, размеры кластеров от 512 до 4096 бывают наиболее полезны. С помощью этой команды так же можно увеличить размер BI блока, о чем будет рассказано ниже.
Увеличение количества BI кластеров. Когда вы создаете новую базу данных, или выполняете truncate bi существующей базы данных, то по умолчанию, PROGRESS создает четыре BI кластера, каждый из которых по умолчанию имеет размер равный 512 Кб. Мы знаем, что как только кластер заполняется, возникает контрольная точка, а PROGRESS начинает писать в следующий по порядку кластер. Но бывают случаи, когда запись в следующий кластер не возможна, так как он содержит активную транзакцию. В этой ситуации, PROGRESS будет вынужден создать новый кластер, и начать запись в него. А пока кластер будет создаваться, ни какая деятельность в базе данных не может выполняться, тем самым снижается производительность. Обычно, на протяжении всего времени работы базы данных (от старта до останова) количество кластеров “вырастает” до оптимального значения. Вы можете сами рассчитать текущее количество BI кластеров в базе данных, разделив физический размер BI файла на размер BI кластера. Например, BI файл имея размер 917 504, и размер BI кластера равный 128Кб, будет содержать общее количество BI кластеров равное 7.
Каждый раз, когда вы выполняете truncate bi, вы должны перед стартом базы данных привести количество BI кластеров к оптимальному значению, тем самым предотвращая необходимость создания новых кластеров во время рабочего процесса. Truncate bi может быть выполнен в следующих случаях:
- Автоматически, когда вы активируете After-Imaging (RFUTIL AIMAGE BEGIN)
- Автоматически, когда вы выполняете перестройку индексов (PROUTIL IDXBUILD)
- Вручную, с помощью PROUTIL TRUNCATE BI
Для того чтобы вручную увеличить количество BI кластеров воспользуйтесь следующей командой: proutil db-name -C bigrow n
где,
n, определяет количество BI кластеров, которые вы хотите создать для базы данных.
По умолчанию, кластеров четыре, таким образом, если указать значение 9, то PROGRESS создаст дополнительно к этим четырем еще 9 BI-кластеров, и их общее количество будет равно 13.
Увеличение размера BI блока. PROGRESS записывает и считывает информацию из BI файла блоками. Увеличение размера этих блоков позволяет считывать и записывать больше информации в один момент времени. Это может уменьшить показатели I/O на дисках, на которых расположены BI экстенты, т.е. таких операций станет меньше. Размер блока, который выставлен по умолчанию, т.е. 8Кб, обычно достаточен для приложений с низкой транзакционной активностью. Тем не менее, если мониторинг BI записи показывает, что запись является узким местом в производительности, и вы знаете, что ваша дисковая система способна на выполнение большего количества записей, то вы должны увеличить размер BI блока, тем самым улучшив производительность.
Для изменения размера BI блока вы должны остановить вашу базу данных, и выполнить следующую команду: proutil db-name -C truncate bi -biblocksize size
Здесь,
size, это новый размер BI-блока в килобайтах.
Допустимые значения размера BI-блока могут быть 0,1,2,4,8 и 16. Если у вас активирован механизм After-Imaging, то вы должны увеличить и размер AI блока. Поскольку для лучшей производительности размеры BI и AI блоков должны совпадать.
Задержка BI записи. В сильно загруженных системах, вы можете значительно улучшить производительность, воспользовавшись параметром Delayed BI File Write (-Mf). По умолчанию, PROGRESS записывает последний BI блок на диск в момент завершения каждой транзакции. Это гарантирует, что завершенные транзакции навсегда будут записаны в базу данных. В системах с низкой транзакционной активностью, такое выполнение BI записи очень важно и не вызывает ни каких потерь производительности. Тем не менее, на сильно загруженных системах, это не так важно, поскольку BI блок в любом случае очень скоро будет записан на диск, что может вызвать ухудшение работы. Установите параметр –Mf, чтобы обеспечить задержку BI записи после завершения транзакции. Параметр будет гарантировать, что последний BI блок записан на диск только по истечению определенного количества секунд. При этом запись будет выполнена быстрее, если пользователь покинет систему или если система будет остановлена. Но имейте ввиду, что если произойдет системный сбой, то вы можете потерять последние несколько завершенных транзакций, так как они на этот момент могут быть не записаны в BI файл.
Установка порогового размера BI файла (BI Threshold). Когда приложение выполняет большие объемы по изменению схемы базы данных, или когда используется плохой стиль программирования, BI файл может вырасти по размеру более 1 Гб. Если в это время произойдет какой-либо сбой, то процесс восстановления может потребовать чуть ли не вдвое больше дискового пространства, чем использовано BI файлом на момент сбоя. И часто, такой рост может быт не возможным, что приведет к повреждению базы данных. Чтобы не допустить такого чрезмерного роста BI файла, используйте параметр запуска базы данных Recovery Log Threshold (-bithold). Как только порог будет достигнут, база данных выполнит аварийное восстановление. Таким образом, вы можете гарантировать, что для восстановления базы данных будет иметься достаточно дискового пространства. Все сообщения, связанные с достижением порогового значения, будут отражены в логе базы данных (.lg). Они будут содержать следующие данные:
- Пороговое значение
- Предупреждающее сообщение, если порог установлен более чем 1000Мб
- Предупреждающее сообщение, если BI экстенты были расширены (extended)
- Сообщение, о том, что база данных будет остановлена, поскольку достигнуто пороговое значение.
Рекомендуемое пороговое значение может быть между 3% и 100% максимально возможного размера BI файла, округленное до ближайшей кластерной границы. Если же порог будет выставлен более 1000Мб, то PROGRESS выдаст предупреждающее сообщение на экран и в лог базы данных. Система будет проверять общее количество используемых BI кластеров каждый раз, когда новый кластер будет помечаться как используемый. При использовании параметра запуска No Crash Protection (-i), пороговое значение будет игнорироваться.
Если же вы не желаете, чтобы при достижении порогового значения ваша база данных выполнила аварийную остановку, то вы можете воспользоваться параметром запуска Threshold Stall (-bistall), который активирует на базе данных так называемую quit point, т.е. до вмешательства администратора, вся деятельность в базе данных будет остановлена. Что предоставляет администратору базы данных, возможность остановки базы данных, проверки доступного дискового пространства и возможность увеличения порогового значения. О том, что включен –bistall, в лог базы данных будет записано соответствующее сообщение.
Использование PROQUIET. С помощью команды PROQUIET вы можете отрегулировать пороговое значения BI файла, т.е. можно увеличить его по отношению к текущему порогу. Для этого вам необходимо выполнить следующее:
- Активировать quiet point на базе данных
proquiet db-name enable
Как только вы это выполните, вся деятельность связанная с записью в файлы базы данных прекратится. Все процессы, которые начнут выполнение транзакций в момент активированной quiet point, будут вынуждены ждать когда блокировка будет снята.
- Увеличить пороговое значение используя параметр bithreshold
proquiet db-name bithreshold n
где,
n, это новое пороговое значение.
- Деактивировать quiet point следующей командой:
proquiet db-name disable
Нам этом всё, но перед завершением, я хотел бы дать еще один совет. Не стоит дожидаться возникновения критической ситуации, чтобы воспользоваться этими советами. Потренируйтесь где-нибудь на тестовой базе данных, что бы все ваши действия, когда будет необходимо, были отлажены и согласованы, чтобы не пришлось в срочном порядке обращаться в службу технической поддержки.
|
Главная
