Библиотека по теме "HighLoad оптимизация" для 1С

HighLoad оптимизация Перенос данных 1C

В коде синхронизации стоял комментарий: операция безопасна, если документ уже на месте, она ничего не делает. Комментарий был правдив и обошёлся дороже любой ошибки. Каждую ночь код безусловно дёргал перемещение около 1400 раз, и на каждый вызов принимающая сторона пересчитывала структуру коллекции в 139 килобайт, в том же потоке, которым отвечала на запросы. Формально ноль изменений, фактически плотный поток тяжёлых записей. Внутри: почему проверка живости показывала здоровье, пока запись деградировала до десятков секунд; чем "сервис занят" отличается от "сервис недоступен", если смотреть снаружи; как три повторные попытки чуть не наплодили дублей; и что осталось необъяснённым, включая 688 против 696 в отчёте прогона. Идемпотентность описывает результат. Про цену вызова она не говорит ничего.

HighLoad оптимизация Администрирование СУБД 1С:Предприятие 8 1С:Управление торговлей 10

Практический кейс обновления сервера 1С:Предприятие на базе Ubuntu Linux. Изначально рядовая задача по обновлению платформы (с 8.3.16.1224 на 1814) для исправления парсинга кодов маркировки GS1 DataMatrix (Честный ЗНАК) вылилась в полноценный рефакторинг инфраструктуры. В статье подробно разбираются: - Миграция процессов сервера 1С с 32-битной на 64-битную архитектуру для утилизации 64 ГБ ОЗУ без потери лицензий HASP. - Оптимизация опасных настроек PostgreSQL (снижение work_mem до 64MB и настройка effective_cache_size), провоцировавших OOM Killer. - Элегантное решение проблемы совместимости 64-битного сервера со старыми 32-битными драйверами торгового оборудования АТОЛ. - Бонус: настройка технологического журнала 1С в формате JSON и парсинг логов консольными утилитами jq и awk. Материал поможет избежать подводных камней при администрировании высоконагруженных баз.

HighLoad оптимизация Мониторинг 1С 8.3

Кто потребляет больше всех и что изменилось - два разных вопроса, и деградацию объясняет только ответ на второй. На сервере 1С, который начал грузить процессор, первым под подозрение попал обмен, и ряд запусков за двенадцать суток показал, что запускается он так же, как раньше. Дальше шесть мест, где расследование могло свернуть не туда, от службы печати с почти целым ядром до пустых файлов технологического журнала, и приём, которым нужный сервис кластера нашли без перезапуска агента. Корневая причина в разборе не названа, текст говорит об этом сразу.

HighLoad оптимизация 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:КА 1С:УТ

Крупному пищевому производству продали проект свёртки базы 1С:ERP на 2,5 ТБ: девять месяцев, 2,5 млн рублей, четыре неудачные приёмки. Мы пришли на аудит, сняли технологический журнал — и ни одна из реальных причин нагрузки не оказалась связана с объёмом данных. Первая часть цикла: как ставился диагноз и почему он был неверным.

DevOps и автоматизация разработки Linux HighLoad оптимизация Групповая разработка (Git, хранилище) 1С:Предприятие 8 1С 8.3 1С:Документооборот 1С:ERP Управление предприятием 2 1С:Управление холдингом 1С:Комплексная автоматизация 2.х

Системный анализ архитектурных границ масштабирования учетных систем «1С:Предприятие 8.3» под управлением PostgreSQL в ОС Linux. Формулирование инженерной методологии сквозного проекта «Торговый контур», определение измеримых целевых показателей (p95, MTTR, APDEX) и стратегии поэтапной модернизации эксплуатационного контура без остановки промышленных учетных процессов.

1 стартмани

HighLoad оптимизация Администрирование СУБД Запросы 1С 8.3

Пока непонятно, по каким данным бежит тяжёлый запрос, про индексы думать рано, а в трассировке вместо имён стоят _AccumRgT40229 и _Fld40219RRef. Взяли тестовую УТ 11.5 и попросили у платформы структуру хранения по четырём объектам - вернулось 25 таблиц, потому что у одной "Реализации товаров и услуг" девять табличных частей плюс регистрация изменений. Дальше выяснилось неприятное: для таблицы итогов регистра платформа отдаёт пустые имена всех полей, хотя поля там те же самые, а запросы к остаткам почти всегда идут именно по итогам. Ещё три таблицы из 25 вообще не имеют имени в конфигурации. Разобрали, как читать такие места, почему регистратор занимает два поля и что означают префиксы _AccumRgT, _ChngR и _VT.

HighLoad оптимизация 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х

