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

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

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

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

Здравствуйте, коллеги! У нас сегодня необычное выступление, нас сегодня двое – парный доклад. Итак, Андрей Овсянкин и Никита Грызлов. Мы в 1С довольно давно. И хотим с вами поделиться нашим опытом по оптимизации запросов, а именно, по просмотру планов запросов.

 

Оптимизация производительности это почти всегда тюнинг запросов

 

 

Андрей: Стоит ли говорить, что всем нужна скорость. Чем быстрее система работает, тем счастливее люди. И ни для кого, наверное, не секрет, что в работе приложения 1С наибольшее влияние на скорость оказывают именно запросы. То есть, код 1С по сравнению с запросами выполняется относительно быстро. А когда что-то тормозит, то, скорее всего, проблема в запросах, и смотреть надо на запросы.

Наверное, каждый при написании того или иного запроса задавался вопросом: «Мне здесь условие написать в ГДЕ или в СОЕДИНЕНИЕ?» или «Как лучше – сначала отсортировать, а потом применить условие или наоборот?» 

Как вы решали этот вопрос? Что делали, чтобы принять решение? Наверное, делали замер производительности? Кто сказал: «План запроса»?

 

План запроса

 

 

Андрей: Итак, план запроса:

  • Кто слышал это слово?

  • А кто знает, что это такое?

  • А кто умеет читать план запроса и использовать его в работе?

Никита: Хорошо, контрольный вопрос – а на Postgres? 

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

Маленькая ремарка – наш сегодняшний доклад будет касаться обычной 1С-ной сборки от Postgres Pro и возможно, некоторые вещи, про которые Олег Бартунов рассказывал в коммерческих редакциях, будут неактуальны. Но, я думаю, что большинство людей (90%) пользуются именно «халявным» Postgres – либо от сайта 1С, либо от Postgres Pro – поэтому для большинства наши рекомендации будут актуальны.

 

Давайте разбираться

 

 

Андрей: Давайте разбираться, что такое план запроса, и почему вообще он нужен?

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

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

У СУБД должен быть админ.

 

 

Андрей: Когда мы пишем запрос, мы находимся на самом верхнем слое прикладной логики. 

  • Язык SQL – декларативный. 

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

  • А как именно будет выполняться запрос, как именно сервер должен добыть эти данные, нас на уровне языка SQL не интересует.

 

 

Андрей: И сервер, прочитав наш запрос, начинает думать:

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

  • Слишком много сложных операций, нужно составить план действий!

 

Устройство плана запроса

 

 

Андрей: План запроса – это некое «Что? Где? Как?» про базы данных:

  • Текст запроса – отвечает на вопрос «ЧТО». Что надо получить на выходе?

  • Структура базы данных – отвечает на вопрос «ГДЕ». Где лежат запрошенные данные, в каких файлах, в каких таблицах. 

  • А вот КАК достать эти данные из структуры таблиц, чтобы выдать результат за вменяемое время – на это и отвечает план запроса. Как правило, для запроса существует более одного способа извлечения данных. И далеко не все эти способы быстро сработают.

 

 

Андрей: Как устроен план запроса?

  • План запроса состоит из операторов – это цепочка операторов. 

  • Каждый оператор – это некий «черный ящик» с одним методом «Дай следующую запись». 

  • Когда эти операторы выстроены один за другим, они вызывают друг друга.

  • И данные начинают считываться в том направлении, которое идет по стрелке – от самого дальнего оператора к самому ближнему. 

 

 

Андрей: Но эти кубики можно поставить и наоборот – можно сначала отсортировать, а потом отфильтровать по имени. Как будет лучше, не знаешь?

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

 

 

Никита: Вот так выглядит план запросов PostgreSQL. Изначально он, конечно, представлен в виде текста или в виде JSON, но есть несколько визуализаторов (на скриншоте один из них), которые позволяют его покрутить. С помощью этих просмотрщиков можно удобно и быстро понять, где у нас есть проблема – видно, какие операторы самые проблемные, и видна вложенность этих операторов.

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

 

Основные операторы плана PG SQL

 

 

Андрей: А как понимать-то всех этих операторов? Я вижу, что что-то написано в плане. Я, например, слышал, что есть такой оператор Scan – сканирование таблицы. Я слышал, что это вроде как очень плохо. А про остальные операторы вообще непонятно, что это такое.

