В настоящий момент 1С-предприятие 8.2 может работать с различными вариантами баз данных. Помимо файлового режима сюда входят такие базы как Microsoft SQL Server, IBM DB2, Postgre SQL, а также не так давно в этот список добавился еще и Oracle. Часто в момент развертывания системы у администратора стоит проблема выбора - какую базы данных выбрать? При этом зачастую не последнее место занимает вопрос производительности полученной системы. В данной статье я попробую исследовать производительность большинства поддерживаемых баз данных (пока что за исключением Oracle) выявить их сильные места, указать на потенциальные недостатки и возможные проблемы в эксплуатации.

Условия тестирования. Очевидно, что в рабочей системе производительность в каждый момент времени может зависит от следующих факторов:

• Аппаратные:
• Процессорная подсистема: количество, частота, режимы работы (в том числе статус режима HyperThreading).
• Подсистема оперативной памяти: физический объем, доступный объем, режимы использования.
• Дисковая подсистема: количество дисков, скорость вращения, наличие аппаратного кэша, режим рейда для дискового массива.
• Сеть: количество и пропускная способность сетевых адаптеров.
• Програмные:
• Различного рода настройки операционной системы и СУБД.
• Эффективность SQL-кода.
• Проблема блокировок и взаимоблокировок при обращении к данным.
• Организационные:
• Количество одновременно работающих пользователей в системе.
• Характер работы, выполняемый каждым из этих пользователей.
• Возможная вероятность пересечения выполняемых действий на общих ресурсах, которая приводит к возникновению проблемы блокировок и взаимоблокировок.

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

Поэтому система тестов была создана с таким условием, чтобы определить по возможности чистую скорость работы сервера с определенными стандартными алгоритмами 1С 8.1 и 8.2.

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

• отсутствие ожиданий на блокировках: поэтому тест будет выполнятся в одном потоке
• отсутствие узких мест с точки зрения количества процессоров: тестирование на 4-х ядерном сервере
• отсутствие узкого места в виде недостаточного объема оперативной памяти: для поддержания этого условия набор тестов был подобран таким образом, чтобы потребление оперативной памяти всеми компонентами не превысило более 80% имеющегося объема оперативной памяти на сервере
• отсутствие узкого места в виде сетевой инфраструктуры: во избежание влияния сети на производительность клиентская часть, сервер приложений и сервер баз данных расположены на одной машине
• для снижения нагрузки на жесткие диски в свойствах конфигурации отключено логирование событий, так как при интенсивном заполнении базы данных количество регистрируемых событий сопоставимо с объемами изменения самой базы данных

Итак, посмотрим список оцениваемых систем:

• Microsoft SQL 2000 Server, версия 8.00.2039

Хотя данная СУБД имеет за спиной уже 12-летнюю историю работы и в данный момент не поддерживается, тем не менее в эксплуатации еще встречается и всем требованиям, предъявляемым к базам данных со стороны 1С-предприятия 8.2, удовлетворяет. К тому же она более простая, чем современные 2005 и 2008 версии. К сожалению 64-битное издание существует только для процессоров Intel Itanium, поэтому в исследовании будет изучаться 32-битная редакция. Один из недостатков 32-битной версии - ограничение объема памяти в 64Гб в режиме AWE в связи с 36-разрядной адресацией, сюда же можно включить и сам режим AWE, при котором в расширенной памяти могут храниться только буферы для данных.

• Microsoft SQL 2005 Server 64-битная редакция, версия 9.0.5057

Предыдущее поколение СУБД от Microsoft. Данная система пришла на смену устаревшей версии SQL 2000 и полностью поддерживает плоскую модель памяти в 64-битном режиме. Также содержит большое количество усовершенствований, направленных на отказоустойчивость и масштабирование. На данный момент активно применяется в рабочих системах.

• Microsoft SQL 2008 R2 Server 64-битная редакция, версия 10.50.2500

Самый свежий продукт компании Microsoft. Есть еще и просто SQL-2008, но было принято решение не плодить сущности и оставить только этот вариант, как самый современный на данный момент. Само собой разумеется, что полностью поддерживается 64-битный режим, поэтому тестирование будет происходить именно в нем.

• Postgre SQL 8.4.3-3.1C

Текущая актуальная редация данной СУБД, которая доступна для скачивания с сайта 1С.

• Postgre SQL 9.0.3-3.1C 64-битная редация (тестовая версия)

