Comments 11
А как разработчик 1С это увидит? У него этой информации нет. Более того, среднестатистический разработчик даже не хочет ее иметь и максимально ограждает себя от нее: «Моя работа код писать, а база тормозит у админов, разбирайтесь с настройками, у меня все хорошо, на стенде отчет летает».
Что, реально так говорит ? Это точно разработчик ? Даже, когда сделает что-то типа SELECT * FROM a FULL JOIN b ON ...? И у него будет на 100 записях работать, а на 50.000 не выполнится никогда ? Или просто for'ом начнет сотни тысяч запросов делать.
Мне кажется, что в таких случаях не аудит нужен. А разработчика просто менять...
Ну, разработчики разные бывают. Тут вы правы. Они могут проверить функционал на разном количестве записей, но его поведение в многопользовательской среде с конкуренцией по ресурсам может давать непредсказуемый результат. И даже хорошие разработчики с этим периодически сталкиваются. Тут, скорее, вопрос взаимодействия отдела разработки и админов в поиске реальных причин.
У нас просто немного другой опыт. Администраторы обычно либо сразу валят, что это не наша зона ответственности, а "криво" написана программа - идите к разработчикам. Но все равно, по умолчанию, проблема возвращается к тому разработчику, который делал задачу. А потом, если он не знает, как оптимизировать, то проблема уходит на более высокий уровень, то есть к разработчикам, которые лучше разбираются.
Но в любом случае, все вернется к разработчику. То есть в 95% процентах случаях проблема в кривом коде, а не настройках. Даже, если аудит выявит проблему, то все равно нужен разработчик, чтобы переделать код.
Более того, часто приходится и к бизнесу обращаться. То есть, например, бывает бизнес просит : а сделайте отчет, который за последние 5 лет по всем розничным чекам найдет какую-то корреляцию. Понятно, что чудес не будет, и тут есть essential complexity. Запрос будет сильно насиловать базу, но разработчик с этим мало что может сделать. Максимум, что он может сделать - это преподсчеты, или инкрементное обновление с увеличением времени транзакций. Но опять же, это надо согласовывать с бизнесом, так как оперативность данных может измениться.
Мы (как разработчики) просто тоже сталкивались с внешним аудитом, и, если честно, не уверен, что в этом была польза. Со стороны аудита, как правило, действительно находятся умные и разбирающиеся люди (как и с нашей стороны). Но они не знают глубоко специфики работы программы. Да, они тратят время и находят узкие места, о которых мы и сами знаем. Но, как правило, там нет простого решения (если бы оно было, мы бы сами его давно сделали). И любое изменение имеет свои минусы, на которые, например, бизнес не хочет идти (или что приведет к другим техническим проблемам).
У нас действительно разнообразный опыт.
Встречали и ваш случай, когда админы валят всё на разработчиков и наоборот, когда разработчики валят всё на админов.
Очень важно найти причину проблемы, а КАК ее исправить становится часто уже вторичным и понятным из правильного описания причины.
Проблема "кривого кода" достаточно вырождена. Откровенно плохого кода мы почти не встречаем. Если в компании налажено тестирование, проверка качества кода, то это редкая проблема.
Часто возникают ситуации, когда запрос выполняется за доли секунды на любом количестве данных (это я про моделирование), но при этом он накладывает избыточные блокировки и начинает влиять на другие запросы. Или наоборот. Также бывает, что запросу не хватает каких-то индексов, он выполняет избыточные чтения, отнимает ресурсы у других. Да, его можно переписать, чтобы не создавать специфические индексы напрямую в базе и обойтись функционалом конфигуратора 1С. Но это может быть долго и повлечет за собой возможные функциональные ошибки. Поэтому индексный тюнинг - это простой, незатратный способ, который нельзя исключать. Я это всё к тому, что разработчики и админы должны пытаться совместно найти решение, а не пинать друг на друга. Важно лишь подойти к вопросу системно.
К тому же, не всегда можно переписать код 1С. Есть неудачная архитектура, появившееся много лет назад и разработчики сейчас являются ее заложниками, т.к. переделать ее легко и быстро уже нельзя. Есть, как вы написали, запрос от бизнеса "а сделайте отчет, который за последние 5 лет по всем розничным чекам". В каждом случае можно найти подходящее решение и компромисс. Например, для тяжелых отчетов, перелопачивающих данные за много лет имеет смысл держать отдельную архивную базу, на заведомо более слабом оборудовании, в которой работает 1,5 пользователя - они никому не мешают и им никто не мешает получать такие отчеты. А оперативную базу можно сделать комфортной по исторической глубине для обслуживания и работы всех пользователей. Причем архивная база может в себе содержать все оперативные данные. Т.е. она "живая" и задержка появления оперативных данных в ней минимальная, измеряется секундами или единицами минут.
Часто возникают ситуации, когда запрос выполняется за доли секунды на любом количестве данных (это я про моделирование), но при этом он накладывает избыточные блокировки и начинает влиять на другие запросы.
Вроде же Microsoft SQL Server поддерживает MVCC, разве нет ? Причем, насколько я помню, хотя возможно ошибаюсь, он там реализован немного по-другому. Там запись идет сразу в таблицы, а старые данные сохраняются сбоку (в Oracle вроде также). И это избавляет от необходимости vacuum (хотя имеет тоже свои недостатки).
Дело в том, что по опыту в PostgreSQL блокировки мимальные (фактически, только на записи). Проблемы там возникают, если кто-то решил в одной записи хранить что-то, что изменяют сразу сотни пользователей. Мне вот интересно, а часто Вы в своей практике используете MVCC для MS SQL Server, и он нормально работает ? Если нет, то почему не использовать ?
Также бывает, что запросу не хватает каких-то индексов, он выполняет избыточные чтения, отнимает ресурсы у других.
К сожалению, тут палка о двух концах. Если на каждый неэффективный запрос добавлять индекс (начнем с того, что это не всегда помогает), то будет как минимум две проблемы. Во-первых, база будет расти и замедляться транзакции, так как больше индексов будет нужно будет обновлять. А во-вторых, возможны ситуации (у нас такие были), когда добавление одного индекса начинает валить другие запросы, когда они радостно его видят, и начинают использовать. После этого план может стать таким, что запрос замедлиться в разы. То есть это нарушает принцип, что я вроде не менял в определенном месте, а все стало тормозить.
Но это может быть долго и повлечет за собой возможные функциональные ошибки. Поэтому индексный тюнинг - это простой, незатратный способ, который нельзя исключать.
К сожалению, очень ограниченный тюнинг. Нам, в lsFusion, конечно проще, так как мы можем добавить MATERIALIZED на любом промежуточное вычисление, и гарантированно функционал не измениться. Но разработчики тоже часто этим злоупотребляют, что приводит к тем же проблема, что я и описал выше с индексами.
В каждом случае можно найти подходящее решение и компромисс.
Ну тут решение простое. Просто использовать специализированную не совсем оперативную аналитическую базу, как Вы и написали выше. Только обычно для этого мы используем не копию основной, а именно СУБД заточенную под быстрые запросы (как правило, Druid). Скорость будет просто в десятки (если не сотни) раз выше. Но да, под нее отчеты пишутся отдельно. Просто когда поступает задача на отчетность, то сразу надо принимать решение к какой базе делать.
MS SQL - "блокировочник", соответственно блокировки там встречаются гораздо чаще, чем в PostgreSQL (он "версионник"). В MS SQL есть режим snapshot isolation, но это позволяет лишь частично использовать режим версионника.
Плюс существенным недостатком этой настройки служит то, что в 1С активно используются временные таблицы и для хранения версий тоже используется tempDB. Встречали ситуации, когда БД временных таблиц не справляется с нагрузкой (многочисленные блокировки и прочие ситуации). Поэтому режим MVCC в MS SQL, особенно в связке с 1С, надо использовать осторожно и обязательно анализировать на предмет проблем с tempDB.
По индексам. Конечно, на все неоптимальные запросы создавать индексы неверно - будут большие накладные расходы на хранение и обновление. Но, как правило, есть достаточно небольшой список видов запросов (5-10), на которые приходится 50+% нагрузки на CPU и диски/память. Их мы получаем с использованием PerfExpert, и кандидаты на индексный тюнинг именно они. Также сморим план выполнения - возможны ошибки компилятора, и в этом случае используем для ускорения точечные подсказки (хинты), используя QProcessing.
Примеры можно посмотреть в других наших статьях.
MS SQL - "блокировочник", соответственно блокировки там встречаются гораздо чаще, чем в PostgreSQL (он "версионник"). В MS SQL есть режим snapshot isolation, но это позволяет лишь частично использовать режим версионника.
Формально, MS SQL заявляет, что он умеет работать как версионник, а именно через READ_COMMITTED_SNAPSHOT :
If you set the READ_COMMITTED_SNAPSHOT database option to ON, the database engine uses row versioning and snapshot isolation as the default, instead of using locks to protect the data.
ALTER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ONТак а на практике, вы часто включаете такой режим ? Или в 95% случаев оставляете блокировочник ?
Встречали ситуации, когда БД временных таблиц не справляется с нагрузкой (многочисленные блокировки и прочие ситуации). Поэтому режим MVCC в MS SQL, особенно в связке с 1С, надо использовать осторожно и обязательно анализировать на предмет проблем с tempDB.
А в чем связь ? Как версионность связана с временными таблицами ? Даже, если в MS SQL, как в PostgreSQL, используются системные каталоги для хранения информации по временным таблицам, то это же разные записи и блокировок быть должно (по крайней мере, в PostgreSQL такого нет).
Режим Snapshot isolation мы советуем включить, если видим большое количество блокировок на данных при чтении. Есть случаи, где суммарно за сутки набегает десятки часов. Но, это надо делать осторожно, так как есть накладные расходы на базу tempdb, так как именно в ней MS SQL сохраняет версии.
После включения мы анализируем эффект, если он скорее положительный, то оставляем, если нет - то возвращаем настройку и ищем другие варианты решения по снижению блокировок.
Так как версионность в MS SQL - это дополнительная возможность, а задумывался MS SQL как блокировочник, то и реализация тоже не самая лучшая. Версии хранятся в единой БД с временными таблицами, которые 1С очень интенсивно использует. Тут и может получиться узкое место, которое мы частенько встречаем.
Господа разработчики FULL JOIN и CROSS JOIN не путают случаем?
Аудит производительности 1С-систем: на что обращаем внимание