Никита: Как таковой Scan – это не плохо, это миф. Мало того, в Postgres их несколько. 

  • Есть Sequential Scan, его аналог в MS SQL – это Table Scan. Это, действительно, последовательный перебор таблицы и, да, он может в каких-то случаях работать медленно и неоптимально.

  • И есть еще два вида сканирования индексов:

    • Index Only Scan – это когда поиск идет только по индексу (когда все поля выборки включены в индекс) и не надо лезть в основную таблицу;

    • Index Scan – это когда после нахождения нужной строки в индексе мы еще залезаем в основную таблицу за дополнительными данными. Например, нашли по измерениям что-то в регистре сведений и вытащили ресурсы. Иногда такая операция будет работать даже медленнее, чем последовательный перебор таблицы.

Андрей: Хорошо, я смотрю, здесь есть еще и несколько видов Join-ов. 

Никита: Да, видов соединений очень много. Сейчас мы про них расскажем. Но перед тем как рассказывать про соединения, нужно немного сказать про индексы.

 

Индексы

 

 

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

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

Андрей: Например, у нас в регистре есть индекс по трем полям – «Организация», «Склад» и «Номенклатура». Если я хочу поискать только по двум полям – «Организация» и «Номенклатура», у меня все будет тормозить?

Никита: Это зависит от многих факторов – например, от распределения. Если у тебя в таблице 100 тысяч уникальных организаций, то индекс по первому полю (по «Организации») действительно будет очень быстрым. 

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

Андрей: Но вот справа здесь у тебя показан какой-то кусочек плана запроса – это хорошо или плохо?

Никита: Здесь Postgres угадал. Он взял индекс, который построен по «Организации», «Складу» и «Номенклатуре», и попытался найти по «Организации». И полученный результат уже будет фильтроваться по «Номенклатуре».

 

Основные виды соединений – Nested loops и Hash Join

 

 

Андрей: Ты нам обещал рассказать про соединения. Первый самый простой способ соединений я знаю – это вложенные циклы (Nested loops).

Никита: А что там рассказывать? Делается два вложенных цикла по двум таблицам, внутри проверяется условие совпадения.

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

 

 

Никита: Следующий вариант уже посложнее – Hash Join. Знаешь, что это такое?

Андрей: Вообще-то я 1С-ник, я, когда слышу слово Hash, я начинаю пугаться. Это что-то страшное, это с бухгалтерией не связано. Я попробую сейчас объяснить. 

Hash Join – это использование соответствия. Мы все знаем класс «Соответствие» в 1С. Сначала мы берем одну таблицу, бежим по ней и в некое соответствие закидываем ключи, по которым мы будем соединять. А потом берем вторую таблицу, бежим по ней и проверяем – есть ли такой ключ в соответствии, и, если есть, то выдаем результат.

Примерно так это и работает.

 

Как читать план запроса

 

 

Андрей: И как же все-таки прочитать план запроса? Например, у меня есть самый простой запрос:

SELECT * FROM test WHERE i=1

Ниже написан план этого запроса – рассмотрим его подробнее.

 

 

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

Допустим, я вижу, что у меня используется скан, выбрано 12 строк, и есть какая-то стоимость. Но что это за стоимость, и почему она так странно написана?

Никита: Стоимость в Postgres записывается через многоточие. 

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

  • А вторая цифра – это уже время на отдачу всех строк, которые этот оператор собирается предоставить. 

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

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

 

 

Андрей: Стоит сказать, что на предыдущем слайде – это был оценочный план. Сам запрос еще не выполнялся, это прикидки планировщика. А вот так выглядит «действительный план», который мы видим в технологическом журнале. У него есть слово actual в описании. Здесь уже Postgres показывает не только примерную прикидку по стоимости, но и реальное время, которое заняло выполнение того или иного оператора, и реальное количество строк, которое выполнил оператор. 

Оценка и реальность могут различаться. Главное, чтобы они не различались радикально.

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

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

 

 

Андрей: Вот так, например, выглядит план запроса с теми самыми вложенными циклами, и вот так на примере вложенных циклов выглядят вложенные операторы. 

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

Мы видим, что один источник – это скан таблицы по какому-то фильтру, а второй – скан индекса (он может внутри иметь еще операторы). Оба этих множества попадают на вход оператора Nested Loop, который и выполняет построчное сравнение и пересылку данных дальше, другим операторам плана запроса.

Так, собственно, и строится план запросов.

 

 

Андрей: Или вот – живой пример из 1С. Сканирование таблицы регистра сведений. Что мы тут видим – это хороший план или нет?

