Режим Snapshot isolation мы советуем включить, если видим большое количество блокировок на данных при чтении. Есть случаи, где суммарно за сутки набегает десятки часов. Но, это надо делать осторожно, так как есть накладные расходы на базу tempdb, так как именно в ней MS SQL сохраняет версии. После включения мы анализируем эффект, если он скорее положительный, то оставляем, если нет - то возвращаем настройку и ищем другие варианты решения по снижению блокировок.
Так как версионность в MS SQL - это дополнительная возможность, а задумывался MS SQL как блокировочник, то и реализация тоже не самая лучшая. Версии хранятся в единой БД с временными таблицами, которые 1С очень интенсивно использует. Тут и может получиться узкое место, которое мы частенько встречаем.
MS SQL - "блокировочник", соответственно блокировки там встречаются гораздо чаще, чем в PostgreSQL (он "версионник"). В MS SQL есть режим snapshot isolation, но это позволяет лишь частично использовать режим версионника.
Плюс существенным недостатком этой настройки служит то, что в 1С активно используются временные таблицы и для хранения версий тоже используется tempDB. Встречали ситуации, когда БД временных таблиц не справляется с нагрузкой (многочисленные блокировки и прочие ситуации). Поэтому режим MVCC в MS SQL, особенно в связке с 1С, надо использовать осторожно и обязательно анализировать на предмет проблем с tempDB.
По индексам. Конечно, на все неоптимальные запросы создавать индексы неверно - будут большие накладные расходы на хранение и обновление. Но, как правило, есть достаточно небольшой список видов запросов (5-10), на которые приходится 50+% нагрузки на CPU и диски/память. Их мы получаем с использованием PerfExpert, и кандидаты на индексный тюнинг именно они. Также сморим план выполнения - возможны ошибки компилятора, и в этом случае используем для ускорения точечные подсказки (хинты), используя QProcessing.
У нас действительно разнообразный опыт. Встречали и ваш случай, когда админы валят всё на разработчиков и наоборот, когда разработчики валят всё на админов. Очень важно найти причину проблемы, а КАК ее исправить становится часто уже вторичным и понятным из правильного описания причины. Проблема "кривого кода" достаточно вырождена. Откровенно плохого кода мы почти не встречаем. Если в компании налажено тестирование, проверка качества кода, то это редкая проблема. Часто возникают ситуации, когда запрос выполняется за доли секунды на любом количестве данных (это я про моделирование), но при этом он накладывает избыточные блокировки и начинает влиять на другие запросы. Или наоборот. Также бывает, что запросу не хватает каких-то индексов, он выполняет избыточные чтения, отнимает ресурсы у других. Да, его можно переписать, чтобы не создавать специфические индексы напрямую в базе и обойтись функционалом конфигуратора 1С. Но это может быть долго и повлечет за собой возможные функциональные ошибки. Поэтому индексный тюнинг - это простой, незатратный способ, который нельзя исключать. Я это всё к тому, что разработчики и админы должны пытаться совместно найти решение, а не пинать друг на друга. Важно лишь подойти к вопросу системно. К тому же, не всегда можно переписать код 1С. Есть неудачная архитектура, появившееся много лет назад и разработчики сейчас являются ее заложниками, т.к. переделать ее легко и быстро уже нельзя. Есть, как вы написали, запрос от бизнеса "а сделайте отчет, который за последние 5 лет по всем розничным чекам". В каждом случае можно найти подходящее решение и компромисс. Например, для тяжелых отчетов, перелопачивающих данные за много лет имеет смысл держать отдельную архивную базу, на заведомо более слабом оборудовании, в которой работает 1,5 пользователя - они никому не мешают и им никто не мешает получать такие отчеты. А оперативную базу можно сделать комфортной по исторической глубине для обслуживания и работы всех пользователей. Причем архивная база может в себе содержать все оперативные данные. Т.е. она "живая" и задержка появления оперативных данных в ней минимальная, измеряется секундами или единицами минут.
Ну, разработчики разные бывают. Тут вы правы. Они могут проверить функционал на разном количестве записей, но его поведение в многопользовательской среде с конкуренцией по ресурсам может давать непредсказуемый результат. И даже хорошие разработчики с этим периодически сталкиваются. Тут, скорее, вопрос взаимодействия отдела разработки и админов в поиске реальных причин.
...Поскольку указатель перестаивался ночью, возможны были случаи, когда поиск не находил клиента, название которого изменялось сегодня ...
Все верно вы говорите. И этот момент тоже был важен заказчику, т.к. отставание по обновлению данных в старом механизме составляло как раз до суток. Да еще и перестроение не всегда успевало завершиться.
Пожалуй, еще добавлю. Если у заказчика с весьма крупной и нагруженной базой данных есть конкретная задача, которую не может, в силу неважно каких причин, решить вендор (включая фирму 1С), за их решение берётся Софтпоинт. С отзывами по разным продуктам можно ознакомиться с на сайте.
Здесь тоже все просто. Добавляется задание, которое, например, раз в сутки проверяет наличие триггеров на нужных таблицах и если их нет, то создает их.
Тоже поначалу использовали и pg_stat_kcache, и pg_state_statement, и другие подобные вещи. Очень тяжело и трудозатратно выйти на конкретные группы запросов при вариативности запросов 1С. Для других систем не спорю, значительную часть можно проанализировать текущими, безусловно, полезными инструментами. Наверняка, кто в реальности сталкивался с высоконагруженными 1С системами на PostgreSQL поймет наши разработки.
В других решениях есть множество разных и полезных наработок, но подобных счетчиков как, например, Кол-во запросов в сек, Скорость чтения из кэша мы не встретили нигде. Та же ситуация с трассировкой. Поэтому и реализовали инструментарий сами и встроили его в мониторинг Perfexpert.
Почему вы решили, что используется аппаратный ключ? Ключ программный. Никаких аппаратных составляющих в решении нет. Ценник продублируем с главной страницы на страницу решения. Еще раз спасибо за подсказку.
Решение действительно узкоспециализированное, как и всё направление анализа производительности ИТ-систем. Мы сделали продукт, который собирает те метрики, которых нет в других расширениях и продуктах, т.к. столкнулись с нехваткой данных во время аудита. И надеемся, что рынок будет от этого только лучше, т.к. появляется здоровая конкуренция, от которой выиграют все.
Мы не наезжаем, а расстраиваемся, что нет привычных и удобных инструментов, и сейчас мы работает над своими. По мере расширения функционала будем здесь о нем рассказывать.
Админ может всё, в том числе остановить SQL.
1. Как-то доступ получил админский. Да это и не важно.
2. Интересная мысль.
Это был первый шаг. В следующем предложении все встанет на свои места.
Режим Snapshot isolation мы советуем включить, если видим большое количество блокировок на данных при чтении. Есть случаи, где суммарно за сутки набегает десятки часов. Но, это надо делать осторожно, так как есть накладные расходы на базу tempdb, так как именно в ней MS SQL сохраняет версии.
После включения мы анализируем эффект, если он скорее положительный, то оставляем, если нет - то возвращаем настройку и ищем другие варианты решения по снижению блокировок.
Так как версионность в MS SQL - это дополнительная возможность, а задумывался MS SQL как блокировочник, то и реализация тоже не самая лучшая. Версии хранятся в единой БД с временными таблицами, которые 1С очень интенсивно использует. Тут и может получиться узкое место, которое мы частенько встречаем.
MS SQL - "блокировочник", соответственно блокировки там встречаются гораздо чаще, чем в PostgreSQL (он "версионник"). В MS SQL есть режим snapshot isolation, но это позволяет лишь частично использовать режим версионника.
Плюс существенным недостатком этой настройки служит то, что в 1С активно используются временные таблицы и для хранения версий тоже используется tempDB. Встречали ситуации, когда БД временных таблиц не справляется с нагрузкой (многочисленные блокировки и прочие ситуации). Поэтому режим MVCC в MS SQL, особенно в связке с 1С, надо использовать осторожно и обязательно анализировать на предмет проблем с tempDB.
По индексам. Конечно, на все неоптимальные запросы создавать индексы неверно - будут большие накладные расходы на хранение и обновление. Но, как правило, есть достаточно небольшой список видов запросов (5-10), на которые приходится 50+% нагрузки на CPU и диски/память. Их мы получаем с использованием PerfExpert, и кандидаты на индексный тюнинг именно они. Также сморим план выполнения - возможны ошибки компилятора, и в этом случае используем для ускорения точечные подсказки (хинты), используя QProcessing.
Примеры можно посмотреть в других наших статьях.
У нас действительно разнообразный опыт.
Встречали и ваш случай, когда админы валят всё на разработчиков и наоборот, когда разработчики валят всё на админов.
Очень важно найти причину проблемы, а КАК ее исправить становится часто уже вторичным и понятным из правильного описания причины.
Проблема "кривого кода" достаточно вырождена. Откровенно плохого кода мы почти не встречаем. Если в компании налажено тестирование, проверка качества кода, то это редкая проблема.
Часто возникают ситуации, когда запрос выполняется за доли секунды на любом количестве данных (это я про моделирование), но при этом он накладывает избыточные блокировки и начинает влиять на другие запросы. Или наоборот. Также бывает, что запросу не хватает каких-то индексов, он выполняет избыточные чтения, отнимает ресурсы у других. Да, его можно переписать, чтобы не создавать специфические индексы напрямую в базе и обойтись функционалом конфигуратора 1С. Но это может быть долго и повлечет за собой возможные функциональные ошибки. Поэтому индексный тюнинг - это простой, незатратный способ, который нельзя исключать. Я это всё к тому, что разработчики и админы должны пытаться совместно найти решение, а не пинать друг на друга. Важно лишь подойти к вопросу системно.
К тому же, не всегда можно переписать код 1С. Есть неудачная архитектура, появившееся много лет назад и разработчики сейчас являются ее заложниками, т.к. переделать ее легко и быстро уже нельзя. Есть, как вы написали, запрос от бизнеса "а сделайте отчет, который за последние 5 лет по всем розничным чекам". В каждом случае можно найти подходящее решение и компромисс. Например, для тяжелых отчетов, перелопачивающих данные за много лет имеет смысл держать отдельную архивную базу, на заведомо более слабом оборудовании, в которой работает 1,5 пользователя - они никому не мешают и им никто не мешает получать такие отчеты. А оперативную базу можно сделать комфортной по исторической глубине для обслуживания и работы всех пользователей. Причем архивная база может в себе содержать все оперативные данные. Т.е. она "живая" и задержка появления оперативных данных в ней минимальная, измеряется секундами или единицами минут.
Ну, разработчики разные бывают. Тут вы правы. Они могут проверить функционал на разном количестве записей, но его поведение в многопользовательской среде с конкуренцией по ресурсам может давать непредсказуемый результат. И даже хорошие разработчики с этим периодически сталкиваются. Тут, скорее, вопрос взаимодействия отдела разработки и админов в поиске реальных причин.
Все верно вы говорите. И этот момент тоже был важен заказчику, т.к. отставание по обновлению данных в старом механизме составляло как раз до суток. Да еще и перестроение не всегда успевало завершиться.
Пожалуй, еще добавлю. Если у заказчика с весьма крупной и нагруженной базой данных есть конкретная задача, которую не может, в силу неважно каких причин, решить вендор (включая фирму 1С), за их решение берётся Софтпоинт. С отзывами по разным продуктам можно ознакомиться с на сайте.
Здесь тоже все просто. Добавляется задание, которое, например, раз в сутки проверяет наличие триггеров на нужных таблицах и если их нет, то создает их.
Никаких сложностей нет. Обновление конфигурации на стороне 1С не затрагивает новую таблицу и её индексы.
С помощью сервиса оптимизации запросов мы улучшаем и ускоряем запросы баз данных для любых приложений, в том числе и 1С.
Понижали уровень совместимости tempDB. Не помогло.
Это коммерческая разработка
Тоже поначалу использовали и pg_stat_kcache, и pg_state_statement, и другие подобные вещи. Очень тяжело и трудозатратно выйти на конкретные группы запросов при вариативности запросов 1С. Для других систем не спорю, значительную часть можно проанализировать текущими, безусловно, полезными инструментами.
Наверняка, кто в реальности сталкивался с высоконагруженными 1С системами на PostgreSQL поймет наши разработки.
В других решениях есть множество разных и полезных наработок, но подобных счетчиков как, например, Кол-во запросов в сек, Скорость чтения из кэша мы не встретили нигде. Та же ситуация с трассировкой. Поэтому и реализовали инструментарий сами и встроили его в мониторинг Perfexpert.
Почему вы решили, что используется аппаратный ключ? Ключ программный. Никаких аппаратных составляющих в решении нет. Ценник продублируем с главной страницы на страницу решения. Еще раз спасибо за подсказку.
Решение действительно узкоспециализированное, как и всё направление анализа производительности ИТ-систем. Мы сделали продукт, который собирает те метрики, которых нет в других расширениях и продуктах, т.к. столкнулись с нехваткой данных во время аудита. И надеемся, что рынок будет от этого только лучше, т.к. появляется здоровая конкуренция, от которой выиграют все.
Ценник есть на главной странице https://softpoint.ru/
Продублируем, спасибо.
Мы не наезжаем, а расстраиваемся, что нет привычных и удобных инструментов, и сейчас мы работает над своими. По мере расширения функционала будем здесь о нем рассказывать.
Такая возможность есть в версии для MSSQL и в скором времени будет в версии для PostgreSQL