Интеграция 1С:Управление торговлей с CMS 1С-Битрикс — стандартная задача для интернет-магазинов, однако при росте базы товаров до десятков тысяч позиций обмен может замедлиться вплоть до полной остановки. Особенно остро эта проблема проявляется при выгрузке торговых предложений (характеристик товаров), объем которых часто в разы превышает количество базовых номенклатурных позиций. Выгрузка каталога из 7 000 товаров и 42 000 предложений не должна занимать сутки — при правильной настройке этот процесс длится не более нескольких десятков минут.
В этой статье мы подробно разберем, почему зависает обмен, проанализируем критическую ошибку СУБД Lock wait timeout exceeded и по шагам настроим систему на максимальную производительность.
Прежде чем приступать к оптимизации кода или настроек сервера, нам необходимо четко понять, на чьей стороне происходит задержка: на стороне 1С при формировании файлов выгрузки или на стороне сайта при их обработке. Проанализируем логи и выполним простую диагностику:
import.xml и offers.xml. Если 1С генерирует файлы быстро (в пределах 10–20 минут для нашей базы), значит, проблема на 100% лежит на стороне веб-сервера и базы данных Битрикс.При обработке предложений на стороне Битрикс часто возникает критическая ошибка, которая прерывает импорт:
[Bitrix\Main\DB\SqlQueryException]
Mysql query error: (1205) Lock wait timeout exceeded; try restarting transaction (400)
DELETE FROM b_cache_tag WHERE TAG = 'iblock_id_28'
Проанализируем эту ситуацию. Ошибка Lock wait timeout exceeded означает, что один из SQL-запросов ожидал освобождения блокировки таблицы дольше, чем разрешено настройками СУБД (параметр innodb_lock_wait_timeout, который по умолчанию равен 50 секундам).
Запрос пытается очистить тегированный кэш для инфоблока предложений (ID 28): DELETE FROM b_cache_tag WHERE TAG = 'iblock_id_28'. При обновлении каждого из 42 000 торговых предложений Битрикс пытается сбросить связанный с ним кэш. Таблица b_cache_tag при этом может содержать миллионы записей. В условиях высокой нагрузки и медленного диска один шаг импорта блокирует таблицу, а параллельный процесс (или следующий шаг импорта) пытается выполнить аналогичное удаление, упирается в блокировку и падает по таймауту.
Чтобы избавиться от блокировок таблицы b_cache_tag, выполним следующие действия:
DELETE FROM b_cache_tag WHERE SITE_ID IS NULL AND CACHE_SALT IS NULL;
OPTIMIZE TABLE b_cache_tag;
Это удалит устаревшие теги кэша и дефрагментирует таблицу, существенно ускорив операции чтения и удаления.
/bitrix/php_interface/dbconn.php (или аналогичный файл настроек) и добавим инструкцию, которая запретит кэширование инфоблоков при вызовах скрипта обмена:
if (strpos($_SERVER['REQUEST_URI'], '/bitrix/admin/1c_exchange.php') !== false) {
define("CACHED_b_iblock", false);
define("CACHED_b_iblock_bucket_size", 0);
}
Это предотвратит лавинообразную запись и удаление тегов кэша в процессе парсинга XML-файлов.
/bitrix/.settings.php. Это полностью уберет операции записи кэша из базы данных MySQL, разгрузив дисковую подсистему.Перейдем в административную панель сайта в раздел Магазин -> Интеграция с 1С на вкладку Каталог (или «Экспорт каталога») и отрегулируем параметры пошаговой загрузки:
0 (выполнить загрузку за один шаг), система попытается обработать весь файл объемом 43 000 предложений за один проход веб-скрипта. Это гарантированно приведет к исчерпанию выделенной оперативной памяти (PHP memory limit) и падению скрипта. Установим значение в диапазоне от 20 до 30 секунд. Это заставит скрипт импорта дробить обработку XML на небольшие транзакции.Большое количество старых, неактивных товаров и предложений, которые давно не продаются, но хранятся в базе данных «на всякий случай», колоссально замедляют операции сравнения при импорте. При каждом обмене Битрикс сопоставляет пришедшие из XML данные с уже существующими записями в таблицах b_iblock_element и b_catalog_product.
Выясним количество неактивных товаров:
Активность = Нет.Часто виртуальные серверы (VPS) поставляются со стандартными настройками MySQL, которые ориентированы на минимальное потребление оперативной памяти и совершенно не подходят для тяжелых транзакционных систем вроде связки 1С и Битрикс. Разберем три ключевых параметра конфигурационного файла СУБД (my.cnf):
innodb_buffer_pool_size — важнейший параметр для движка таблиц InnoDB. Он определяет объем оперативной памяти, выделяемый под кэширование данных и индексов таблиц. По умолчанию он может быть равен всего 128 МБ. Увеличьте его значение так, чтобы в него помещалась вся ваша активная база данных (рекомендуется выделять до 60-70% от общего объема RAM сервера, например, innodb_buffer_pool_size = 4G на сервере с 8 ГБ RAM).innodb_flush_log_at_trx_commit — по умолчанию этот параметр равен 1, что требует записи лога транзакции на диск при каждом коммите. Это гарантирует сохранность данных при сбое, но создает колоссальную нагрузку на диски при массовом импорте предложений. Установка значения 2 заставит MySQL сбрасывать лог на диск раз в секунду, что ускорит запись данных в таблицы Битрикса в несколько раз.innodb_lock_wait_timeout — увеличим время ожидания блокировок с дефолтных 50 до 120-180 секунд (innodb_lock_wait_timeout = 150). Это позволит шагам импорта дожидаться завершения предыдущих тяжелых транзакций без генерации ошибки 1205.Проанализируем настройки выгрузки в самой «1С:Управление торговлей». Главная ошибка администраторов — регулярный запуск **полной выгрузки** вместо дельта-выгрузки (только изменений).
Выясним причину, почему 1С каждый раз пытается выгрузить все 42 000 предложений:
prices.xml и rests.xml, обработка которых на сайте происходит мгновенно и не нагружает базу данных тяжелыми операциями обновления структуры инфоблоков.Применение этих комплексных мер позволит сократить время обработки предложений с десятков часов до нескольких минут, ликвидирует взаимные блокировки таблиц MySQL и обеспечит стабильную и быструю работу интернет-магазина.