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

[demon201984]

Ужас какой-то. Перенес вчера БД на новый более мощный сервак (8Гб оперативки, проц 3Гц*4), а сам сайт не переносил. В итоге на новом серваке нагрузка на cpu от mysql которая создавала основную нагрузку на старом серваке в общем не высокая. Зато на старом серваке на котором пока остался сайт 100% нагрузка на CPU теперь она от php.

 

[jia3apb]

Ужас какой-то. Перенес вчера БД на новый более мощный сервак (8Гб оперативки, проц 3Гц*4), а сам сайт не переносил. В итоге на новом серваке нагрузка на cpu от mysql которая создавала основную нагрузку на старом серваке в общем не высокая. Зато на старом серваке на котором пока остался сайт 100% нагрузка на CPU теперь она от php.

Высокая нагрузка на php и при этом в логах апача ничего нет?

 

[SkiLLer]

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

 

[jia3apb]

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

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

 

[mefish]

Ужас какой-то. Перенес вчера БД на новый более мощный сервак (8Гб оперативки, проц 3Гц*4), а сам сайт не переносил. В итоге на новом серваке нагрузка на cpu от mysql которая создавала основную нагрузку на старом серваке в общем не высокая. Зато на старом серваке на котором пока остался сайт 100% нагрузка на CPU теперь она от php.

Что за двиг, какое по стоит, кеширование присутствует ? Второй сервер в этом же ДЦ ? Пинг к нему с первого какой ? Нагрузка от пхп может и не упасть, в следствии долгого ответа от второго сервера. Если что, стучи, полечу пациента.

 

[Шумадан]

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


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

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

`sp_items`.`purchase_id` = '5317'

у вас в таблице есть purchase_order который наверное соответствует либо вышеуказанному
purchase_id либо это индекс с sp_items, вследствии чего можно оптимизировать запрос и не использовать декартово умножение в исходном.

 

[ne4to]

Нагрузка от пхп может и не упасть, в следствии долгого ответа от второго сервера.

молодой человек, Ваши ответы меня не перестают удивлять, смоделируйте ситуацию в уме

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

 

[Doctor_Chaos]

Стоит Vbulletin? Попробуй отключить на время капчу при реге и посмотри, не упадет ли нагрузка.

 

[demon201984]

SELECT `id_items`, `sp_items`.`vars`, `bundle`, `bundle_var` FROM `sp_items`, `sp_cats`, `sp_orders_items`
это произведение таблиц, нужно избавлятся от таких запросов по возможности обязательно. почему скорость изменилась, сколько в каждой из перечисленных таблиц записей? попробуйте просто выполнить этот запрос, сколько строк он вернёт?
ну и да, експлейном смотреть узкие места

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

Этот запрос без ограничений по where выполняется бесконечно долго, ждал пару минут потом рубанул его - после в phpmyadmin уже было не возможно работать пришлось перезагружать сервак.
А так в записей потаблично:



sp_items 460,601
sp_orders_items 334,936
sp_cats 10,956
Итого приблизительно 800 тыс. записей

Что за двиг, какое по стоит, кеширование присутствует ? Второй сервер в этом же ДЦ ? Пинг к нему с первого какой ? Нагрузка от пхп может и не упасть, в следствии долгого ответа от второго сервера. Если что, стучи, полечу пациента.

движок phpbb - в нем включен gzip на серваке установлен XCache v1.2.2. Сервер в этом же ДЦ - но это не принципиально, сегодня я и сайт перенесу на новый сервак, т.е. все будет на одном и БД и сайт.

у вас в таблице есть purchase_order который наверное соответствует либо вышеуказанному
purchase_id либо это индекс с sp_items, вследствии чего можно оптимизировать запрос и не использовать декартово умножение в исходном.

purchase_id - есть во всех 3-ех таблицах, это идишник закупки.

Стоит Vbulletin? Попробуй отключить на время капчу при реге и посмотри, не упадет ли нагрузка.

phpbb народу в сутки регится не так много человек 50 где то.

 

[Шумадан]

purchase_id - есть во всех 3-ех таблицах, это идишник закупки.

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

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_items`.`purchase_id` = '5317' AND `sp_items`.`bundle` != 's:0:"";'
`sp_cats`.`hidd en` = '0' AND `sp_cats`.`bundle_var` != '' AND тут добавить фильтр по айдишнику закупки (5317?)
`sp_orders_items`.`item_order` = `sp_items`.`id_items` AND `sp_orders_items`.`state_order` != 3 AND `sp_orders_items`.`state_order` != 5 AND тут добавить фильтр по айдишнику закупки (5317?)
GROUP BY `sp_items`.`id_items` ASC;

попробуйте для начала посмотреть сколько получится записей в трёх таблицах если использовать только where по айдишнику закупки (в вашем случае я так понимаю это 5317)

модуль-функционал ваш или сторонний? ну, кто создавал эти запросы? если это вообще коммерц. примочка - тогда насиловать разработчика

PS: разделение mysql и вэб сервера было логичным путём попытки решения проблемы, но приципиально проблема не в этом (насколько я понял с описания).