Никита: Не очень. Ключевые вещи здесь показаны цветом. 

  • И первое, на что стоит обратить внимание – это первая красная цифра – 550 тысяч. Это – стоимость данного оператора. Цифра довольно большая. Разница между 550 тысяч и нулем как раз и говорит о том, что оператор сам по себе тяжелый, он будет работать медленно. 

  • Далее мы видим оценку строк. 

    • 2,5 миллиона строк будет просканировано, и на них будет наложен фильтр по полю «Статус». 

    • Но тут важно обратить внимание на третью строчку на скриншоте там, где написано actual. Это означает, что по данным действительного, актуального плана запроса, который, в итоге, сформировал Postgres, этим оператором на самом деле было возвращено всего 27 тысяч строк – это меньше чем 1% от планируемого количества. 

Что можно сделать в случае, когда мы видим, что у нас в плане большое количество прочитанных строк не попадает в возвращаемые? Скорее всего, нам не хватает какого-то индекса. Предлагаемое решение в данном вопросе – добавить индекс по полю _fld4431, в котором хранится статус.

 

Пример из жизни № 1 – срез последних

 

 

Андрей: Вообще, основная головная боль в Postgres – это виртуальные таблицы «СрезПоследних». Особенно, если регистр сведений довольно большой.

Никита: На слайде показан пример с одного из моих проектов. Не очень большой регистр сведений (порядка 300 тысяч строк) – делается срез последних, и соединяется с табличной частью документа.

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

Андрей: Я думаю, что там разработчик в файловой базе на 15 записях потестил и решил, что все отлично, запрос работает, задачу можно запускать в продакшен. Действительно, мы обычно в тестовой базе делаем в справочник три записи, и смотрим, что запрос работает, как ожидается. А потом отправляем в продакшен – там два миллиона записей вместо трех, другой план запроса, и все работает совсем по-другому.

 

 

Никита: Давайте посмотрим план запроса, который сформировался по этому тексту.

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

Подкрашенная красным нижняя строка – это оператор чтения из таблицы документа. Его стоимость – 5 тысяч. На тех настройках, которые стояли, это – не самое страшное. Но ключевое – это то, что он выполнялся 241 тысячу раз (колонка loops). 

Андрей: Получается, что сам оператор стоимостью 5 тысяч, который выдает 491 строку, но при этом сам он выполнялся 240 тысяч раз. 

Никита: Postgres, когда строит «СрезПоследних», делает много вложенных запросов, и эти запросы получаются настолько сложными, что он, скорее всего, не будет использовать индекс вообще, потому что, по его мнению, самым оптимальным решением здесь будет – использовать вложенные циклы.

Андрей: Что же тут делать? 

Никита: Включать голову.

 

 

Андрей: Да, во-первых, все знают, что надо накладывать отборы на виртуальные таблицы. Это позволит закинуть фильтр внутрь того вложенного запроса, который внизу делает 1С.

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

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

 

Андрей: Как платформа делает срез последних?

Вообще этот вопрос часто задают на собеседованиях 1С-никам, поэтому можно прямо здесь решить вопрос для собеседования.

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

Как работает срез последних?

  • Выбираются все записи с условием по периоду, где период меньше заданной даты, 

  • Берется максимум от этих строк. Но поскольку у нас в запросе есть не только измерения, но и ресурсы, мы сначала группируем измерения, а после того, как мы сгруппировали, у нас ресурсы пропали из результата группировки. 

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

  • И уже в таком виде выдается результат. 

Так работает срез последних.

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

 

 

Андрей: Вот, например, как выглядел запрос по срезу последних, который выполнялся 3 часа. Причем, учтите, что это – не весь запрос. Весь он у меня на слайд не уместился, и я его значимую часть подрезал.

  • Итак, в самом верху добываются РАЗЛИЧНЫЕ значения измерений, которые соединяются с таблицей документа.

  • Источником этого набора различных является вложенный запрос, который берет свои данные из еще одного вложенного подзапроса, соединенного с этой таблицей для вычисления МАКСИМУМа по позиции регистратора.

  • А поскольку используется периодичность по позиции регистратора, то начинаются подстроки от ссылки и всякое такое – получается аж четыре вложенных запроса.

И Postgres уже думает – да не буду я тут уже индексы смотреть, тут что-то непонятное, я просто вложенными циклами все это обработаю, и все. И получается медленный большой запрос. 

 

 

