В данном разделе содержатся рекомендации, которые легко может выполнить каждый. Их можно быстро сделать за несколько минут, когда база остановлена. Однако следует понимать, что самые простые средства не обязательно будут оптимальными – но они существенно лучше настроек по умолчанию и должны приблизить вас к оптимальным значениям. Заметим, что под значениями параметров конфигурации по умолчанию, о которых говорится в данной монографии, понимаются значения для Progress версии 9.1. Более поздние версии могут иметь другие значения параметров по умолчанию.
Самый эффективный способ увеличения производительности – выделить базе данных больше памяти для работы, начиная с размера пула буферов. Пул буферов базы данных – это область памяти, предназначенная для ускорения многих операций базы данных. Ускорение работы происходит благодаря снижению числа операций чтения с диска за счет сохранения в памяти копий недавно использованных блоков данных. Другой фактор ускорения работы – снижение числа операций записи, т.к. блоки данных в памяти могут многократно обновляться перед тем, как, в конечном счете, будут записаны на диск. Доступ к блокам, которые уже находятся в памяти, осуществляется намного быстрее, чем при считывании с диска. Пул буферов базы данных обычно занимает самую большую часть области совместно используемой памяти. Увеличение размера этой области обычно приводит к повышению производительности.
Число буферов в пуле базы данных устанавливается параметром -B. Размер буфера равен размеру блока данных базы данных.
Размер по умолчанию достаточно мал и очень далек от оптимального. Для однопользовательского режима, по умолчанию устанавливается 10 буферов, а для многопользовательского – в 8 раз больше, чем -n. Если –n по умолчанию равно 20, то число буферов по умолчанию будет равно 160. Хотя оптимальное значение зависит от конкретной базы данных и нагрузки приложений, для начала в качестве двух весьма приблизительных значений можно использовать:
В программе promon можно найти значение параметра ”Buffer Pool Hit Ratio” показываемое на нескольких экранах. Это значение говорит о проценте операций доступа к базе данных, которые были выполнены с использованием данных, уже находящихся в памяти, когда не требовалось читать их с диска. Чем больше это значение, тем лучше. Если значение равно 98 %, это означает, что только 1 из каждых 50 операций доступа к базе данных требует чтения с диска. Если значение ниже 95 % и производительность неудовлетворительная, определенно следует увеличить размер пула буферов. Следует добиться значения не менее 98 %, если это возможно. Упоминавшаяся ранее программа ProTop, разработанная Томом Баскомом, имеет guesstimator, который может оказаться полезным для выбора размера пула буферов.
Вы можете увеличивать размер пула буферов до тех пор, пока у вас в системе имеется свободная память. Но имеются и ограничения: если вы сделаете его слишком большим, система может начать свопинг, который может привести к резкому падению производительности системы в целом. Многие системы имеют достаточно памяти, поэтому можно указать для пула буферов 100,000 или более буферов. Заметим, что для базы данных с размером блока данных 8192 байт, 100,000 буферов потребуют около 900 мегабайт памяти.
Для 64-битных версий Progress OpenEdge, если система имеет достаточно физической памяти, можно установить общий размер области совместно используемой памяти вплоть до 116 гигабайт.
Для 32-битных версий Progress OpenEdge общий размер совместно используемой памяти не может превышать примерно 2 ГБ. Точное значение предела зависит от операционной системы, но для большинства систем, в идеальных условиях 32-битные программы могут использовать примерно 2 ГБ5 памяти. Реальный лимит зачастую будет меньше, в зависимости от многих факторов4.
Если ваше приложение соединяется со многими базами данных в режиме самообслуживания (self-serving mode), общее пространство, занимаемое областями совместно используемой памяти для всех баз данных, с которыми вы устанавливаете соединения одновременно, в сумме не должно быть больше указанного ранее предела. Кроме того, вы должны иметь достаточно памяти для хранения и других ресурсов, например, дескрипторов файлов для всех файлов, связанных с базами данных, и семафоров, используемых для взаимодействия процессов.
Чем больше число баз данных, с которыми ваше приложение устанавливает соединения одновременно, тем меньше для каждой из них должна быть область совместно используемой памяти, для того чтобы все они поместились в адресное пространство, доступное для приложений, использующих соединения в режиме самообслуживания.
Для кэширования в памяти информации о транзакциях используется свой набор буферов, которые впоследствии сбрасываются на диск в журнал before-image. Каждое изменение состояния транзакции и изменение состояния базы данных записывается в виде одной или более записей журнала транзакций, которые сначала помещаются в текущий буфер журнала before-image, а затем записываются в журнал before-image. Обычно это делает процессом записи BIW. Наличие в памяти достаточного количества буферов дает этому процессу необходимое время для выполнения записи. Когда текущий буфер журнала полон, а свободных пустых буферов больше нет, то транзакция, которая хочет записать данные в буфер журнала, должна ждать, пока не станет доступен пустой буфер. Увеличивая число буферов, мы снижаем вероятность ожидания при выполнении изменения базы данных.
По умолчанию число буферов журнала before-image равно 5 и устанавливается параметром -bibufs. Следует увеличить это значение примерно до 25. Заметим, что этот параметр не является ”регулятором скорости”. Необходимо просто иметь достаточное число буферов для сглаживания временных изменений в количестве данных журнала, которые следует записать. В программе promon можно увидеть число ожиданий пустых буферов для журнала before-image. Если значение превышает несколько единиц в секунду, следует увеличить число буферов. Однако если диск, на котором расположен журнал before-image, перегружен и не в состоянии своевременно выполнить дополнительные операции записи, то увеличение числа буферов не даст эффекта.
Если Вы не используете Before-Image Writer, увеличение числа буферов даст незначительный эффект или не даст его вообще.
При включении after-image журналирования, также как и для before-image файла используется свой набор буферов для кэширования записи на диск в файл after-image. Каждая запись журнала транзакций, записываемая в журнал before-image3 будет записываться также в журнал after-image. Обычно этим занимается процесс записи AIW. Как и для буферов журнала before-image, когда текущий буфер журнала after-image полон, а пустых буферов журнала after-image не имеется, транзакция, которая хочет записать данные в буфер журнала, должна ждать, пока не станет доступен пустой буфер after-image. Увеличивая число буферов, мы снижаем вероятность ожидания при выполнении изменения базы данных. Следует установить число буферов журнала after-image немного больше, чем число буферов журнала before-image, в большинстве случаев на 25-50 % выше. (Примечание комментатора – данная рекомендация не вполне корректна и лучше задавать значения параметров –bibufs и –aibufs равными друг другу.)
Если вы не запускаете процесс AIW, то увеличение числа буферов даст незначительный эффект или не даст его вообще.
Если Вы не используете after-image журналирования, увеличение числа буферов не даст никакого положительного эффекта, а приведет лишь к пустой трате памяти.
База данных может использовать механизм spinlock’ов как метод синхронизации деятельности процессов, осуществляющих одновременный доступ к данным, хранящимся в совместно используемой области разделяемой памяти, например, к пулу буферов базы. Если система, управляющая вашей базой данных, имеет более одного процессора, для параметра -spin следует установить ненулевое значение.
Поиск оптимального значения для параметра spin требует значительного времени, а выбор хорошего значения – нет: просто используйте значение 50,000. (Примечание комментатора – тесты показывают, что оптимальное значение этого параметра лежит в диапазоне 10,000 – 30,000.) Для современных систем, мы предлагаем в качестве приблизительного начального значения использовать 20,000, но проще запомнить значение 50,000 и это значение оказывается вполне достаточным. В большинстве случаев, определение точных лучших значений не столь важно и не стоит затрат вашего времени. В наших тестах со 150 пользователями, мы обнаружили очень незначительную разницу в производительности при изменении значения -spin от 10,000 до 90,000, при этом разница между 2,000 и 40,000 составляла около 50% (436 и 680 транзакций в секунду соответственно). Обычно, чем меньше число пользователей, осуществляющих доступ к базе данных, тем меньше сказывается разница в настройке параметра -spin.
При условии, что вы запустили свою базу с ненулевым значением параметра –spin, его можно изменить прямо во время работы базы, используя утилиту promon. Это позволит определить более удачное значение этого параметра.
Сделав это, не забудьте обновить конфигурационный файл или скрипт запуска базы.
Мы видели большую систему со многими процессорами, для которой прекрасно работало значение 2,000,000, но это довольно нетипично.
Заметим, что лицензия Workgroup RDBMS не поддерживает использования параметра -spin.
В многопользовательском режиме база данных выполняет непрерывный процесс синхронизации содержимого разделяемой памяти с состоянием базы на диске, в рамках которого в фоновом режиме измененные блоки данных пишутся на диск. Новый цикл синхронизации начинается с открытием очередного кластера журнала before-image. Увеличение размера кластера журнала before-image приводит к увеличению интервала между контрольными точками, что дает процессам записи APWs необходимое время для их работы. Продолжительность последних 8 проверок показывается на экране Checkpoints программы promon. В идеальном состоянии интервал между проверками должен составлять около минуты или более, а число буферов, сброшенных на диск в контрольной точке, должно быть равным или близко к нулю. Более длительные интервалы возможны, но не нужны. Если они короче минуты, то следует увеличить размер кластера. Если число buffers flushed больше 10, то следует увеличить размер кластера, или увеличить число фоновых процессов APW, или повысить производительность дисков по записи.
Размер before-image кластера можно установить следующей командой:
proutil foo -C truncate bi -bi 4096
Размер кластера указывается в килобайтах. В качестве стартового значения можно использовать 4 МБ, но для баз данных с высоким уровнем транзакционной активности может потребоваться больший размер кластера. База запомнит значение размера кластера, которое вы ей задали.
При работе с лицензий Workgroup RDBMS размер кластера следует оставить небольшим. Значение 512 КБ или менее будет лучше, чем кластеры большего размера. Поскольку с этой лицензией Вы не можете запускать фоновые процессы, то все модифицированные блоки данных будут писаться на диск именно в контрольных точках. Чем больше размер кластера, тем больше измененных блоков накопится к этому моменту . Запись этих блоков на диск будет приводить к периодическому “подвисанию” базы.
Увеличение размера блока, используемого для работы с журналом before-image, увеличивает производительность. В UNIX-системах (Solaris, AIX, HP-UX, Tru64, UnixWare и т.д.) следует использовать значение 8КБ. На Linux-системах следует использовать значение 4КБ. Под Windows следует использовать значение 4КБ до тех пор, если вы не увеличили размер кластера NTFS, как указано в разделе, посвященном специфическим вопросам Windows.
Размер блока before-image можно установить в программе proutil следующей командой:
proutil foo -C truncate bi -biblocksize 8
Размер блока указывается в килобайтах.
(Примечание комментатора – размер before-image блока можно задать равным 8 или 16 КБ на всех платформах)
Увеличение размера блока для журнала after-image увеличивает эффективность его работы. Желательно иметь размер after-image блока в точности равным размеру before-image блока. В UNIX-системах (Solaris, AIX, HP-UX, Tru64, UnixWare и т.д.), следует использовать 8КБ. На Linux-системах следует использовать 4КБ. Под Windows, следует использовать 4КБ до тех пор, пока вы не увеличите размер кластера NTFS как указано в разделе, посвященном специфическим вопросам Windows. Перед изменением размера блока after-image следует выключить журнал after-image (если он был включен) и обнулить журнал before-image:
rfutil foo -C aimage end
proutil foo -C truncate bi
Размер блока after-image можно установить следующей командой:
rfutil foo -C aimage truncate -aiblocksize 8
Размер блока указывается в килобайтах.
Before-image writer - это процесс, предназначенный для записи на диск только что заполненных буферов журнала before-image. Если этот процесс запущен, то серверу базы данных эти действия не нужно выполнять, что дает ему больше времени для полезной работы. При использовании самообслуживающихся клиентов, сервер и клиент будет находиться в равных условиях, но по-прежнему будете желательным, чтобы серверная часть была занята своей непосредственной работой.
Заметим, что лицензия Workgroup RDBMS не позволяет запускать before-image writer.
Запустить before-image writer можно следующей командой:
probiw foo
Можно запустить только один before-image writer.
Если вы используете after-image журналирование (а это следует делать, хотя и не для повышения производительности), следует запускать процесс after-image writer (AIW). Этот процесс предназначен для записи на диск только что заполненных буферов журнала after-image, для того чтобы этого не приходилось делать серверу. Если процесс запущен, то серверу базы данных эти действия не нужно выполнять, что дает ему больше времени для полезной работы. При использовании самообслуживающихся клиентов, сервер и клиент будет находиться в равных условиях, но по-прежнему будете желательным, чтобы серверная часть была занята своей непосредственной работой.
Заметим, что лицензия Workgroup RDBMS не позволяет запускать after-image writer.
Запустить after-image writer можно следующей командой:
proaiw foo
Можно запустить только один after-image writer.
Всегда следует запустить как минимум один асинхронный процесс page writer (APW).
Асинхронный page writer - это фоновый процесс, предназначенный для записи недавно измененных блоков базы данных на диск в область данных. В этом случае, серверу не приходится выполнять эту задачу, а блоки модифицированных данных не будут сбрасываться на диск все сразу в конце цикла проверки (checkpoint cycle). Ряд пунктов меню утилиты promon сообщает о подобных записях как об очистке буферов (buffers flushed). Для большинства проверок это число должно быть менее 10.
В большинстве случаев будет достаточно запуска одного или двух таких процессов. Излишнее их число обычно не приносит вреда, но слишком большое число, скажем 50, может несколько снизить производительность, поскольку увеличится число конфликтов при доступе к пулу буферов.
Заметим, что лицензия Workgroup RDBMS не позволяет запускать page writers.
Асинхронный page writer можно запустить следующей командой:
proapw foo
Почти во всех рекомендациях, приведенных в данной главе, предполагается, что база данных работает в многопользовательском режиме. Обычно при использовании базы данных в однопользовательском режиме, ее производительность будет значительно хуже.
Когда база данных работает в однопользовательском режиме, имеется только одно соединение с базой данных, и нет области разделяемой памяти (вместо этого все структуры данных расположены в частной памяти процесса). Однопользовательский режим имеет следующие недостатки по сравнению с многопользовательским режимом:
3 на последних версиях Linux, максимум равен 2,7 ГБ
4 рассмотрение которых выходит за рамки данной монографии
5 в действительности, имеется одно или два исключения, но не стоит о них беспокоиться