Magento core_url_rewrite sporadic performance

Question

В нашей производственной среде я замечаю спорадическую медленную производительность для одного из запросов.

SELECT `core_url_rewrite`.* 
    FROM `core_url_rewrite` 
    WHERE (request_path IN (:path?, :path?, :path?, :path?)) 
    AND (store_id IN(?, ?)) 

Explain Plan от производства сервера:

id: 1 
    select_type: SIMPLE 
    table: core_url_rewrite 
    type: range 
    possible_keys: UNQ_CORE_URL_REWRITE_REQUEST_PATH_STORE_ID,IDX_CORE_URL_REWRITE_STORE_ID 
    key: UNQ_CORE_URL_REWRITE_REQUEST_PATH_STORE_ID 
    key_len: 770 
    ref: NULL 
    rows: 4 
    Extra: Using index condition 

Mysql версия: 5.6.34. Количество строк в таблице: 473847. Обычно оно выполняется менее чем за 1 мс, но некоторые из Tx в соответствии с новой реликвией: 8.03s, 5.35s, 3.04s, 2.97s, 1.92s за последние 30 минут.

Создать таблицу является:

CREATE TABLE `core_url_rewrite` (
     `url_rewrite_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Rewrite Id', 
     `store_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Store Id', 
     `id_path` varchar(255) DEFAULT NULL COMMENT 'Id Path', 
     `request_path` varchar(255) DEFAULT NULL COMMENT 'Request Path', 
     `target_path` varchar(255) DEFAULT NULL COMMENT 'Target Path', 
     `is_system` smallint(5) unsigned DEFAULT '1' COMMENT 'Defines is Rewrite System', 
     `options` varchar(255) DEFAULT NULL COMMENT 'Options', 
     `description` varchar(255) DEFAULT NULL COMMENT 'Deascription', 
     `category_id` int(10) unsigned DEFAULT NULL COMMENT 'Category Id', 
     `product_id` int(10) unsigned DEFAULT NULL COMMENT 'Product Id', 
     PRIMARY KEY (`url_rewrite_id`), 
     UNIQUE KEY `UNQ_CORE_URL_REWRITE_REQUEST_PATH_STORE_ID` (`request_path`,`store_id`), 
     UNIQUE KEY `UNQ_CORE_URL_REWRITE_ID_PATH_IS_SYSTEM_STORE_ID` (`id_path`,`is_system`,`store_id`), 
     KEY `IDX_CORE_URL_REWRITE_TARGET_PATH_STORE_ID` (`target_path`,`store_id`), 
     KEY `IDX_CORE_URL_REWRITE_ID_PATH` (`id_path`), 
     KEY `IDX_CORE_URL_REWRITE_STORE_ID` (`store_id`), 
     KEY `FK_CORE_URL_REWRITE_CTGR_ID_CAT_CTGR_ENTT_ENTT_ID` (`category_id`), 
     KEY `FK_CORE_URL_REWRITE_PRODUCT_ID_CATALOG_CATEGORY_ENTITY_ENTITY_ID` (`product_id`), 
     CONSTRAINT `FK_CORE_URL_REWRITE_CTGR_ID_CAT_CTGR_ENTT_ENTT_ID` FOREIGN KEY (`category_id`) REFERENCES `catalog_category_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE, 
     CONSTRAINT `FK_CORE_URL_REWRITE_PRODUCT_ID_CATALOG_CATEGORY_ENTITY_ENTITY_ID` FOREIGN KEY (`product_id`) REFERENCES `catalog_product_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE, 
     CONSTRAINT `FK_CORE_URL_REWRITE_STORE_ID_CORE_STORE_STORE_ID` FOREIGN KEY (`store_id`) REFERENCES `core_store` (`store_id`) ON DELETE CASCADE ON UPDATE CASCADE 
    ) ENGINE=InnoDB AUTO_INCREMENT=95984103 DEFAULT CHARSET=utf8 COMMENT='Url Rewrites' 

Answer 1

Причина этой проблемы была окончательно диагностирована и не связана с mysql! У нас был низкий ulimit (по умолчанию) 1024. Мы изменили его на 65535. Вы можете проверить это, используя: ulimit -n.

Это один из самых выполненных запросов, поэтому всякий раз, когда на сервере будет сильная лихорадка, он начнет ждать. Он не будет отображаться в медленном журнале, но новая реликвия фиксирует его как медленный запрос.

Answer 2

(не однозначный ответ, различным бредом, и несколько вопросов ...)

Индекс почти оптимальный; EXPLAIN говорит, что он использует лучший индекс. Предполагая, что набор результатов не возвращает тысячи строк, я должен выйти на конечность и догадаться, что этот запрос не является злодеем.

Если выполняется еще один запрос (когда этот выполняется так медленно), и этот запрос много бьет по этой таблице (предположительно с помощью записи), то это может замедлить этот запрос. FKs добавляют к накладным расходам.

Или еще один запрос - это наводнение buffer_pool, из-за чего выходят из кэша, что приводит к внезапному всплеску ввода-вывода.

Или у вас есть сотня соединений, которые активно что-то делают, но не делают это очень быстро. (Это тот случай, соперничают за ресурсы, каждый получает «справедливой» доли, никто не получая быстро закончил.)

Включение slowlog с long_query_time=1 и суммируя по pt-query-digest или mydumpslow -s t поможет найти конкурирующие запросы.

Проверьте размер оперативной памяти и innodb_buffer_pool_size, чтобы увидеть, что последний является значительным процентом от прежнего. (Если она мала, то, что может привести к сценарию ввода/вывода.)

Как и в сторону, KEY(product_id) является излишним с ключом 3-колонки, начиная с product_id. Избыточные ключи теряют время на INSERT.

Другой в стороне: у вас есть AUTO_INCREMENT, который достиг 95M, это 140/th предела (4B). Делайте математику - когда вы закончите? Между тем в таблице всего 0,47 М строк. Это подразумевает использование REPLACE (которое может иметь лучшую замену) или другое действие, которое «сжигает» идентификаторы. Пожалуйста, уточните свой INSERTs.

Одним из решений (в приведенном выше абзаце) может быть избавление от url_rewrite_id и продвижение одного из ключей UNIQUE к ПК. (Для таблицы есть три значимых уникальных ключа.) Есть плюсы для продвижения, но есть значительные минусы, поскольку UNIQUE включает VARCHAR(255). Поэтому я не буду рекомендовать его .

Сопровождающий ключ этот вопрос использует бы ускорение этот вопрос.