Никита: Мы решили проблему очень просто:

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

  • Также сделали группировку и поместили результат в индексированную временную таблицу.

  • Применительно конкретно к той задаче не нужны были ресурсы регистра сведений. Поэтому соединяться еще раз с самой же таблицей для доставания ресурсов было не нужно. Платформа строит намного более сложный запрос, но за счет того, что мы не используем ресурсы регистра, нам достаточно той самой группировки по максимуму. Мы делали максимум по периоду и набор только нужных нам измерений, и оказалось, что срез последних получался за одно «СГРУППИРОВАТЬ ПО» без всяких дополнительных соединений. 

И вместо 4-х соединений получилось только два. 

 

 

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

 

Пример из жизни №2 – сортировка различных

 

 

Андрей: Итак, еще один пример, как работают планы запросов и как они помогают находить «узкие места».

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

Как здесь работал Postgres?

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

  • сначала Postgres делал соединение;

  • потом все это большое соединенное он сортировал. А сортировка – это значит, нужно пересмотреть всю таблицу, переупорядочить записи и выдать наверх;

  • И только потом этот большой массив данных обрезался по объему оператором «РАЗЛИЧНЫЕ» и выдавал результат. 

Получалось довольно медленно. 

 

 

Андрей: Посмотрели на план запроса, поняли, что он делает, и решили заставить его сделать наоборот. 

РАЗЛИЧНЫЕ вынесли во временную таблицу. Это сразу обрезало большую часть записей, и соединение с сортировкой выполнялось уже для меньшего количества записей. Это сократило время выполнения почти в 3 раза.

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

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

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

 

Инструменты

 

 

Андрей: Мы тут показываем красивые графики и картинки, а у 1С-ников в распоряжении есть только технологический журнал, в котором можно посмотреть план запроса. И там будут такие тексты, которые до нас показывал Олег Бартунов на своих слайдах, где много разных букв на английском языке.

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

Как они работают?

Это – визуализаторы, тот самый набор инструментов, который мы хотели показать. Вы получаете план запроса либо из технологического журнала, либо из pgadmin, если вы выполнили там запрос с Explain Analyze. И вставляете на специальный сайт – либо на один, либо на второй. 

  • На первом сайте https://explain.depesz.com/ (в случае левой части картинки) вы видите такое симпатичное дерево, которое раскрывается, складывается, показывает информацию по статистике, по разнице между реальными данными, ожидаемыми данными и т.д.

  • А на втором сайте https://tatiyants.com/pev/ – он вам показывает такое же дерево в виде таблички. Он, в принципе, выводит ту же самую информацию, только в другом представлении.

Мне очень нравится инструмент https://tatiyants.com/pev/ (справа), потому что там есть справка по каждому оператору. Если вы обратите внимание, тут операторы Nested Loop, Unique – подчеркнуты. Это, на самом деле, гиперссылки, и если вы на них нажмете, у вас откроется подробнейшая справка конкретно по этому оператору. То есть, изучая план запроса, вы можете не только пытаться предположить, почему этот оператор работает медленно, но и быстро, буквально на расстоянии одного клика, понять, что конкретно этот оператор делает. Глядя в выдачу технологического журнала, можно только угадывать, что делает план запроса, а загрузив это в визуализатор, можно по каждому оператору почитать подробную справку.

 

Заключение

 

 

Хочется поговорить о важном. 

  • Планы запросов – это вообще не страшно, это очень просто. Это всего лишь кубики вызовов функций и больше ничего. 

  • Важно просто почитать некую небольшую справку о том, что эти функции делают, и все.

  • Вы можете любой запрос, самый сложный, самый страшный раскрыть. Главное – найти там операторов с большой стоимостью (где большая разность), понять, что они делают, поменять порядок следования их вызовов и всего лишь сделать рефакторинг запроса. Это очень просто.

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

  • Не бойтесь неизвестного, дерзайте, экспериментируйте. 

 

 

А если что – вы всегда можете найти нас в интернете.

 

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

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

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

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

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. mpeg1989 125 17.02.20 16:50 Сейчас в теме
А не будет ли обычный срез по регистру сведений работать быстрее за счет итогов по регистру? Там же сейчас отдельная таблица будет задействована.

По поводу различных и сортировки. Если поместить во вложенный запрос РАЗЛИЧНЫЕ, а потом сделать сортировку, то не получим ли мы выигрыш за счет того, что не скидываем данные в tempdb?
2. Vladimir Litvinenko 2333 17.02.20 18:34 Сейчас в теме
(1)
А не будет ли обычный срез по регистру сведений работать быстрее за счет итогов по регистру? Там же сейчас отдельная таблица будет задействована.

