В смысле 1C использует UNLOGGED таблицы ? Если речь идет о пуле временных таблиц для соединений, то в lsFusion это было сделано давно (до этой статьи)
Нет, 1С не использует UNLOGGED таблицы, просто вы в 3м варианте написали про переиспользование временных таблиц. Я имел ввиду, что это есть в 1С. Большое количество временных таблиц в IsFusion генерируют разработчики приложений или на уровне вашей платформы в определенных сценариях зашито использование временных таблиц, что и приводит к их большому количеству?
Конкретно последняя оптимизация была, чтобы вообще заменить их на unlogged и делить между разными подключениями
Интересное решение, но непонятно какой эффект это дало и как оценить профит из фразы "На стенде четыре сохранения потребовали ноль CREATE вместо сорока"? Не добавило ли проблем то, что разные сеансы стали конкурировать за эти UNLOGGED таблицы?
Но показанного текста недостаточно, чтобы сказать, что ожидание LockManager возникло непосредственно на invalidation queue
Да, возможно тест не показателен, ниже в статье был рассказ и об очереди инвалидационных сообщений. Разработчики собирали perf и делали анализ его результатов. Я потом на основе их результатов и писал статью. Что-то мог конечно не раскрыть так, как это мог бы раскрыть разработчик, который делал анализ результатов perf и работал с исходным кодом PostgreSQL.
Я уже проектирую свое первое расширение. Fable предложил 3 варианта проработки: Уровень 1: грубая эвристика в расширении, без ядра Уровень 2: честный провенанс, форк или инвазивное расширение Уровень 3: патч в ванильное ядро
И как он пишет " Уровень 1 я бы реализовал уверенно". Скоро узнаем..
Вы упомянули в статье, что при высоких значений collapse_limit приходит OOM Killer из-за повышенной утилизации ОЗУ при планировании запроса. Может быть geqo был отключен? Про 1С могу сказать так, что между ситуациями "все тормозит" и "работает быстро" или "приходит OOM Killer" и "теперь все ок" как раз и стоит разница в значениях по параметрам collapse_limit
Да причем тут рекомендации от фирмы 1С. Вы сами для прохождения теста 30К поставили *_collapse_limit = 20 и пишите об этом в статье. Зачем? Чем 8 не устроило?
Это нормальный вид. Установите данный параметр перед выполнением запроса (как делает платформа 1С) и тогда должны получить результат: SET standard_conforming_strings=off;
Только как вы боритесь с тем что auto_dump так же как auto_explain искажают запросы с отборами
Не совсем понял, что вы имеете ввиду под искажением? Стоит учитывать, что платформа 1С при каждом выполнении запроса устанавливает вот эти параметры, это может влиять на выбор плана запроса: SET enable_mergejoin=off; SET escape_string_warning=off; SET standard_conforming_strings=off; SET cpu_operator_cost=0.001;
Если вы выполняете запрос без установки этих параметров в pgadmin, то результат может быть другой
Во всех типовых конфигурациях есть мониторинг через APDEX, там можно понять, как изменение параллелизма повлияло на производительность ключевых операций бизнеса. Анализ проблем производительности, на мой взгляд, правильно начинать со стороны именно 1С, а не СУБД.
Нет, 1С не использует UNLOGGED таблицы, просто вы в 3м варианте написали про переиспользование временных таблиц. Я имел ввиду, что это есть в 1С.
Большое количество временных таблиц в IsFusion генерируют разработчики приложений или на уровне вашей платформы в определенных сценариях зашито использование временных таблиц, что и приводит к их большому количеству?
Интересное решение, но непонятно какой эффект это дало и как оценить профит из фразы "На стенде четыре сохранения потребовали ноль
CREATEвместо сорока"? Не добавило ли проблем то, что разные сеансы стали конкурировать за эти UNLOGGED таблицы?Да, возможно тест не показателен, ниже в статье был рассказ и об очереди инвалидационных сообщений. Разработчики собирали perf и делали анализ его результатов. Я потом на основе их результатов и писал статью. Что-то мог конечно не раскрыть так, как это мог бы раскрыть разработчик, который делал анализ результатов perf и работал с исходным кодом PostgreSQL.
Тут будет плюс от unlogged в том, что у вас появляется параллелизм, если конечно результат такого запроса вы не помещаете во временную.
А вообще ваш выбранный 3 вариант это то, как делает платформа 1С. Вот тут в начале статьи объяснение как сервер приложений 1C работает с временными таблицами и какую информацию хранит - https://infostart.ru/1c/articles/2221687/
Также мы сталкивались с подобной проблемой как в вашей текущей статье, вот ее описание - https://infostart.ru/1c/articles/2535895/#Первые результаты и проблемы
А вот ее решение на уровне доработки PostgreSQL - https://habr.com/ru/companies/tantor/articles/924978/#2-2
Не совсем понял. В ходе статьи вы пишите про временные таблицы, а затем
То есть вы заменили использование временных таблиц на unlogged-таблицы?
pg_anon: как обезличить базу 1С без промежуточной копии - https://infostart.ru/1c/articles/2747170/
Я уже проектирую свое первое расширение.
Fable предложил 3 варианта проработки:
Уровень 1: грубая эвристика в расширении, без ядра
Уровень 2: честный провенанс, форк или инвазивное расширение
Уровень 3: патч в ванильное ядро
И как он пишет " Уровень 1 я бы реализовал уверенно". Скоро узнаем..
Буквально свежий пример от одного из клиентов.
Периодически кончается оперативная память на сервере субд и он уходит в рестарт. В настройках видим коллапс_лимиты в значении 8.
Подписка Claude Pro на месяц 2100
Моя версия https://habr.com/ru/companies/tantor/articles/1038214/
Вы упомянули в статье, что при высоких значений collapse_limit приходит OOM Killer из-за повышенной утилизации ОЗУ при планировании запроса. Может быть
geqoбыл отключен?Про 1С могу сказать так, что между ситуациями "все тормозит" и "работает быстро" или "приходит OOM Killer" и "теперь все ок" как раз и стоит разница в значениях по параметрам collapse_limit
Да причем тут рекомендации от фирмы 1С. Вы сами для прохождения теста 30К поставили *_collapse_limit = 20 и пишите об этом в статье. Зачем? Чем 8 не устроило?
https://habr.com/ru/companies/tantor/articles/1035568/comments/#comment_29978522
Я тоже написал инструмент Profiler для PostgreSQL, скоро выпущу статью.
Было неожиданно увидеть, что кому-то пришла аналогичная идея)
Войдут некоторые из доработок вывода EXPLAIN и ускорение планирование запросов
Это нормальный вид.
Установите данный параметр перед выполнением запроса (как делает платформа 1С) и тогда должны получить результат:
SET standard_conforming_strings=off;
Не совсем понял, что вы имеете ввиду под искажением? Стоит учитывать, что платформа 1С при каждом выполнении запроса устанавливает вот эти параметры, это может влиять на выбор плана запроса:
SET enable_mergejoin=off;
SET escape_string_warning=off;
SET standard_conforming_strings=off;
SET cpu_operator_cost=0.001;
Если вы выполняете запрос без установки этих параметров в pgadmin, то результат может быть другой
Сравнивать процессоры замерами расчёта себестоимости длительностью 30 секунд на демо-базе ерп - первый раз такое вижу.
И стоит добавить, что расчёт себестоимости как правило однопоточный процесс, поэтому ему важнее частота, а не количество ядер
А на сколько claude помогает/ускоряет написание таких фич как sort pushdown?
Российские IT-компании массово «нанимают» нейросотрудников
HR диасофт: знакомьтесь, Александр Сахаров
Вторая и третья оптимизации для 1С не актуальны, т.к. там таких кейсов почти нет)
Во всех типовых конфигурациях есть мониторинг через APDEX, там можно понять, как изменение параллелизма повлияло на производительность ключевых операций бизнеса.
Анализ проблем производительности, на мой взгляд, правильно начинать со стороны именно 1С, а не СУБД.