Новая версия СУБД, которая работает в 64-битном режиме. В данный момент доступна для тестирования партрнерам на сайте 1С. Впрочем на сайте разработчиков Postgre SQL эта версия уже давно находится в статусе релиза, а тестовой версией считается в данный момент 9.1 beta 3.

• IBM DB2 Enterprise Server Edition 9.7 Fix Pack 4, 64-битная редация

Самая свежая на текущий момент версия СУБД от компании IBM.

• Файловая база данных

Файловый режим взят для сравнения. Поскольку все остальные варианты являются типичными примерами 3-звенной архитектуры, было интересно сравнить их чистую производительность с простым файловым режимом.

В тестировании принимала участие версия платформы 8.2.14.519. Сервер приложений 64-разрядный.

В качестве системы тестов были выбраны следующие 5 режимов тестирования:

• Cоздание 200 000 элементов справочников без общей транзакции. Создаваемые элементы содержат некоторое количество реквизитов и табличную часть.

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

• Cоздание 200 000 элементов справочников в единой транзакции. Как и в прошлом тесте, создаваемые элементы содержат табличную часть.

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

• Создание 15 000 документов и проведение их в неоперативном режиме. Дата документа последовательно выбирается из диапазона с 01.01.2011 по 30.06.2011. В документе присутствует табличная часть, она заполняется 100 строчками. Документ делает движение по 3-м регистрам накопления. На момент выполнения данного этапа тестирования регистры накопления рассчитаны по 30.06.2011. Режим разделения итогов включен.

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

• Последовательная выборка в цикле и повторное проведение всех документов в базе. По сути на данном этапе происходит тестирование скорости перепроведения.

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

• Выполнение запросов к имеющимся данным. На основании данных каждого из документов идет запрос к регистру накопления для построения отчета оборотно-сальдового типа за полгода. В качестве фильтра выбирается список товаров из табличной части документа. Этот список указывается в качестве фильтра виртуальной таблицы «ОстаткиИОбороты».

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

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

Рассмотрим трудности инсталляции и особенности настройки отдельно по каждой СУБД.

• Microsoft SQL 2000 Server.

После установки СУБД и последующей установки 4-го сервис-пака была предпринята попытка установить свежие обновления, которая закончилась неудачно. На 64-битной платформе не удалось установить ни один из многочисленных, последовавших за 4-м сервис-паком пакетов обновления. Запуск каждого из них завершался ошибкой и сообщением «Недостаточно памяти для обработки команды». В 4-м сервис-паке (версия 8.00.2039) содержится ошибка при работе с памятью в режиме AWE, делающая возможным использование не более половины доступной памяти, поэтому при тестировании был выбран стандартный режим работы памяти. В качестве предварительного вывода уже по результатам установки можно сказать, что на системах Windows-7 и Windows-2008 x64 с большим объемом памяти использовать SQL-2000 не рекомендуется.

При установке использовались все стандартные параметры, настройка на максимальную производительность заключалась в изменений свойств файла данных и файла логов, было изменено приращение: вместо 10% для файла данных было выбрано приращение в 20 мегабайт, вместо 10% для лога приращение в 10 мегабайт. Также был отключен параллелизм, выставлением опции «max degree of parallelism» в значение 1.

При выполнении тестов была продемонстрирована интересная особенность работы с памятью на 64-битной системе. Как известно SQL-сервер в стандартном режиме может занять до 1.7 Гб памяти, в режиме «⁄3GB» до 2.7 Гб, и до 64 Гб в расширенном режиме «AWE». Тем интереснее оказалось поведение системы. На приведенном скриншоте можно наблюдать следующую картину - служба SQL использует для своих нужд 3.7 Гб памяти, причем в стандартном режиме.




• Microsoft SQL 2005 Server и Microsoft SQL 2008 R2 Server

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

• Postgre SQL 8.4.3-3.1C и Postgre SQL 9.0.3-3.1C

При установке по умолчанию неправильно выбирается кодировка, поэтому пришлось провести повторную инсталляцию и во время диалога инсталляции указать кодировку UTF-8. После установки пришлось отключить один из существующих в системе виртуальных адаптеров, так как иначе не происходило соединение с СУБД.

Так как система не настроена по умолчанию на максимальную производительность, были применены следующие настройки по сравнению со стандартными:

Опция	Стандартное значение	Новое значение
shared_buffers	32MB	512MB
temp_buffers	8MB	64MB
work_mem	1MB	512MB
maintenance_work_mem	16MB	512MB
wal_buffers	64KB	4096KB
checkpoint_segments	3	24
checkpoint_timeout	3min	15min
effective_cache_size	512MB	4096MB