Менеджеры жалуются на долгий подбор товаров, клиенты ждут на линии, а ИТ-отдел требует бюджет на новый сервер? Разбираем реальный кейс: почему тормозит 1С, как найти узкие места в коде с помощью технологического журнала и как кратно ускорить работу УТ 11 без обновления «железа». Внутри — архитектурный подход к оптимизации и пример решения проблемы перегруженного интерфейса.

HighLoad оптимизация 1С 8.3

Практическое руководство по построению устойчивого DevOps-контура для 1С на Linux: от сборки и CI/CD до эксплуатации кластера под нагрузкой. В статье разобраны ключевые узкие места, которые чаще всего приводят к сбоям: разрыв форматов EDT и Конфигуратора, ложноположительные «успешные» сборки, особенности запуска 1С в Docker, ограничения лицензий ПРОФ/КОРП и рост памяти rphost/rmngr. Показаны инженерные подходы к повышению доступности: многоступенчатая валидация пайплайна, корректная работа с логами и кодировками, мониторинг, safe-ротация процессов, внешняя оркестрация через systemd/скрипты и сценарии реагирования на инциденты. В результате вы получаете набор готовых практик и шаблонов для перехода от ручного администрирования к предсказуемой, отказоустойчивой эксплуатации 1С на Linux.

1 стартмани

HighLoad оптимизация Механизмы платформы 1С

Встроенный язык 1С однопоточный: код в рамках одного сеанса выполняется строго последовательно. Пока «тяжёлая» обработка молотит миллион строк, пользователь смотрит на крутящийся индикатор, а из восьми ядер сервера работает одно. При этом СУБД и оборудование давно готовы к параллельной нагрузке — простаивает именно прикладной код. В статье разберём, что в 1С вообще считать «потоком», какими штатными средствами организуется параллельная обработка, как передавать данные между заданиями и собирать результат, и на какие грабли наступают чаще всего. Примеры даны на управляемых формах и БСП; имена методов и сигнатуры проверяйте под свою версию платформы и библиотеки.

HighLoad оптимизация Администрирование СУБД 1С:Предприятие 8 1С:ERP Управление предприятием 2

В рамках 18 релиза СУБД Tantor Postgres мы рассказывали об оптимизациях, которые помогают планировщику сделать более точный выбор между Nested Loop и Hash Join. В следующем релизе у нас планируются оптимизации, которые позволят ускорить выполнение как Nested Loop, так и Hash Join. Сегодня мы расскажем об одном из таких методов - фильтре Блума.

HighLoad оптимизация Сервера 1С 8.3

Поставил RAS, а кластер отвечает "различаются версии клиента и сервера". Открыл свойства сервера, а поля интервала перезапуска там больше нет. Разбор двух диалогов консоли: что вписывать в каждое поле и от чего это защищает.

HighLoad оптимизация Сервера 1С 8.3

Кластер достался настроенным кем-то другим: rphost растёт, к утру обмены не выполнены, а в консоли десятки значений, и непонятно, норма это или мина. Разбор того, чего стоят дефолты кластера на боевой базе и чем их читать, не открывая консоль.

HighLoad оптимизация Мониторинг 1С 8.3

Код не меняли год, а операция, которая раньше шла секунду, стала идти минуту. Виноват в таком обычно не код, а то, что данные перешли порог: у квадратичного алгоритма удвоение объёма стоит четырёхкратного роста работы, поэтому поломка не подкрадывается постепенно, а наступает сразу. В разборе - случай коллеги, где сервис деградировал месяц. Три объяснения закрыли замером, а развязку дал профиль на 16 642 снимках: 80,0 % процессорного времени в одной функции, которую при этом нельзя было чинить. Разогнали её 20 копий одного документа по 443 581 байту, наплодил их собственный экспортёр сервиса. Дальше - как отличить квадратичный рост от линейного двумя замерами, где такие места прячутся в коде 1С и что делать, если урезать боевую базу вдвое нельзя.

HighLoad оптимизация

Как найти узкие места в 1С по файлу замера PFF: стек и граф вызовов.

1 стартмани

HighLoad оптимизация Администрирование СУБД Архивирование (backup)

Взял секундомер и проверил, сколько на самом деле едет восстановление: 23 ГБ приехали за 19 минут 39 секунд, 3,4 ГБ за 3 минуты. Две независимые базы дали одну и ту же скорость, около 1 ГБ в минуту, и значит терабайтная база едет 15-16 часов - это то число, которое надо называть бизнесу вместо слова "быстро". А дальше выяснилось, что у третьей базы копий нет вообще: скрипт три месяца исправно дампил соседнюю базу, потому что имя брал из переменной со значением по умолчанию. Доказали не совпадением имён, а арифметикой: при базе в 597 МБ и обычном сжатии 11,8 раза дамп должен весить около 50 МБ, а весил 302. Дальше - про откат, который целится в чужой прод, про данные, которые не восстановятся ничем, и про пять проверок, которые делаются за вечер.

