Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 113
А почему не проверяли на SSD дисках? Они по сравнению с SATA дают огромный прирост производительности и сейчас использовать SATA в базах данных для бизнес-приложений очень странно (по крайней мере у нас на всех проектах прирост производительности был минимум на 50 процентов, с еще более значительным уменьшением времени отклика).
Кроме того, тут вообще немного странное сравнение, учитывая, что MS SQL — блокировочник, а PostgreSQL — версионник. В production'е ключевое отличие будет именно в этом (когда пойдет длинный запрос на чтение из какой-нибудь таблицы, а в это время будет идти в нее запись). Понятно, что на относительно простеньких запросах от одного/двух пользователей разницы не будет.
Вот если бы тестирование было, что 5 человек формируют «длинные» отчеты и в это время идут стандартные действия от 50-100 пользователей, то это было бы более показательно.
Кроме того, тут вообще немного странное сравнение, учитывая, что MS SQL — блокировочник, а PostgreSQL — версионник. В production'е ключевое отличие будет именно в этом (когда пойдет длинный запрос на чтение из какой-нибудь таблицы, а в это время будет идти в нее запись). Понятно, что на относительно простеньких запросах от одного/двух пользователей разницы не будет.
Вот если бы тестирование было, что 5 человек формируют «длинные» отчеты и в это время идут стандартные действия от 50-100 пользователей, то это было бы более показательно.
Вы правы, обычно используется SSD в продах, но для теста были выбраны обычные диски и т к железо было одно для двух сред, то для сравнения данный ньюанс не противоречит результатам тестирования.
На счет множества пользователей указано в разделе «Замечание»
На счет множества пользователей указано в разделе «Замечание»
Не соглашусь, для более точно оценки скорости работы, хотелось бы, чтобы абсолютные значения тестов были побольше, тогда и погрешность оценки результатов будет ниже. А тут собраны все узкие горлышки для 1С систем, SATA диски, разнесенные сервер приложений и сервер БД. В итоге развернуться самим БД и негде :)
Но так как делал подобные сравнения и понимаю насколько это тяжело и выматывающе могу понять нежелание собирать отдельный конфиг, а взять то что было под рукой.
В целом, мое мнение, в реальной системе от 100 пользователей разницы в выбранной СУБД нет. Для проведения каких-то сложных отчетов проще выгрузиться на отдельную собранную для них машину (быстрый CPU+NVMe+RAM disk) и там все сделать, а остальные как работали так и будут.
Но так как делал подобные сравнения и понимаю насколько это тяжело и выматывающе могу понять нежелание собирать отдельный конфиг, а взять то что было под рукой.
В целом, мое мнение, в реальной системе от 100 пользователей разницы в выбранной СУБД нет. Для проведения каких-то сложных отчетов проще выгрузиться на отдельную собранную для них машину (быстрый CPU+NVMe+RAM disk) и там все сделать, а остальные как работали так и будут.
Тестирование заняло более 2-х недель, не говоря уже о подготовке.
Важны не абсолютные величины, а их отношение в процентах.
Т е сами попугаи мало о чем говорят, а вот отношение обычно должно остаться прежним при замене железа и настроек с условием, что это будет одинаково для двух сравниваемых систем.
Важны не абсолютные величины, а их отношение в процентах.
Т е сами попугаи мало о чем говорят, а вот отношение обычно должно остаться прежним при замене железа и настроек с условием, что это будет одинаково для двух сравниваемых систем.
В MS SQL давно (то ли с 2005, то ли с 2008) появилась возможность работать как с «версионником» (read committed snapshot isolation). Операции чтения в режиме Read Committed теперь не ждут завершения изменяющей транзакции, а читают версию на момент «до начала изменения»
1С работает в этом режиме начиная с 8.3.1. Так что по блокировкам большой разницы быть не должно
1С работает в этом режиме начиная с 8.3.1. Так что по блокировкам большой разницы быть не должно
Из отчёта не понял, как был устроен сервер приложений. Из личной практики — овер 100 пользователей потребовали классическую трехзвенку. Совмещение двух ролей (СУБД и сервер приложений) на одном сервере привело к коллапсу производительности.
Следует заметить также:
1. В IRL за организацию бэкапов выгрузкой в dt порвут на флажки, т.к. данный процесс требует монопольного доступа к базе. Исходя из этого считаю, что этот параметр из набора тестов можно исключить.
2. Совмещение логов транзакций у MS SQL на одном диске с базами — нарушение рекомендаций по настройке СУБД и рекомендаций по обеспечению целостности информации. Также не понятно, где у PostgreSQL располагался WAL (подозреваю, что по-умолчанию, и тогда MS SQL и PostgeSQL были в примерно равных условиях)
Следует заметить также:
1. В IRL за организацию бэкапов выгрузкой в dt порвут на флажки, т.к. данный процесс требует монопольного доступа к базе. Исходя из этого считаю, что этот параметр из набора тестов можно исключить.
2. Совмещение логов транзакций у MS SQL на одном диске с базами — нарушение рекомендаций по настройке СУБД и рекомендаций по обеспечению целостности информации. Также не понятно, где у PostgreSQL располагался WAL (подозреваю, что по-умолчанию, и тогда MS SQL и PostgeSQL были в примерно равных условиях)
П.1 был как дополнительный тест.
И п.1, и п.2 были обе СУБД в равных условиях, т е журнал транзакций и сама БД были на одном диске.
На счет сервера приложений отпишу чуть позже
И п.1, и п.2 были обе СУБД в равных условиях, т е журнал транзакций и сама БД были на одном диске.
На счет сервера приложений отпишу чуть позже
Сеансы клиентские запускались на сервере приложения, сам 1С сервер находился на отдельном сервере для изоляции и достижения равных условий.
СУБД и сервер 1С разнесены. Как и описано в статье.
СУБД и сервер 1С разнесены. Как и описано в статье.
В тесте Гилева есть рекомендация Установите значение параметра standard_conforming_strings в конфигурационном файле postgresql.conf в значение ‘off’
Была ли она выполнена?
Была ли она выполнена?
Все настройки приведены в сполинге «Детали» в том числе и по postgresql.conf.
Также брался установщик PostgreSQL, пропаченный от 1С, сборка которой указана в таблице.
Данный параметр не настраивали
Также брался установщик PostgreSQL, пропаченный от 1С, сборка которой указана в таблице.
Данный параметр не настраивали
Я «Детали» читал просто решил уточнить т.к.в деталях прведены авно не все параметры а скорее всего только отличные от дефолтных. В руководстве по проведению теста Гилёва есть явное указание это параметр настраивать. www.gilev.ru/tpc1cgilv
Если пройтись по параметрам то
max_connections = 1000 — сильно завышен
Приведу строки из документации
«Generally, PostgreSQL on good hardware can support a few hundred connections. If you want to have thousands instead, you should consider using connection pooling software to reduce the connection overhead. „
shared_buffers = 9GB — похоже на рекомендуемое значение
huge_pages = on — ОК
temp_buffers = 512MB
Далее сравним чисто рекомендации от 1с см. its.1c.ru/db/metod8dev#content:5866:hdoc work_mem ОП/32...64 то есть 0,5-1,0Гб
work_mem = 128MB — это то что у Вас
Конечно, сейчас говорить можно ±. Если уже быть полностью объективным в этом вопросе, то можно было бы пойти путем дословного выполнение всех методических указаний 1с см. its.1c.ru/db/metod8dev#content:5866:hdoc — наверное что-то похожее есть и в инструкциях к ПО 1с.
Также остались за кадром важные параметры ядра ОС (такие как максимальное количество сокетов (умолчание 128, открытых файлов и т.п.) При 1000 открытых коннектов коннектах несоответсвие параметров сокетов/файлов может стать причиной торомозов
max_connections = 1000 — сильно завышен
Приведу строки из документации
«Generally, PostgreSQL on good hardware can support a few hundred connections. If you want to have thousands instead, you should consider using connection pooling software to reduce the connection overhead. „
shared_buffers = 9GB — похоже на рекомендуемое значение
huge_pages = on — ОК
temp_buffers = 512MB
Далее сравним чисто рекомендации от 1с см. its.1c.ru/db/metod8dev#content:5866:hdoc work_mem ОП/32...64 то есть 0,5-1,0Гб
work_mem = 128MB — это то что у Вас
Конечно, сейчас говорить можно ±. Если уже быть полностью объективным в этом вопросе, то можно было бы пойти путем дословного выполнение всех методических указаний 1с см. its.1c.ru/db/metod8dev#content:5866:hdoc — наверное что-то похожее есть и в инструкциях к ПО 1с.
Также остались за кадром важные параметры ядра ОС (такие как максимальное количество сокетов (умолчание 128, открытых файлов и т.п.) При 1000 открытых коннектов коннектах несоответсвие параметров сокетов/файлов может стать причиной торомозов
Большое спасибо за уточнение-протестирую
тут согласно рекомендациям:
its.1c.ru/db/metod8dev#content:5866:hdoc
указывают от 32 до 128 МБ, не более.
Но формула такая же-делить от 32 до 64
its.1c.ru/db/metod8dev#content:5866:hdoc
указывают от 32 до 128 МБ, не более.
Но формула такая же-делить от 32 до 64
дотестировали, получили оптимальные результаты при work_mem = 128MB, т к если взять 256 или 64, то перфоманс падал более чем на 5%
Если правильно понял, то 8 ядер на 1000 подключений. Не многовато процессов на 8 ядер?
Вы только не учли что у того-же Гилева присутствуют откровенные подтасовки.
Сравнение тюнингованной PostgreSQL и дефолтного MSSQL.
1C-ники сами говорят что при наличии бюджета 1С работает лучше на MSSQL, просто потому что она написана с учетом возможностей MSSQL, а уж потом адаптирована под PostgreSQL.
В этом нет ничего странного. Причем Гилев сам предлагает тюнинг под обе СУБД, что тоже есть правильно. Однако есть эмперическое правило если на PostgreSQL 1С «лежит», то переводом ее на MSSQL можно продолжить агонию.
Все конечно зависит от конфигурации, но за «широкие» выборки конечно нужно бить по рукам.
Сравнение тюнингованной PostgreSQL и дефолтного MSSQL.
1C-ники сами говорят что при наличии бюджета 1С работает лучше на MSSQL, просто потому что она написана с учетом возможностей MSSQL, а уж потом адаптирована под PostgreSQL.
В этом нет ничего странного. Причем Гилев сам предлагает тюнинг под обе СУБД, что тоже есть правильно. Однако есть эмперическое правило если на PostgreSQL 1С «лежит», то переводом ее на MSSQL можно продолжить агонию.
Все конечно зависит от конфигурации, но за «широкие» выборки конечно нужно бить по рукам.
Мы старались быть обьктивными и потому провели ряд специфических тестов помимо теста Гилева.
Есши верить 1С, то они все лучше поддерживают СУБД PostgreSQL.
Также в общем получается, что 1С примерно одинаково работает на обеих СУБД.
Однако, конечно в большей степени беда именно в самих запросах, а не в СУБД.
Есши верить 1С, то они все лучше поддерживают СУБД PostgreSQL.
Также в общем получается, что 1С примерно одинаково работает на обеих СУБД.
Однако, конечно в большей степени беда именно в самих запросах, а не в СУБД.
Благодарю за столь ценный комментарий)
В MS SQL достаточно «открутить» значение max degree of parallelism до 2-4 и выше и тогда запросы так же будут параллелиться на 2-4 или больше потоков. 1С перестраховывается и не рекомендует этого делать (оно и понятно: в кривых руках можно одним запросом съесть все ядра).
Вы дальше пишете, что «стоит отдельно <..> включить [параллелизм] для MS SQL», но меня резанула фраза, что «этого не получается для MS SQL». Фактически же, и там, и там это дополнительные настройки, так что тут все в равных условиях.
Вы дальше пишете, что «стоит отдельно <..> включить [параллелизм] для MS SQL», но меня резанула фраза, что «этого не получается для MS SQL». Фактически же, и там, и там это дополнительные настройки, так что тут все в равных условиях.
Для MSSQLSERVER — это тоже возможно.
Путей несколько — например, через Resource Governor (только для всего богатства — оно требует Энтерпрайза, ЕМНИП)
Путей несколько — например, через Resource Governor (только для всего богатства — оно требует Энтерпрайза, ЕМНИП)
Адаптация прямо скажем, не очень, на обеих СУБД. Достаточно посмотреть на то, что лепит платформа из запросов В ИЕРАРХИИ.
Сборка PostgreSQL была от 1С или от PostgresPro?
От 1С сборка
Хорошая у них сборка 10.5 получилась. По производительности рвет прошную 11.2, и даже их новую тестовую 10.8. Я надеюсь 10.8 1С все-таки допилят
Там уже скоро будет 11, где слоноводы обещают значительный прорыв как в функционале, так и в производительности
Уже есть сборки от постгрес про 11 версии, но работают они медленнее 10 от 1С. Не знаю почему, то так есть
А можете хотя бы поверхностный анализ привести на сколько медленный, чем 10.5 и чем мерили и как?
пару месяцев назад делал тесты разных сборок от постгре, пришёл к выводу, что по тесту Гилёва 10.5 как раз хуже всего, надо либо 9.6 продолжать использовать или переходить на 11.х. Но опять же надо понимать что тест Гилёва показывает относительную погоду на Марсе :) которая вряд ли вам поможет в реальной эксплуатации вашего комплекса. Скорость одного потока на постгре показывает медленнее, однако количество пользователей и максимальная скорость выше, чем у МСскуль. Другое отступление, постгря ставилась в винду, методом научного тыка выяснилось, что часть настроек в конфиге просто не работает (а была идея сравнивать их в режиме кластера приложений и хранилища БД на одном сервере).
полученные результаты на Я.Дзен или Лицекниге, кому как удобнее. Там в конце результаты другого теста, достаточно интересного в силу развернутых оценок, и видно что разница только в скорости работы с временными таблицами, если их унести на быстрый диск или в рамдрайв, то все тесты уйдут в космос по абсолютным значениям.
полученные результаты на Я.Дзен или Лицекниге, кому как удобнее. Там в конце результаты другого теста, достаточно интересного в силу развернутых оценок, и видно что разница только в скорости работы с временными таблицами, если их унести на быстрый диск или в рамдрайв, то все тесты уйдут в космос по абсолютным значениям.
слона не стоит ставить на винду
Ну оно работает, возможно не так быстро, как работало бы на линуксе, я ставил просто для проверок. Но знаю и боевую установку уже много лет отлично живущую на винсервере. Собстно по просьбе этих людей я и проводил сравнение 9.6 — 10.5 — 11.1
Тестировал через оценку производительности APDEX. Делал групповое перепроведение документов, формировал отчеты (ОСВ) и другие, тестировал время открытия форм
Можете уточнить какая версия самой сборки использовалась в тесте — последняя актуальная 24?
Разница в производительности это ерунда. Гораздо интереснее разница в: 1 — очевидности и длительности настройки после установки, 2 — простоте переноса баз между версиями, 3 — простоте и понятности настройки плана бэкапов, 4 — уверенности в том, что бэкап в случае чего быстро поднимется на другой машине, 5 — работоспособности сложных запросов после трансляции из языка запросов в SQL.
По всем этим пунктам у PG твердый неуд. Мое ИМХО — ставить PG можно только там, где есть грамотный сисадмин, а в такой конторе экономия на лицензиях в 40-100 тысяч рублей не критична.
По всем этим пунктам у PG твердый неуд. Мое ИМХО — ставить PG можно только там, где есть грамотный сисадмин, а в такой конторе экономия на лицензиях в 40-100 тысяч рублей не критична.
Уточнение: где есть опытный специалист, обладающий достаточными компетенциями в настройке и оптимизации CentOS, файловой системы и самого PostgreSQL.
В данной статье вравнивалось только быстродействие и только для 1С.
Цена переноса, настроек и т д и т п не рассматривались.
В данной статье вравнивалось только быстродействие и только для 1С.
Цена переноса, настроек и т д и т п не рассматривались.
Базовым принципам работы с CentOS и PostgreSQL можно научиться за несколько часов (я имею ввиду установку, базовую настройку, backup/restore). Настройки можно просто делать по check-list'у и все. Главное тут SSD. Он нивелирует все огрехи при настройках shared_buffers, work_mem и temp_buffers.
Тут не очень понятно, чем админ поможет с запросами в SQL. Максимум, что он сможет сделать в PostgreSQL — это подстраивать индексы и строить cross-column statistics.
Часто это делают админы под MSSQL?
Другое дело, что если запросы в базовой поставке 1С изначально не были сделаны под оптимизатор PostgreSQL, то тут да — беда.
Тут не очень понятно, чем админ поможет с запросами в SQL. Максимум, что он сможет сделать в PostgreSQL — это подстраивать индексы и строить cross-column statistics.
Часто это делают админы под MSSQL?
Другое дело, что если запросы в базовой поставке 1С изначально не были сделаны под оптимизатор PostgreSQL, то тут да — беда.
согласен, что SSD спасает от плохих запросов, прикрывая проблему. Но если потом оттюнить сам запрос, то будет просто космос
Согласен. Но оттюнить запрос — это дополнительные человеко-часы дорогого человека. И возможно затраты на SSD будут ниже. А пользователю может быть без разницы, будет там 100мс или 1мс, если, например, фронт будет рендерить 2 секунды.
в большинстве рано или поздно к этому приходят-более дорогое оборудование вместо оптимизаций запросов.
Даже если много серверов-там где оттюнить быстро не получается, добавляют SSD или выкручиваются иными способами, или банально «терпят»
Даже если много серверов-там где оттюнить быстро не получается, добавляют SSD или выкручиваются иными способами, или банально «терпят»
Просто тут важно понимать, что запросов тысячи. И всех их оптимизировать экономически неэффективно. Все равно будут неоптимизированные, и это жизнь. SSD просто уменьшает то количество запрос, время выполнения которых выходит за допустимые рамки.
Да, также стараемся сначала железо мощнее поставить. Но для всех серверов не напасешься и потому для этого есть штатные DBA.
А если серверов не много и бюджет позволяет, то сначала лучше железо, а что все равно медленным осталось, то тюнить
А если серверов не много и бюджет позволяет, то сначала лучше железо, а что все равно медленным осталось, то тюнить
Не очень понимаю, а чем DBA поможет? Он будет переписывать 1С код?
Нет, но совместно с разработчиками 1С можно понять что за запрос идет от 1С и оптимизировать его
То есть тут придется задействовать аж 2х высококвалифицированных людей. А учитывая, что им придется взаимодействовать друг с другом, когда, как правило, они друг друга недолюбливают, то тогда точно SSD в большинстве случае выгоднее :)
Смотря в какой компании
Если серверов много, то и железо, и высококвалифицированные сотрудники будут.
А взаимодействие всегда должно быть.
Вопрос лишь в кадрах и в их квалификации, а также в уровне экспертизы в определенных вопросах.
Если серверов мало, то либо железо лучше сделают, либо спеца 1-2 наймут.
Если компания не IT-профиля и серверов немного и бюджет не рассчитан на спецов, то тупо железо лучше приобретут. И то не факт.
Если серверов много, то и железо, и высококвалифицированные сотрудники будут.
А взаимодействие всегда должно быть.
Вопрос лишь в кадрах и в их квалификации, а также в уровне экспертизы в определенных вопросах.
Если серверов мало, то либо железо лучше сделают, либо спеца 1-2 наймут.
Если компания не IT-профиля и серверов немного и бюджет не рассчитан на спецов, то тупо железо лучше приобретут. И то не факт.
Интересны ещё свойства БД на SQL Server, а именно: модель восстановления, начальные размеры файлов данных и журнала транзакций и их приращения (и последние два пункта было бы неплохо у темпдб посмотреть).
У постгресе это параметры настраиваемые и их можно посмотреть в конфиге они там и заданы кстати явно в статье этой
Для базы заданы настройки по умолчанию, т е что шло из коробки 1С.
БД tempdb на отдельном HDD диске, состоящее из 4 файлов данных с начальным размером 1 ГБ каждая и максимальным 4 ГБ каждая с приращением 1 ГБ каждая.
БД tempdb на отдельном HDD диске, состоящее из 4 файлов данных с начальным размером 1 ГБ каждая и максимальным 4 ГБ каждая с приращением 1 ГБ каждая.
>>Для базы заданы настройки по умолчанию, т е что шло из коробки 1С.
Вот это очень грустно. Гораздо лучше были бы настройки как у темпдб (без ограничения на максимальный размер). Было бы ещё интересно узнать размеры файлов данных и, особенно, ЖТ после каждого теста, хотя и понимаю, что это вряд ли возможно :).
Вот это очень грустно. Гораздо лучше были бы настройки как у темпдб (без ограничения на максимальный размер). Было бы ещё интересно узнать размеры файлов данных и, особенно, ЖТ после каждого теста, хотя и понимаю, что это вряд ли возможно :).
По последнему мы не снимали такие показатели, по tempdb-ни один из файлов данных не достиг максимального размера, по осиальному как и для БД PostgreSQL-только настройки всего экземпляра, а не БД
По темпдб всё понятно. А вот по самой БД настройки по-умолчанию — это не очень хорошо. По-умолчанию там будет полная модель восстановления и какие-то смешные размеры БД и ЖТ с автоприращением на 10%. Учитывая, как SQL Server работает с ЖТ, он будет часто и понемножку увеличиваться на первых тестах и редко и по-долгу на последующих. При увеличении, ЖТ всегда заполняется нулями и всё это время SQL Server не будет выполнять DML, пока приращение не завершится. Поэтому у вас во время тестов SQL Server регулярно «вставал на паузу».
Файлов данных это касается в меньшей степени, 2016-й SQL Server ещё при установке должен был запросить разрешение на Instant File Initialization.
Файлов данных это касается в меньшей степени, 2016-й SQL Server ещё при установке должен был запросить разрешение на Instant File Initialization.
Ну, модель восстановления — не влияет на быстродействие (ну, практически :-) ), а вот начальный размер и приращение — еще как влияет!
И еще б неплохо было бы узнать, а даны ли привилегии Volume Task учетной записи сервера?
Кстати, на мой взгляд, MSSQLSERVER — слишком много памяти дали. Он будет обкрадывать сервер приложений и ОС.
Или сервер приложений на другом сервере располагался?
И еще б неплохо было бы узнать, а даны ли привилегии Volume Task учетной записи сервера?
Кстати, на мой взгляд, MSSQLSERVER — слишком много памяти дали. Он будет обкрадывать сервер приложений и ОС.
Или сервер приложений на другом сервере располагался?
1С был на отдельном сервере-дополнил в деталях в статье.
Привилегии были даны.
Модель восстановления повлияла бы если была бы простой, т к БД tempdb располагался пусть и на логическом, но отдельном диске.
Привилегии были даны.
Модель восстановления повлияла бы если была бы простой, т к БД tempdb располагался пусть и на логическом, но отдельном диске.
>>Ну, модель восстановления — не влияет на быстродействие (ну, практически :-) ), а вот начальный размер и приращение — еще как влияет!
И приращение никак не связано с моделью восстановления?
Вне зависимости от установленного размера приращения ЖТ, при простой модели восстановления они будут оказывать меньшее влияние на производительность, т.к. выполняться приращение, при прочих равных, будет реже. Отсюда и был мой вопрос автору.
И приращение никак не связано с моделью восстановления?
Вне зависимости от установленного размера приращения ЖТ, при простой модели восстановления они будут оказывать меньшее влияние на производительность, т.к. выполняться приращение, при прочих равных, будет реже. Отсюда и был мой вопрос автору.
Вас понял, модель восстановления полная
Ну, при правильной настройке первоначального размера лога и своевременном его бэкапе — нет, никак не связано.
Но да. Вы правы. С учетом того, что админы не понимают, зачем нужно бэкапить лог (прежде всего), как, когда и зачем он растет, т.е. — в «нормальных», т.с. условиях — да, получается еще как связаны.
:-)
Но да. Вы правы. С учетом того, что админы не понимают, зачем нужно бэкапить лог (прежде всего), как, когда и зачем он растет, т.е. — в «нормальных», т.с. условиях — да, получается еще как связаны.
:-)
del
Справедливости ради, хотел бы отметить, что 1С рекомендует для postgresql.conf ставить:
Пруф тут, its.1c.ru/db/metod8dev/content/4692/hdoc, с разбором и реальными тестами тут infostart.ru/public/1023353
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
Пруф тут, its.1c.ru/db/metod8dev/content/4692/hdoc, с разбором и реальными тестами тут infostart.ru/public/1023353
Большое спасибо за ценную информацию-учту для дальнейшей оптимизации
При дополнительных тестах, оптимальным вариантом получилось следующее:
seq_page_cost = 1
random_page_cost = 2.5
cpu_operator_cost = 0.00025
т к при других значениях, например тех, что привели Вы, производительность падал в среднем до 7%.
Возможно это связано с тем, что приведенные Вами настройки годны для SSD, но не для HDD. Что тоже важно учитывать. Тем более, что невсегда есть SSD на проде.
seq_page_cost = 1
random_page_cost = 2.5
cpu_operator_cost = 0.00025
т к при других значениях, например тех, что привели Вы, производительность падал в среднем до 7%.
Возможно это связано с тем, что приведенные Вами настройки годны для SSD, но не для HDD. Что тоже важно учитывать. Тем более, что невсегда есть SSD на проде.
Диски: 6 шт. HGST HUS726T6TAL,
Sector-Size: 512 Bytes
Write Cache: on
Не делайте так. Выключите кэш на дисках. Кэш RAID-контроллера защищён аккумулятором, кэш дисков не защищён ничем. Угадайте, что произойдёт, если внезапно пропадёт питание? (shit happens) Правильно — кэш дисков сброситься, данные из него не будут записаны на диски, а в кэше контроллера их уже нет, утеряны навсегда. Нарушится консистентность массива. Дальнейшее развитие событий зависит от продвинутости контроллера. В случае с RAID 10, если контроллер не сверяет данные с зеркалом, то он и не заметит рассогласованности, со временем блоки будут перезаписаны и о случившемся можно забыть, а если сверяет, то, возможно, потребуется повторное зеркалирование с одной части массива, на другую. В случае с RAID 5/6 дела обстоят похуже, ведь помимо блоков с данными скорее всего испорчены и блоки контроля чётности. Итог предсказуем — массив «развалится».
большое спасибо за инфу-взяли на заметку, также поправил
после всех рекомендаций-перетестим
после всех рекомендаций-перетестим
Уважаемый jobgemws, если это возможно, подключите меня к тестированию с точки зрения настроек Postgres
увы напрямую подключить не могу, но Вы можете рекомендовать параметры, а мы их применим и протестим
Тогда покажите Postgresql.conf и точные параметры железа для сервера СУБД:
Количество ядер
Тип HDD их количество и как разбиты на логические диски
Количество оперативной памяти
если можно.
Количество ядер
Тип HDD их количество и как разбиты на логические диски
Количество оперативной памяти
если можно.
Это все описано в статье в деталях как на физическом уровне, так и на виртуальном.
Логических дисков два в обоих средах. Постгрес на одном логическом диске.
Логических дисков два в обоих средах. Постгрес на одном логическом диске.
Извиняюсь, не увидел детали…
Посмотрю конфиг, если будет что поправить, напишу
Посмотрю конфиг, если будет что поправить, напишу
Спасибо, да-мнение со стороны опытного спеца будет весьма кстати
max_files_per_process = 10000 вместо max_files_per_process = 1000
synchronous_commit = off вместо #synchronous_commit = on
commit_delay = 1000 вместо #commit_delay = 1000
seq_page_cost = 1.0 вместо seq_page_cost = 0.1
from_collapse_limit = 8 вместо from_collapse_limit = 20
join_collapse_limit = 8 вместо join_collapse_limit = 20
max_parallel_workers_per_gather = 0 вместо max_parallel_workers_per_gather = 4
log_autovacuum_min_duration = 1000 вместо log_autovacuum_min_duration = 0
autovacuum_vacuum_scale_factor = 0.02 вместо #autovacuum_vacuum_scale_factor = 0.2
autovacuum_analyze_scale_factor = 0.01 вместо #autovacuum_analyze_scale_factor = 0.1
вынести каталог pg_stat_tmp в RAM
В файл etc/fstab добавляем tmpfs <путь к pg_stat_tmp> tmpfs noatime,nodiratime,defaults,size=256M
Перезагружаем сервер полностью
ОЧЕНЬ ВАЖНЫЙ момент — после загрузки базы в Postgres, не важно через dump или dt, обязательно проведите analyze на всей базе, так как дамп PG не содержит статистику, а при загрузке из dt атовакуум не успеет проанализировать всё. Если для повторного теста базу вгружать не планируете, то проведите на ней перед тестирование vacuum full.
Попробуйте с этими изменениями провести тесты (кроме теста Гилёва, так как по моему мнению этот тест для клиент-серверной 1С не показателен )
P.S. Насколько я понял дисковый массив 1, если нет, то WAL на отдельный дисковый массив (по аналогии выноса temdb у MS SQL). По возможности поменяйте версию платформы, 8.3.13.1513 одна из самых неудачных версий.
P.P.S. при проведении тестов для статьи на которую Вы ссылаетесь индексирование дисков было отключено)
synchronous_commit = off вместо #synchronous_commit = on
commit_delay = 1000 вместо #commit_delay = 1000
seq_page_cost = 1.0 вместо seq_page_cost = 0.1
from_collapse_limit = 8 вместо from_collapse_limit = 20
join_collapse_limit = 8 вместо join_collapse_limit = 20
max_parallel_workers_per_gather = 0 вместо max_parallel_workers_per_gather = 4
log_autovacuum_min_duration = 1000 вместо log_autovacuum_min_duration = 0
autovacuum_vacuum_scale_factor = 0.02 вместо #autovacuum_vacuum_scale_factor = 0.2
autovacuum_analyze_scale_factor = 0.01 вместо #autovacuum_analyze_scale_factor = 0.1
вынести каталог pg_stat_tmp в RAM
В файл etc/fstab добавляем tmpfs <путь к pg_stat_tmp> tmpfs noatime,nodiratime,defaults,size=256M
Перезагружаем сервер полностью
ОЧЕНЬ ВАЖНЫЙ момент — после загрузки базы в Postgres, не важно через dump или dt, обязательно проведите analyze на всей базе, так как дамп PG не содержит статистику, а при загрузке из dt атовакуум не успеет проанализировать всё. Если для повторного теста базу вгружать не планируете, то проведите на ней перед тестирование vacuum full.
Попробуйте с этими изменениями провести тесты (кроме теста Гилёва, так как по моему мнению этот тест для клиент-серверной 1С не показателен )
P.S. Насколько я понял дисковый массив 1, если нет, то WAL на отдельный дисковый массив (по аналогии выноса temdb у MS SQL). По возможности поменяйте версию платформы, 8.3.13.1513 одна из самых неудачных версий.
P.P.S. при проведении тестов для статьи на которую Вы ссылаетесь индексирование дисков было отключено)
по P.S. и P.S.S сделано было, просто забыли в статье обновить инфу по 1С 8.3.13.1865 (поправил-спасибо, что заметили).
seq_page_cost = 1.0 и 0.1 выставлялись в итоге оставили 1 (вновь прошу прощения-не обновил).
По остальным параметрам сделаем-отпишусь чуть позже что получилось. Правда пока без выноса в RAM.
seq_page_cost = 1.0 и 0.1 выставлялись в итоге оставили 1 (вновь прошу прощения-не обновил).
По остальным параметрам сделаем-отпишусь чуть позже что получилось. Правда пока без выноса в RAM.
Огромное спасибо за коммент еще раз. Поигрались отдельно и в комбинациях с теми параметрами и их значениями, что Вы дали, а также с остальными рекомендациями Вашими, кроме RAM.
Получили где-то чуть лучше, где-то чуть хуже, но все в рамках до 3%.
Единственное, формирование месячного отчета стало быстрее в среднем на 3%.
В статье поправил файл настроек PostgreSQL, который отвечает оптимальным показателям.
Получили где-то чуть лучше, где-то чуть хуже, но все в рамках до 3%.
Единственное, формирование месячного отчета стало быстрее в среднем на 3%.
В статье поправил файл настроек PostgreSQL, который отвечает оптимальным показателям.
выключили-перепроверили, производительность упала несильно-менее чем на 1%
Виртуалка + разнесенные сервера + медленные диски HDD = сравнение, где роль СУБД занижена настолько, насколько это вообще возможно. Возникает ощущение, что сделано это с умыслом.
Так же не указано, было ли включено ограничений на уровне записей (RLS) для пользователей 1С. Именно этот момент приводит к самым большим тормозам Postgree.
Пожалуйста, проведите тестирование на одной машине, с SSD, без виртуалки, с включенным RLS, вот тогда сравним MS и Postgree.
Так же не указано, было ли включено ограничений на уровне записей (RLS) для пользователей 1С. Именно этот момент приводит к самым большим тормозам Postgree.
Пожалуйста, проведите тестирование на одной машине, с SSD, без виртуалки, с включенным RLS, вот тогда сравним MS и Postgree.
Нет, железо было одно для двух сред.
Среды включались поочередно для тестирования. Как и описано в публикации.
Т е обе системы были в равных условиях.
Отношение производительности двух систем в процентах на SSD должно быть таким же как и на HDD, иначе система нестабильна.
Среды включались поочередно для тестирования. Как и описано в публикации.
Т е обе системы были в равных условиях.
Отношение производительности двух систем в процентах на SSD должно быть таким же как и на HDD, иначе система нестабильна.
Я так понял, под «разнесенные сервера» androidt1c имел ввиду, что сервер приложений 1С размещался отдельно от СУБД.
В случае, если сервер приложений 1С и MSSQLSERVER расположены на одном сервере, общение между ними можно настроить через протокол shared memory (нужно имя сервера в настройках прописать как. (точку)). В случае, если они живут на разных серверах — то общение идет через в целом менее производительные протоколы tcp/ip или named pipes, и ограничивающими факторами является пропускная способность сети и ее латентность. У вас же не 10G между сервером БД и сервером 1С, правильно?
С другой стороны, уважаемому androidt1c хочу сказать, что в «реальном мире мелких контор» — оно всё так и живет.
Вот когда им нужно будет 1000 пользователей одновременно в 10Тб базе, тогда и начнут всплывать… нюансы.
А уважаемому jobgemws — скажу спасибо. Годно.
Резюмировать можно так: Практически, с учетом среднестатистически кривожопого конфигурирования — системы одинаковы.
ЧТД.
В случае, если сервер приложений 1С и MSSQLSERVER расположены на одном сервере, общение между ними можно настроить через протокол shared memory (нужно имя сервера в настройках прописать как. (точку)). В случае, если они живут на разных серверах — то общение идет через в целом менее производительные протоколы tcp/ip или named pipes, и ограничивающими факторами является пропускная способность сети и ее латентность. У вас же не 10G между сервером БД и сервером 1С, правильно?
С другой стороны, уважаемому androidt1c хочу сказать, что в «реальном мире мелких контор» — оно всё так и живет.
Вот когда им нужно будет 1000 пользователей одновременно в 10Тб базе, тогда и начнут всплывать… нюансы.
А уважаемому jobgemws — скажу спасибо. Годно.
Резюмировать можно так: Практически, с учетом среднестатистически кривожопого конфигурирования — системы одинаковы.
ЧТД.
Забавно: серверу на PostgreSQL дали в два раза меньше ОЗУ и начали сравнивать.
Впрочем, если вся тестовая база влезала в память, то и ладно.
Впрочем, если вся тестовая база влезала в память, то и ладно.
Тест Гилева даже по его собственному признанию измеряет производительность железа
Сравнивать им СУБД некорректно. СУБД желательно сравнивать в режиме нагрузки приближенной к реальной (в идеале) или многопользовательской если вы имитируете просто нагрузочное тестирование
Ваши кастомные тесты — тоже выгрузка загрузка баз и перепроведение всех документов — это монопольные операции.
Т.е. вы своими тестами померяли то, что было интересно ИТ отделу — выгрузки, перепроведения, но это частные случаи и они за бортом рабочего времени. А реальная работа пользователей — это как раз то что происходит в рабочее время. Это время кстати самое интересное для оптимизации. Ее кстати можно спокойно померять по APDEX и даже на ваших серверах если собрать нагрузочный тест. И там конечно будут другие результатыт.
Поэтому в данном случае можно сказать — проведены работы, но не более того.
Для СУБД есть промышленный тест TPC-C — его можно померять HammerDB, для 1С есть конфигурация fragster.ru — она имитирует различные варианты нагрузки и по ней как раз видно как Postgres проседает на запросах с виртуальными таблицами (до тех пор пока дисковая подсистема не становится очень хорошей) тогда результаты выравниваются.
В любом случае MS пока идет чуть лучше Postgres по показателям, но за Postgres конечно его бесплатность
Пример вот infostart.ru/public/984026
Сравнивать им СУБД некорректно. СУБД желательно сравнивать в режиме нагрузки приближенной к реальной (в идеале) или многопользовательской если вы имитируете просто нагрузочное тестирование
Ваши кастомные тесты — тоже выгрузка загрузка баз и перепроведение всех документов — это монопольные операции.
Т.е. вы своими тестами померяли то, что было интересно ИТ отделу — выгрузки, перепроведения, но это частные случаи и они за бортом рабочего времени. А реальная работа пользователей — это как раз то что происходит в рабочее время. Это время кстати самое интересное для оптимизации. Ее кстати можно спокойно померять по APDEX и даже на ваших серверах если собрать нагрузочный тест. И там конечно будут другие результатыт.
Поэтому в данном случае можно сказать — проведены работы, но не более того.
Для СУБД есть промышленный тест TPC-C — его можно померять HammerDB, для 1С есть конфигурация fragster.ru — она имитирует различные варианты нагрузки и по ней как раз видно как Postgres проседает на запросах с виртуальными таблицами (до тех пор пока дисковая подсистема не становится очень хорошей) тогда результаты выравниваются.
В любом случае MS пока идет чуть лучше Postgres по показателям, но за Postgres конечно его бесплатность
Пример вот infostart.ru/public/984026
на счет теста Гилева: «Другими словами, и настройки СУБД, и настройки ОС, и оборудование оказывают влияние на общий командный результат»:
www.gilev.ru/tpc1cgilv
Тесты были приближены максимально к типовым манипуляциям пользователей в системе 1С Бухгалтерия.
За APDEX спасибо-возьмем за вооружение
www.gilev.ru/tpc1cgilv
Тесты были приближены максимально к типовым манипуляциям пользователей в системе 1С Бухгалтерия.
За APDEX спасибо-возьмем за вооружение
На счет APDEX-коллеги из 1С рекомендовали внимательнее почитать доку, т к она не предназначена в том, что Вы выше описали. Здесь как раз подходит синтетический тест Гилева и специализированные тесты для выбранной системы-в нашем случае для 1С
Все мы коллеги из 1С ) Вы конкретнее называйте имена фамилии явки и пароли )
Дело все в том, что как я написал вы выбрали тесты, которые интересны ИТ.
Но реальные пользователи базы — это пользователи, извините за повторение.
Их скорость работы оценивается скоростью операций которые выполняют они — проведение документов, открытие формы документов.
Ее (скорость) достаточно удачно измеряет APDEX
«Насчет» — пишется вместе
на счет теста Гилева: «Другими словами, и настройки СУБД, и настройки ОС, и оборудование оказывают влияние на общий командный результат» — в вашем тесте вы же не настраиваете ОС и СУБД, ну или не пишете об этом, отсюда простым вычитанием мы получаем — этим тестом вы измеряете оборудование, которое одно и то же в ваших тестах. Если конечно вы настроили правильно ОС и СУБД, но это я под сомнение не ставлю.
Тогда вам надо убрать из шапки фразу Цели и требования к тестированию «1С Бухгалтерии»
И тогда возникает вопрос — зачем так сложно тестировать оборудование, когда для этого есть более приемлемые тесты
Дело все в том, что как я написал вы выбрали тесты, которые интересны ИТ.
Но реальные пользователи базы — это пользователи, извините за повторение.
Их скорость работы оценивается скоростью операций которые выполняют они — проведение документов, открытие формы документов.
Ее (скорость) достаточно удачно измеряет APDEX
«Насчет» — пишется вместе
на счет теста Гилева: «Другими словами, и настройки СУБД, и настройки ОС, и оборудование оказывают влияние на общий командный результат» — в вашем тесте вы же не настраиваете ОС и СУБД, ну или не пишете об этом, отсюда простым вычитанием мы получаем — этим тестом вы измеряете оборудование, которое одно и то же в ваших тестах. Если конечно вы настроили правильно ОС и СУБД, но это я под сомнение не ставлю.
Тогда вам надо убрать из шапки фразу Цели и требования к тестированию «1С Бухгалтерии»
И тогда возникает вопрос — зачем так сложно тестировать оборудование, когда для этого есть более приемлемые тесты
В данном тесте мы не сравниваем конфигурации на разных платформах.
Конфигурация использовалась типовая Бухгалтерия 1С Проф.
Естественно, что и саму конфигурацию можно оптимизировать, но цель была сравнить работу 1С для двух разных сред с разными СУБД, а не сравнивать конфигурации 1С.
P.S.: с мобильного устройства крайне сложно не сделать ошибку при написании текста. Думаю такое можно простить в комментариях
Конфигурация использовалась типовая Бухгалтерия 1С Проф.
Естественно, что и саму конфигурацию можно оптимизировать, но цель была сравнить работу 1С для двух разных сред с разными СУБД, а не сравнивать конфигурации 1С.
P.S.: с мобильного устройства крайне сложно не сделать ошибку при написании текста. Думаю такое можно простить в комментариях
Всё ж интересно, а Allow Snapshot Isolation и Is Read Committed Snapshot On — были включены на базе, или нет?
Оно, конечно, в случае 1C это сильно помогает только при большом количестве одновременных пользователей и когда tempdb где-нибудь на ssd или на виртуальном ram-диске, но всё же…
Оно, конечно, в случае 1C это сильно помогает только при большом количестве одновременных пользователей и когда tempdb где-нибудь на ssd или на виртуальном ram-диске, но всё же…
диски обычные HDD-все настойки шли от 1С, т е сами свойста БД на уровне СУБД не трогалось.
Плюс если в компании сотни серверов с СУБД, то на всех не напасешься SSD.
В данном случае 1С для нас не самая критичная система, потому начали с нее.
Также навряд ли она получит в бою SSD в виду того, что есть боее критичные системы, для которых SSD нужнее.
Плюс я сторонник проводить тесты и эксперименты специально на гораздо хуже по характеристикам железе, чем в проде, чтобы сразу увидеть узкие места
Плюс если в компании сотни серверов с СУБД, то на всех не напасешься SSD.
В данном случае 1С для нас не самая критичная система, потому начали с нее.
Также навряд ли она получит в бою SSD в виду того, что есть боее критичные системы, для которых SSD нужнее.
Плюс я сторонник проводить тесты и эксперименты специально на гораздо хуже по характеристикам железе, чем в проде, чтобы сразу увидеть узкие места
Не совсем понятна идея тестирования. Железо не подходящее для 1С — медленный процессор и медленные диски. ИМХО пока явные узкие места не устранены — сравнивать производительность не корректно.
Судя по результатам обе СУБД показывают низкую производительность на тестовом сервере.
Судя по результатам обе СУБД показывают низкую производительность на тестовом сервере.
Главный критерий-что железо было одно и тоже для двух сред.
Да, оно было существенно хуже, чем на проде, чтобы сразу выявит узкие места.
Да, оно было существенно хуже, чем на проде, чтобы сразу выявит узкие места.
Приведу аналогию с тестами видеокарт — стенд подбирается всегда такой, чтобы тестировать именно видеокарты, чтобы узких мест не было.
Тут же ситуация другая — сходные значения тестов получились из-за слабого железа.
Название статьи «Исследование быстродействия СУБД MS SQL Server Developer 2016 и PostgreSQL 10.5 для 1С», тестируйте именно СУБД.
Сейчас теста не получается, к сожалению.
Тут же ситуация другая — сходные значения тестов получились из-за слабого железа.
Название статьи «Исследование быстродействия СУБД MS SQL Server Developer 2016 и PostgreSQL 10.5 для 1С», тестируйте именно СУБД.
Сейчас теста не получается, к сожалению.
Если железо одинаковое, то тест корректен, т к условия были одинаковые, а на SSD и RAM любое решение будет лучше и не увидишь проблем+ далеко невсегда удается в проде сделать SSD в виду нерезинового бюджета.
При выводе бралось отношение абсолютных величин, а не сами эти величины.
Потому на любом железе примерно это соотношение и останется.
При выводе бралось отношение абсолютных величин, а не сами эти величины.
Потому на любом железе примерно это соотношение и останется.
Почему низкую то?
По тесту Гилева уровень: «работать можно и пусть бухи рыдают».
По тесту Гилева уровень: «работать можно и пусть бухи рыдают».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Исследование быстродействия СУБД MS SQL Server Developer 2016 и PostgreSQL 10.5 для 1С