1С:Предприятие 8

Как избавиться от гонок при параллельной загрузке данных в 1С без блокировок При миграции 28 тысяч позиций номенклатуры из SAP в 1С:ERP разработчики столкнулись с классической проблемой конкурентного доступа — дублированием элементов справочников. В чём проблема? Несколько фоновых заданий одновременно проверяли существование элемента. Не находили его и создавали каждый свою копию. Попытки решить проблему блокировками дали неожиданные результаты: • Исключительные блокировки — дублей нет, но 85% сообщений завершаются ошибкой из-за таймаутов. • Разделяемые блокировки — ошибок меньше (20%), но появляются дубли. В результате около 250 лишних элементов. • Детерминированный GUID — практически без ошибок блокировок и без дублей. Как решили? Вместо случайного идентификатора стали вычислять GUID из MD5-хеша типа сущности и нормализованного бизнес-ключа. Теперь два параллельных процесса пытаются создать элемент с одинаковым первичным ключом. Один успешно записывает данные, второй получает конфликт уникальности и повторяет обработку сообщения. Что интересно с архитектурной точки зрения: 1. Уникальность обеспечивает сама СУБД, а не распределённая блокировка. 2. Конфликт записи становится штатным сценарием, который обрабатывается через retry. 3. Повтор выполняется на уровне всей транзакции, а не отдельной операции. 4. Идемпотентность позволяет безопасно обрабатывать сообщения повторно. Результат: все 28 тысяч позиций загружены без дублей, параллельная обработка перестала упираться в общие блокировки. В статье также разобраны ограничения подхода: переименование сущностей, коллизии нормализации и работа с ранее созданными элементами. Хороший практический пример того, как детерминированные идентификаторы и ограничения уникальности помогают заменить сложную координацию конкурентных процессов. 📖 Читать статью на Хабре

Отчёт в 1С завис? Возможно, дело вообще не в запросах. Отличная статья с практическими кейсами диагностики 1С. Вместо гадания и перебора гипотез — конкретные инструменты и реальные причины проблем. Что внутри: 948 → 66 секунд. Через rac и технологический журнал нашли SQL-запрос на 240 секунд и конкретную строку кода. Переписали проблемный отчёт. 365 секунд в одной временной таблице. Из 15 шагов пакета 14 выполнялись суммарно за 0,76 секунды. Замер каждого шага помог найти узкое место. 50 минут ложного зависания. Сервер простаивал, а клиент ожидал закрытия невидимого модального окна с ошибкой. Зомби-вызовы. Пользователь закрыл отчёт, но SQL продолжил выполняться на сервере. Повторный запуск только увеличил нагрузку. Зависшее фоновое задание. Открытая транзакция удерживалась более двух суток и мешала обновлению конфигурации. Задание «выполнено», но данные не обновляются. Неправильное расписание, ошибка формирования SQL и перехваченное исключение скрывали проблему. Готовая методика расследования: как с помощью rac, DBMSSQL, SDBL и журнала регистрации быстро сузить круг причин, не тратя часы на изучение непричастного кода. Хороший материал, который стоит сохранить как шпаргалку для разбора инцидентов в 1С.

Сжатие PostgreSQL: меньше данных ≠ выше производительность Обычно эффективность сжатия оценивают по размеру базы. Но экономия диска не гарантирует ускорения запросов. Авторы статьи исследовали компрессию страниц в Tantor Postgres на базах 1С. Что выяснили: • ZSTD лучше сжимает, но требует больше CPU. • LZ4 обеспечивает лучший баланс скорости и сжатия. • На большой таблице объём сократился с 95 до 12 ГБ. LZ4 ускорил холодное чтение почти втрое. • На небольших таблицах распаковка может стоить дороже сэкономленного I/O. • Сжатие страниц переменного размера усложняет запись и может приводить к фрагментации. Архитектурный вывод Оптимизировать нужно не коэффициент сжатия, а стоимость работы с данными: CPU, I/O, write/read amplification. Максимальное сжатие ≠ максимальная производительность. Отдельно интересно решение CSM в Tantor Postgres: сохранять фиксированную адресацию страниц, уменьшая их физический размер. Это компромисс между экономией диска и стоимостью операций чтения и записи. Читать исследование →

Как не отправлять ПДн во внешнюю LLM Практический кейс маскирования персональных данных в пользовательском тексте. Схема: regex + справочники → локальная LLM → токенизация → внешняя LLM Телефоны, email, паспорта и известных людей ловят детерминированно. Склонения, прозвища и живую речь — локальной моделью. Архитектурный паттерн: deterministic preprocessing → local intelligence → external LLM. Подходит для любого AI-gateway, где чувствительные данные нельзя отправлять наружу.

https://youtu.be/2MCcLSZP5Y4?si=lLvijUHKopVdbD4o Говорим о зарплатах Junior, Middle и Senior 1С, переходе из бухгалтерии в разработку, сертификатах 1С, высшем образовании и софт-скиллах. Разбираем автоотклики на hh.ru, сопроводительные письма, технические собеседования, использование ИИ и работу в нескольких компаниях. Отдельно спорим о накрутке опыта: где проходит граница между реальными знаниями и годами в резюме. Смотри, если ищешь первую работу в 1С, готовишься к смене компании или хочешь понять, что мешает росту дохода. Зарплатные цифры и оценки рынка в беседе — опыт и мнения участников, а не гарантированные условия трудоустройства.

Работу техподдержки 1С обычно редко обсуждают, пока все работает в штатном режиме. Но когда случается сбой и выясняется, что время реакции на инцидент слишком большое, возникает ощущение, что проверить это стоило заранее.  К счастью, теперь такую проверку можно провести структурно. K2 Cloud и АСТОН подготовили калькулятор технической поддержки 1С. Ответьте на 10 вопросов о ваших сервисах, процессах и требованиях к доступности. По итогам калькулятор покажет, какой уровень поддержки вам подходит, оценит ее зрелость и даст чек-листы для перехода на новый уровень. Проверить>>

Как 1С на самом деле работает с временными таблицами в PostgreSQL — и почему безобидный FASTTRUNCATE может съедать заметную долю CPU. Разбор внутренней механики, переиспользования временных таблиц и реального кейса оптимизации PostgreSQL под 1С. https://habr.com/ru/companies/tantor/articles/1078088/