Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

Публикация № 1429971

Администрирование - Производительность и оптимизация (HighLoad)

postgresql

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

7 лет пути

 

 

Расскажу для начала, какой путь мы прошли в 1С на PostgreSQL.

  • Путь этот начался в 2014 году, мы рискнули перевести 5 небольших баз на PostgreSQL – тогда это была еще версия 9.2. Никакую операционную систему, кроме Windows, мы не могли себе даже представить в связке с 1С. В то время мир 1С состоял только из Windows, Linux всех пугал своими черными экранами с белыми буковками – было вообще ничего непонятно. Первое наше впечатление было: «Ничего себе, оно работает»! 1С-ка запустилась и даже что-то сформировалось. 
  • К 2016 году мы поняли, что уже не можем переварить на Windows то количество баз, которое нам нужно. К тому времени у нас появилось уже около 50 баз на PostgreSQL. Именно в этот промежуток времени мной и моей командой экспертов был обнаружен первый баг PostgreSQL на Windows, там оказалась блокировка файла при обновлении статистики, которая приводила к тому, что 1С-ка замирала на 15 секунд, не выполняя никаких операций. Пока этот баг правили, мы поняли, что все равно Windows из-за своих особенностей не может удовлетворять наши запросы. Мы рискнули и перешли на Linux. В то время PostgreSQL обновился до версии 9.4, 
  • До 2018 года мы спокойно жили, пока наш облачный сервис не вырос в 5-6 раз, у нас стало 300 баз 1С. Тут мы вовремя познакомились с командой Postgres PRO, они начали выпускать отличные сборки для 1С. Кроме того, сам ванильный Postgres обновился до серии 9.6. Это была революционная версия – огромное количество изменений, и, как ни странно, для сообщества Postgres эти изменения были почти ни о чем: подумаешь, автовакуум стал лучше работать, стал чуть быстрее, ведь для наших 100 таблиц это ерунда. Для 1С это обновление стало критичным, ведь наша с вами любимая 1С имеет базу данных с тысячами таблиц и десятками тысяч индексов, а еще мы любители развернуть по 100 баз на одном сервере. Поэтому получаем миллионы элементов для СУБД. Для PostgreSQL это тяжело, и версия 9.6 в этом очень помогла. 
  • В 2019 году количество баз у нас выросло вдвое. И параллельно PostgreSQL стал очень быстро развиваться – раз в год обновляется релиз. Мы проскочили десятую версию и сразу заскочили на одиннадцатую. В 2018-2019 годах мы использовали сборки от команды Postgres PRO, не ванильную версию, не отдельные патчи для 1С, а именно готовые сборки.
  • В 2020-м году мы начали использовать Postgres PRO Enterprise. Используем мы его полгода, пока не везде он стоит на продакшн-базах, в своем докладе объясню – почему. Расскажу, что мы накопали, что уже исправили. 

 

 

  • В 2020 году мною был получен сертификат администратора PostgreSQL уровня Эксперт от компании Postgres PRO. Так получилось, что момент получения сертификата совпал с получением доступа к PostgreSQL PRO Enterprise 11 – когда мы начали его активно «ковырять».

 

Версии Postgres для 1С

 

Но прежде чем окунуться в Enterprise, сначала напомню, какие версии PostgreSQL для 1С есть. В этом моменте у многих есть недопонимание.

 

PostgreSQL для 1С – самосборка

 

 

Версия №1 – это самосборка PostgreSQL для 1С на основе открытых исходников ванильной версии. Для тех, кто умеет собирать пакеты – это самая теплая ламповая сборка. 

В чем ее особенности использования:

  • Эта версия PostgreSQL обойдется вам бесплатно, но использовать вы ее сможете только на свой страх и риск. Поддерживать ее даже за деньги вряд ли кто-то возьмется. Если вы обратитесь к кому-то за поддержкой такой «самосборки», скорее всего, вас попросят переустановить PostgreSQL из другого источника. 
  • Эта сборка не входит в «Единый реестр программ», который действует в рамках стратегии импортозамещения, и не может использоваться ни в одной организации, подчиняющейся приказу Минкомсвязи. 
  • Техподдержку этой версии вам придется оказывать самим – вряд ли кто-то вам поможет. Это не значит, что решение плохое, но, как и все бесплатное в мире OpenSource – поддерживайте сами. Форумы PostgreSQL и Linux похожи, поэтому, если вы там зададите вопрос – вас 100 раз спросят, зачем вы взялись за эту технологию, если такой “дурак”, а потом отправят учить матчасть. Причем без ссылок, где ее искать. Возможно, попадется один сердобольный специалист, который вам намекнет, где искать ответ. Это жестокая тренировка для тех, кто хочет окунуться в этот мир.

 