Нагрузка на запись может оказаться очень высокой. Судя по исходному времени выборки в регистре очень много данных, а это значит, что в него ведётся активная запись. Запись в регистр сведений с физическим срезом последних - это фактически запись в исходную таблицу + расчет среза последних по записываемым измерениям + запись в таблицу итогов. Время записи увеличивается, снижая скорость OLTP операций. Период перестаёт быть разделителем блокировок снижая параллельность записи.

Добавьте сюда тот факт, что срез последних хранится в отдельной таблице, фактически дублируя часть данных. Если движений по каждому аккредетуемому в целом не много, но много разных аккредетуемых (что скорее всего так) , то физическая таблица среза значительно увеличит общий размер таблиц регистра. Например регистр в целом занимал 100 ГБ, а стал 120 ГБ.

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

Если поместить во вложенный запрос РАЗЛИЧНЫЕ, а потом сделать сортировку, то не получим ли мы выигрыш за счет того, что не скидываем данные в tempdb

По временным таблицам в Постгрес можно включить авторасчёт статистики, которая будет довольно точной. По вложенным запросам такого не получится - с ними будет не статистика, а предположения оптимизатора о количестве строк. Фактически это обмен риска задействовать диск и израсходовать temp buffers на статистику.

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

Кроме того рассмотрен очень частный случай - когда ресурсы не нужны. При потребности выбирать ресурсы выигрыш в ручном формировании среза скорее всего был бы незначительный. При ручном формировании можно промежуточные таблицы (результаты вычисления максимумов периодов) во временные таблицы складывать. А это не очень хорошо при больших выборках. Если же без временных таблиц обходиться и выбирать ресурсы, то разницы между ручным запросом и автоматическим почти не будет.
3. Dach 295 18.02.20 10:27 Сейчас в теме
(0) спасибо за труды!

Такой вопрос - из практики, кроме срезов, какие еще запросы на слонике ведут себя совсем не так, как на мелкомягком сиквеле? Что-то прям запомнившееся или не особо очевидное
4. buganov 150 18.02.20 14:04 Сейчас в теме
(3) от коррелирующих запросов потгрес вообще в обморок падает
5. Dach 295 18.02.20 16:48 Сейчас в теме
(4) можно пример, если не трудно?
6. buganov 150 18.02.20 17:49 Сейчас в теме
(5)
https://forum.mista.ru/topic.php?id=764178

ВЫБРАТЬ Ф, К1, К2, К3, К4
ИЗ Дано
ГДЕ (Ф, К1, К2, К3, К4) 
В (ВЫБРАТЬ ПЕРВЫЕ 1 * ИЗ Дано КАК ВСЁ ГДЕ ВСЁ.Ф = Дано.Ф)
7. Dach 295 18.02.20 19:03 Сейчас в теме
(6)

Безмерно уважаю ildarovich и его труды, но при всем этом - ни разу в своей практике не приходилось писать корелированные запросы.

Аналоги exist, нарастающий итог, подзапросы в условиях, иерархию, разузлование и т.д. - это да, встречалось и не раз

Задача вида "выбрать одну любую запись" - звучит мягко говоря абстрактно.

И кстати, с чего вдруг PG сходить с ума от такого запроса? А mssql с ума не сходит от него? Математика одна и та же вроде, t-sql и там и там одинаковый, за счет каких-таких особенностей такие отличия? И на скольких записях в исходной таблице такое поведение воспроизводится?

К чему я это все? К тому, что хочется иметь некий туториал особенностей написания запросов в Postgres. Сколько не задавал этот вопрос ни на IE, ни на PGconf - всегда ответ один: "мил человек, читайте план да и будет счастье вам, а инструкций как на грабли наступить мы дать не можем, потому что сами не особо наступали, а где наступали - выводы забыли"
8. buganov 150 19.02.20 04:33 Сейчас в теме
(7) MS и вложенные запросы раскручивает на ура, чего нельзя сказать о PG. И коррелированные запросы тоже МС трескает, за ушами трещит.
PG штука интересная если звезды совпали: конфигурацию пишут и дописывают разработчики очень высокого уровня, которые знают, что делают, а не натыкали как попало, а так же DBA на таком же уровне. PG не MSSQL, и каждая настройка у него может, как улучшить производительность, так и сломать ее совсем. К тому же, PG, в отличие от MSSQL, не прощает ничего и за любой грешок готов свалиться в скан таблицы. И это не говоря про таких темных коней, как перезапись файла статистики под высокой нагрузкой на винде.
9. ansh15 19.02.20 10:16 Сейчас в теме
(8)
как перезапись файла статистики под высокой нагрузкой на винде

