Обмен с 1С обрывается на середине
Запустили выгрузку, часть каталога приехала, дальше ошибка соединения. При повторе обрывается снова — иногда на том же месте, иногда на другом. Разбираемся, что именно рвётся.
Как устроена передача
Обмен идёт по протоколу CommerceML через адрес /bitrix/admin/1c_exchange.php. Данные передаются не целиком, а порциями: файл выгрузки дробится на части, каждая отправляется отдельным запросом, сайт её принимает и просит следующую. В журнале 1С это видно по именам вида v8_9_8ed.zip.373 — число на конце и есть номер части.
Отсюда главное следствие: рвётся не «обмен», а конкретный запрос. И чинить нужно то, что мешает отдельному запросу дойти.
Что говорит журнал
| Сообщение | Что значит |
|---|---|
| Файл не отправлен (…zip.NNN), обмен не выполнен | Оборвалась передача конкретной части: смотрите лимиты и сеть |
| Ответ сервера: MySQL Query Error | Сайт принял данные, но не смог записать их в базу |
| Получен неизвестный статус импорта | Сайт ответил не тем, что ожидала 1С: чаще всего вместо ответа пришла страница ошибки |
| Выгрузка завершена с ошибками, обрыв на произвольном файле | Плавающая причина: нагрузка, лимиты соединений, сеть |
Отдельно обратите внимание на время: если обрывы случаются только в рабочие часы, а ночью всё проходит, дело в нагрузке, а не в настройках.
Настройки, которые решают
Магазин → Настройки → Интеграция с 1С на сайте:
- Интервал одного шага, секунд. Ноль означает «всё за один раз» — на большом каталоге это и есть причина обрывов. Поставьте небольшое значение, чтобы шаги были короткими.
- Размер части файла, байт. Уменьшите, если падает на передаче.
- Элементов за шаг при экспорте. Для тяжёлых карточек с картинками уменьшайте.
- Сжатие ZIP. Включите, если канал медленный: меньше объём — меньше шансов не дойти.
Лимиты сервера
Настройки шага бесполезны, если процесс останавливает сам сервер:
- Время выполнения. Требование вендора — 300 секунд. Проверьте значение для той версии PHP, под которой работает сайт.
- Память. Минимум 256 МБ. При нехватке процесс падает молча, без сообщения в журнале обмена.
- Таймауты веб-сервера. Если nginx перестаёт ждать ответ раньше, чем PHP закончит шаг, 1С получит обрыв. В журнале веб-сервера это 504.
- Ограничение размера запроса. Слишком крупная часть файла упирается в лимит загрузки, и сайт её не принимает.
Когда дело в базе
Ответ MySQL Query Error означает, что до базы дошло, а записать не удалось. Здесь смотрят в сторону базы, а не обмена: не кончилось ли место на диске, не превышен ли размер пакета, не падает ли база под нагрузкой. Обмен — самая тяжёлая операция на сайте, и он первым находит проблемы, которые в обычной работе незаметны.
Когда обрывается на одном и том же товаре
Если место обрыва не плавает, а повторяется, лимиты ни при чём — дело в данных. Обычные виновники: огромное описание, битая картинка, нестандартные символы, аномально много характеристик у одной позиции. Найдите, на какой позиции встаёт, и посмотрите её в 1С.
Порядок разбора
- Журнал обмена в 1С и журнал на сайте: на каком шаге встало и с каким текстом.
- Журнал ошибок веб-сервера и PHP за время обмена — память, таймауты, 504.
- Уменьшите размер части файла и число элементов за шаг вдвое, повторите.
- Если место обрыва постоянное — ищите проблему в данных позиции.
- Если обрывы только днём — переносите тяжёлые обмены на ночь.
Большой каталог
На десятках тысяч позиций первую выгрузку делят на части: сначала справочники и разделы, потом номенклатура, потом цены и остатки, картинки отдельно принудительной выгрузкой. Дальше переходят на обмен по изменениям — он передаёт только изменившееся и в лимиты укладывается без правок.
Частые вопросы
Почему полная выгрузка падает, а обмен по изменениям идёт нормально?
Полная передаёт весь каталог и держит соединение дольше — она первой упирается во все лимиты. Обмен по изменениям мал по объёму и до них не доходит. Поэтому первую загрузку настраивают отдельно: меньше шаг, больше времени, ночное окно.
В журнале «Ответ сервера: MySQL Query Error». Это проблема обмена?
Нет, данные дошли, но сайт не смог записать их в базу. Смотрите свободное место на диске, настройки базы и не падает ли она под нагрузкой. Обмен тут не причина, а первый пострадавший.
Увеличил время выполнения, всё равно рвётся.
Значит обрывает веб-сервер своими таймаутами, они обычно короче. Либо кончается память — тогда процесс падает молча. Ответ ищите в журнале веб-сервера, там будет 504 или сообщение о памяти.
Обрыв всегда на одном и том же месте.
Это не лимиты, а данные. Посмотрите позицию, на которой встаёт: огромное описание, битая картинка, нестандартные символы, аномальное число характеристик.
Можно ли продолжить с места обрыва?
Обмен идёт шагами и при повторном запуске продолжает незавершённую сессию. Но если причина не устранена, он упрётся в неё снова на том же месте.
Обрывы только в рабочее время.
Дело в нагрузке: сайт и база заняты посетителями, и тяжёлому обмену не хватает ресурсов. Переносите полные выгрузки на ночь, а днём обменивайтесь только ценами и остатками.
