Приветствую вас, коллеги!
Сегодня про то, о чем почти не пишут, потому что для этого надо разбираться в двух вещах одновременно.
Ситуация знакомая: компания внедрила маркировку, все настроили, все работает - и через пару месяцев пользователи начинают жаловаться, что программа стала заметно медленнее. Раньше летала, теперь тормозит.
Дальше обычно происходит одно из двух. Либо зовут программиста, и он копается в обработках. Либо зовут админа, и он предлагает купить сервер помощнее. И довольно часто ни то ни другое не помогает, потому что причина лежит ровно посередине между этими двумя специальностями.
Разбираемся, что там на самом деле происходит))
Почему об этом почти никто не пишет
Потому что тема пограничная.
Специалисты по маркировке знают про коды, ГИС МТ и УПД, но не лезут в производительность серверов. Админы настраивают железо, но не понимают, что именно делает 1С, когда вводит партию в оборот.
А проблема живет ровно на стыке. И пока эти двое не поговорят друг с другом, клиент платит обоим и остается с тем же самым.
Я занимаюсь и тем и другим - настраиваю маркировку и держу серверы, - поэтому попробую свести картину воедино.
Что изменилось в вашей базе на самом деле
Вот главное, что надо понять. И это не про настройки, а про сам характер учета.
До маркировки вы вели номенклатурный учет. У вас была позиция "Колбаса докторская" и количество - двести штук. Одна строка в документе, одна запись в регистре. Двести штук или две тысячи - разницы для базы почти никакой.
После маркировки вы ведете поштучный учет. Каждая упаковка - это отдельный уникальный код, отдельная сущность со своей историей: заказан, нанесен, введен в оборот, отгружен, продан. Двести штук - это двести записей. И каждая живет своей жизнью.
Разница в объеме данных - на несколько порядков.
Посчитаем на пальцах. Небольшое производство, тысяча упаковок в день. Это тридцать тысяч кодов в месяц и триста шестьдесят тысяч записей за год. И это только сами коды, без документов, движений и истории статусов, которые к ним прицепляются.
Розница с хорошим оборотом набирает столько же за пару месяцев.
То есть после маркировки ваша база растет принципиально быстрее, чем росла раньше. Не на проценты - в разы. И то железо, которое год назад было с запасом, внезапно оказывается впритык.
Вот это и есть корень истории.
Пять источников тормозов
Теперь конкретно, откуда берется медленно. Источников пять, и лечатся они по-разному - вот почему универсального ответа нет.
Первый: объем данных. Про него выше. База выросла, запросы к большим таблицам стали дольше, отчеты строятся медленнее. Это классическая нагрузка, и она честно лечится железом и обслуживанием.
Второй, и самый недооцененный: обращения к ГИС МТ поштучно. Вот это место, где ломаются ожидания.
Штатный механизм при работе с партией отправляет отдельный запрос на каждый код маркировки. Не один запрос на партию - на каждый код.
Что это значит на практике. Партия в три тысячи единиц - это три тысячи последовательных обращений к внешнему сервису. Даже если каждое занимает полсекунды, это уже почти полчаса. А реальные задержки внешнего API бывают больше, и на объемах в десять-двадцать тысяч единиц операция растягивается на часы. Бывает, что и на сутки.
И все это время программа честно ждет ответа. Пользователь видит "Не отвечает" и идет пить чай.
Третий: фоновые задания и обмены. Вместе с маркировкой в базу приехал целый набор новых регулярных операций: обмен с ГИС МТ, обмен по ЭДО, обмен с кассами. Они работают в фоне и конкурируют за те же ресурсы, что и пользователи.
Хуже того, они умеют зависать - когда внешний сервис не отвечает, а таймаут ожидания не настроен. Задание висит, держит ресурсы, следующее запускается поверх него, и через несколько часов у вас очередь из мертвых заданий.
Четвертый: проверка кодов на кассе. Касса с ФФД 1.2 проверяет код маркировки при пробитии. Это плюс несколько секунд на каждую маркированную позицию в чеке. Для покупателя с одной пачкой незаметно. Для очереди в час пик - очень даже заметно.
И вот здесь есть готовый ответ, который на удивление часто не используют, - локальный модуль "Честный знак". Он проверяет коды на месте, не дожидаясь ответа из интернета, и с 1 марта 2025 года обязателен для большинства товарных групп: табак, пиво, молочная продукция, вода, БАД, антисептики, парфюмерия, обувь, одежда, шины. Поддержка есть в 1С:ERP 2.5, Комплексной автоматизации 2.5 и Управлении торговлей 11.5 - программа сначала пробует проверить онлайн и уходит к локальному модулю, когда связи нет. Если касса задумывается на каждой позиции, первым делом стоит выяснить, установлен ли он вообще.
Пятый: блокировки на больших документах. Документ с десятью тысячами строк проводится долго и все это время держит блокировки. Остальные пользователи в этот момент ждут. Формально все работает - фактически контора стоит.
Главный вопрос диагностики
Вот вопрос, который надо задать до всего остального. Он делит все случаи на две категории и экономит огромное количество денег.
Тормозит вообще все - или только операции с маркировкой?
Ответ определяет, кого звать и что покупать.
Если медленно только там, где работа с кодами - ввод в оборот, проверка партии, обмен с ГИС МТ, - а обычные операции летают как раньше, то сервер тут ни при чем. Вы упираетесь во внешний сервис и в то, как программа с ним разговаривает. Новое железо не ускорит чужой API ни на секунду.
Если тормозит вообще все - открытие форм, обычные отчеты, проведение немаркированных документов, - то дело в выросшей базе и в железе, которое перестало справляться. Вот тут сервер уже в теме.
Звучит просто. А на практике половина обращений, которые я вижу, - это первый случай, в котором человеку уже успели предложить купить сервер.
Проверяется за пять минут: откройте любой обычный отчет, не связанный с маркировкой, и засеките время. Сравните с тем, как было раньше. Если разницы нет - железо в порядке, ищите в другом месте.
Если тормозит только работа с кодами
Разберу этот случай первым, потому что он самый частый и самый дешевый в лечении.
Что помогает:
Дробить партии. Если операция на десять тысяч кодов не проходит, а на две тысячи проходит - работайте партиями по две тысячи. Некрасиво, зато работает сегодня и бесплатно.
Проверить актуальность релиза. Механизмы работы с маркировкой активно дорабатываются, и в свежих версиях многое ускорено. Если конфигурация не обновлялась год - обновление может решить вопрос само по себе. Это первое, что надо проверить, а не последнее.
Перенести тяжелые операции на нерабочее время. Ввод в оборот большой партии в три часа дня - это гарантированный простой конторы. В восемь вечера тот же объем никому не мешает.
Настроить таймауты. Чтобы зависшее обращение к внешнему сервису не висело вечно, а отваливалось с ошибкой и повторялось.
Разнести обмены по времени. Чтобы обмен с ГИС МТ, ЭДО и кассами не стартовали одновременно и не дрались за ресурсы.
Проверить локальный модуль на кассах. Если тормозит именно касса, скорее всего проверка кодов идет онлайн там, где должна идти локально. Заодно это и требование, а не только скорость.
Проверить канал в интернет. Раз уж вся работа теперь идет через внешние сервисы, качество и стабильность канала стали такой же частью производительности, как диск и память. Раньше это было неочевидно, теперь критично.
Типичная картина, которую я вижу: человек уже согласовал бюджет на новый сервер, а после разбора выясняется, что ввод в оборот делается одной гигантской партией в разгар рабочего дня, релиз годовалой давности, и все обмены запускаются в один и тот же момент. Перенастройка занимает день. Сервер не понадобился вообще.
Если тормозит вообще все
Здесь уже честная нагрузка, и лечится она по-настоящему.
Сначала убедитесь, что дело не в бесплатных причинах - про них я писал отдельно, и после маркировки они никуда не делись:
- исключения антивируса для каталогов базы и рабочих файлов 1С;
- регламентные задания, которые запускаются в рабочее время;
- кеш 1С, который давно не чистили;
- сеть, если база файловая.
И отдельно - размер базы. Здесь важно понимать, где именно стена, потому что общепринятая формулировка про пять гигабайт неточна.
Ограничен не файл базы целиком, а каждая внутренняя таблица внутри него: четыре гигабайта, а с формата 8.3.8 - шесть. База на двадцать гигабайт с мелкими таблицами живет и работает. База на три гигабайта встает намертво, если журнал регистрации или один регистр накопления уперся в потолок.
Поэтому общий размер файла - это сигнал, а не диагноз. Перевалило за пять гигабайт - пора смотреть размеры таблиц, а не сразу закладывать бюджет на лицензию. А вот когда конкретная таблица подошла к пределу - это уже приговор формату: никакие настройки не помогут, только переход на клиент-серверный вариант.
И маркировка бьет сюда особенно точно. Она наливает данные не размазанно по базе, а в несколько конкретных таблиц - и упирается обычно одна из них, пока общий размер выглядит еще прилично.
Кстати, маркировка - самая частая причина, по которой компании этот переход и делают. База, которая годами росла спокойно, после внедрения поштучного учета упирается в потолок за несколько месяцев.
Что реально помогает по железу
Если по итогам диагностики железо действительно надо - вот в каком порядке.
Первое и главное: диск. Не процессор. Маркировка - это в первую очередь много записи: коды, движения, история статусов, журнал регистрации. Если база живет на обычном SATA-диске, переезд на NVMe даст разницу, которую видно сразу. Это самое выгодное вложение из всех возможных, и я повторяю это в каждой статье, потому что это правда.
Второе: память. База выросла, рабочий набор данных вырос, кеш СУБД должен быть больше. Если система уходит в файл подкачки - добавляйте.
Третье: разнести нагрузку. База, бэкапы и файловое хранилище на одном физическом диске - обычное дело в маленьких инсталляциях и обычная причина тормозов, когда объемы выросли.
Процессор - в последнюю очередь. Он упирается редко.
И честно: если вы покупаете сервер, покупайте с запасом кратно, а не на двадцать процентов. База после маркировки растет быстрее, чем вы привыкли. Железо, взятое впритык по сегодняшним цифрам, станет тесным через год. Считать надо на три года вперед, а не на текущий момент.
Что делать с обменами и фоновыми заданиями
Отдельный раздел, потому что тут больше всего быстрых побед.
Посмотрите, что у вас вообще запускается. Открываете список регламентных заданий и смотрите честно. Регулярно нахожу включенными обмены, которые не используются вообще - остались от старых интеграций или от типовой поставки. Они исправно работают и исправно едят ресурсы.
Разнесите расписание. Обмен с ГИС МТ, ЭДО, кассами, банком - все в разное время. Не в 12:00 одновременно.
Настройте контроль зависаний. Чтобы вы узнавали о повисшем задании сразу, а не через три дня, когда накопится очередь.
Отследите долгие задания. В журнале регистрации видно, какое задание сколько выполняется. Если одно из них стабильно висит по полчаса - вот с него и начинайте.
Обслуживание, которого у вас раньше не было
Неприятная новость для тех, кто привык, что база живет сама.
После маркировки объемы растут так, что регулярное обслуживание становится обязательным. Раньше можно было годами ничего не делать и не замечать разницы. Теперь нельзя.
Что должно быть в регламенте:
- обновление статистики и реиндексация - на выросших таблицах это дает заметный эффект;
- контроль размера базы - не раз в год, а регулярно, чтобы видеть динамику и успеть подготовиться;
- бэкапы с проверкой - объем вырос, время на копию выросло, старая схема может уже не укладываться в окно;
- контроль свободного места - вот это отдельно. База растет быстрее, чем раньше, и место кончается раньше, чем вы ожидаете. А 1С на сервере без свободного места не тормозит - она встает;
- мониторинг очереди обменов - чтобы видеть, что все ушло, а не копится.
Скучно. Но именно это отличает базу, которая через год работает так же, от базы, которую через год приходится спасать.
Чек-лист на полчаса
Если хотите разобраться сами - вот порядок.
Минуты 1-5. Откройте обычный отчет без маркировки. Тормозит? Если нет - проблема только в маркировке, переходите к пункту про партии и обмены. Если да - идите дальше по списку.
Минуты 5-10. Посмотрите размер базы и сравните с тем, что было до маркировки. Если файловая перевалила за пять гигабайт - смотрите размеры внутренних таблиц, а не только файла: упирается каждая таблица по отдельности. Подошла к четырем гигабайтам, а на формате 8.3.8 к шести - вопрос закрыт, нужен переход на клиент-серверную.
Минуты 10-15. Диспетчер задач на сервере в момент тормозов. Смотрите на диск, а не на процессор. Активность 100 процентов и растущая очередь - нашли.
Минуты 15-20. Список регламентных заданий. Что включено, что реально нужно, когда запускается. Все ли в нерабочее время.
Минуты 20-25. Журнал регистрации: долгие задания и ошибки обменов за последнюю неделю.
Минуты 25-30. Релиз конфигурации. Когда обновлялись последний раз? Если больше полугода назад - половина вопросов может решиться обновлением.
Если разбираться некогда
Как вы помните, я айти-специалист: настраиваю маркировку в 1С и держу серверы. Именно сочетание этих двух вещей и позволяет разобраться в таком случае за раз, а не гонять клиента между программистом и админом.
Чем помогаем:
- проводим диагностику и говорим прямо, в чем причина: внешний сервис, настройки, база или железо. И говорим "сервер не нужен", когда он не нужен;
- чиним то, что чинится бесплатно - расписания обменов, таймауты, лишние задания, размер партий;
- обновляем конфигурацию до актуального релиза, где механизмы маркировки уже ускорены;
- переводим на клиент-серверный вариант, если файловая база уперлась в потолок;
- подбираем и разворачиваем сервер с запасом на рост, если он действительно нужен;
- настраиваем регламент обслуживания и мониторинг, чтобы через год не пришлось повторять;
- сдаем в аренду серверы с поддержкой, где все это уже работает без вашего участия.
Подробнее про обслуживание: 1c.akernel.ru/services/it-podderzhka
Группа по 1С: https://t.me/russia1c_corp
Напишите, что именно у вас тормозит - все подряд или только операции с кодами. По одному этому ответу уже можно сказать, надо ли вам вообще тратить деньги на железо. Бесплатно)
Читайте также: 1С тормозит: диагностика за 30 минут, Какой сервер нужен под 1С и Маркировка колбасы с 1 октября.
Комментарии
Комментариев пока нет. Будьте первым!