что лучше для 1с mssql или postgresql

Сравнение производительности 1С при использовании СУБД PostgreSQL и MS SQL

Затраты на СУБД MS SQL и PostgreSQL:

В связи со стремительной девальвацией рубля, покупать СУБД Microsoft SQL стало очень дорого, а для некоторых компаний стоимость этих лицензий стала совсем «неподъемной». В данный момент чтобы развернуть сервер Microsoft SQL для 20 пользователей необходимо купить такие лицензии:

1 лицензия на операционную систему (WinSvrStd 2012R2 )

20 лицензий на подключение к серверу (WinSvrCAL 2012)

1 лицензия на сервер СУБД (SQLSvrStd 2014)

20 лицензий на подключение к СУБД (SQLCAL 2014)

Так как использовать свободное ПО очень привлекательно с финансовой точки зрения, было решено проверить, на сколько это хорошо с точки зрения производительности.

Тестирование производительности 1С:

Таблица 1. Тестовые стенды

Windows Server 2012R2

Microsoft SQL Server 2012R2

Intel Core i 5 3330 (3.0 Ghz )

24 GB DDD 3 1333 Ghz

Для начала был выполнен «тест Гилева», который показал незначительное преимущество стенда номер 2, против стенда со свободным ПО.

Результаты смотрим ниже, разница в значениях получилась всего 3%.

Рисунок 1. Результат теста Гилева. Стенд №2 СУБД MS SQL

Рисунок 2. Результат теста Гилева. Стенд №1 СУБД PostgreSQL

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

Таблица 2. Характеристики тестовой базы

Управление производственным предприятием

Таблица 3. Результаты APDEX

Время выполнения в секундах

Проведение нового документа

Документ объект: Заказ клиента

Анализ доходов расходов

Ведомость по партиям товаров

Ведомость по товарам на складах

Расчеты с клиентами

В среднем наша реальная база при использовании MSSQL работала на 45% быстрее, чем на стенде со свободным ПО. На некоторых тестах отрыв был очень значителен, а на таких как, например проведение нового документа составлял всего 11%.

Вывод:

1C на СУБД MSSQL работает примерно в 1,5 быстрее, чем на PostgreSQL. Соответственно, если есть возможность купить или арендовать лицензии MSSQL, лучше использовать его для более высокой производительности. Для небольших и ненагруженных баз можно попробовать использовать версию MSSQL Express. Тестов с ней мы не проводили, поэтому она может показать себя по производительности как лучше так и хуже PostgreSQL. Данная редакция ограничена использованием 1 процессора и 1 Гб ОЗУ, также не работает с базами более 10Гб. Если база дорастет до такого размера, то она остановиться и перестанет работать полностью, но как показывает практика, если в базе работает 15-20 пользователей, то комфортно можно работать при размере базы 4-5ГБ, далее база начинает сильно тормозить.

Оценка «тестом Гилева» показывает крайне незначительное превосходство MSSQL, что позволяет сделать предположение о том, что другие базы 1С могут работать на PostgreSQL так же хорошо, как и на MSSQL, а возможно и быстрее. Перед выбором СУБД рекомендуем провести тесты на своей конкретной базе и сравнить полученные результаты.

В конце 2017 года мы провели новые тесты и опубликовали их в очередной статье.

Источник

Выбор между Postgre и MS SQL для 1С

1. PostgreSQL	80% (4)
2. MS SQL	20% (1)

Всего мнений: 5

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

Вот мне что нравится в такого рода обсуждениях = хз лет тому назад один кто-то накорябал о допилках для постгри, потому что в те самые годы и не было готовых настроек для него.

Теперь же, не взирая на то, что на самих дистрибах 1С выкладывается сборка постгри, которая жестко глючить не будет, а проблемы могут появиться только если система будет реально нагружена, ну даже не знаю. может после 200 или 250 пользователей будут проблемы, а может и не будет.
А на 50, на 70, на 100 пользователей проблем не наблюдается.

Но нет. Это же страшный страшный постгри и надо приходить в ветки и рассказывать страшилки о неких сакральных знаниях, которые знают грамотные админы, а что это за знания сакральные кто-то о них что-то знает? Вы бы хоть у админов спросили, что это там такое сакральное, но ведь нет ничего! Но напугать обязательно нужно.

(27) Я в таких постах смотрю на дату сообщений, думаю, может что взглючнуло и древние мысли повылазили. Нет, наши дни.
А пг-админ обязательно должен дорого стоить, без этого никак.

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

