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

Тема в разделе "Администрирование серверов", создана пользователем demon201984, 18 мар 2013.

Статус темы:
Закрыта.
Модераторы: mefish
  1. demon201984

    demon201984 Постоялец

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

    jia3apb Создатель

    Регистр.:
    19 мар 2013
    Сообщения:
    20
    Симпатии:
    5
    Высокая нагрузка на php и при этом в логах апача ничего нет?
     
  3. SkiLLer

    SkiLLer

    Регистр.:
    22 авг 2007
    Сообщения:
    306
    Симпатии:
    61
    Сделай вывод медленных запросов в файл и уже от этого отталкивайся, смотри в каком именно месте ложится.
     
  4. jia3apb

    jia3apb Создатель

    Регистр.:
    19 мар 2013
    Сообщения:
    20
    Симпатии:
    5
    Он же говорит, что базу перенес на другой сервер. Получается дело уже не в медленных запросах.
     
  5. mefish

    mefish Support

    Moderator
    • Супермодератор
    Регистр.:
    30 авг 2007
    Сообщения:
    913
    Симпатии:
    653

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

    Шумадан Хабарра!!11

    Регистр.:
    6 фев 2008
    Сообщения:
    1.740
    Симпатии:
    2.120
    вы пробовали запускать тот запрос, который я постил, почему на sp_orders_items так мало ограничений, в то время как
    у вас в таблице есть purchase_order который наверное соответствует либо вышеуказанному
    purchase_id либо это индекс с sp_items, вследствии чего можно оптимизировать запрос и не использовать декартово умножение в исходном.
     
    demon201984 нравится это.
  7. ne4to

    ne4to Постоялец

    Регистр.:
    16 ноя 2012
    Сообщения:
    107
    Симпатии:
    50
    молодой человек, Ваши ответы меня не перестают удивлять, смоделируйте ситуацию в уме

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

    Doctor_Chaos Проктолог-гинеколог

    Moderator
    • Супермодератор
    Регистр.:
    7 сен 2013
    Сообщения:
    952
    Симпатии:
    659
    Стоит Vbulletin? Попробуй отключить на время капчу при реге и посмотри, не упадет ли нагрузка.
     
  9. demon201984

    demon201984 Постоялец

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



    sp_items 460,601
    sp_orders_items 334,936
    sp_cats 10,956
    Итого приблизительно 800 тыс. записей
    движок phpbb - в нем включен gzip на серваке установлен XCache v1.2.2. Сервер в этом же ДЦ - но это не принципиально, сегодня я и сайт перенесу на новый сервак, т.е. все будет на одном и БД и сайт.


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

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

    Шумадан Хабарра!!11

    Регистр.:
    6 фев 2008
    Сообщения:
    1.740
    Симпатии:
    2.120
    тоесть вы его можете включить в where условие чтоб отсечь огромное колличество ненужных записей в sp_orders_items и sp_cats, тоесть по сути было б логично сделать так
    попробуйте для начала посмотреть сколько получится записей в трёх таблицах если использовать только where по айдишнику закупки (в вашем случае я так понимаю это 5317)

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

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