Свёртка, которая не лечит: разбор реального проекта на 2,5 ТБ

Часть 1. Хирургия головного мозга 1С: как бизнесу предлагали удалить «почку», когда болела поясница

Представьте ситуацию. У вас заболела поясница — ну, потянули где-то на даче или в зале. Вы идёте к терапевту, жалуетесь на боль. Врач выслушивает, кивает:

— А, я про такое слышал. Вам срочно нужно удалить почку. Вот направление к хирургу.

Вы приходите к хирургу, он смотрит на бумажку:

— Ну раз надо, давай удалим. Зачем анализы? Зачем МРТ? Режем.

После операции вам выкатывают пациента и говорят:

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

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

Пациент

К нам на аудит попала крупная производственная компания (круглосуточное производство, ночная смена). История классическая, вы её наверняка узнаете: предприятие несколько лет росло, обрастало кастомными доработками от разных подрядчиков, бизнес-процессы усложнялись, каждая новая «срочная» правка ложилась поверх предыдущей. В какой-то момент база 1С:ERP разрослась до 2,5 ТБ и начала тяжело вздыхать в пиковые часы — примерно как первоклассник, которому задали на дом тридцать страниц.

Что делает обычный здравый человек, когда болит? Идёт на обследование.

Руководство пригласило подрядчика, который специализировался на свёртках. Базу перед стартом обследовали — по объёму, а не по нагрузке. Поэтому и вывод вышел про объём: «База огромная, значит, она умирает. Её надо сжать».

Второе мнение

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

Картина за один типичный рабочий день: 243 оборванных сеанса, 58 таймаутов на блокировках, 110 операций длиннее минуты. И четыре источника всей этой боли — ни один из которых не был связан с объёмом данных:

• Маркировка. Одно ночное задание по кодам маркировки работало от 38 до 97 минут и съедало всё ночное окно. Не потому, что кодов много, а потому, что на каждый код открывалась своя транзакция.
• Обмен с бухгалтерией. Один цикл — около девяти часов. При любом сбое цикл начинался с нуля. Узкое место — не сеть, не диски, а логика сборки сообщения.
• Ветеринарный госконтроль. Постоянный опрос очереди — 8 365 вызовов за сутки. Система спрашивала «есть что-нибудь?» примерно каждые десять секунд. Обычно ничего не было.
• Расчёт себестоимости. Запускался в рабочее время и конкурировал с людьми за процессор.

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

Первое, что я сказал руководству:

— База в 2,5 ТБ для промышленной ERP — это не мега-размер, это ещё подросток. Она не умирает. Её зажали кандалами из кривого кода и блокировок. Никакую почку резать не нужно.

Нам не поверили сразу — и это нормально: за нашими словами пока были только цифры из журнала.

Приёмка первая: «а где, собственно, свёртка?»

Примерно в те же дни подрядчик прислал первую версию свёрнутой базы «на тестирование». Пользователи зашли — и сразу словили системные ошибки.

Мы открыли журнал регистрации и обнаружили удивительное. В присланной базе не было признаков свёртки. Зато было много другого: пропали пользовательские варианты отчётов (при свёртке такого не бывает физически), у части объектов метаданных поменялись внутренние идентификаторы (то есть объекты были удалены и созданы заново — привет, система прав доступа), не завершилось обновление информационной базы, отвалилась интеграция с внешним сервисом проверки контрагентов.

Всё вместе соответствовало прерванному обновлению конфигурации, а не свёртке. Продолжая медицинскую аналогию: пациента готовили к удалению почки, а в выписке — следы совсем другой операции, и та не закончена.

Замечания мы оформили письменно — четыре пункта — и запросили протокол работ и резервную копию «до». Так стоит делать при любой приёмке. Дальше история пошла двумя параллельными треками: подрядчик готовил следующую версию свёртки, а мы начали лечить живую базу — прямо на рабочем сервере, без остановки производства.

Мы открыли капот

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

И, забегая вперёд, почти ничего из найденного не было делом рук подрядчика по свёртке. У него в этом музее будет всего один зал. Но зато какой.

Продолжение — в части 2: контур обмена документами, который сошёл с ума, ночное обслуживание базы, которое никогда не заканчивалось и раздуло служебную базу до 25 гигабайт, «мёртвые души» в планах обмена с КПД меньше тысячной доли процента и таблица, на которую сервер тратил 45 часов процессорного времени в сутки. Да, в сутках 24 часа. Мы тоже удивились.

Случай обезличен, отдельные детали обобщены. Оценки — мнение автора по результатам замеров, а не оценка свёртки как метода или исполнителей в целом.

Технические подробности для коллег

Чтобы статья не выглядела рассказом без доказательств — вот как собиралась картина.

Чем измеряли. Технологический журнал с фильтром по длительности (события CALL, DBMSSQL, TTIMEOUT, EXCP, TLOCK), сутки непрерывного сбора; параллельно — Query Store на стороне SQL Server и системные представления sys.dm_db_index_physical_stats, sys.dm_db_stats_properties для оценки индексов и статистик.

Что показал журнал за сутки: 243 события разрыва сеанса, 58 TTIMEOUT (ожидание блокировок свыше 20 с), 110 вызовов длительностью больше минуты. Профиль ожиданий важнее самих цифр: у проблемных операций dur в разы превышал CpuTime, то есть время уходило не на счёт, а на ожидание — либо ответа СУБД, либо чужой блокировки. Это сразу отсекает гипотезу «не хватает мощности процессора» и переводит разговор в плоскость блокировок и планов запросов.

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

• маркировка — O(N) по количеству кодов в текущей партии, транзакция на код;
• обмен — время сборки сообщения зависит от объёма изменений за период, а не от размера базы;
• опрос очереди госконтроля — фиксированная частота обращений, 8 365 вызовов в сутки;
• расчёт себестоимости — конкуренция за ресурсы, вопрос расписания, а не объёма.

Свёртка уменьшает историю, но не меняет ни одну из этих величин. Отсюда и вывод, с которого началась вся работа: лечить надо код и настройки, а не резать данные.

Что было не так с присланной свёрнутой базой. Диагноз ставился по журналу регистрации: удаление пользовательских вариантов отчётов (при свёртке невозможно), смена GUID у части объектов метаданных (объекты пересозданы — ломается система прав доступа и ссылочная целостность в подсистемах, которые хранят ссылки на идентификаторы), незавершённое ОбновлениеИнформационнойБазы (отсутствовали предопределённые элементы), сломанная интеграция с внешним сервисом. Совокупность признаков соответствует прерванному обновлению конфигурации, а не свёртке.