(44) Ну то что вам на мисте сказали, это же тоже не аргумент? Вы постгрес ставили/настраивали хоть раз? А MS SQL? Проведите изыскания: поставьте, прогоните тесты, сравните. Погуглите и все вопросы отпадут.

P.S. Мне Постгрес нравиться ровно тем, что я умею его готовить. MS SQL не умею, в редакциях не разбираюсь, ценники не видел. Но еще ни разу не слышал, что он работает хуже Postgres.

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

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

И еще раз, пишите что доросла база или Компания до покупки выделенного сервера внезапно.
Уточните, если не трудно, а сколько же пользователей могло работать в этой базе в файловом режиме и без сервера?
И сколько пользователей будет работать сейчас?
И если не трудно, то может намекнете какие конфигурации у этих баз или если не хотите называть сами конфигурации, то характеристики какие-то, может там версии БСП и режим совместимости и какую платформу 1С (версию платформы) собираетесь ставить. Ну и т.д.

Вот для уравновешивания ссылки на обсуждение постом выше еще одна ссылка

Источник

Исследование быстродействия СУБД MS SQL Server Developer 2016 и PostgreSQL 10.5 для 1С

Цели и требования к тестированию «1С Бухгалтерии»

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

Основными параметрами, которые должны быть получены при тестировании:

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

Описание настроек и характеристик тестируемых сред

Мы в компании Fortis решили перепроверить результаты, в том числе с помощью известного теста Гилева.

Также нас подстегнуло к тестированию в том числе и некоторые публикации по результатам изменения производительности при переходе от MS SQL Server к PostgreSQL. Такие как: 1С Батл: PostgreSQL 9,10 vs MS SQL 2016.

Итак, вот инфраструктура для тестирования:

Сервера для MS SQL и PostgreSQL являлись виртуальными и запускались поочередно для нужного теста. 1С стоял на отдельном сервере.

Спецификация гипервизора:
Model: Supermicro SYS-6028R-TRT
CPU: Intel® Xeon® CPU E5-2630 v3 @2.40GHz (2 sockes * 16 CPU HT = 32CPU)
RAM: 212 GB
ОС: VMWare ESXi 6.5
PowerProfile: Performance

Дисковая подсистема гипервизора:
Контроллер: Adaptec 6805, Cache size: 512MB
Volume: RAID 10, 5.7 TB
Stripe-size: 1024 KB
Write-cache: on
Read-cache: off
Диски: 6 шт. HGST HUS726T6TAL,
Sector-Size: 512 Bytes
Write Cache: on

PostgreSQL был настроен следующим образом:

Настройки заданы в формате файла профиля для демона tuned:

Все содержимое файла postgresql.conf:

MS SQL был настроен следующим образом:

Настройки кластера 1С оставили стандартными:

На серверах не стояла антивирусная программа и не было установлено ничего стороннего.

Для MS SQL, БД tempdb была вынесена на отдельный логический диск. Однако, файлы данных и файлы журналов транзакций для баз данных располагались на одном логическом диске (т е не было сделано разнесения файлов данных и журналов транзакций на отдельные логические диски).

Индексирование дисков в Windows, где располагалась MS SQL Server, было отключено на всех логических дисках (как это принято делать в большинстве случаев на продовских средах).

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

На каждый день выполнения запускаются блоки ввода и вывода информации:

Основные возможности скрипта тестирования:

Результаты

А теперь самое интересное-результаты на СУБД MS SQL Server:

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

Как видно из результатов, в общем синтетическом тесте СУБД PostgreSQL проиграла по производительности СУБД MS SQL в среднем на 14,82%. Однако, по последним двум показателям PostgreSQL показал значительно лучше результат, чем MS SQL.

Специализированные тесты для 1С Бухгалтерии:

Как видно из результатов, 1С Бухгалтерия примерно одинаково работает и на MS SQL, и на PostgreSQL при данных выше настройках.

В обоих случаях СУБД работала стабильно.

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

Стоит отметить, что тест Гилева запускался многократно для PostgreSQL-приведены самые лучшие результаты. По MS SQL был запущен тест Гилева 3 раза, т к далее оптимизацией по MS SQL не занимались. Все последующие попытки были привести слона к показателям MS SQL.

После достижения оптимальной разности по синтетическому тесту Гилева между MS SQL и PostgreSQL, были проведены специализированные тесты для 1С Бухгалтерии, описанные выше.

Общий вывод заключается в том, что, несмотря на существенную просадку в производительности по синтетическому тесту Гилева СУБД PostgreSQL относительно MS SQL, при должных настройках, данных выше, 1С Бухгалтерию можно установить как на СУБД MS SQL, так и на СУБД PostgreSQL.

