Высокая нагрузка на сервере - CPU 100%

[ne4to]

я так понимаю апач+мод пхп ? лимитируйте количество процессов
есть еще интересные модуль mod_performance

 

[demon201984]

Выяснил, что идет высокая нагрузка на mysql если обычно в mytop Se/In/Up/De(% 1239737/00/00/00
То при включении определенного функционала уже становится Se/In/Up/De(% 60269778/00/00/00 - это при кол-ве юзеров 160 челов на сайте. (т.е. возрастает раз в 60-70 - возросло за период 5-10 мин. с момента включения функции, приводящей к нагрузке, потом рубанул.)
А в среднем юзеров бывает более 200, доходит и до 300.

Зависает на запросах вида:

 Query_time: 32.828569  Lock_time: 0.000115 Rows_sent: 36  Rows_examined: 500604
SET timestamp=1363624304;
SELECT `id_items`, `sp_items`.`vars`, `bundle`, `bundle_var` FROM `sp_items`, `sp_cats`, `sp_orders_items` WHERE `catalog_id` = `id_cats` AND `sp_items`.`hidden` = '0' AND `sp_cats`.`hidd en` = '0' AND `sp_orders_items`.`item_order` = `sp_items`.`id_items` AND `sp_orders_items`.`state_order` != 3 AND `sp_orders_items`.`state_order` != 5 AND `sp_items`.`purchase_id` = '5317' AND `sp_items`.`bundle` != 's:0:"";' AND `sp_cats`.`bundle_var` != '' GROUP BY `sp_items`.`id_items` ASC;

Данные запросы выполняются от 5 до 40 сек.

Одного не пойму почему стало на них зависать, ранее-то проблем не было. На выходных ставил мод, который производил изменения в базе, но он никоим образом не затрагивал таблиц участвующих в выше указанном запросе. Деинсталлировал мод и откатил той же деинсталяцией измения в БД, но ошибка все равно сохраняется. Таблицы в БД постоянно оптимизирую, чего не хватает?

Помониторил еще, теперь ситуция в mytop совсем другая

Спойлер

23:48 119 юзеров
MySQL on localhost (5.1.49-3)                          up 0+22:27:46 [23:49:06]
Queries: 907.0  qps:    0 Slow:    0.0        Se/In/Up/De(%):    321584/00/00/00
              qps now:    0 Slow qps: 0.0  Threads:    2 (  1/  8) 48100/00/00/00
Key Efficiency: 99.7%  Bps in/out:  0.2/ 44.0  Now in/out:  2.7/568.0
 
 
--сразу возрос было около 1
top - 23:49:27 up 1 day, 30 min,  2 users,  load average: 5.16, 2.20, 1.69
Tasks: 105 total,  2 running, 103 sleeping,  0 stopped,  0 zombie
Cpu(s):  2.8%us,  0.5%sy,  0.1%ni, 96.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  2457600k total,  1523996k used,  933604k free,        0k buffers
Swap:        0k total,        0k used,        0k free,        0k cached
 
 
23:55 136 юзеров
MySQL on localhost (5.1.49-3)                          up 0+22:33:33 [23:54:53]
Queries: 1019.0  qps:    0 Slow:    0.0        Se/In/Up/De(%):    287277/00/00/00
              qps now:    0 Slow qps: 0.0  Threads:    2 (  1/  8) 5650/00/00/00
Key Efficiency: 99.7%  Bps in/out:  0.3/ 49.3  Now in/out:  8.4/ 1.5k
 
 
top - 23:55:30 up 1 day, 36 min,  2 users,  load average: 1.11, 2.08, 1.89
Tasks: 107 total,  1 running, 106 sleeping,  0 stopped,  0 zombie
Cpu(s):  7.5%us,  1.6%sy,  0.0%ni, 91.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  2457600k total,  1533788k used,  923812k free,        0k buffers
Swap:        0k total,        0k used,        0k free,        0k cached
 
 
 
00:04 150 юзеров
 
MySQL on localhost (5.1.49-3)                          up 0+22:43:10 [00:04:30]
Queries: 1.2k    qps:    0 Slow:    0.0        Se/In/Up/De(%):    247372/00/00/00
              qps now:    0 Slow qps: 0.0  Threads:    4 (  1/  8) 5050/00/00/00
Key Efficiency: 99.8%  Bps in/out:  0.3/ 57.6  Now in/out:  5.5/ 1.1k
 
 
top - 00:04:49 up 1 day, 46 min,  2 users,  load average: 5.28, 4.73, 3.15
Tasks: 107 total,  5 running, 102 sleeping,  0 stopped,  0 zombie
Cpu(s): 88.4%us, 11.6%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  2457600k total,  1530060k used,  927540k free,        0k buffers
Swap:        0k total,        0k used,        0k free,        0k cached

При это если обращаться к странице на которой работает указанный выше функционал, вызывающий повышенную нагрузку, то cpu сразу же становится равен 100%, что в приципе видно и выше ( Cpu(s 88.4%us, 11.6%sy, ). Посмотрел в htop при открытии страниц, на которые вызывают нагрузку нагрузка на mysql тут же возрастает и обычно находится в пределах 50-90%, в среднем около 70%. Когда же нет обращений к этой странице то нагрузка от mysql на CPU не более 30%

 

[ne4to]

Rows_examined: 500604

делай explain и оптимизируй запрос, может просто индексы надо правильно расставить, пол лимона записей каждый раз перебирать это не приколько

 

[Шумадан]

SELECT `id_items`, `sp_items`.`vars`, `bundle`, `bundle_var` FROM `sp_items`, `sp_cats`, `sp_orders_items`

это произведение таблиц, нужно избавлятся от таких запросов по возможности обязательно. почему скорость изменилась, сколько в каждой из перечисленных таблиц записей? попробуйте просто выполнить этот запрос, сколько строк он вернёт?
ну и да, експлейном смотреть узкие места

PS: есть ещё перловый скрипт который может помочь с установкой "правильных" настроек mysql - Для просмотра ссылки Войди или Зарегистрируйся это не даёт гарантий, скорее рекомендации.

 

[demon201984]

Вот сделал explain указанного запроса, что можно из него понять, то бишь как его читать?

 

[Шумадан]

Вот сделал explain указанного запроса, что можно из него понять, то бишь как его читать?

покажите структуру sp_orders_items, поясните немного чего хотите от запроса? суть некоторых полей непонятна

меня смущает

AND
`sp_orders_items`.`item_order` = `sp_items`.`id_items` и наличие самой таблицы `sp_orders_items` в запросе

 

[demon201984]

В файле "Буфер обмена05.jpg" структура таблицы sp_orders_items а в файле "результат запроса.jpg" результат указанного проблемного запроса. Запрос выводит параметры товара, по этим параметрам должен быть собран так называемый размерный ряд (форум совместных покупок вообщем)

 

[Шумадан]

В файле "Буфер обмена05.jpg" структура таблицы sp_orders_items а в файле "результат запроса.jpg" результат указанного проблемного запроса. Запрос выводит параметры товара, по этим параметрам должен быть собран так называемый размерный ряд (форум совместных покупок вообщем)

у вас есть индексы на user_order и purchase_order, индекса на item_order не было, не пробовали добавлять временно и потестировать?

и не легче б было основную выборку делать из sp_orders_items с джоинами на остальные таблички с нужными where условиями, а не создания проиведения, а потом наложение условий? хотя для меня до сих пор остаётся загадкой sp_orders_items в этом запросе. ведь sp_orders_items это елементы покупки с какогото заказа.

 

[ne4to]

sp_orders_items.item_order
как минимум попробуйте поставить сюда индекс, и посмотрите как изменится ситуация

 

[demon201984]

попробовал добавить 2 индекса item_order и state_order в таблице sp_orders_items (добавлял кликом по кнопке индекс на соответствующем поле таблицы sp_orders_items). В explain после этого по данной таблице ничего не изменилось - все равно отбираются все записии

и не легче б было основную выборку делать из sp_orders_items с джоинами на остальные таблички с нужными where условиями, а не создания проиведения, а потом наложение условий? хотя для меня до сих пор остаётся загадкой sp_orders_items в этом запросе. ведь sp_orders_items это елементы покупки с какогото заказа.

Ну там суть такая у товара есть какой то размерный ряд и каждый пользователь осуществляя покупку должен выбрать какой то из размеров, если все размеры в размерном ряду заполнятся, то значит товар можно выкупить у поставщика.