Случайное ускорение расчёта себестоимости
Случайный кейс ускорения расчёта с/с в ЕРП случился.
Клиент обратился, Большой и Уважаемый в Челябинске. Себестоимость, говорит, долго считается: 20-40 часов.
Это чисто расчёт себестоимости, другие операции закрытия тоже тормозят.
Сделайте хоть что-нибудь, направление подскажите, может чё не так делаем.
Покопался, и почему-то опять повезло - нашёл в партионном учёте место, где порождается больше 1 млрд. связей.
Эти связи обрабатываются даже не запросом - кодом. Т.е. какой-то код бегает миллиард раз, что-то куда-то гоняет - партии прокидывает, наверное.
Говорю "наверное" потому, что обошёлся вообще без отладчика - просто внимательно прочитал протокол расчёта, там все замеры есть.
Ну, короче, движения у документов этого типа свернул, и себестоимость стала считаться в 6-8 раз быстрее.
Что интересно - движения там не сказать, что прям по делу были развёрнуты. Там к себестоимости зачем-то прицепили счета-фактуры и НДС, которому эта себестоимость ни к селу, ни к городу. Сэкономили, видимо.
Написал на партнёрке, получил три лайка.
ДО 3, проказник
На прошлой неделе маленький, но гордый ДО 3 очень интересно уронил сервер клиента.
Короче, стоял ДО 2, никого не трогал, клиент пробовал в нём работать. База весила меньше 1 Гб, в виде dt - около 300 Мб.
Малявка, наверное как демобаза.
Перевели на ДО 3 - ну, чисто по приколу. Недельку работает, всем даже нравится - интерфейс, говорят, приятнее. Ну, я и забыл про него.
А потом вдруг - АААААААААА - админ пишет, что база ДО разрослась до 400 Гб!
Ну, думаю, дурак какой-то попался - новый админ, аутсорс, пусть сам ковыряется. Дал стандартные рекомендации, типа иди шринк сделай, ограничения на размеры файлов SQL проверь, размер лога погляди, бла-бла-бла. И забыл про него.
Но не надолго. ААААААААААААААА база ДО продолжает расти! На 1 Гб в минуту! Всё, щас винт кончится!
Снял корону, бегу смотреть. Одного человека отправил смотреть со стороны SQL, сам из базы смотрю - в ДО 3 есть стандартная измерялка размеров таблиц. И она, блин, показывает 300 Мб! Я думал - ну, мало ли, может кто-то с дуру к документу ДО приложил фильм blu-ray. Нет, данные в норме.
Чувак со стороны SQL тоже в панике - растёт не лог, а именно база. Шринк не помогает. Ничего не помогает.
Бежим в ЖР - ну, ничего особенного там нет. Что-то делается, что-то пишется, но без ошибок, и интенсивность записи - самая обычная.
В активных сеансах висят ФЗ - так это нормально, ДО 3 даже в заднице через ФЗ ковыряется - мода нынче такая.
Я думаю - есть несколько минут, сниму бэкап. И вот чот думалось, что в dt выгрузятся те же 300 Мб. Выгружаю - да, блин.
Админ деаттачит базу, валит её нахер, перезагружает сервер. Делаем новую базу, загружаем dt, запускаем, ждём...
Опять растёт на 1 Гб в минуту!
Чё делать? Ну, надо что-то делать. Отключаем регл.задания. Штош - база перестаёт расти. Оставили в таком состоянии - на сколько успела вырасти, но с выключенными регл.заданиями, и больше не растёт.
Ковыряюсь, смотрю - ничё не могу найти. Всё хорошо.
Ну, думаю, поотключаю опасные регл.задания. Все эти 100500 выполнений задач по почте, кому они вообще нужны.
Поотключал, запустили регл.задания - вроде всё хорошо. Бегу докладывать - починил, попал пальцем в небо.
Только сел чайку попить - админ опять пишет. Эх, растёт дальше.
Ну думаю, сраный ДО, не победишь ты меня, говна кусок. Иду смотреть на работающие ФЗ. Вижу, что некоторые регулярно перезапускаются, а несколько зависли. 5 минут, 10, 20... Висят, но ничего не делают. Ничего не пишут. Как назло, у админа была выключена серверная отладка, поэтому задача получилась детективная.
Зависшие ФЗ - обработка очереди. Есть там какая-то такая хрень, которая двигает задачи по маршруту, вроде. Я плохо знаю ДО, не люблю его.
Информацию о том, что куда двигать, берёт из справочника - есть там такой. В нём - несколько десятков элементов, часть из них красненькие - ошибки в них.
Ага, думаю. Там же счётчик нарисован - сколько было попыток обработки элемента, и сколько он уже чего-то там ждёт. У всех красненьких время примерно соответствует тому, сколько висят ФЗ. Есть протокол обработки этих элементов, в виде текста - пару дней назад в обоих была ошибка, связанная с правами на какие-то грифы. Спрашиваю у программистов - да, чот тыкались, разбирались вместе с клиентом в ДО 3, включили какие-то грифы.
Ладно, идём выключать грифы. Валим ФЗ, запускаются новые, и опять зависают. Грифы, не грифы - пофиг им. Видимо, в ДО 3 всё зависает раз и навсегда.
Ладно, помечаем на удаление. Делаем удаление помеченных - о чудо, нет на них ссылок! Торжественно удаляем эти зависшие штуки, и всё работает норм.
Ну вот чё это было?
Ты сюда не лезь
Несостоявшийся кейс по производительности. Большой завод, УПП, себестоимость считается то ли сутки, то ли больше. Регулярно обращается во франчи с задачей оптимизации. Что важно: обращается ИТ-отдел.
Все разговоры, конечно, крутятся вокруг СУБД, серверов, оптимизации типовых запросов. Эксперты по производительности пыхтят, выжимают последние соки, как-то становится чутка лучше, ИТ-отдел выдыхает. Где-то через год история повторяется.
Один раз меня зачем-то подпустили. Полез в базу - в рот мне ноги... 10 000 записей в способах распределения затрат! Десять тысяч, Карл! С одинаковым, блин, способами распределения! Раньше была такая проблема в УПП - надо было вбивать каждое сочетание статьи и подразделения, иначе не закрывалось.
И, не помню сколько, но дохренища копеечных записей в остатках затрат, зависших с прошлых месяцев и годов. Этих копеечных, по количеству записей, сильно больше, чем реальных остатков.
Ну, ежу понятно, что делать. Там же тупо перебор используется - не важно, циклом или запросом.
Чисто по приколу списываем старые остатки и резко сокращаем количество способов распределения. Расчет себестоимости буквально прорывает - считается со скоростью базы среднего бизнеса.
Угадайте, что сказал ИТ-отдел? Им страшно пойти в бухгалтерию и предложить списать остатки из регистра, о существовании которого бухгалтерия даже не подозревает (в оборотке-то всё закрывается).
Только технические решения. В методику не лезьте, не ваше дело.
И так каждый год.
Нельзя уволить
Вчера случилось забавное приключение. Началось не страшно - люди в ЕРП не могут сформировать форму Т-8, приказ об увольнении. Выдаёт странную ошибку, типа файл такой-то не обнаружен. Причём, не во всех документах - где-то норм. По описанию похоже на проблему серверного кеша. Ну, садимся потихоньку ковыряться - не срочно и не страшно вроде, формочка простая, увольнения случаются не часто.
Остановка по ошибке не помогает. Значит, надо отладочкой идти. Лень. Подождём, может само рассосётся. Но на всякий случай посадил человека разбираться.
А тут вдруг скдыщ! - та же ошибка начинает рандомно выскакивать в кадровых документах и справочниках. Теперь нельзя ни уволить человека, ни принять. У клиента нарастает паника. Штош, садимся разбираться по-настоящему.
Итак, остановка по ошибке не работает. Идём отладкой. Печатная форма Т8 - никакая не печатная форма, а отчёт, который печатной формой прикидывается. Внутри прост, как топор - выполняется СКД, в дерево значений, потом циферки и буковки из дерева подставляются в макет.
Отладочка говорит - падает на программном выполнении СКД, когда процессор выводится. Так, ещё интереснее.
Все знаем, СКД - штука капризная. Любит куда-то зачем-то закешировать настройки, чтобы потом падать с ошибкой или не реагировать на изменения в схеме компоновки. И сама дура, на уровне платформы, и БСПшная оболочка с вариантами отчётов - то ещё чудище.
А тут вроде похоже на проблему непрошенного кеширования настроек - падает ведь не везде. Ладно, применяем старый добрый метод - сохраняем отчёт Т8, как внешний, меняем всё, что можно - имя файла, имя отчёта, синоним, имя основного варианта. Ругается, что внесены критичные изменения - самозащита ЗУПовских модулей срабатывает. Затыкаем её рот. Но - хрена с два, внешний отчёт тоже ни бе ни ме.
Ладно, зато у нас теперь есть внешний отчёт, в котором можно вытворять всё, что угодно. Да, забыл - всё это делается на рабочей базе, копии нет. Клиент зачем-то пользуется арендованным облачным сервером, и добиться чего-то от волшебной администрации этого облака почти нереально. Поэтому работаем нежно, даже документы не перепроводим.
Где-то посередине ещё отработали версию со скрытыми реквизитами - некоторые документы ведь печатаются. Посмотрели консолькой, нашли разницу - в "плохих" документах не указана статься ТК, по которой человек увольняется. Попробовали указать не помогло.
Ковыряем дальше схему компоновки во внешнем отчёте. Запрос - простой, палочкой потыкали - не помогло. Пошли бегать по закладкам конструктора СКД. Под подозрение попали вычисляемые поля - там целый клондайк, штук 15, и большинство вычисляются встроенными функциями ЗУПа.
Ага, нужен метод исключения. В каждом подозрительном поле вместо ЗУПовской функции пишем пустую строку. И вуаля, проблемное поле быстро находится - склонённое ФИО, в винительном падеже. Идём в код.
А в коде красота. Не знал, что по склонению столько кода написано. Там примерно три способа, как получается склонённое ФИО:
1. Платформенная функция склонения;
2. Кеш (есть регистр сведений, в котором кешируются склонённые ФИО в пяти падежах);
3. Какой-то внешний сервис, забыл название - то ли Морфий, то ли Морфеус.
Ну, дальше просто. Документ, из которого Т8 печатается, брал склонённое ФИО из кеша. Все остальные не находили сотрудника в кеше, и пытались просклонять платформенной функцией. А она, бедняжка, почему-то слегла. Судя по тому, что она ругалась на файл, это сторонняя компонента, встроенная в платформу. В УПП и ЗУП 2.5 тоже была внешняя компонента, но она прям внешней и была - в виде общего макета, вроде, лежала. Тут она, получается, сохраняется на диск, исполняется, самоудаляется. Ну или файлы какие-то в процессе работы пишет на диск, но тот ей говорит твёрдое "нет".
По коду видно, что платформенное склонение - штука капризная, и разработчики ЗУПа/ЕРП об этом знают. Склонение обёрнуто в попытку/исключение, и в случае ошибки пишется в ЖР с отдельным событием, типа ошибки склонения. Однако, вот эта ошибка с файлом, которая у нас была, в исключение не падает, Попытка не спасает.
Да, а остальные-то документы чё падали? Приёмы на работу и т.д. Тоже несложно - они все иногда отправляют сотрудника кешировать склонённое ФИО. В т.ч. - просто запись сотрудника в справочнике, если диагностируется изменение ФИО (достаточно пробельчик добавить в конце).
Ну, чё делать - говорим клиенту, что надо всё равно почистить серверный кеш и ребутнуть службу сервера 1С. Он вздыхает, вспоминая клиентоориентированность своего облачного провайдера. Идёт писать Заявление.
А мы ставим заплатку - не используем платформенное кеширование склонения. Теперь все некешированные ранее ФИО выводятся в именительном падеже, в печ. формах приходится исправлять вручную. Хорошо, что людей принимают и увольняют не так часто.