Замечания

Сразу необходимо отметить, что данный анализ делался только для сравнения производительности 1С в разных СУБД.

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

Однако, результат теста Гилева позволяет предположить, что на всех конфигурациях 1С версии 8.3 и новее при должных настройках максимальная просадка в производительности вероятнее всего составит не более 15% для СУБД PostgreSQL относительно СУБД MS SQL. Также стоит учесть, что любое детальное тестирование для точного сравнения занимает значительное время и ресурсы. Исходя из этого, можно сделать более вероятное предположение, что 1С версии 8.3 и новее можно перенести с MS SQL на PostgreSQL с максимальной потерей производительности до 15%. Объективных препятствий для перехода не выявлено, т к эти 15% могут и не проявиться, а в случае их проявления, достаточно просто закупить немного мощнее оборудование при необходимости.

Также важно отметить, что тестируемые БД были небольшими, т е значительно меньше 100 ГБ размером данных, а также максимальное количество одновременно работающих потоков было 4. Это означает, что для больших баз, размер которых существенно больше 100 ГБ (например, около 1 ТБ), а также для баз с интенсивными обращениями (десятки и сотни одновременных активных потоков) данные результаты могут быть некорректными.

Для более объективного анализа, будет полезно в будущем сравнить выпущенную MS SQL Server 2019 Developer и PostgreSQL 12, установленных на одной и той же ОС CentOS, а также когда MS SQL стоит на последней версии ОС Windows Server. Сейчас же PostgreSQL никто не ставит на ОС Windows, т к просадка в производительности у СУБД PostgreSQL при этом будет весьма существенной.

На данный момент пока мы не готовы провести такой анализ, но в будущем вполне возможно его проведем. Тогда мы и напишем более подробно при каких операциях PostgreSQL лучше MS SQL и на сколько в процентах, а где MS SQL лучше PostgreSQL и на сколько в процентах.

Также в нашем тесте не были применены методы оптимизации для MS SQL, которые описаны здесь. Возможно в этой статье просто забыли выключить индексирование дисков Windows.

При сравнении двух СУБД надо помнить об еще одном весомом моменте: СУБД PostgreSQL бесплатная и открытая, тогда как СУБД MS SQL платная и имеет закрытый исходный код.

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

На счет остальных тестов Гилева. По трассировке видно, что максимальное количество потоков было 7, однако вывод о количестве пользователей было более 50. Также по запросом не совсем понятно как вычисляются и прочие показатели. Потому остальные тесты не являются объективными и носят крайне вариативный и приближенный характер. Более точные значения дадут лишь специализированные тесты, учитывающие специфику не только самой системы, но и работы самих пользователей.

Благодарности

Послесловие

Также любопытный анализ делался в этой статье.

А какие результаты были у вас и как вы проводили тестирование?

Источник

Тест-драйв: Postgres Pro в сборке для Скалы-СР против MS SQL на примере 1С:Предприятие

Трудно найти организацию, в которой не используются бухгалтерские системы от 1С – даже в мегахолдингах, где давно внедрён SAP или OEBS, они почти всегда используются на том или ином участке. Отрадно, что российское прикладное ПО стало фактическим стандартом для наших компаний, но есть одна тонкость: столь же фактическим стандартом для самого 1C:Предприятия стало использование Microsoft SQL Server в качестве СУБД.

В среде практикующих 1С-ников наиболее распространено мнение, что без коммерческих СУБД от американских производителей ничего хорошего не выйдет, дескать, несколько сотен пользователей неизбежно требуют установки базы на MS SQL, Oracle Database или IBM DB2 в этом случае. Про работу под управлением свободой СУБД PostgreSQL известные нам мнения практиков расходились, но в диапазоне от «совсем не работает» до «пригодно для нескольких десятков пользователей, не более».

Был и ряд правдоподобных объяснений столь скромным оценкам: и активное использование платформами 1С механизмов временных таблиц (которые в Постгресе реализованы слишком «честно» – с транзакционным DDL, всеми возможностями по восстановлению), и особенности работы с текстовыми данными (тогда как в области многоязычных текстов ванильный Постгрес, опять же, слишком консервативен, используя не самые высокопроизводительные системные библиотеки), и ряд других менее значимых аспектов.

Но мы тайно верили в Постгрес, тем более, что в сборке Postgres Pro Enterprise Edition заявлялось о решении всех тех проблем, которыми скептики оправдывали выбор коммерческих СУБД. К тому же нам было важно получить показатели назначения для аппаратно-программного комплекса Скала-СР / Postrgres Pro – построенной на основе санкционно безопасного оборудования и софта машины баз данных для СУБД, разработанной IBS совместно с Postgres Professional.

