Что делать, если импорт товаров на «1С-Битрикс» зависает

Разбираем, почему обмен с 1С встаёт на середине и как довести его до конца

В чём проблема и кому полезна статья

Обмен товаров между 1С и «1С-Битрикс» проходит несколько этапов: сайт получает данные, разбирает каталог, обновляет товары, цены и остатки. Реальная последовательность и способ запуска зависят от версии модуля и настроек. Если обмен остановился, зафиксируйте последний успешный этап и ответ сервера, а затем проверяйте журналы 1С, веб-сервера и Битрикса. Один только тайм-аут не объясняет, какие товары успели обновиться.

Статья полезна тем, кто администрирует интернет-магазин на «1С-Битрикс: Управление сайтом», настраивает или поддерживает обмен CommerceML2 с 1С, и тем, кто получил задачу «обмен встал — разберитесь» без готового доступа к логам сервера.

Как устроен обмен и почему он вообще может зависать

Обмен товарами между 1С и «1С-Битрикс» работает по протоколу CommerceML2 поверх HTTP: 1С всегда выступает клиентом-инициатором, точка входа на сайте — файл /bitrix/admin/1c_exchange.php [4][5]. Последовательность запросов такая: checkauth (проверка логина/пароля), init (определение версии протокола и параметров шага), file (постепенная передача файла обмена частями), import (собственно обработка данных на сайте) [4][5].

Важный нюанс: запрос import физически один и тот же URL, но внутри он выполняет до 11 разных операций, о которых 1С ничего не знает — какая именно операция выполняется сейчас, Битрикс хранит в переменной сессии $_SESSION['BX_CML2_IMPORT']['NS'], в частности в узле STEP [1][6]. Пока файл читается, парсится и раскладывается во временную таблицу b_xml_tree, которая затем индексируется для ускорения дальнейшей обработки [1][6].

Из этой архитектуры вытекают три типовых источника зависаний:

• шаг физически не укладывается в тайм-аут — PHP убивает процесс по max_execution_time, а 1С в это время просто ждёт ответа и не понимает, что скрипт уже остановлен на сервере [7][2];
• шаг не укладывается в лимит памяти — при большом количестве свойств и элементов PHP выбрасывает Fatal error: Allowed memory size ... exhausted [3];
• шаг зависает логически — например, из-за собственных обработчиков событий каталога, тяжёлого пересчёта после каждого товара, либо из-за расхождения версий модуля обмена после обновления платформы [3][8].

Российская специфика: где смотреть и что проверять на практике

Специфики законодательства здесь немного — это чисто техническая интеграция, но есть особенности инфраструктуры, характерные именно для проектов на «1С-Битрикс» и «1С:Предприятие» в России.

Логи обмена смотрите в двух местах. На стороне сайта — «Магазин → Настройки → Интеграция с 1С», там же задаются параметры шага [9][10]. Если стандартных логов не хватает, включите режим отладки: в файле bitrix/php_interface/dbconn.php (или dbconn_before.php) добавьте константу define("BX_CATALOG_IMPORT_1C_PRESERVE", true) — тогда файлы последнего обмена не будут удаляться из папки /upload/1c_catalog/, и их можно будет изучить после сбоя [3].

Проверьте расхождение времени между серверами. Если время на сервере БД и на веб-сервере (или между сервером сайта и сервером 1С) отличается больше чем на 10 минут, обмен блокируется целиком — это частая причина внезапного «зависания» после миграции на новый хостинг или после смены таймзоны в конфигурации PHP/MySQL [11].

Проверьте версии модуля обмена. Обновление платформы «1С-Битрикс» иногда меняет файл cml2.php и логику обмена: то, что раньше укладывалось в тайм-аут, после обновления может начать выполняться на порядок дольше [2]. Здесь стоит свериться с таблицей соответствия версий модуля обмена и конфигурации 1С на официальной странице загрузки [3].

Проверьте временную папку на сервере 1С. Известен случай, когда обмен переставал идти из-за того, что каталог /tmp на linux-сервере с 1С заполнялся сотнями тысяч файлов v8*.tmp — обмен восстанавливался только после перезагрузки сервера 1С [12]. Это тоже стоит проверить, если зависание происходит на стороне 1С, а не сайта.

Практические шаги: как найти и снять зависание

Шаг 1. Зафиксируйте, на каком именно шаге встаёт обмен

Включите режим отладки (BX_CATALOG_IMPORT_1C_PRESERVE) и посмотрите протокол обмена в логах 1С или в файлах папки /upload/1c_catalog/. Типичная картина зависания выглядит так: «Шаг 5: Метаданные импортированы успешно. Шаг 6: Группы импортированы. Шаг 7: …» — и дальше тишина до ошибки по тайм-ауту [13]. Важно понять, зависает ли конкретный шаг стабильно или в разное время — это подскажет, тайм-аут это или логическая ошибка.

Шаг 2. Проверьте и увеличьте max_execution_time и memory_limit