Можно просто не использовать Windows, в Linux этой проблемы нет.
10. buganov 150 19.02.20 11:09 Сейчас в теме
(9)
Можно просто не использовать Windows, в Linux этой проблемы нет.


Можно просто не использовать PG, в MSSQL этой проблемы нет.
11. ansh15 19.02.20 11:17 Сейчас в теме
(10) Или так
А уговорить клиента/работодателя расстаться с не одной сотней тыс. р. никакой сложности не представляет, конечно же. Они всегда с радостью...
12. buganov 150 19.02.20 14:05 Сейчас в теме
(11)если умный, то да, с радостью. Ну, и не рога и копыта
13. DmitriyPerevalov 20.02.20 12:32 Сейчас в теме
Спасибо за информацию. Познавательно.

Есть вопросы.
1. На сколько медленнее/быстрее PG работает с 1Сными агрегатами при чтении/записи? Понятно, что случаи разные, на простеньких примерах можно.
2. Можно ли решить часть проблем скорости выполнения запросов на PG с помощью агрегатов?
3. А может всё намного проще и агрегаты вообще лучше не включать?

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

См. также

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

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

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

30.10.2017    28748    0    MrWonder    42    

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

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

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

25.06.2020    1777    0    ivanov660    12    

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

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

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

24.05.2020    5906    0    DataReducer    22    

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

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

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

18.05.2020    1610    0    Aleksey.Bochkov    3    

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

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

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

22.04.2015    40025    0    Gilev.Vyacheslav    1    

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

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

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

06.04.2020    9957    0    YPermitin    0    

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

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

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

03.04.2020    3220    0    feva    14    

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

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

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

31.03.2020    11072    0    informa1555    21    

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

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

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

22.01.2014    66428    0    yuraos    112    

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

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

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

31.03.2020    2735    0    vasilev2015    9    

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

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

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

20.03.2020    4017    0    vasilev2015    21    

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

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

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

18.03.2020    6058    0    kaliuzhnyi    43    

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

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

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

21.06.2013    53211    0    Антон Ширяев    116    

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

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

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

23.01.2020    5823    0    darkdan77    59    

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

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

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

23.01.2020    7117    0    Kaval88    26    

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

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

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

19.02.2013    53858    0    Gilev.Vyacheslav    46    

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

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

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

19.12.2019    9876    0    ivanov660    16    

Весёлые картинки о работе 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    6923    0    EugeneSemyonov    11    

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

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

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

14.10.2019    16320    0    YPermitin    28    

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

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

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

11.02.2013    29614    0    gallam99    19    

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

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

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

13.09.2019    8461    0    Repich    5    

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

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

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

10.09.2019    17422    0    Sloth    24    

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

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

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

09.09.2019    7934    0    2tvad    17    

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

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

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

03.11.2012    41808    0    madmpro    32    

Анализ производительности APDEX

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

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

31.08.2019    9777    2    YPermitin    7    

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

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

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

19.07.2019    8440    0    Филин    12    

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

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

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

16.07.2019    9080    0    fhqhelp    0    

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

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

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

02.07.2019    10570    0    igordynets    119    

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

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

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

27.06.2019    9307    0    YPermitin    16    

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

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

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

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

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

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

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

13.06.2019    12067    0    Repich    117    

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

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

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

13.06.2019    5575    0    slayer-ekb    10    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

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

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    22774    0    dmurk    144    

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С

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

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    17669    0    ivanov660    9    

Не думать о секундах свысока...

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

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    7587    0    vasilev2015    21    

Альтернативная стратегия управления блокировками

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

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

20.05.2019    6801    0    zhichkin    15    

Как работают управляемые блокировки

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

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

29.04.2019    21202    0    comol    198    

Странное потребление места на диске С

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

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    13689    0    kuzyara    12    

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С

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

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    13080    0    Elf1k    27    

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С

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

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

18.04.2019    27661    0    ivanov660    77    

Как разбить базу на файлы и не сойти с ума

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

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    14951    0    YPermitin    30    

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз

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

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    14987    0    w.r.    23    

Простое программное решение проблем с блокировками SQL

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

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    8605    0    dmitrydemenew    38    

Производительность сервера 1С и фоновые задания

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

В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

05.02.2019    17873    0    user715208    38