PostgreSQL для 1С – сборка фирмы «1С»

 

 

Есть сборка PostgreSQL от фирмы «1С». Она распространяется в двух видах – как дистрибутив и в качестве исходников набора патчей, которые нужно использовать для ванильного PostgreSQL. 

В чем ее особенности:

  • Собирается она специалистами фирмы 1С. Получить ее можно бесплатно на сайте, где выкладываются обновления платформы 1С. Но использовать вы ее можете так же на свой страх и риск. Впрочем, как и все ПО: ни одно ПО вам ничего не гарантирует, даже за очень большие деньги. 
  • Эта сборка также не входит в «Единый реестр ПО», запрещена в госорганах. 
  • Поддерживается фирмой «1С» бесплатно, в рамках партнерского форума и v8@1c.ru через “кровь и боль”.

 

PostgreSQL для 1С от Postgres PRO

 

 

Следующая сборка появилась недавно, в день проведения конференции Infostart Event 2019, от команды Postgres PRO. О ней объявил Олег Бартунов. Это сборка от команды Postgres PRO, скачать ее можно с сайта https://1c.postgres.ru. Это – ванильный Postgres, собранный с патчами для 1С и плюс некоторые улучшения, которые команда Postgres PRO считает важными для 1С и внедряет их. 

  • Эта сборка полностью бесплатная, лицензий на нее нет, используется на свой страх и риск.
  • Она также не входит в «Единый реестр ПО».
  • Техподдержку по ней можно получить за деньги.

 

Postgres PRO Standart

 

 

Еще одна такая же сборка с небольшой цензурой Postgres PRO Standart. 

Получить ее можно, зарегистрировавшись на сайте Postgres PRO. 

  • Она может использоваться бесплатно только для разработки, тестирования, экспериментов и изучения возможностей продуктов. То есть как разработчики на тестовых серверах вы ее использовать можете, но продуктивные базы на этой сборке работать могут только после приобретения лицензией. От Enterprise она отличается тем, что тут нет платных фишек Enterprise. Здесь есть некоторые улучшения планировщика, есть PTRACK – маркер для pg_probackup. 
  • Она входит в «Единый реестр ПО», потому что ее планируют использовать для госучреждений, которые обучают: институты и школы. Лицензия живая, меняется – надо ее изучать и следить за обновлениями.
  • Техподдержка осуществляется компанией Postgres PRO за отдельные деньги, а также входит в покупку лицензий в первый год.

 

Postgres PRO Enterprise

 

 

Коммерческая сборка Postgres PRO Enterprise – чем она отличается от версии Postgres PRO Standart:

  • Это коммерческий форк Postgres PRO, она отличается набором изменений – их около 100. Причем различий, имеющих смысл для 1С, там гораздо меньше. 
  • Надо понимать: платная версия не значит, что отчет 1С, который у вас на бесплатной версии выполнялся две минуты, тут будет выполняться две секунды. Это примерно такое же заблуждение, когда файловую базу переводят на клиент-серверный вариант и ждут, что она станет быстрее работать – не будет она быстрее работать в однопоточном режиме. Но по аналогии с тем, как клиент-серверная база 1С по сравнению с файловой будет работать с одинаковой скоростью – и при одном человеке, и при 300-400 пользователях. Так же и Postgres PRO Enterprise оптимизирован для высоких многопользовательских нагрузок – у него нет деградации от количества пользователей, он оптимизирован для больших баз данных. 
  • Postgres PRO Enterprise имеет сертификат ФСТЭК – его можно использовать в организациях с требованием секретности. 
  • Эта сборка входит в «Единый реестр ПО». 
  • Техподдержка осуществляется компанией Postgres Professional – в первый год после покупки бесплатно.

 

Фишки Enterprise, полезные для 1С

 

 