Это первое, что стоит сделать при ошибках вида «Failed sending data to the peer», «Получен пустой ответ сервера» или явном Fatal error: Maximum execution time … exceeded [3][7]. Особенность именно «1С-Битрикс»: значение может задаваться не только в php.ini, но и переопределяться в bitrix/php_interface/dbconn.php вызовом set_time_limit(), и именно это значение реально влияет на шаги импорта из 1С — стандартный phpinfo() может показывать одно число, а фактический лимит для обменных скриптов будет другим [14]. Также нужно синхронно увеличить memory_limit — 512 МБ часто называют разумным стартовым значением для крупных каталогов [3].

Отдельно проверьте тайм-ауты веб-сервера и балансировщика (fastcgi_read_timeout в nginx, ProxyTimeout в Apache) — PHP может быть готов работать дольше, но соединение оборвёт именно веб-сервер с ошибкой 502/504 [15][2].

Шаг 3. Синхронизируйте тайм-аут PHP и «Интервал одного шага» в настройках Битрикс

В форме «Магазин → Настройки → Интеграция с 1С» на вкладке «Каталог» задаётся интервал одного шага обмена в секундах и размер единовременно передаваемой части файла [9][10]. Если это значение больше, чем реальный max_execution_time, обмен будет систематически падать на длинных шагах. Если поднять max_execution_time не получается (ограничения хостинга), альтернативный путь — уменьшить интервал шага и размер порции данных, тем самым разбив тяжёлую операцию на больше мелких запросов [3].

Шаг 4. Уменьшите объём данных за одну итерацию

Если проблема не в тайм-ауте, а в памяти или в тяжёлой логике на конкретных элементах, полезно протестировать обмен на уменьшающихся объёмах: сначала 1 товар, затем 100, 1000, 10000 — чтобы понять, при каком объёме конкретно начинаются проблемы [3]. Это быстрее, чем гадать, и сразу показывает, упирается ли дело в объём данных или в конкретный «плохой» элемент каталога.

Шаг 5. Временно отключите обработчики событий каталога

Часто на проекте есть собственные обработчики событий (OnBeforeIBlockElementUpdate, пересчёт цен, синхронизация с внешними сервисами и т. п.), которые срабатывают на каждый импортируемый товар и заметно замедляют обмен. Стоит временно закомментировать их в bitrix/php_interface/init.php и повторить обмен — если он проходит быстрее, проблема локализована, и обработчики нужно оптимизировать или перенести на постобработку через штатное событие catalog:OnCompleteCatalogImport1C, которое вызывается уже после завершения основного импорта и даёт доступ к данным во временной таблице b_xml_tree [3][16].

Шаг 6. Проверьте права доступа, место на диске и работу ZIP

Ошибки «Ошибка открытия файла» и «Ошибка записи файла» обычно связаны либо с нехваткой места на диске, либо с правами на папку обмена, либо с проблемами модуля zip на сервере — его наличие можно проверить через phpinfo() [3]. Отдельно стоит свериться, что кодировка базы и временных таблиц (b_xml_tree) совпадают — известная ошибка Illegal mix of collations возникает, когда база в одной кодировке, а новые таблицы создаются в другой [3].

Шаг 7. Проверьте синхронизацию времени и авторизацию

Если обмен не просто «зависает», а обрывается с ошибками авторизации или соединения — проверьте, не блокирует ли антивирус или файрвол на сервере 1С исходящие соединения к сайту, и совпадает ли время на серверах с разницей менее 10 минут [11][17].

Шаг 8. Если стандартный обмен исчерпал себя — переходите на асинхронную обработку

Для по-настоящему больших каталогов (десятки и сотни тысяч товаров) штатный синхронный обмен через 1c_exchange.php рано или поздно упирается в архитектурный предел: даже корректно настроенный тайм-аут не спасает, если один шаг объективно требует пересчёта сотен тысяч записей. В этом случае имеет смысл выносить тяжёлую обработку импортированных данных в фоновые агенты (CAgent) или очереди, обрабатывая данные порциями по cron уже после того, как 1С получила success, — такой подход описан, в частности, для события OnCompleteCatalogImport1C [16].

Ограничения, ошибки и риски

• Не увеличивайте тайм-ауты бесконтрольно. Если реальная причина — зависший в цикле PHP-процесс или тормозящий SQL-запрос, увеличение max_execution_time только отсрочит ошибку, а не устранит её [2].
• Не путайте «зависание» с логическим отказом обмена. Сообщение «Изменения товаров не зарегистрированы» — это не сбой, а следствие настройки «Выгружать только измененные объекты с момента последнего обмена», когда в 1С действительно ничего не изменилось [3].
• Осторожно с кастомизацией модуля обмена. Правки файлов catalog.import.1c, cml2.php и подобных без резервной копии и понимания протокола обмена — частая причина, по которой обмен «вдруг» перестаёт работать после обновления платформы [8][2].
• Разница версий модуля обмена и конфигурации 1С — ещё один источник трудноуловимых зависаний, особенно после обновления любой из систем [3].
• Если после проверки логов, тайм-аутов, памяти и обработчиков событий обмен всё равно нестабилен, вероятная причина — в объёме данных, который штатный синхронный протокол уже не тянет на данной инфраструктуре, и здесь потребуется пересмотр архитектуры обмена, а не очередная точечная настройка.