• IBM DB2 9.7 FP4

Для обеспечения производительности на сервере баз данных отключен параллелизм, опция «MAX_QUERYDEGREE» установлена в «1».

Далее были применены стандартные настройки оптимизации, путем выполнение команды консоли:


db2stop
db2set DB2_WORKLOAD=1C
db2start

Также были применены опции базы данных, разрешающие использовать порядка 6 Гб памяти:

UPDATE DATABASE CONFIGURATION FOR DB2TEST USING UTIL_HEAP_SZ 321032 ;

Интересные моменты при выполнении тестирования:

• Postgre SQL обоих версий.

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

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


• IBM DB2 9.7 FP4

В ходе тестирования была выявлена интересная особенность. На третьем этапе, когда используется механизм создания и проведения документов происходит значительное увеличение объемов базы данных. При этом общая производительность начинает постепенно замедляться. Причем, судя по замерам производительности, основное время уходило на механизм проведения документа. На скриншоте видно, что в нескольких замерах время, уходящее на запись документа все время возрастает:



По результатам замеров после 5000-7000 созданных документов время проведения одного документа достигает порядка 30 секунд и в будущем продолжает увеличиваться. Без дополнительных настроек завершения тестирования я так ни разу и не дождался, так как на один третий этап уходило более суток.

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

Результаты тестирования:

Расмотрим результаты подробнее. Сразу видно, что эталонная система на базе файловой версии показывает самые лучшие результаты. Это предопределено самим подходом к тестированию, так как измеряется чистая производительность без учета факторов многопользовательской работы. Зеленым, желтым и красным цветом помечены соответственно первый, второй и худший в группе результат. В обычных рабочих условиях наибольшую ценность имеет выполнение этапа 3 и этапа 5 в силу наибольшей статистической распространенности.

• Тест 1.

  Наилучшим образом себя показывают себя оба варианта Postgre SQL: 32-разрядная версия на первом месте, и 64-разрядная версия Postgre SQL 9.0.3 на втором. Самый худший результат у SQL-2008 R2. DB2 показывает результат чуть хуже SQL-2000 и SQL-2005 R2, но все же лучше, чем SQL-2008 R2.

• Тест 2.

Снова на первом месте Postgre SQL. 64-разрядная версия 9.0.3 на первом, 32-разрядная на втором. Последний результат у SQL-2000. Впрочем все результаты очень близко друг от друга, разница измеряется в секундах.

• Тест 3.

Один из основных тестов - демонстрирует производительность СУБД в процессе создания и проведения документов - типичное действие в OLTP базах данных. Почетное первое место занимает SQL-2000. Далее, с отставанием следуют SQL-2005 и SQL-2008 R2, затем с заметным отставанием идет DB2. Очень плохие результаты показывают системы на базе Postgre SQL, разница по данному тесту между первым и последним местом примерно в 4.5 раза. 64-разрядная версия Postgre SQL показывает себя лучше, чем 32-разрядная, которая занимает последнее место, впрочим с такими отставанием от лидеров это уже не важно.

• Тест 4.

Перепроведение документов - операция, довольно часто встречающаяся в OLTP-системах. Посмотрим, как распределились участники. На первом месте SQL-2005, на втором SQL-2008 R2. Далее следует SQL-2000, за ним Postgre SQL, причем 64-разрядная версия опять немного превосходит своего 32-разрядного собрата. Хуший результат в этом тесте у IBM DB2.

• Тест 5.

Второй основной тест - демонстрирует производительность СУБД при выполнении запросов средней сложности на выборку данных. Что характерно - сильного разброса значений тут не наблюдается. Первое место занимает DB2, второе SQL-2008 R2, далее с небольшим отрывом SQL-2000 и SQL-2005. На последнем месте - Postgre SQL в 32-битной редакции.

Общее время.

Подведем итоги. Наибольшую долю времени во всех тестах занимают 3 и 5 этапы, соответственно, системы, лучше всего себя проявившие в них, фактически становятся победителями. Первые три места занимают по результатам тестирования представители семейства Microsoft SQL. На первом месте идет SQL-2000, на втором - SQL-2008 R2, на третьем - SQL-2005. Далее со значительным отрывом идут DB2 и Postgre SQL обоих версий. Остальные выводы можно сделать самостоятельно.

Файл выгрузки базы (1Cv8.dt) для проведения самостоятельных экспериментов по аналогичной методике можно скачать здесь (требуется версия платформы 8.2.14.519 или выше).