Теперь подробнее поговорим о фишках Enterprise, которые важны именно для 1С.

  1. Снято так называемое «проклятие 100 сессий». Кто интересовался PostgreSQL немного раньше, тот помнит: ходил слух, что PostgreSQL тормозит. Как про антивирус от «Лаборатории Касперского» говорили, что он тормозит, хотя он уже 15-20 лет не тормозит, если его правильно настроить. Так же про PostgreSQL ходил слух, что он после 100 соединений начинает резко деградировать. На самом деле, современные релизы даже ванильного Postgres не деградируют после 100 сессий – скорость работы может незначительно деградировать, если неправильно подобрано оборудование. В Enterprise эта деградация убрана полностью – тесты Benchmark показывают 20 тыс. соединений без деградации. В этой сборке поменяли взаимодействие между процессами и возможное количество одновременно работающих сессий резко увеличилось.
  2. Как и в версии Standard, в версии Enterprise есть PTRACK для pg_probackup. На пальцах постараюсь объяснить, что это такое. Мир 1С в большинстве случаев – это MS SQL. Все привыкли в MS SQL к дифференциальным бэкапам. В Postgres дифференциального бэкапа не существует, есть только инкрементальный бэкап. Если вы делали фулл, потом инкремент, то следующий инкремент – это изменения от последнего инкремента, а не фулла, в отличие от дифференциального. Но в чем сложность. Из-за особенностей хранения данных в файлах – не в одном файле, как в MS SQL, а каждое представление в отдельном файлике – очень трудоемко выяснить, какие страницы данных изменились, а если вычислять по времени обновления файлов, то получаем серьезную избыточность бэкапа в объёме. Особенно на базах 1С, где десятки тысяч файлов на одну базу. Поэтому сделали специальный реквизит PTRACK, который помечает: эти данные поменялись. И тогда pg_probackup очень быстро делает инкрементальный бэкап.
  3. Также тут внедрен важный патч для планировщика: статистика по составным индексам. Ванильный PostgreSQL не умеет делать статистику по составным индексам, а в 1С 100% индексов составные. Вряд ли платформа позволит вам сделать индекс по одному полю, она в любом случае добавит туда разделитель данных, даже если вы его не используете, и составит индексы так, как написано на ИТС, а не так, как вам захотелось. Все индексы в 1С составные, и Enterprise научили ориентировать статистику в том числе и по ним. 
  4. В Enterprise уже внедрено расширение pg_hint_plan. Я о нем чуть позже расскажу, с помощью этого расширения можно изменять поведение планировщика для нужного вам запроса.
  5. Самая крутая фишка, по моему мнению – сжатие данных на уровне СУБД. В MS SQL это есть, теперь появилась и в Postgres PRO. Фишка хорошая, имеет свои ограничения и свои плюсы, о них тоже расскажу чуть позже. 

Все отличия Enterprise от не-Enterprise смотрите по ссылке https://postgrespro.ru/products/postgrespro/enterprise

Теперь давайте подробнее рассмотрим, как это в жизни работает. 

 

pg_hint_plan

 

 

pg_hint_plan – это не фишка Enterprise, это открытое расширение, которое вы можете спокойно внедрять в свои сборки, но в Enterprise оно уже внедрено.

Что оно делает? На просторах интернета можно встретить жалобы на то, что в 1С плохо работает отчет. Но если в настройках join_collapse_limit поставить 1 (вместо 8 или 20 – по умолчанию на разных сборках установлено по-разному), то отчет сразу начинает работать быстро, а вся остальная база «встает колом».

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

Конкретно этот пример взят мной из документации. Здесь указано:

  • HashJoin(a,b) – таблицы a и b нужно соединить по хэшу. 
  • SeqScan(a) – в таблице a сделать SeqScan. 

Ниже план выполнения, где видно, что Postgres выполняет команды так, как ему сказали. 

Таким образом, независимо от того, как отработал планировщик – “Бог” СУБД, вы как программист можете выступить «помощником Бога» и исправить ошибки “Бога” так, как считаете нужным. Не факт, что это будет правильно или быстрее, но эксперты вполне могут себе позволить это делать.

 

 

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

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

А с помощью указания Set вы можете на время планирования запроса задать планировщику параметры GUC (например, указать join_collapse_limit=1 на ваш любимый отчет) – получается, что и запрос ускорится и база летать начнет. 

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

https://postgrespro.ru/docs/enterprise/12/pg-hint-plan