Из тиражируемых приложений самым очевидным применением для такой машины должны стать, конечно же, системы 1C. И результаты проведённых бенчмарков полностью перевели нас из разряда «тайно верующих» (и даже сомневающихся) в категорию «убеждённых»: теперь мы можем смело утверждать, что 1C:Предприятие версии 8.3 на сборке Postgres Pro EE 1.5 для Скалы-СР / Postgres Pro работает лучше, чем на MS SQL 2012 на том же оборудовании со всеми возможными оптимизациями.

Итак, некоторые детали экспериментов. В плане тестирования производительности у 1С всё системно и научно – есть типовая конфигурация «Стандартный нагрузочный тест», на которой и запускается бенчмарк, поэтапно добавляющий новых пользователей в нагрузку до тех пор, пока приложение работает достаточно отзывчиво для комфортной работы. (Более точно – пользователи добавляются до тех пор, пока стандартный показатель производительности приложений Apdex не опускается ниже порога в 0,85, и максимальное число таких эффективно работающих пользователей и считается результатом бенчмарка.)

Мы использовали версию 8.3.9.1850 1С:Предприятия, стандартный нагрузочный тест в версии 2.0.17.36. Изначально было решено никаких скидок Постгресу не давать: делаем максимальные оптимизации на MS SQL на узле из комплекса Скала-СР / Postgres Pro (ставим Windows на «голое железо», настраиваем по всем канонам, для скорости – делаем ramdisk для временных таблиц), а потом – возвращаем тот же узел в комплекс Скала-СР, накатываем Linux и Postgres Pro EE, и на нём одном (без доступных в комплексе кластерных фишек) – прогоняем тот же тест.

Тест первый: начинаем со 100 рабочих мест, нагрузка 50/50 – половина формирует документы, половина – отчёты. Тест второй: начинаем с 400, нагрузка 70/30. MS SQL «закончился» в первом тесте на 360 пользователях, на втором – на 540, притом ограничителем в обоих пусках стала работа с локальным вводом-выводом, при том, что загрузить процессор удалось в среднем лишь на 30%. Postgres Pro в первом тесте дошёл до 440 рабочих мест, а на втором – до 660, а упёрлось на сервере БД всё в процессор, уходящий в загрузку более 90% на «максимальных пользователях».

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

Источник

1С Батл: PostgreSQL 9,10 vs MS SQL 2016

Предыстория

Примерно пять лет назад в мире 1С начал появляться Postgres, за что большое спасибо команде Postgres Pro: Олегу Бартунову и Федору Сигаеву, которые продвинули эту СУБД. Как раз в это время у руководства нашей компании появилась задача резко вырасти в масштабах ИТ-инфраструктуры 1С. При этом была поставлена задача максимально сэкономить бюджет. Мой хороший друг, а по совместительству эксперт по техвопросам 1С сказал: «Антоха, кто не рискует, тот потом на Инфостарте не выступает!». И мы рискнули. И я выступаю на Инфостарте.

Первый опыт работы с PostgreSQL на Windows

С чего мы начали? В 2014 году рискнули перевести 5 баз 1С общим объемом порядка 100 гигабайт на Postgres. Не сразу стали перепрыгивать бездну нашего незнания между Windows и Linux, а мир 1С, мне кажется, до сих пор на 80% это мир Windows. Поэтому сначала решили перепрыгнуть пропасть незнания между двумя базами данных: MS SQL и PostgreSQL.

Мы запустили Postgres на Windows. Сначала сильно удивились, что оно заработало. В целом все завелось, заработало, даже база открылась. Правда, потом начались бессонные ночи и дни без обеденного перерыва в попытках настроить Postgres так, чтобы он работал хорошо.

На момент 2014 года информации никакой нет. Есть английская документация, а в мире 1С английский язык не в почете: вы даже код пишете на русском. Поэтому читать тяжело, понимать еще тяжелее. И по сравнению с дружественным интерфейсным MS SQL, где вся настройка – это 5 галочек и 2 цифры, настройки в Postgres – это сотни параметров, слишком непонятно, как и на что отреагирует система, отреагирует ли вообще. Менять приходилось по одному параметру, потому что иначе вообще не поймешь, на что была реакция. А очень часто смена одного параметра не давала никакой реакции. Вот так мы и жили примерно полгода до момента обнаружения той самой ошибки, которая сейчас уже исправлена. О ней рассказывал Олег Бартунов.

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

