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

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

Если сервер 1С после зависания перезагрузили, проверьте, что у вас останется от аварии через неделю: технологический журнал 1С с history=48 живёт двое суток, статистика ожиданий SQL Server обнуляется при каждом запуске службы, журнал ERRORLOG хранит шесть файлов. В разборе, который начался через три недели после сбоя касс, уцелели почти одни события vCenter, и в них нашлись три расширения диска tempdb за 1 час 41 минуту. Разобрал по каждому источнику, почему его не было, что можно утверждать без причины на руках и что я предложил поставить заранее: снимки SQL Server раз в минуту, снимки кластера 1С через RAS со связкой по PID rphost и правило "сначала снимок, потом перезагрузка".

HighLoad оптимизация Инструментарий разработчика Технологический журнал 1С 8.3

Скрипт tj_baseline.py собрал акт замеров из технологического журнала: 7 повторов до и 7 после замены запросов в цикле на «Нано-УТ 2.0». Справка на 150 строк ускорилась с 817,0 до 145,0 мс, проверка доступности с 301,3 до 2,2 мс. При 120 и 300 вызовах в день и ставке 800 руб. выгода 9353 руб. в год по журналу, 4939 руб. по секундомеру без журнала. В архивах скрипт, тесты, журналы опыта, образец приложения к договору и калькулятор.

7 стартмани

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

Расчет сложного многопередельного заказа в 1С:ERP падает с ошибкой «Превышен максимальный расход памяти сервера за один вызов», процесс rphost на сервере Linux сжирает 8 ГБ за 7 минут, а лицензия на сервере - ПРОФ, где тонкие настройки памяти кластера игнорируются платформой. В статье делюсь практическим опытом: как без покупки дорогой лицензии 1С:КОРП и без наращивания планок памяти ускорить тяжелый расчет в 8 раз. Разбираем отказ от копирования таблиц остатков (наложение дельты), кэширование деревьев спецификаций и параллельный запуск через 4 фоновых задания. Примеры кода на встроенном языке 1С, замеры производительности и разбор граблей внутри.

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

Если к HTTP-сервису 1С обращаются сразу несколько программ, сколько запросов в секунду он успеет обработать? Я опубликовала простой HTTP-сервис на нашей "подопытной" конфигурации «Нано-УТ» (файловая база, Apache, без прав администратора) и нагрузила его скриптом на Python. Ответ: около 15-16 запросов в секунду, сколько бы клиентов ни обращалось одновременно. Запросы ждут своей очереди, и при 32 клиентах ответ приходит через 2 секунды вместо 64 мс. Заодно разобрала скрипт из первого варианта статьи: он «проверял» сервер, который отвечал по одному, и считал ошибки вместе с успешными ответами. В архиве исправленный скрипт, учебный сервер, HTTP-сервис для 1С и инструкция по запуску.

1 стартмани

HighLoad оптимизация Администрирование СУБД Технологический журнал 1С 8.3

Проверила на стенде совет «сортируйте строки перед записью»: 1С 8.3.27 на PostgreSQL, учебная «Нано-УТ», 20 потоков и по 2000 документов на каждый способ записи движений. Взаимоблокировки дают построчный захват (99 % ошибок) и повышение разделяемой блокировки до исключительной (95 %, сортировка не помогает); одна блокировка на весь набор работает без сортировки. Плюс механика PostgreSQL, дерево ожиданий через pg_blocking_pids, TDEADLOCK в журнале и единицы порога TLOCK в logcfg.xml. В архиве стенд, выгрузка конфигурации и журналы прогона.

5 стартмани

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

После миграции с MS SQL на PostgreSQL закрытие месяца в 1С:ERP стало идти 8 часов вместо 12 минут. Рассказываем, как мы нашли причину в оценке Hash Join, которую планировщик завышал в миллионы раз, и как исправили её так, что проблемный запрос теперь выполняется за 18 секунд вместо часа.

HighLoad оптимизация Технологический журнал Сервера Запросы 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0

Составной отчет формировался 15 минут. Вместо перебора разделов одна команда rac показала, что сеанс занят запросом к СУБД, а временный техжурнал с порогом 20 секунд за один прогон назвал виновника: один SQL на 240 секунд и точную строку модуля. В статье четыре разные картины «висит» и как их различить: идет запрос в СУБД, клиент ждет невидимое модальное окно, зомби-вызов после закрытого клиента, зависшее фоновое задание. Пример logcfg.xml, разбор события DBMSSQL с полем Context, замер пакета запросов по временным таблицам, регламентное задание, которое «выполнено», а данные стоят, и шпаргалка по диагностике.

HighLoad оптимизация Инструменты администратора БД 1С 8.3

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

HighLoad оптимизация Разработка внешних компонент 1С 8.3

