2013-12-18 6 views
6

На моем веб-сайте возникают проблемы при оформлении заказа. Я использую Magento Enterprise 1.8, а мой контрольный модуль - Onestepcheckout от Idev.Magento 1.8: Блокировка времени ожидания ожидания ожидания, когда клиент проверяет

Проблема, которую мы видим, заключается в том, что таблица eav_entity_store занимает очень много времени (до 51 секунды), чтобы вернуть номер заказа в Mage_Eav_Model_Entity_Type.

Что я знаю, так это то, что запрос выполняется, чтобы получить это транзакцию, выполняемую как «ДЛЯ ОБНОВЛЕНИЯ», чтобы доступная строка блокировалась до завершения транзакции. Я просмотрел другие части кода, а также код PHP во время транзакции, где строка заблокирована (мы используем InnoDB, чтобы блокировка была освобождена после совершения транзакции), и я просто не вижу что угодно (или в медленных журналах запросов), которые должны вызывать блокировку, подождите около 51 секунды.

Я считал, что запросы могут быть сложены и медленно ползут во времени, поскольку они ждут, но я вижу, что время запроса идет от 6 мс до 20 кГц до 50 кГц 1,2,3. Это не проблема 100-200 запросов сложены, так как их всего несколько десятков в день.

Я знаю, что MySql использует родительскую блокировку, но FK не связан с этой таблицей. Есть два индекса BTREE, которые в какой-то момент были FK, но с тех пор были изменены (это произошло много лет назад). Для тех, кто не является Magento savy, таблица eav_entity_store имеет менее 50 строк и имеет ширину всего 5 колонок (4 маленьких и varchar). Я серьезно сомневаюсь в том, что обвинение в таблицах или неправильное индексирование является виновником. Однако в духе TLDR я скажу, что два индекса BTREE - это два столбца, которые мы выбираем из этой таблицы.

Одна из возможностей заключается в том, что мне может потребоваться заменить два индекса на составной индекс, поскольку ТОЛЬКО читает эту таблицу, исходя из запроса, который читается (FROM [Column with Index A] AND [Column with Index B]). Я просто не знаю, будет ли блокировка на уровне строк препятствовать доступу этого запроса к другой строке в таблице с индексами, находящимися в настоящее время в таблице.

На этом этапе я убедился, что основная проблема связана с строго связанными с БД, но любые советы Magento или MySql, касающиеся этого, будут очень признательны. Любой, кто все еще на самом деле читает это, может надеяться, что я уже исчерпал несколько вариантов, и здесь серьезно стоит. Любая информация, которая, по вашему мнению, может помочь, приветствуется. Благодарю.

Редактировать Точная ошибку мы наблюдаем: сообщение об ошибке : SQLSTATE [HY000]: Общая ошибка: 1205 Блокировка срока ожидания превышено; попробуйте перезапустить транзакцию

+0

Можете ли вы воспроизвести, когда вы запускаете медленный запрос вручную? В этом случае вы можете просмотреть его. –

+0

К сожалению, я не смог воспроизвести. Хостинг БД осуществляется удаленно. Я ждал ответа от DBA там, чтобы посмотреть, какую информацию они могут дать. Я обновлю здесь, как только они это сделают. –

+0

та же проблема на Magento 1.8 ... может быть, это проблема на стороне ИБП, а не пурпурный? – WonderLand

ответ

0

Проблема решена. Не было проблем с MySql. По какой-то причине генерация счетов-фактур занимала непристойное количество времени. Компания не использует счета-фактуры Magento. Отключил их. Задача решена. Никакой полный RCA не сделал, что конкретно проблема с генерацией счета-фактуры.

+0

Я использую Magento Community 1.8.0, а мой контрольный модуль - Onestepcheckout от Idev. Столкнувшись с той же проблемой, можете ли вы указать мне, где я должен проверить или отключить форму счета? –

+1

Это, вероятно, не лучший способ исправить, но мы сделали это так, потому что мы сбросили нашу текущую установку для новой копии пурпурного. Я позабочусь, прежде чем идти по этому маршруту.В Mage_Eav_Model_Entity_Type :: fetchNewIncrementId, вокруг строки 150 (мои строки немного разные, потому что файл был изменен) после строки $ type = $ this-> getEntityTypeCode(); добавьте что-то вроде if ($ type === 'invoice') return 'INV0' Не для того, чтобы что-то исправить, но он снова прошел проверку. –

+0

Спасибо Danny за вашу помощь. –

Смежные вопросы