Там происходило очень чудесная вещь: у Postgres есть много файлов статистики. Один из них на весь сервер, и он переименовывается несколько десятков, может быть, сотен, может быть, тысяч раз в секунду. Так построена система: она создает рядом новый файл статистики, переименовывая его в действующий. А наша любимая Windows не дает так работать с файлами в своей файловой системе. Если файл кто-то читает, переименовать его нельзя. Postgres по-честному пишет, что у него нет доступа к статистике, поэтому он будет использовать старые файлы. Ладно, используй. Но нет, происходило 15-ти секундное торможение всего сервера, просто на 15 секунд останавливались все транзакции.

Мы долго не верили своим глазам, мы боялись рассказать это разработчикам. Что они бы подумали? Что какие-то дураки взялись за систему, и теперь непонятно, что от нас хотят. В итоге мы боролись-боролись, но не побороли. И все-таки написали письмо в Postgres Pro. Там тоже долго удивлялись, не верили, что такое может быть. Потом подтвердили, что, действительно, есть косяк. Пообещали исправить.

Отказ от Windows

Но у нас время поджимало. И мы решили прыгать через пропасть незнания в Linux. Это вообще кошмар. То есть система Linux – хорошая, но кошмар для админов, которые всю жизнь жили на Windows. Ни красивых окошек, ни мышек, ни кликов, даже диспетчера задач нет. Есть какие-то черные окна с белыми буковками. Когда разберешься, буковки станут цветными. Но это все, что ожидает админа в Linux. Какие службы работают, как что куда поставить – ничего не понятно. Там уже бессонные ночи начались не только у 1С-ников, но и у админов. Но примерно на 20-ой инсталляции CentOS все, вроде, стало хорошо.

Запустили Postgres, и он тоже заработал. А мы к тому времени уже были крутые чуваки в настройке Postgres, и мы его сразу настроили: и статистику внесли в оперативную память, и все параметры включили как надо.

На текущий момент мы пришли к такой ситуации: у нас 400 с лишним баз, 15 терабайт данных, все это крутится на Postgres на Linux, все сервера Postgres имеют реплики, кто-то имеет каскадные реплики, кто-то имеет несколько реплик на один мастер. То есть это не просто какая-то одноранговая система баз данных. Мы там снимаем бэкапы (backup) с реплик, мы можем восстановить бэкап с рабочей базы в тестовую или базу разработчиков одной строчкой, сохраняя транзакционную целостность данных, при этом не создавая файла бэкапа.

Самое удивительное – все есть в документации! Ты на грабли наступил уже 15 раз, все попробовал, думаешь, что «открыл Америку». Заходишь в документацию, а там прямым текстом написано все то, что ты открывал до этого три дня. Понимать эту документацию ты начинаешь только тогда, когда несколько раз уже окунулся в саму практику.

Так мы счастливо живём до сих пор.

Тестирование

В какой-то момент задумались, а может, нам страсть к Postgres на Linux застила глаза, и нам только кажется, что все хорошо работает. Решили попробовать подтвердить, что работает как минимум не хуже чем с MS SQL, а может быть, если и хуже-то, то совсем чуть-чуть.

На самом деле, когда приступали к нагрузочному тестированию, вся моя команда, скрестив пальчики думала, ладно, пусть Postgres проиграет, но проиграет не сильно. Все-таки он еще новенький, может быть, нами еще не до конца изученный, но очень активно развивается, и как рассказывал Олег Бартунов, будет очень много крутых фишек в версиях 10 в 11.

На момент организации нашего батла была версия 9. И мы решили, что площадкой для батла будет Windows 2012 R2. Почему Windows? Это для того чтобы соревнование было совсем честным, не учитывая операционные системы, просто проверка двух баз данных.

Итак, в красном углу ринга – заслуженный чемпион, обладатель всех поясов производительности 1С, имеющий любые регалии в мире 1С – Microsoft SQL server версия 2016, последняя поддерживаемая на данный момент.

В синем углу ринга – наш новичок, претендент, PostgreSQL. Он выступает сразу двумя бойцами, каждый бьется по очереди. Это Postgres 9.6 и Postgres 10. Обе версии на данный момент поддерживаются 1С.

Платформа взята последняя релизная на момент тестирования. Все сервера баз данных располагаются на одном и том же железе, это прямо одна и та же коробочка. Все настроено оптимально: и дисковые подсистемы, и процессор, и сервера баз данных (оптимально, согласно требованиям фирмы 1С и нашему опыту). Плюс к этому все настроено на многопользовательскую нагрузку, в том числе параллелизм отключен: и на MS SQL, и на Postgres стоят единички.