Поскольку не всегда мы можем дождаться исправления в платформе 1С, где, по нашему мнению, неправильная интерпретация запросов. А здесь вы можете сами взять и что-то подправить в планировщике.

 

Сжатие данных на уровне СУБД

 

 

Что дает сжатие данных на уровне СУБД:

  • Дает экономию места – в документации написано от 3 до 5 раз, на наших тестах от 5 до 8 раз от объема базы.
  • Дает еще большее уменьшение деградации производительности при смешанных нагрузках – именно у нас в 1С постоянно смешанные нагрузки OLAP+OLTP. Мы хотим, чтобы у нас мгновенно записывались транзакционные операции в базу, и так же очень быстро все читалось из базы в огромных отчетах, которые соединяют между собой по 200 таблиц. От чего здесь идет уменьшение деградации? Все элементарно – вы уменьшаете нагрузку на диск. В современном СУБД основные тормоза – это диски. Процессоры справляются, память очень дешевая, ее можно добавить, сколько угодно. А диски, даже SSD, все равно тормозят по сравнению с процессорами и памятью. Да, сейчас активно начали использовать NVME, но и они не всесильны, а так же немалую роль играет стоимость 1ГБ места на диске, которую можно уменьшить в разы, используя сжатие. При сжатии на уровне СУБД вы чисто физически уменьшаете объем поднимаемых данных в 5-8 раз. Причем не только данных, но и индексов и временных таблиц тоже – они так же жмутся. 
  • Еще одна фишка – шифрование данных. Это важная возможность для тех, кто хранит конфиденциальные данные. В этом случае при старте базы данных надо будет указать пароль. 

Казалось бы, сжатие –  крутая вещь, но когда мы ее начали использовать на 1С, нас начало не по-детски “штормить”. 

 

 

На тот момент у нас были настройки сжатия, как на слайде. Не было только одной настройки – Compress first segment of relations. 

Что это такое? По умолчанию сжатие происходит вообще всех элементов базы данных. Опять же напоминаю, что типовая Бухгалтерия содержит 5,5 тысяч таблиц и 27 тысяч индексов – итого 32 тысячи файлов. 

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

По умолчанию CFS попробует сжать все 300 тысяч файлов. 

 

 

В результате мы получим у каждой базы вот такой файл-отражение со стандартным размером 1 мегабайт, поскольку именно в 1 мегабайте они могут удержать отражение 1 Гб данных. 

Postgres не знает, что его сжали, он обращается к номеру страницы на диске, который у него в базе написан.

Система сжатия перехватывает этот запрос, и запрашивает в CFM-файле, где эти данные теперь в реальности находится – мы же сжали файлы, а оригиналы, грубо говоря, удалили, они находятся в другом месте. Это и называется файл-отражение, когда на каждый элемент создается файл размером 1 мегабайт. 

В чем случилась беда? Наш первый тест на базе 1С показал следующее: CFS-worker бегает по всем файлам отражения и пытается их дефрагментировать – удалить оттуда то, что мы удалили из данных. Грубо говоря, еще один вакуум еще одного элемента. При таком количестве файлов, как в базе 1С, CFS-worker клали на лопатки любые дисковые системы. У нас система легла на 4 млн файлов – это 150 баз на сервере 1С.

После этих тестов разработчики PostgreSQL:

  • добавили параметр cfs_compress_small_relations, чтобы компрессия работала только для файлов больше 1 ГБ;
  • и в принципе, исправили поведение CFS-worker – теперь он меньше грузит диски, даже если вы не отключите сжатие всего и вся.

 

 

Дальнейшие исследования показали, что нельзя сжать табличное пространство по умолчанию. Изначально Postgres ставится и создает пространство-default. Но сжать уже созданное пространство нельзя, сжатие происходит путем создания пространства с сжатием.

Здесь можно пойти несколькими путями:

  • Можно воспользоваться фишкой платформы 1С для Postgres, которая разделяет данные и индексы на разные tablespace. Если платформа обнаруживает, что tablespace вызывает v81c_index или v81c_data – раскидывает данные туда. 
  • Но здесь опять есть свой подводный камень. Когда вы создадите табличное пространство, вы захотите туда базу перекинуть с несжатого табличного пространства. Скорее всего, будете перекидывать постгрессовым дампом. И дампу не рассказать, куда класть данные и индекс. Как выход из ситуации – создавайте одно сжатое пространство и кладите туда. 
  • Более того, поскольку вы теперь создаете отдельное пространство, не default, вам надо аккуратнее работать с дампом и рестором. Вам надо подправить все скрипты, чтобы рестор правильно восстанавливал в существующие tablespace, а дамп правильно дампил.
  • Ну или просто создать отдельный сжатый tablespace и восстанавливать дамп, указав его утилите restore.

 

 