HighLoad оптимизация Рефакторинг и качество кода 1С 8.3

Режим снимка(snapshot) убрал почти все дедлоки: с 73 в час до 7-8. Через несколько дней выяснилось, что разделяемые замки раньше сами обеспечивали сериализацию там, где код читал, решал и писал. После включения снимка эта защита пропала. Пришлось пересмотреть код: 234 места с намерением записи, 59 оставили разделяемыми, чтобы не получить взаимные блокировки. Проверка "хватит ли данных" часто стояла выше открытия транзакции - такие места линтер и ревьюер не видят. Дальше - про поддельные блокировки, опасность смены умолчания и шесть проверок.

HighLoad оптимизация Механизмы платформы 1С 1С 8.3

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

HighLoad оптимизация Тестирование QA 1С 8.3

Шесть внешних отчётов на боевой базе крупной сети переписали за неделю. По секундомеру ускорились четыре, в акт пошли три: у одного отчёта минус тринадцать процентов оказались выбросом нагрузки прода, а не эффектом кода. Поймал это чередующийся замер до/после в одном окне, обычные три прогона с метрикой "минимум" показывали ускорение уверенно. Дальше в тексте: почему построчная сверка выхода ломается ровно на тех правках, ради которых её заводят; из чего собирается повторяемый слепок результата и почему главную работу в нём делает нормализация, а хеш только сигнализация; где слепок не берётся вовсе и его заменяет по-колоночная сверка; чем проверять пересчёт итогов, чистку данных и операции с кластером. Отдельно - гипотеза, которую замер отклонил, и честный счёт, во что вся эта дисциплина обходится.

HighLoad оптимизация Мониторинг 1С 8.3

Мониторинг блокировок сам оказался старейшей открытой транзакцией в базе: сеанс спит, блокировок по нему ноль, транзакция висит четверо с половиной суток. Порог в его собственном запросе - пять секунд, свою транзакцию он продержал порядка восьмидесяти тысяч таких порогов и себя ни разу не заметил. Ни в один отчёт "кто кого блокирует" такой сеанс не попадает: никто никого не ждёт. Это четвёртый из четырёх механизмов, разобранных в статье. Остальные три: один текст ошибки на две совершенно разные причины, из-за которого уходят в разбор графов вместо одной правки обработчика; кольцевой буфер диагностики, обнуляемый переключением основного узла; события, записанные под чужим именем базы, из-за чего запрос отдаёт ноль строк там, где данные лежат. По каждому разобрано, как он выглядит, чем отличается от настоящей пустоты и что с ним делать.

HighLoad оптимизация Сервера 1С 8.3

Сводная таблица показывала загрузку диска 97-99 % каждый день, и вывод напрашивался сам: диск упирается в потолок, надо расширять. Среднее по тому же ряду оказалось 4,24 %, а выше 80 % диск был в семи пятиминутных интервалах из 2016 - по одному на каждую ночь недели, это окно резервного копирования. В потолок диск не упирается. Потом тот же метод соврал в обратную сторону: на прореженном до пяти минут ряде исчезли пятнадцатисекундные провалы свободного места до 27 мегабайт. Одна ошибка чтения графиков дала два противоположных ложных вывода из одних данных. Настоящее узкое место сидело в памяти, и находок там две: растущий рабочий процесс сервера приложений и мёртвые сеансы терминального сервера. Разбираю, какие свойства кластера это ограничивают, какие три таймаута проверить, и показываю место, где мой собственный расчёт не сошёлся на три с половиной гигабайта.

HighLoad оптимизация Запросы 1С:Предприятие 8

Практический разбор SQL-трансляции и способа ограничить число неявных соединений. В конкретном тесте: 3,8 с до изменения и 0,5 с после ограничения типа через «ВЫРАЗИТЬ». Структурный результат однозначен: шесть соединений с таблицами документов превратились в одно.

HighLoad оптимизация Мониторинг 1С 8.3

