По-видимому, случайные зависания/лаги при загрузке веб-сайта

Мы запускаем веб-страницу на платформе OS Commerce на нашем собственном выделенном сервере. В апреле прошлого года мы были вынуждены обновить сервер. Примерно в этот момент мы начали замечать, что были, казалось бы, случайные перебои в работе веб-сайта, когда нашу страницу нельзя было просмотреть ни с одного компьютера, и единственным решением для этого в то время был жесткий перезапуск нашего сервера. Это происходило около месяца. Эта проблема решена, но теперь перед нами стоит другая задача. Наш сайт замедляется, по-видимому, случайным образом. Иногда страница загружается очень быстро, а иногда загрузка занимает до 2 минут. Похоже, что для этого нет закономерности, которую мы могли бы выяснить. Сайт www.westerndepot.com. Мы пытались проверить работоспособность нашего веб-сайта с помощью Yslow и подобных, но все выполненные нами запросы показывают, что наш веб-сайт имеет рейтинг «А». Похоже, что время ожидания колеблется, а не фактическое время загрузки. Недавняя диагностика Firebug показала время ожидания 23,9 секунды при времени загрузки 24,17 секунды.

Сервер имеет 64 ГБ оперативной памяти, а текущий максимальный объем используемой оперативной памяти составляет 10 ГБ. Мы используем SME Server 9.0. Сервер состоит из двух дисков WD Caviar Black емкостью 1 ТБ, зеркалированных с помощью программного обеспечения Raid под SME 9, с оставшимся свободным пространством 833 ГБ. Таблица products_to_categories содержит 18 375 записей для 13 923 продуктов, из которых 2 427 неактивны. Всего 385 категорий.

Наш файл конфигурации MySQL выглядит следующим образом:

character-set-server=utf8
collation-server=utf8_general_ci
key_buffer_size=2048M
preload_buffer_size=512M
query_cache_limit=64M
query_cache_size=512M
query_cache_type=1
query_prealloc_size=512M
read_buffer_size=2M
read_rd_buffer_size=4M
sort_buffer_size=2M
thread_cache_size=300
join_buffer_size=256K
table_open_cache=512K
tmp_table_size=256M
max_heap_table_size=256M
slow_query_log=1
max_connections=500
concurrent_insert=2
log_output=FILE

Ниже приведен пример журнала медленных запросов.

    # Query_time: 12.277704  Lock_time: 0.000193 Rows_sent: 1  Rows_examined: 39652497
    SET timestamp=1427835801;
    select count(distinct p.products_id) as total  from products p left join manufacturers
 m using(manufacturers_id) left join (select * from (select products_id, specials_new_products_price
, expires_date, status from specials where status = 1 order by products_id, specials_new_products_price,
 expires_date) as t group by products_id) as s on p.products_id = s.products_id left join 
products_to_notes ptn on ptn.products_id = p.products_id join products_description
 pd on p.products_id = pd.products_id join (select products_id from 
products_to_categories where (categories_id not in (728)) group by products_id) as 
 p2c on p.products_id = p2c.products_id where p.products_status = '1';
    # Query_time: 11.654512  Lock_time: 0.000367 Rows_sent: 240  Rows_examined: 36425129
    SET timestamp=1427835812;
    select distinct m.manufacturers_name, p.products_model, p.products_image, 
p.image_folder, p.image_display, p.products_quantity, p.hide_qty_over,
 p.products_bundle, IF(s.status, s.expires_date, NULL) as expires_date,  
m.manufacturers_id, p.products_id, pd.products_name, p.products_msrp, 
p.products_price, p.products_tax_class_id, IF(s.status, 
s.specials_new_products_price, NULL) as specials_new_products_price, IF(s.status, 
s.specials_new_products_price, p.products_price) as final_price, 
p.sold_in_bundle_only, p.products_type , pd.extra_value_id6 , pd.extra_value_id10 
from products p left join manufacturers m using(manufacturers_id) left join 
(select * from (select products_id, specials_new_products_price, expires_date, 
status from specials where status = 1 order by products_id, 
specials_new_products_price, expires_date) as t group by products_id) as s on 
p.products_id = s.products_id left join products_to_notes ptn on ptn.products_id = 
p.products_id join products_description pd on p.products_id = pd.products_id join 
(select products_id from products_to_categories where (categories_id not in (728)) 
group by products_id) as  p2c on p.products_id = p2c.products_id where 
p.products_status = '1' order by products_name  limit 2160, 240;

Все медленные запросы поступают из "расширенного поиска".
На сайте используется несколько продаж для каждого продукта.

Какие-нибудь мысли? Мы пропустили что-то простое? Будем очень признательны за любую помощь, направления, мысли или контакты.


person westerndepot    schedule 31.03.2015    source источник
comment
Если вы постоянно загружаете одни и те же данные, почитайте о кэшировании mysql. Некоторым это может помочь. (Например, для запросов, которые заполняют раскрывающиеся списки)   -  person developerwjk    schedule 01.04.2015
comment
Если ваши поисковые запросы изучают примерно 40 млн строк, неудивительно, что они медленные. Пересмотрите свои стратегии индексации.   -  person eggyal    schedule 01.04.2015
comment
Также возможно сделать представление для этого запроса.   -  person developerwjk    schedule 01.04.2015
comment
вы присоединяетесь к подзапросам, которые никогда не будут использовать индекс, у вас также есть условные операторы, которые замедлят его, запустите эти запросы с DEFINE, чтобы помочь уточнить ваши индексы   -  person cmorrissey    schedule 01.04.2015


Ответы (1)


Вы видели результаты команды MySQL explain? Я предполагаю, что в таблицах БД не хватает некоторых индексов.

Подробнее о режиме см. в документах.

person lazy.lizard    schedule 23.07.2015