Как я уже сказал, каждый файл отражения весит 1 МБ, но это не реальное место, которое занимает файл на диске, а просто атрибут файла. В итоге можете получить интересный эффект. После сжатия 100-гиговой базы в свойствах Postgres вы обнаружите, что 100-гиговая фаза начала весить 250 гигов. Как же так, мы же сжали? Все просто: у вас образовалось 150 тысяч файлов отражений. Это пока не исправлено, нет отдельной процедуры, которая показывает правильный размер, либо я о ней не знаю. 

Реальный размер в Linux проверяется через утилиту du (disk usage) – на слайде приведена командная строка, как проверять. Эта утилита покажет вам реальный размер, который данные занимают на диске, а не размеры, подсчитанные по атрибутам файлов. В pg_admin будет искаженная информация. 

 

 

Еще одна особенность, обнаруженная случайно: оказывается, утилита pg_repak (по факту vacuum_full без блокировки данных), знает, но не учитывает tablespace у таблиц. 

А поскольку при сжатии мы создаем отдельный tablespace, то pg_repack, когда вы натравите его на сжатую базу, перепакует таблицы в несжатое пространство, в default.

Чтобы это исправить, ей при вызове нужно указать параметр -s (маленькая). И указать, в какой tablespace перепаковать – передать идентификатор для переупаковки сжатого tablespace. 

При этом при переупаковке индексов у них tablespace учитываются. Но на всякий случай привел вам команду и для индексов -S (большая). Это надо обязательно иметь в виду.

 

Что изменится в августе

 

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

 

 

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

Итак, когда мы подумали, что все окей, мы, как правильные эксплуататоры СУБД, решили настроить реплику и нарвались там на две ошибки. Эти ошибки нам обещают исправить в августе. Что это за ошибки?

  • PS_BaseBackup не умеет определять в файлах отражений, сколько они занимают места на диске. Когда мы попытались нашу сжатую 100-гиговую базу снять PG_BaseBackup’ом, чтобы потом запустить реплику, мы получили на BaseBackup 400 гигов занятого места, поскольку слилось еще 300 тысяч файлов CFS. BaseBackup прочитал атрибут, что ему требуется 1 МБ места, и реально выделил 1 МБ. Это исправлено, но еще нет в релизе. У нас на серверах это уже исправлено. 
  • Еще в августовское исправление войдет исправление самой реплики. Сейчас реплика «устраивает гонки» (ревнует) с CFS-сжатием. Система репликации не понимает, что работает на сжатой системе и взаимоблокирует два процесса, и в итоге полностью останавливает сервер реплики. У нас на серверах это тоже исправлено. В августе будет выпущено в релиз.

С 1 сентября, когда с нас снимут все карантины, заодно мы получим полностью работающую Enterprise версию PostgreSQL со сжатием данных. Огромное спасибо разработчикам движка базы данных и моей команде 1С-ников, которые все это протестили.

P.S. Все исправления обнаруженных нами проблем со сжатием вошли в версию 12.5.1.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Новосибирск. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в INFOSTART EVENT 2021 (6-8 мая, СПб).

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. 3vs 23.04.21 07:36 Сейчас в теме
Как про антивирус от «Лаборатории Касперского» говорили, что он тормозит, хотя он уже 15-20 лет не тормозит, если его правильно настроить.

А это как - "Приостановить защиту"?
EliasShy; user1578983; +2 Ответить
2. zinzillya 29.04.21 09:08 Сейчас в теме
Оставьте свое сообщение

См. также

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    31389    MrWonder    42    

Ускорение реструктуризации больших таблиц. Мой вариант

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

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

28.04.2021    698    buganov    0    

Поиск причин блокировок СУБД

Производительность и оптимизация (HighLoad) v8 v8::blocking 1cv8.cf Бесплатно (free)

Расследование блокировок СУБД.

