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

[demon201984]

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


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

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

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

Функционал не мой - сторонний и зашифрованный, да придется к разрабу обращаться с просьбой исправить, если запрос будет реально выгднее по времени по сравнению с текущим (потестю).

Mysql и веб сервер разделил лишь на время, планирую все-таки все держать в одном месте - там куда перенес ныне mysql (сервер куда мощнее предыдущего).

Как показал текущий день - функционал вырубать не пришлось - он худо бедно но отработал: периодически нагрузка на ЦПУ повышалась до 100%, а не так как ранее постоянно 100%, load_average бывало тоже возрастал где то до 17, но тоже не так часто, в среднем держится на уровне 2-4.

 

[ne4to]

Функционал не мой - сторонний и зашифрованный

а этот функционал поддерживает кеширование ?

 

[demon201984]

без понятия, даже не знаю как это проверить.

 

[demon201984]

да ставил обновление на сайт. Файлы на сервере вернул в первоначальное состояние из бекапа (на 100% вернул). Данные в БД, конечно да откатил деинсталяцией - но они откатились все (это точно). Каким образом обновление таблиц в БД могло сказаться на производительности ума не приложу до сих пор. А само по себе обновление очень интересное и я хочу все таки чтобы оно у меня работал, но теперь побаиваюсь его ставить(

Но может все-таки на все это повлияло и не мое обновление а это, хотя вообще мало понимаю о чем в этом сообщении речь

Скорее всего проблема связана с тем, что в связи с ночной аварией хост-сервер, на котором расположен Ваш VDS, был включен не так давно и не все необходимые наиболее популярные данные с дисков сервера были прочитаны и попали в кэш в оперативной памяти. Постепенно данные будут попадать в кэш оперативной памяти и ситуация должна улучшиться, вероятно уже в ближайшие часы нагрузка должна стать меньше.

 

[Шумадан]

Функционал не мой - сторонний и зашифрованный, да придется к разрабу обращаться с просьбой исправить, если запрос будет реально выгднее по времени по сравнению с текущим (потестю).

Mysql и веб сервер разделил лишь на время, планирую все-таки все держать в одном месте - там куда перенес ныне mysql (сервер куда мощнее предыдущего).

Как показал текущий день - функционал вырубать не пришлось - он худо бедно но отработал: периодически нагрузка на ЦПУ повышалась до 100%, а не так как ранее постоянно 100%, load_average бывало тоже возрастал где то до 17, но тоже не так часто, в среднем держится на уровне 2-4.

да, пусть разработчик наведёт порядок с знаниями t-sql ещё и зашифровал небось, чтоб не было видно, какой там адЪ. по сути, можно в прицнипе оставить как есть, но по мере наполнения тех трёх таблиц демоны из шкафа опять могут выпрыгнуть