Если в журнале регулярно всплывает deadlock, а пользователь жалуется на документ, которого в отчёте о взаимоблокировке вообще нет, эта статья про то, как искать настоящего виновника. Главный вывод: разбирать один deadlock бесполезно. Один случай не отличить от совпадения, а картину даёт только частота: какие объекты повторяются во всех отчётах сразу. Внутри готовый SQL-запрос, который разворачивает список ресурсов в таблицу частот, и три грабли на нём. Плюс четыре ложных следа, на которые мы потратили часы, и объяснение, почему объект из жалобы виноват не был. Чем закончилось: помогла одна галочка на реквизите, а замер до и после показал разницу на два порядка по логическим чтениям. Есть и раздел про цену этого решения, которую мы не измерили.

HighLoad оптимизация

Задумался, а почему 1С дает рекомендации, как сделать конфигурацию или сервер SQL быстрее, а рекомендаций по оптимизации локальной сети не дает.

Администрирование СУБД HighLoad оптимизация 1С:Предприятие 8

Со временем любая информационная система на базе «1С:Предприятие» начинает работать медленнее. Пользователи жалуются на «зависания» при проведении документов, а формирование стандартных отчетов превращается в ожидание чашки кофе. Часто проблему пытаются решить простым наращиванием серверных мощностей (покупкой нового железа), однако в 80% случаев причина кроется не в нехватке ресурса, а в некорректной эксплуатации СУБД, загрязнении локальных данных и неоптимальном коде. Разберем подробно три ключевых направления, которые позволяют вернуть системе былую скорость.

HighLoad оптимизация Запросы 1С 8.3

Мы ускорили запрос регламентной обработки в 390 раз — с 39 минут до 6 секунд, — не изменив его логику и получив построчно идентичный результат. Разгадка в том, что запрос не был медленным: из 2 353 секунд elapsed чистой работы (CPU) было лишь 124 — остальные 95 % он ждал блокировки, потому что срез последних без отбора читал весь регистр цен следом за массовой записью. Детектив по шагам с цифрами из статистики СУБД, чек-лист «проверь свою обработку за 15 минут» и один твист в финале.

HighLoad оптимизация

Разбираем, как быстро понять, чем занят SQL Server, кто создает блокировки и почему запросы 1С внезапно начинают тормозить. Показываем, какие настройки сервера и базы данных стоит проверять, как анализировать ожидания, планы запросов, статистику и индексы, а также переводить сырые данные SQL на понятный 1С-нику язык. Объясняем, как наладить предметный разговор с DBA и перейти от диагностики к конкретным рекомендациям. В статье также представлена бесплатная обработка для 1С, которая автоматизирует основную часть анализа для MS SQL Server и PostgreSQL и формирует готовые к применению SQL-скрипты.

HighLoad оптимизация 1С:Предприятие 8

В следующей серии статей хочу разобрать ускорение и оптимизацию ключевых операций — тех самых действий, которые пользователи 1С выполняют каждый день и от скорости которых зависит, будут они материться на систему или спокойно работать.

Администрирование веб-серверов Сервера HighLoad оптимизация

Каждый вечер в час закрытия смен 200 касс розничной сети начинали «залипать», и у всех было готовое объяснение: блокировки. Аудит ожиданий в час пика показал: блокировок — ноль. Сессии ждали не друг друга, а свободных потоков: заводские cost threshold for parallelism = 5 и MAXDOP = 0 на 48-ядерном сервере отправляли даже лёгкие запросы разбегаться по всем ядрам, и две трети запросов стояли в очереди за потоками. Разбираем детектив: почему рефлекс «вечером тормозит — значит, блокировки» подменяет диагностику, как читается картина ожиданий, причём тут сосед по инстансу с отчётом на 24 потока и 4,3 часа — и как две динамические настройки без перезапуска сняли проблему в тот же вечер. С чек-листом «блокировки или параллелизм».

HighLoad оптимизация

База 1С розничной сети выросла до 4,2 ТБ: бэкап — два часа, кассиры ждут список чеков по 25 секунд, диски кончаются. Прежде чем что-то чинить, мы две недели строили карту «что сколько занимает» — платформенными средствами, через ПолучитьСтруктуруХраненияБазыДанных(). Диагноз удивил всех: 3,85 ТБ — мёртвый кэш механизма разграничения доступа БСП, копившийся с 2020 года. Разбираем: как ставится такой диагноз, три красивые гипотезы, которые не подтвердились, почему кэш нельзя просто удалить (208 живых ролей), матрица эквивалентности прав на 329 проверок и почему вечерние «блокировки» оказались параллелизмом. Очистка — только штатными средствами; главный герой статьи — диагностика.

HighLoad оптимизация 1С 8.5

Чек-лист по оптимизации производительности 1С 8.5: ОС, PostgreSQL/MS SQL, кластер, индексы, запросы и архитектура. С конкретными параметрами, примерами «до/после» и разбором новых инструментов мониторинга в 8.5.

