Попытка номер два.
Выключаю проактивную защиту. На локальном компе выключаю интернет, файервол, весь лишний софт.
Настраиваю MySQL согласно инструкциям из справки и из форумов по оптимизации MySQL. Перевожу все таблицы в InnoDB. Включаю параметр define("MYSQL_TABLE_TYPE", "InnoDB").
my.cnf:
Код |
---|
max_connections = 1000
table_cache = 2048
thread_cache = 32
query_cache_size = 64M
query_cache_type = 1
max_tmp_tables = 5000
max_connect_errors = 100
flush
flush_time = 3600
key_buffer = 16K
key_buffer_size = 32M
max_allowed_packet = 1M
sort_buffer_size = 8M
read_buffer_size = 16M
read_rnd_buffer_size = 8M
net_buffer_length = 2K
thread_stack = 64K
tmp_table_size = 32M
join_buffer_size = 2M
innodb_buffer_pool_size = 320M
innodb_additional_mem_pool_size = 32M
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_flush_log_at_trx_commit=0 # По рекомендации документации 1С:Битрикс
innodb_lock_wait_timeout = 50
innodb_fast_shutdown = 1
|
Устанавливаю ZendOptimizer. Перезапускаю сервер. Стартую выгрузку в 15:00. 1С сообщает:
- Выгружено товаров: 6153
- Выгружено картинок: 2332
- Выгружено файлов: 51
- Выгружено предложений: 12891
На "Временные таблицы созданы" как всегда уходит в глубокий штопор.
В процессе наблюдаю за таблицей b_xml_tree. Она бесконечно-изменяется, каждую секунду прибавляется по 1000-2000 записей. Идентификатор ID растёт, вырастает до значений (внимание) выше 1700000 — почти два миллиона записей
Затем обнуляется и процесс повторяется. За несколько часов выгружается "Основной каталог товаров" (не знаю, полностью ли). "Пакет предложений" так и не меняется. Сейчас 20:20. Выгрузка всё продолжается и конца не видно. b_xml_tree выростает / обнуляется / выростает / обнуляется и так бесконечно. Это какой-то идиотизм.
У меня нет ни одного разумного довода в пользу системы, которая на 12891 + 6153 записей плодит таблицу с миллионными количествами строк и при этом ещё и неоднократно.
Объясните мне: это полный коллапс мышления программистов, создававших выгрузку или всё-таки что-то где-то волшебным образом нужно настроить?
Пошел шестой час выгрузки шести тысяч товаров! Всё больше склоняюсь к мысли, что нужно написать собственный механизм выгрузки, скооперировавшись с 1с-никами из офиса.
Скорость работы MySQL: 1000-2000 запросов в секунду. На каждый товар, допустим, выделяется по 3 строки в разных таблицах. Плюс у каждого товара есть как минимум один дубликат (ну не бред ли?) — это его "пакет предложений".
Вот алгоритм, рождённый "от балды":
1. 1С соединяется с сервером и передаёт полную выгрузку товаров в виде чистых SQL-запросов (а не хронического дибилизма в XML). Также передаёт простенький конфиг, в котором описана структура (вот для этого, блин, существует XML) переданных данных.
2. Сервер Битрикс сравнивает структуру, переданную от 1С со своей структурой объектов - и если не совпадает, сообщает об этом и прерывает синхронизацию, либо добавляет / игнорирует недостающие поля.
3. Сервер читает конфиг, создаёт временные таблицы согласно переданной структуре (с точными характеристиками полей).
4. Затем импортирует SQL-файл. 12891 + 6153 = 19 044 / 1000 запросов в секунду = пару минут времени максимум даже на слабых машинах.
5. Пробегаем SELECT-ом по временной таблице, выбираем связку товаров id=>last_upd_time. То же по реальным товарам. Определяем те, которые не сходятся (не существуют на сайте, либо обновлены). Тут у нас уходит, допустим, до пяти минут.
6. Добавляем новые, обновляем старые (если это выгрузка на пустую базу, то это ещё пару минут). На лету перебиваем ссылки на вложения / графику, которая была передана с 1С.
7. То же проделываем с дополнительными характеристиками "пакета предложений". Плюс 5-10 минут предел.
8. Синхронизируем заказы, конец.
Если пройдёт 30 минут - я буду удивлён. Одно но: нужно перелопатить всю структуру данных Битрикс, чтобы понять где именно, как и чем связаны товары из b_iblock_element с другими таблицами. А это могут знать досконально только разработчики Битрикс. Если знают, конечно...