Первая IT лаборатория!
8-800-100-13-05
b2b@silverbulleters.org
b2b@silverbulleters.org
Error get alias
Не обижайте linux'оида или особенности патча 1С для PostgreSQL
Существует такой интернет-мем «бросить на вентилятор». Желающие могут ознакомится с тем что он означает в поисковике или на всем известном Луркоморье. Я же хочу сейчас поговорить о том, что такое «Сформировавшаяся позиция» и как она напрямую влияет на опыт. К текущему году в сообществам 1С и linux сложилось довольно странное отношение к тому, как себя ведет связка 1С+PostgreSQL, обычно отношение к этой связке выражается эмоциями в виде отдельных слов типа «извращение», «оно тормозит», «оно нормально не работает», «я посмотрел и мне не понравилось». Читающие данную статью, должны знать, что все указанные слова означают только одну сентенцию «У меня не получилось». Причин почему не получилось может быть множество, как-то нехватка времени или знаний, но означают такие слова, что человек их произносящий не смог. Точка.
В связи с этим, чтобы у Вас было чуть больше информации хотел бы поделить парочкой ссылок и информацией. Началось всё с того, что меня «обидели», так сказать в лучших чувствах ;-). В рамках публикации http://infostart.ru/public/295830 (по ссылке публикация о «пробах пера» с виртуализацией серверов 1С, что кстати говорит о том, что автор молодец и пытается попробовать и разобраться в этой достаточно интересной теме), так вот в рамках публикации кто-то меня потянул за клавиатуру, и я порекомендовал поизучать наш опыт с Docker, а также связку 1С(CentOS) и PostgreSQL в качестве docker контейнеров. Не буду говорить, что подобные советы в linux мире вызывают нещадные споры, потому что считается неверным рекомендовать конкретных решений, рекомендовать можно только подход или how-to. И отвечая на очередной комментарий формата «Сам дурак», оказалось, что текст ответа превысил 2 страницы. Учитывая, что как вы понимаете, осознав беспредметность спора, который сам и завязал, отвечать стало бесперспективно. Но куда девать с таким трудом написанный ответ ;-). Опубликую его здесь. Возможно кому-либо пригодится.
Итак вопрос звучит так: Посмотрели patch от 1С для PostgreSQL и вам понравилось?
Итак вопрос звучит так: Посмотрели patch от 1С для PostgreSQL и вам понравилось?
В целом конечно понравилось, вы даже не представляете насколько. Только прежде чем вы попробуете опять применить слово «изврат», я вам расскажу, что понравилось конкретно.
Изучая патчи от 1С первое, что я оттуда почерпнул — это особенности настройки postgresql.conf
Пройдя по ссылкам, а также дополнительно использовав поиск я узнал, что, как и в остальном мире OpenSource у PostgreSQL действует тоже самое правило — для использования в production, его необходимо адаптировать под конкретную задачу использования. То есть в зависимости от того какая нагрузка будет от приложения уже после запуска, можно играться и версионировать параметры.
Обычно кто начал использовать PostgreSQL после установки на конкретное железо и в зависимости от запущенного пользовательского приложения начинают играться с http://pgfoundry.org/projects/pgtune/ . И хотя проект старый — для изучения, очень полезен. Прогоняя нагрузку ТестЦентра и Теста Гилева со стороны 1С и периодически запуская pgtune я узнал и подтвердил, что патч1С на postgresql.conf делал то же самое, что и pgtune после запуска 1С в тестовом режиме. Изучая patch от 1С и patch от pgtune я узнал какой параметр настройки сервера на что влияет и какие параметры необходимо мониторить в реальном времени, чтобы построить адаптированный конфигурационный файл.
Изучая патчи от 1С первое, что я оттуда почерпнул — это особенности настройки postgresql.conf
Пройдя по ссылкам, а также дополнительно использовав поиск я узнал, что, как и в остальном мире OpenSource у PostgreSQL действует тоже самое правило — для использования в production, его необходимо адаптировать под конкретную задачу использования. То есть в зависимости от того какая нагрузка будет от приложения уже после запуска, можно играться и версионировать параметры.
Обычно кто начал использовать PostgreSQL после установки на конкретное железо и в зависимости от запущенного пользовательского приложения начинают играться с http://pgfoundry.org/projects/pgtune/ . И хотя проект старый — для изучения, очень полезен. Прогоняя нагрузку ТестЦентра и Теста Гилева со стороны 1С и периодически запуская pgtune я узнал и подтвердил, что патч1С на postgresql.conf делал то же самое, что и pgtune после запуска 1С в тестовом режиме. Изучая patch от 1С и patch от pgtune я узнал какой параметр настройки сервера на что влияет и какие параметры необходимо мониторить в реальном времени, чтобы построить адаптированный конфигурационный файл.
Понравился ли мне патч от 1С на конфигурацию PostgreSQL ?
Конечно же — остальной мир настраивает конфигурацию кластера СУБД с нуля и «через личную боль», а я получается получил бесплатно чужой опыт.
Имеется ввиду, например, параметр:
Имеется ввиду, например, параметр:
max_locks_per_transaction = 150 #default 64
Всем советую для личного опыта , запускать типовой тест на нагрузку (тот который считает максимальное абстрактных пользователей 1С) и играться с этим параметром, и понаблюдать за поведением postgresql
для мониторинга можно использовать бесплатные и красивые плагины new-relic http://newrelic.com/plugins/boundless/109
Ключевое в данном случае знание:
Будете ли вы запускать PostgreSQL от 1С или PostgreSQL-Original вам в любом случае придется прийти на сайт стандартной документации PostgreSQL https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server , только в случае с 1С, вам придется это сделать чуть позже, так как частично тюнинг провели за вас
для мониторинга можно использовать бесплатные и красивые плагины new-relic http://newrelic.com/plugins/boundless/109
Ключевое в данном случае знание:
Будете ли вы запускать PostgreSQL от 1С или PostgreSQL-Original вам в любом случае придется прийти на сайт стандартной документации PostgreSQL https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server , только в случае с 1С, вам придется это сделать чуть позже, так как частично тюнинг провели за вас
G-Ones
ArchTeam
Понравилось ли мне патч с «Блокировками приложения» (если вы понимаете о чем я) ?
Конечно же понравился. Пока все кричали «1С сделало из версионника блокировочник», я изучал патч и обратил внимание на следующий код
(отдельная выдержка из патча)
(отдельная выдержка из патча)
static const LockMethodData user_lockmethod = {
- AccessExclusiveLock, /* highest valid lock mode number */
+ ApplicationExclusiveLock, /* highest valid lock mode number */
static const LockMethodData default_lockmethod = {
- AccessExclusiveLock, /* highest valid lock mode number */
+ ApplicationExclusiveLock, /* highest valid lock mode number */
Для тех кто не умеет читать код C++ поясню. По умолчанию включается самый максимальный уровень блокировки. Причем это максимальный уровень НЕ стандартен для типового PostgreSQL. Для дополнительной информации знатокам MSSQL следует обратиться к http://www.postgresql.org/docs/9.3/static/explicit-locking.html
Ключевые слова здесь: по умолчанию, максимальный, НЕ типовой
А это значит — если 1С-ный программист НЕ управляет блокировками, то PostgreSQL с точки зрения будет вести себя НЕ как PostgreSQL. Надеюсь идея понятна. Тогда, когда проводилось это исследование в стандарт 1С:Совместимо только-только включали требования явно управлять блокировками и тестировать производительность на стороне кода 1С на параллельность. А я уже своим программистам и себе рекомендовал тоже самое (в том числе типовые конфигурации, в которых не было управления блокировками для меня были уже не актуальными и в работу не брались — в таком случае писались свои системы, а с типовыми только интегрировались).
Ключевые слова здесь: по умолчанию, максимальный, НЕ типовой
А это значит — если 1С-ный программист НЕ управляет блокировками, то PostgreSQL с точки зрения будет вести себя НЕ как PostgreSQL. Надеюсь идея понятна. Тогда, когда проводилось это исследование в стандарт 1С:Совместимо только-только включали требования явно управлять блокировками и тестировать производительность на стороне кода 1С на параллельность. А я уже своим программистам и себе рекомендовал тоже самое (в том числе типовые конфигурации, в которых не было управления блокировками для меня были уже не актуальными и в работу не брались — в таком случае писались свои системы, а с типовыми только интегрировались).
И это всё?
Ну и последнее для данной публикации это патч вводящий новый тип, точнее «контрибьютящий» некоторой количество кода внутрь нашего «адаптированного для 1С PostgreSQL». И тут нам вдруг открывается, что оказывается можно собирать свой PostgreSQL со своим набором библиотек. Интересное знание, и прежде чем вы скажете, что мы должны использовать только нативное и без расширений, я вам скажу что функционал таких модулей http://www.postgresql.org/docs/9.3/static/contrib.html — это официальный нативный функционал. Казалось бы, что такое знание совершенно не полезно.
Напомню, что дополнительных библиотек, которые собираются вместе со стандартными всего 5 в последнем (на текущий момент) патче.
online_analyzer и plantuner – сразу нас приводят на сайт http://sigaev.ru/
для НЕ желающих ходить по ссылкам, сразу скажу – эти 2 модуля добавляют известное поведение MSSQL – USEPLAN и аналог AUTOUPDATESTATS. И мне понравилось – во-первых данные библиотеки сразу же были включены в Ruby on Rails проект (точнее в их PostgreSQL), где в тот момент в силу большого количества пользователей наблюдались проблемы с производительностью с PostgreSQL. Особенную проблему вызывала как все 1С-ники знают, проблемы со статистикой записей. А тут оказалось, что можно построить адаптивный план обслуживания. Просто в PostgreSQL функция UPDATE STATS из MSQL называется ANALYZE TABLE.
Необходимость использования «хинтов» для плана запроса, говорит нам о том, что в 1С знают, что их запросы, формируемые в виде SQL достаточно нетривиальны, а также о том что оптимизатор планов запросов PostgreSQL проигрывает тому же MSSQL, где прецедентов необходимости подобного было очень мало и чаще всего причиной являлся плохой код. Вместе с этим именно это знание послужило основанием для решения НЕ использовать 1C+PostgreSQL для 1С:Зарплата и управление персоналом, в связи с особенностями текстов запросов. Но тесты на 1С ЗУП 3.0 уже показывают обратное поведение в связи с переработкой модели и методологии, которые на несколько порядков упрощают запросы. Вообще поведение последних редакций больших типовых (УТ 11.1, БП 3.0, ЗУП 3.0) позволяет с уверенностью сказать о их адаптированном поведении к PostgreSQL и Oracle. Спросите – откуда здесь появился Oracle? Мало кто знает, но PostgreSQL очень похож на Oracle. Не функционалом конечно, в Oralce он на порядок мощнее, а заложенной методологией. Существует версия что PostgreSQL рождался как OpenSource ответ большому и дорогому Oracle. Ключевым, наверное, термином здесь является PLpgSQL и остальные. Изучив PostgreSQL и его поведение, в случае если ваша компания захочет адаптировать 1С к Oracle, ваш опыт будет повторно использован, в силу особенностей архитектуры обоих. Ну и необходимо понимать, что PostgreSQL имеет версию и платную функциональность http://www.enterprisedb.com/products-services-training/subscriptions и цены там вполне себе Enterprise. Особенно для функциональности наподобие AlwayOn от MSSQL.
На самом деле, если продолжать можно понять, что 3 остальных библиотеки mchar, fulleq и fastrun – то же добавляют интересную функциональность, и даже НЕ для решений на 1С платформе. Особенно интересен новый тип MCHAR, а также то зачем для него понадобилась библиотека ICU. Что дает нам понимания, что работа в том числе с UTF-8 при использовании чистого PostgreSQL будет и есть достаточно Не тривиальной задачей, с чем вы обязательно столкнетесь, когда начнете писать приложение, которому будет необходимо хранить строки в национальных кодировках – когда например ваше приложение будет иметь пользователей из России и Канады например, да еще с Китая в добавок. Прежде чем мы начнем спорить необходимо понимать какую функциональность содержит mchar.h и файлы mchar\mchar*.c. Но для этого вам понадобится знания языка С для чтения кода.
В сухом остатке. Теперь я могу точно ответить – «Мне очень нравится данный патч». Надеюсь вы понимание почему?
Ну и последнее для данной публикации это патч вводящий новый тип, точнее «контрибьютящий» некоторой количество кода внутрь нашего «адаптированного для 1С PostgreSQL». И тут нам вдруг открывается, что оказывается можно собирать свой PostgreSQL со своим набором библиотек. Интересное знание, и прежде чем вы скажете, что мы должны использовать только нативное и без расширений, я вам скажу что функционал таких модулей http://www.postgresql.org/docs/9.3/static/contrib.html — это официальный нативный функционал. Казалось бы, что такое знание совершенно не полезно.
Напомню, что дополнительных библиотек, которые собираются вместе со стандартными всего 5 в последнем (на текущий момент) патче.
- mchar
- fulleq
- fastrun (опечатка сделана специально ;-))
- online_analyzer
- plantuner
online_analyzer и plantuner – сразу нас приводят на сайт http://sigaev.ru/
для НЕ желающих ходить по ссылкам, сразу скажу – эти 2 модуля добавляют известное поведение MSSQL – USEPLAN и аналог AUTOUPDATESTATS. И мне понравилось – во-первых данные библиотеки сразу же были включены в Ruby on Rails проект (точнее в их PostgreSQL), где в тот момент в силу большого количества пользователей наблюдались проблемы с производительностью с PostgreSQL. Особенную проблему вызывала как все 1С-ники знают, проблемы со статистикой записей. А тут оказалось, что можно построить адаптивный план обслуживания. Просто в PostgreSQL функция UPDATE STATS из MSQL называется ANALYZE TABLE.
Необходимость использования «хинтов» для плана запроса, говорит нам о том, что в 1С знают, что их запросы, формируемые в виде SQL достаточно нетривиальны, а также о том что оптимизатор планов запросов PostgreSQL проигрывает тому же MSSQL, где прецедентов необходимости подобного было очень мало и чаще всего причиной являлся плохой код. Вместе с этим именно это знание послужило основанием для решения НЕ использовать 1C+PostgreSQL для 1С:Зарплата и управление персоналом, в связи с особенностями текстов запросов. Но тесты на 1С ЗУП 3.0 уже показывают обратное поведение в связи с переработкой модели и методологии, которые на несколько порядков упрощают запросы. Вообще поведение последних редакций больших типовых (УТ 11.1, БП 3.0, ЗУП 3.0) позволяет с уверенностью сказать о их адаптированном поведении к PostgreSQL и Oracle. Спросите – откуда здесь появился Oracle? Мало кто знает, но PostgreSQL очень похож на Oracle. Не функционалом конечно, в Oralce он на порядок мощнее, а заложенной методологией. Существует версия что PostgreSQL рождался как OpenSource ответ большому и дорогому Oracle. Ключевым, наверное, термином здесь является PLpgSQL и остальные. Изучив PostgreSQL и его поведение, в случае если ваша компания захочет адаптировать 1С к Oracle, ваш опыт будет повторно использован, в силу особенностей архитектуры обоих. Ну и необходимо понимать, что PostgreSQL имеет версию и платную функциональность http://www.enterprisedb.com/products-services-training/subscriptions и цены там вполне себе Enterprise. Особенно для функциональности наподобие AlwayOn от MSSQL.
На самом деле, если продолжать можно понять, что 3 остальных библиотеки mchar, fulleq и fastrun – то же добавляют интересную функциональность, и даже НЕ для решений на 1С платформе. Особенно интересен новый тип MCHAR, а также то зачем для него понадобилась библиотека ICU. Что дает нам понимания, что работа в том числе с UTF-8 при использовании чистого PostgreSQL будет и есть достаточно Не тривиальной задачей, с чем вы обязательно столкнетесь, когда начнете писать приложение, которому будет необходимо хранить строки в национальных кодировках – когда например ваше приложение будет иметь пользователей из России и Канады например, да еще с Китая в добавок. Прежде чем мы начнем спорить необходимо понимать какую функциональность содержит mchar.h и файлы mchar\mchar*.c. Но для этого вам понадобится знания языка С для чтения кода.
В сухом остатке. Теперь я могу точно ответить – «Мне очень нравится данный патч». Надеюсь вы понимание почему?
Дополнение от 2016 года
Так случилось, что данная простая заметка показывает свою актуальность и на 2016 год. Наверное в том числе и с идеей «имортозамещения».
Что поменялось за это время:
Что поменялось за это время:
- появилась коммерческая российская компания Postgres Proffessionals https://postgrespro.ru/products/1c_build — обратите внимание, что фактически это компания является поставщиком дистрибутива, и что самое главное — теперь у данного дистрибутива появилась платная поддержка
- мы со своей стороны реализовали подход, когда у разработчика 1С на «разработческом» контуре также разворачивается PostgreSQL для того чтобы:
- проверять алгоритмы раньше чем они попадут в production
- проводить эксперименты не только с PostgreSQL но и с расширениями для PG.
- бесплатно — в GitHub репозитории https://github.com/VanessaDockers/pgsteroids
Дополнение от 2017 года
Мы сознательно не убираем эту статью, хотя движение идет дальше:
- самая главная проблема с PG как вы уже поняли - он без патчей и "расширений" не работает, это надо осознавать и не бояться этого. В июле на конференции PGDay.2017 мы в очередной раз попробуем побороть эти страхи.
- https://github.com/VanessaDockers/pgsteroids
- эксперименты продолжаются: в этот раз хочется проверить работу адаптивного плана запроса и отработать переход на 9.6
Поделиться