28.04.2021    2851    vasilev2015    11    

Решение нестандартных проблем производительности на реальных примерах

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    3097    AlexKriulin    37    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    42484    Gilev.Vyacheslav    1    

Долгое воспроизведение звука по RDP с удаленной машины

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

При воспроизведении короткого звука в 38 Кб, сигнализирующего об успешном сканировании, порою происходило подвисание примерно в 5 секунд.

09.02.2021    584    pashamak    2    

Highload-оптимизация 1С: теория и практика на примере консолидированной отчетности группы "Магнит" и розничной аптечной сети "Магнит"

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Тема оптимизации 1С на больших данных бесконечная и всеобъемлющая, поскольку на производительность влияет целый ряд факторов – количество пользователей, данных, транзакций, неоптимальные запросы и т.д. Об инструментах для локализации проблем производительности и практических кейсах оптимизации рассказал Алексей Олейник, руководитель сектора автоматизации отчетности МСФО компании «Информационные технологии Магнит».

11.01.2021    21304    user662404_itlexusss    14    

Анализ блокировок СУБД: таблица изменений плана обмена 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    2236    zhichkin    6    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    68381    yuraos    112    

Анализ проблем производительности по динамике мониторинга RAS 1C

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

07.10.2020    4077    ivanov660    12    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

Производительность и оптимизация (HighLoad) v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    4731    Nykyanen    16    

Тест скорости работы мобильной платформы 1С

Мобильная разработка Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

14.09.2020    1592    capitan    25    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

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

21.06.2013    58403    Антон Ширяев    117    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    17384    YPermitin    30    

Адаптация автоматической классификации ошибок технологического журнала при появлении новых текстов и типов

Технологический журнал v8 1cv8.cf Бесплатно (free)

Корректируем классификацию ошибок ТЖ в процессе работы для конфигурации мониторинг производительности

17.08.2020    716    ivanov660    0    

SQL для 1С: пишем правильно, красиво, сложно

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Многие программисты боятся работать с Null, считая, что от этих данных в запросах нужно избавляться. О том, как с помощью Null-полей в запросе решать востребованные в учете задачи по выборке данных, на конференции Infostart Event 2019 Inception рассказал ведущий разработчик ГК WiseAdvice Дмитрий Дудин.

14.08.2020    12548    dmurk    33    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    57601    Gilev.Vyacheslav    46    

Нестандартные блокировки при работе с OLAP-нагрузкой

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    2399    Филин    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    3425    ivanov660    13    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    9448    DataReducer    22    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    32508    gallam99    19    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

18.05.2020    2456    Aleksey.Bochkov    4    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    14052    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

Производительность и оптимизация (HighLoad) Практика программирования v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    6544    feva    15    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    45000    madmpro    32    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    14850    informa1555    35    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

Разбор технологического журнала с группировкой событий по первой или последней строке многострочного контекста.

31.03.2020    3520    vasilev2015    10    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 v8::blocking Бесплатно (free)

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

20.03.2020    6097    vasilev2015    27    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    8076    kaliuzhnyi    44    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    12310    Evil Beaver    13    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

23.01.2020    7050    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    9398    Kaval88    26    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    13810    ivanov660    20    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    8337    EugeneSemyonov    11    

Обслуживание баз данных. Не так просто, как кажется

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    20064    YPermitin    31    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    9741    Repich    5    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    20581    Sloth    30    

Хранение файлов - как уменьшить размер базы данных

Чистка базы Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 Россия Бесплатно (free)

Хранение файлов в базе 1С можно оптимизировать для уменьшения размера хранимых данных.

09.09.2019    9491    2tvad    17    

Неочевидные проблемы производительности: важность системного подхода при анализе

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    9421    Филин    12    

Ловля блокировок на связке "Microsoft SQL server - 1С"

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    11395    fhqhelp    0    

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка v8 Бесплатно (free)

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    12114    igordynets    120    

Ускорение чтения правил обмена в УПП 1.3 в 20 раз!

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

27.06.2019    10428    YPermitin    17    

Хотите снизить нагрузку на процессор сервера в 2 раза?

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

27.06.2019    10973    Дмитрий74Чел    6    

Непридуманные истории по оптимизации. История 1

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    13243    Repich    117    

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

Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

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

13.06.2019    6181    slayer-ekb    10