Первый раунд

В первом раунде тяжелая операция – загрузка DT 40 с лишним гигабайт, итоговая база почти 2 терабайта. Сразу оговорюсь, если заглянуть в интернет, там будет много информации о том, что в DT не выгружается база, потому что она более 100 гигабайт, и ничего не работает. Все работает, надо только правильно настраивать сервер 1С, надо понимать, куда сервер 1С выгружает DT. Подтверждаю на своем опыте: база до 5 терабайт (больше не приходилось выгружать) из DT загружается и в DT выгружается. Все остальное – это неумение настраивать сервера 1С.

Первые результаты. С явным преимуществом побеждает MS SQL. Он в 2 раза быстрее загрузил данные в DT. Оба загружали очень долго, Postgres – почти двое суток, а MS SQL – почти сутки.

В то время как раз был шум про мельдоний (скандал в СМИ), и мы тоже решили обратиться к допингу. Решили использовать топ вредных советов из интернета на запрос «1С + Postgres тормозит». Первый совет – отключить fsync. Отключили. Получили другой результат – на 10% быстрее, чем с включенным, но риски несоизмеримы. Потому что такое отключение приведет к потере всего сервера баз данных. Вы не сможете ничего восстановить при аварийном завершении. Никогда так не делайте! Это самый вредный совет, который только может быть. Если вдруг вам действительно помогло отключение fsync, и все заработало в 10 раз быстрее, Это значит что у вас сервер неправильно настроен, начиная с самого низкого уровня – с железа, с дисками.

Fsync отключать нельзя никогда!

Но что такое есть в Postgres, что он загружает данные в DT в 2 раза дольше? Наши исследования показали, что это «create index». Он создает индексы намного медленнее MS. В начале 2018 года разработчики обещали, что в версии 12 эта ситуация улучшится. Ждем с нетерпением, думаю, тогда даже в этом раунде мы будем близки к MS SQL.

Второй раунд

Тут уже практически пользовательская нагрузка. Операция, на которой проводится тестирование, – восстановление последовательности партионного

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

Все это делаем в 10 потоков. Это уже чуть-чуть не типовой этап, сделана определенная обработка, но внутри все запросы типовые.

В результате у нас получилось, что Postgres всего на 4% лучше. Делалось все очень долго – порядка 18 часов. И бухгалтеры будут вынуждены весь день не работать, чтобы дождаться результатов.

Поскольку результат получился не очень большой, плюс 4%, решили вместо

мельдония использовать что-нибудь похлеще. Второй в рейтинге вредных советов интернета на запрос «1С + Postgres тормозит» оказалась рекомендация отключить autovacuum. Отключили.

Результат получился еще хуже – примерно на 5%. То есть если бы мы изначально настроили систему с помощью этого вредного совета, мы бы вообще раунд полностью проиграли, было бы минус 0,6%.

На этом хочу остановиться чуть подробнее. Что за зверь такой autovacuum, зачем он нужен. И почему разработчики Postgres на каждой конференции твердят: «Не отключайте autovacuum!», но народ упорно его отключает. Попытаюсь объяснить, как говорят, на пальцах.

Чтобы понять, для чего нужен autovacuum, нужно понять, как Postgres работает с данными. Операция insert – записали строчку. Помимо строчки, пишется еще два служебных параметры x min и x max. В x min записывается номер транзакции, которая выполнила этот insert. Операция delete на самом деле ничего не удаляет, она просто в служебное поле строки x max записывает номер транзакции, которая ее удалила. Потом идет самая прикольная операция update. На самом деле нет такой операции, это просто delete + insert.

А в мире 1С, к сожалению, просто обожают работать задним числом: для пользователей не вопрос перевести месяц или год. То есть апдейтов миллионы. У нас не столько растут данные с помощью insert, сколько с помощью update, мы постоянно что-то обновляем. Из-за этого база имеет эффект распухания. Ладно, пусть раздувается, скажем админам, что это их проблемы, пусть увеличивают диски. Они увеличат. Но если было бы все так просто, никто не заморачивался бы. Проблема в том, что данные хранятся не где-то в сферическом вакууме, они хранятся в страницах. И когда у вас в страницах хранится куча мертвых данных, а в Postgres есть такое страшное понятие, как мертвые строчки, и когда вы делаете запрос базе данных, движок вынужден поднять все страницы с данными, отфильтровать данные, в которых x max пустой, и только с ними потом работать. Вы каждый раз заставляете Postgres ставить олимпийские рекорды по поднятию данных с дисков, чтобы выдать вам выборку.