Когда достаточно настройки, а когда нужна разработка

В большинстве случаев зависание обмена — это вопрос корректных настроек PHP, веб-сервера и модуля обмена, и решается без программирования: правкой php.ini/dbconn.php, синхронизацией времени, уменьшением размера порции данных. Разработка или интеграция нужна, когда:

• каталог настолько велик, что синхронный протокол CommerceML2 объективно не укладывается в разумные тайм-ауты даже после оптимизации настроек;
• на проекте много собственной логики (пересчёт цен, синхронизация с маркетплейсами, ERP), которая должна выполняться отдельно от самого факта импорта;
• нужно перейти на асинхронную обработку через очереди или REST API вместо штатного файлового обмена.

Команда «Пятого фактора» может изучить текущую схему обмена, найти узкое место в логах и настройках и помочь с доработкой или переходом на более устойчивую архитектуру интеграции, если типовых настроек уже недостаточно.

Вывод

Зависший импорт товаров почти всегда объясняется одной из типовых причин: не хватает времени или памяти PHP, размер шага обмена не согласован с реальными возможностями сервера, разошлось время между серверами, либо мешают собственные обработчики или устаревшая версия модуля обмена. Прежде чем что-то менять — включите логирование обмена и найдите шаг, на котором он встаёт: это сразу отсекает половину гипотез и экономит часы отладки. Если после проверки всех типовых причин обмен всё равно нестабилен, скорее всего дело в объёме данных, и стандартный синхронный обмен пора дополнять асинхронной обработкой.

Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.

Источники

[1] intervolga.ru — Советы программисту про интеграцию сайта и 1С — https://www.intervolga.ru/blog/1C/chto-nuzhno-znat-programmistu-pro-integratsiyu-sayta-i-1s/

[2] medium.com — Битрикс. Что делать, если выгрузка из 1С стала зависать и падать по таймауту? — https://medium.com/@dermanov.mark/bitrix-what-to-do-if-1c-integration-crashes-by-timeout-561fa7e13dac

[3] intervolga.ru — Типовые ошибки интеграции между 1С и 1С-Битрикс — https://www.intervolga.ru/blog/support/tipovye-oshibki-integratsii-mezhdu-1s-i-1s-bitriks/

[4] hmarketing.ru — Отладка интеграции между Битрикс и 1С — https://hmarketing.ru/blog/bitrix/otladka-integratsii/

[5] wiseadvice-it.ru — Интеграция 1С-Битрикс и 1С — настройка обмена — https://wiseadvice-it.ru/o-kompanii/blog/articles/obmen-1s-i-bitrix/

[6] itsale.ru — Интеграция сайта на CMS Bitrix с 1С. Обмен товарами — https://itsale.ru/info/articles/interatsiya-1s-i-veb-prilozheniy/integratsiya-sayta-na-cms-bitrix-s-1s-obmen-tovarami/

[7] 1vps.org — Увеличение времени выполнения PHP скрипта — https://1vps.org/faq/uvelicenie-vremeni-vypolnenia-php-skripta

[8] dev.1c-bitrix.ru — Изменения протокола обмена между 1С-Битрикс и 1С Предприятие — https://dev.1c-bitrix.ru/community/webdev/user/30123/blog/11416/?commentId=59243

[9] dev.1c-bitrix.ru — Форма «Интеграция с 1С» (учебный курс) — https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=131&LESSON_ID=3392

[10] dev.1c-bitrix.ru — Интеграция с 1С (справка) — https://dev.1c-bitrix.ru/user_help/store/sale/settings/1c_admin.php

[11] blog.nikovit.ru — Битрикс. Время на сервере базы данных отличается — https://blog.nikovit.ru/bitrix-cms/bitriks-vremya-na-servere-bazy-dannykh-otlichaetsya-ot-vremeni-na-vebs/

[12] qna.habr.com — Что за ошибки при обмене 1С и Битрикс? — https://qna.habr.com/q/1402506

[13] 1c.1c-bitrix.ru — Зависает при затяжке import.xml (форум) — https://1c.1c-bitrix.ru/support/forum/forum26/topic50315/

[14] blog.ispsystem.info — bitrix не меняется maxexecutiontime — https://blog.ispsystem.info/2017/03/bitrix-maxexecutiontime.html

[15] g-rain-design.ru — Запуск долгих скриптов на php — https://g-rain-design.ru/blog/posts/php-long-scripts-timeouts/

[16] dev.1c-bitrix.ru — Щадящая кастомизация импорта из 1С (блог) — https://dev.1c-bitrix.ru/community/webdev/user/24164/blog/7651/?commentId=49670

[17] 1c.1c-bitrix.ru — Импорт товаров с торговым предложением не работает (форум) — https://1c.1c-bitrix.ru/support/forum/forum26/topic97857/