HighLoad оптимизация 1С 8.3 1С:Зарплата и Управление Персоналом 3.x

Недавно мы успешно завершили масштабное нагрузочное тестирование (НТ) корпоративной информационной системы на базе «1С:Зарплата и управление персоналом 8 КОРП» редакции 3.1. Проведенные испытания подтвердили исключительную стабильность и производительность решения при моделировании работы сверхкрупного предприятия в условиях пиковых нагрузок. Уникальность данного проекта заключается в подтверждении масштабируемости системы 1С:ЗУП КОРП, которая является комплексным решением для автоматизации всех HR-процессов: от подбора и обучения до расчета зарплаты и охраны труда.

Механизмы платформы 1С HighLoad оптимизация 1С 8.3

Исследование нелинейной деградации платформенной записи ODS на больших объёмах данных: почему время записи растёт быстрее размера документа, как на это влияет содержимое ячеек и что происходит внутри файла. Разбор причин и линейные альтернативы — собственный писатель с переносом оформления и прямая потоковая запись. К публикации приложена обработка-бенчмарк для воспроизведения замеров на любой базе.

1 стартмани

HighLoad оптимизация

Разбираем, зачем бизнесу переходить с MS SQL на PostgreSQL и какие риски сдерживают миграцию больших баз 1С. Показываем основные этапы перехода: от предварительного тестирования и конвертации через ibcmd до синхронизации данных с помощью DBReplication и других технологий. Объясняем, как выполнить миграцию с минимальным технологическим окном, сохранить возможность отката при непредвиденных ситуациях и подстраховать бизнес от простоев. Отдельно рассматриваем методику и инструменты обеспечения производительности после перехода.

HighLoad оптимизация 1С 8.3 1С 8.5

Пользователь говорит “1С зависла”, но за этим может быть блокировка, тяжелый запрос, массовая обработка, фоновое задание или доработка после релиза. Разбираю практический маршрут для 1С-разработчика: как не гадать, а сначала понять сценарий, найти признаки ожидания и проверить код, который сам может создавать такие проблемы

HighLoad оптимизация Администрирование СУБД

Если вы работаете с 1С на PostgreSQL и жалуетесь на тормоза — скорее всего, дело в join predicate pushdown, которого в стандартном PostgreSQL нет. В MS SQL Server этот механизм работает «из коробки», и при миграции именно запросы к виртуальным таблицам 1С бьют по производительности сильнее всего. В этой статье — реальный кейс от Postgres Professional с разбором плана выполнения, ручным экспериментом и доработкой планировщика СУБД, которая ускорила запросы от 22 до 54 000 раз.

HighLoad оптимизация Администрирование СУБД 1С:Предприятие 8

Вышел релиз СУБД Tantor Postgres 18, и мы хотим рассказать о его новых возможностях для работы с приложениями на платформе "1С:Предприятие". В обзоре разберем улучшения планировщика, по традиции коснемся работы временных таблиц и не обойдем вниманием вспомогательные утилиты, которые упрощают поиск и диагностику проблем в высоконагруженных системах. За каждым пунктом - реальные запросы 1С, реальные рабочие базы и сотни часов тестирования!

HighLoad оптимизация 1С:Предприятие 8

Фраза “1С тормозит” почти никогда не помогает разработчику найти причину. Медленно может открываться форма, выполняться запрос, записываться документ, работать регламентное задание, строиться отчет или блокироваться пользовательская операция. Разбираем практичный подход к диагностике производительности 1С: как перейти от жалобы к замеру, где искать узкие места и как не лечить систему наугад.

HighLoad оптимизация

Продукт для сбора, обработки и публикации данных из 1С баз данных и внешних источников. Платформа оптимизирована для highload-сценариев: сотни и тысячи баз данных, большие объёмы обмена и near real-time обработка данных. Решение построено на Golang, поддерживает горизонтальное масштабирование и развертывание в Kubernetes и Docker Swarm. Для хранения и аналитической обработки данных используются PostgreSQL и ClickHouse. Самый большой пользователь: 1800+ 1С баз (Бухгалтерия, Зарплата) сбор данных до 700ГБ в день

HighLoad оптимизация

Благодаря возможности подключения в кластер 256 серверов приложений платформу 1С можно масштабировать практически бесконечно. Но в итоге большая система упрется в другие ограничения. Расскажем о подходах и инструментах, которые позволят системе 1С расти, обходя существующие ограничения

HighLoad оптимизация 1С:Предприятие 8

Практическое применение пересчета итогов. Сравнение пересчета итогов из предприятия и пересчета из конфигурации.