Что делает autovacuum? Autovacuum – это своеобразный пылесос, он циклически и периодически идёт к каждой таблице вашей базы данных и делает выборку всех данных, где x max не пустой и чистит их физически. Теперь туда insert возможен, у вас на страницах будет больше живых данных, чем мертвых. Эффект – вам проще поднимать страницы. Это первое.

Второе. Помимо чистого autovacuum, есть еще такой фоновый процесс autovacuum analyze. Это аналог фонового обновления статистики в MS SQL. Без него планировщик никогда не узнает, что вы в таблицу добавили данные. Было в таблице 100 записей, добавили вы миллион записей, но планировщик свято уверен, что там их 100. И при любом запросе не парится и не ищет никакие индексы. Он просит TableScan, ему его дают, а там миллион записей. И вы сидите и ждете несколько минут.

Поэтому никогда не выключайте autovacuum. Надо его правильно настраивать, но ни в коем случае не отключать. Он имеет кучу настроек, и если у вас autovacuum настроен достаточно агрессивно, то есть он срабатывает на очень маленьком проценте изменения данных в таблицах, то вам не нужны даже ночные и недельные регламенты над базой данных, которые имеются у MS SQL. Ничего не надо делать, просто ничего. Кое-что делают только админы, если точно знают, что в этой таблице недавно удалили огромный массив данных, и ее нужно, грубо говоря, сжать. Тогда делается autovacuum full – это реструктуризация таблицы в понятиях 1С. Рядом создается табличка, куда и копируются данные.

В других случаях вам никакие регламенты, ни ночные, ни недельные, не нужны. Autovacuum все сделает за вас. Только настраивайте его правильно.

Третий раунд

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

В этом раунде Postgres выигрывает с явным преимуществом.

Гораздо благодарнее отнесся к более правильному коду, код правильный в той части, что поднимает гораздо меньше данных, намного меньше данных. Postgres выиграл почти в 2 раза, а по сравнению с изначальным временем выполнения процедура целиком стала выполняться в 3 раза быстрее. И это после вмешательства компетентного специалиста 1С, который понимает, что делать. Я даже думаю, что, обновив весь сервер за космические деньги, вы вряд ли добьетесь большего ускорения, если будут неправильные запросы.

Ничего бы этого не произошло, и этого бы доклада не было, и Postgres бы у меня не было, если бы в свое время Фёдор Сигаев – ведущий разработчик команды Postgres Pro, а также один из всего лишь двух коммитеров во всей России не создали патч OnlineAnalyze для 1С.

Что это такое? Во всем нормальном мире база данных считает, что временные таблицы – это чуть ли не ошибка проектировщика базы данных, и уж точно ошибка программиста, который просто не умеет писать правильные запросы. И считает, ну ладно, раз уж так случилось, простим, создадим этим неучам временную таблицу. Она в любом случае будет очень маленькой – на сотню, может, тысячу записей, но ни в коем случае не на миллионы и не на миллиарды, как это в 1С сделано. 1С вся построена на временных таблицах: на любой запрос мы создадим временные таблицы. И тут возник вопрос о быстродействии Postgres в связи с этим. Postgres крайне прохладно относится к временным таблицам, он их вообще «за людей не считает». Это просто какой-то артефакт, который создался. А мы же когда пишем кода в 1С, мы даже индексируем временные таблицы (прямо индексы по ним создаем). А Postgres на все плевать, потому что планировщик просто не в курсе, что это за временная таблица, сколько там записей, что в ней есть индекс. Он ничего не знает. Он всегда пользуется TableScan и все.

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

Ради интереса отключили OnlineAnalyze. Получили результат тестирования в 17 раз хуже. Мы прождали несколько дней, она у нас все-таки посчитала, результаты упали в 17 раз.

К сожалению, в своей практике сталкиваюсь очень часто и даже на очень крупных предприятиях, на которых есть Postgres и которые уже поискали ответы в интернете на запрос «1С + Postgres тормозит», что люди следуют этим 2 вредным рекомендациям. А тем временем в самом конце конфигурационного файла есть строчка OnlineAnalyze.enable = off. Но если поправим настройку на on, все взлетает.

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

И еще один момент. В последней сборке Postgres, опубликованной на сайте 1С, к сожалению, этого патча нет. Его просто нет в строчке предкомпилированных библиотек, он в настройках есть и даже внизу включен, но его нет в строчках предкомпилируемых библиотек. Надо добавить. Внимательно отнеситесь: патч должен быть, патч должен быть включен. И будет резкий рост производительности.

Финальный раунд

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