Медленное место хочется переписать на C++ внешней компонентой. Проверьте у себя, с каким параметром подключения она работает: на 8.3.27 без четвёртого параметра компонента изолирована, и пустой вызов стоит 123 мкс вместо 4. Замер 31 задачи против лучшего кода 1С с проверкой одинаковости результата: где компонента выигрывает в десятки и сотни раз, где только в процессе 1С и где проигрывает, потому что время съедает сборка структур и таблиц из ответа.

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

Финал разбора проекта 1С:ERP: как догрузка свёрнутой копии роняла сервер восемнадцать раз за воскресенье, почему повисли полторы тысячи кодов маркировки, как подчёркивание в коде замедлило печать до нескольких кодов в минуту, зачем на каждую строку создавалась своя транспортная операция — и честная таблица «было / стало».

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

Кейс адаптации PostgreSQL (Platform V Pangolin) под 1С:Предприятие 8.3: флаг optimize_for_1c, роль без superuser, postgresql.conf и нагрузочный прогон с ~2400 одновременными сессиями. Разберём стенд, метрики тест-центра, диагностику от pg_profile до flame graph и первый симптом конкуренции за блокировки на 1С:Управление холдингом.

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

Третья часть разбора проекта 1С:ERP на 2,5 ТБ — живые бои на площадке: сервер, падавший по памяти, документ, который ждал сам себя, галочка, из-за которой система думала 26 минут, воскресный призрак в статистике и 300 гигабайт файлов внутри базы.

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

Параллельная обработка данных в фоновом задании, универсальная процедура.

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

Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны — какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.

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

Вторая часть разбора проекта свёртки базы 1С:ERP на 2,5 ТБ. Что на самом деле нагружало сервер: ЭДО, которое раз за разом подписывало уже подписанное, ночное обслуживание, не доходившее до конца очереди, 45 ГБ регистрации изменений для брошенных обменов — и расширение свёртки, на которое уходило около 45 часов процессорного времени в сутки.

HighLoad оптимизация Инструменты администратора БД 1С 8.3

Найдите сеанс, занявший память rphost, и выведите процесс из работы тремя шагами через rac, не обрывая остальные сеансы. Прогнано на платформе 8.3.27.2130 (Windows) с серверной базой и фоновыми заданиями: в статье реальный вывод rac, замеры памяти и запись технологического журнала. Утилита на Python и скрипты в архиве. Linux не проверялся.

1 стартмани

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

Разбор медленного запроса 1С на PostgreSQL 16: pg_stat_statements, отчет pg_profile за окно инцидента и postgresql.conf под OLTP. Установка, диагностика и отчеты из архива прогнаны на PostgreSQL 16.15 с pg_profile 4.16: сервер стартует с готовым конфигом, снимок создается, отчет сохраняется. Цифры кейса «Торговый контур» взяты с контура автора и на стенде не воспроизводились.

1 стартмани

HighLoad оптимизация 1С 8.3 1С:Управление торговлей 11

Разобран частный случай одной транзакции записи документа «Перераспределение зон отбора», где два последовательных запроса к регистрам накопления «СвободноВЗонахОтбора» и «РезервПодКлиента» дают согласованную пару чисел только при явном уровне изоляции и фиксированном порядке захвата. Приведена пошаговая трассировка на сервере 1С для двух параллельных сессий, таблица режимов изоляции и границы применимости подхода. Материал для разработчиков и администраторов, которые настраивают учёт складских зон под пиковую нагрузку.

HighLoad оптимизация Закрытие периода 1С 8.3 1С:Бухгалтерия 3.0

В базе «1С:Бухгалтерии предприятия КОРП 3.0» перепроведение 40 тысяч документов при закрытии месяца занимало больше трёх часов. По журналу регистрации, технологическому журналу и статистике PostgreSQL нашли основной источник задержки — запрос остатков при проведении поступлений по эквайрингу. В статье разобраны два расширения: первое исключает запрос остатков там, где он не влияет на суммы проводок, второе сокращает число повторно проводимых документов. На проверенном месяце время перепроведения снизилось с 3 ч 06 мин до 1 ч 33 мин. Приведены условия применения, методика замеров и результаты сверки движений: суммы по счетам и субконто после свёртки совпали, у отдельных документов изменилось количество строк проводок.

7 стартмани

HighLoad оптимизация Технологический журнал 1С:Предприятие 8

В этой статье рассматривается только первый этап диагностики производительности: как получить длительный SQL-запрос из технологического журнала, связать его с прикладным кодом 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 ТБ: девять месяцев. Мы пришли на аудит, сняли технологический журнал — и ни одна из реальных причин нагрузки не оказалась связана с объёмом данных. Первая часть цикла: как ставился диагноз и почему он был неверным.

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.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 с после ограничения типа через «ВЫРАЗИТЬ». Структурный результат однозначен: шесть соединений с таблицами документов превратились в одно.