И тут Postgres опять выиграл. Он опять более благодарно отнесся к порядку в данных, чем MS. Выиграл не так круто, как на старых итогах, но все-таки на четверть быстрее – это очень серьезный результат.

Итоги батла

Итак, Postgres выиграл со счетом 3:1. Но хочу обратить внимание, что на пользовательских нагрузках, а именно многопоточное проведение документов, участвующих в восстановление последовательности партионного учета, Postgres выиграл вообще со счетом 3:0. Вот такие противоречивые результаты.

Postgres на Linux и Postgres на Windows: что лучше

Сами удивились, сами себя похвалили, какие мы молодцы, что 5 лет назад сделали крутой выбор. Но встречаем очень часто вопрос: стоит ли переходить на Postgres.10 на Windows.

Тот самый злополучный баг Postgres, когда система замирала на 15 секунд из-за недоступности файла статистика исправлен в версии Postgres 10.4.1. Говорю об этом отдельно, потому что эта версия на данный момент 1С не поддерживается. Она есть только на сайте Postgres Pro, мы ее поставили и запустили ради этой конференции. Что получили? При 10 потоках все почти одинаково, что на Postgres версии 9, что на Postgres версии 10. При 20 потоках Postgres.10 в 3 раза быстрее. Я бы даже сказал иначе: Postgres.9 на Windows в 3 раза медленнее, потому что возникает та самая блокировка, замирание на 15 секунд. Причем, оно рандомное, то есть вы не угадаете, это будут замирания один раз в минуту или у вас будет секунда работы, 15 секунд замирание и так тысячу раз.

При 50 потоках Postgres.9 медленнее в 11 раз. При 100 потоках мы не дождались завершения операции. Данные я не привожу. Нам надоело: мы неделю ждали.

Второй самый популярный вопрос, стоит ли переходить на Linux? Да, стоит переходить! По нашим данным, а они у нас достаточно релевантные – 15 терабайт и 400 баз, Postgres работает почти в 2 раза быстрее.

Почему? Не потому что Postgres такой плохой на Windows, а потому что файловая система Windows не способна обрабатывать такое большое количество файлов. Тут вся фишка в том, как Postgres и MS хранят файлы. Если MS хранит по умолчанию всю вашу базу данных в двух файлах (это файл данных mdf и файл журнала транзакций lgf), то Postgres хранит каждую таблицу в отдельном файле и каждый индекс в отдельном файле.

Типовая база бухгалтерии содержит 6 тысяч таблиц и 20 тысяч индексов. Значит, одна база будет в Postgres представлена 26 тысячами файлов. На наших серверах мы примерно делаем по 60 баз на один instant Postgres, это в районе 2 миллионов файлов. С таким количеством файлов Linux управляется, как мы видим, почти в 2 раза быстрее, чем Windows.

Поэтому если вы уже всерьез на Postgres, а всерьез – это наличие хотя бы 20 сессий, начинайте подумывать о переходе на Linux. Причем, не обязательно железный, можете на этой же винде, если сильно страшно, то поднимите hyper-v, поднимите виртуалку, на эту виртуалку ставьте Linux, ставьте Postgres, и получите отличный эффект. Проверено!

Два важных момента

Хочу обратить еще внимание на два небольших досадных недоразумения, которые пока есть еще в Postgres. Первое недоразумение – это такой параметр по настройке default_statistics_target. Это своеобразный множитель количества страниц, который берет Postgres для расчета статистики. Он этот множитель умножает на 300 и берет такое количество страниц. Множитель может иметь значение от 1 до 10 тысяч, по умолчанию 100. Все хорошо работает при сотке. Но как только мы ставим 10 тысяч, Postgres, действительно, берет много страниц, считает статистику, но потом запросы к базе начинают резко тормозить. К разработчикам мы еще с этим не обращались, вот-вот обратимся, думаю, победим и разберемся.

Второй момент – это репликация. Просто обращу ваше внимание. Разработчики говорят: репликации – это не бэкап. Это действительно так. Кроме того, репликация может отставать на часы и дни. Потому что она однопоточная. Все, что мастер-сервер удалил, создал, обновил в сотне своих потоков, все это придется догонять в один поток. Поэтому реплика это хорошо, мы, например, с нее бэкапы льем, но перед тем, как слить бэкап с реплики, мы проверяем какое отставание. Если отставание не больше секунды, то делаем бэкап с нее, а если больше – то с мастера.

В завершение хочу сказать, что, привлекая компетентных специалистов, вы можете зарабатывать золотые медали любых тестов 1С. Даже на таком новичке в мире 1С, как Postgres, выбирая правильную инфраструктуру.

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.

Источник