Как снизить нагрузку сервера?

Question

[Андрей Еськов]

Доброго всем времечка!

Имеется виртуальный сервер.
Память: 4 GB
Процессор: 1 core
Диск: 40 GB

Стоит ispmanager5 развёрнуто пару сайтов на YII2. И тут я решил перенести сайт на Joomla+VM (хостинг ругался всегда что убивает mysql из за нехватки памяти, было 2 гага.)

Теперь и мой сервачёк нагнулся, он то работает, но Htop показывает что при каждом переходе по сайту проц кушает 100процентов. И загрузка сайта намного увеличивается.

А оператива кушается на 94-97 процентов.



Собственно вопрос помогите, хоть немного сбросить нагрузку. Только прошу отвечать более развёрнута, какая команда, где лежат файлы и так далее))) а то я нубик)

Comments

[Евгений]

У вас много mysqlей запущено

[Андрей Еськов]

Если я их закрою, то думаю хорошего не будет, как проследить чтобы лишние не запускались, или почему они зупустились?

Answer 1

[romy4]

профилирование и ещё раз профилирование. Ищите отсутствие индексов в запросах, затем переделывайте запросы, затем агрегируйте данные.

Comments

[Андрей Еськов]

Ваш ответ много мне не сказал, ну пойду гуглить.

[Андрей Еськов]

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

[romy4]

Андрей Еськов: нет единого решения для столь размытых вопросов. Если б вы спросили. вот такой-то запрос, с такими-то данными, с такой-то структурой таблиц работает медленно — было бы о чём говорить. А между запросом пользователя и ответом ему миллионы операций и кто знает, в чём могут быть тормоза?

[Андрей Еськов]

А вы не могли бы подсказать, как отследить какой именно скрипт тормозит базу, или хотя бы компонент и так далее, есть решения из коробки, или лопатить логи?

[romy4]

проверьте количество запросов: может вас ддосят местами.
если нет, то включите сперва slow_query_log и настройте long_query_time секунды на 3, после чего смотрите в логах что так нагружает. можно пробежаться по запросами и затем по таблицам, расставив индексы на числовые и некоторые текстовые поля (если таблицы не слишком большие), которые используются в запросах.
это как для затравки я обычно делаю

[Андрей Еськов]

Спасибо пойду пробовать!

Answer 2

[Андрей Еськов]

Оказывается это хДебаг, жрал всю систему на сайте 1000 хостов, и вот они и генерировали нагрузку.

Comments

[abcyu]

Если много видео или графики - вынести на сторонний специализированный хостинг типа Cloud Storage.

Настройка nginx?
Вы же писали ispmanager5 там одной галочки достаточно.

[Андрей Еськов]

abcyu: Ставил галочку, но все сайты перестали работать.

[abcyu]

Андрей Еськов:
когда ставишь галочку, nginx прописывается на 80 порту.
а apache уходит на не помню какой порт, может 8080.
и в кофах ngin прописывается прокидывание на 8080.

после установки галочки проверьте в конфигурационных файла - а так ли это.

[Андрей Еськов]

Вообщем нашёл ещё 1 проблему, теперь и жёский диск весь заполнен файлами cachegrind.out в tmp насколько я понимаю это хдебаг. Ох на мою головушку то сколько упало.

Answer 3

[Юрий]

Единого совета тут дать нельзя.
Есть нечто общее для облегчения страданий.
1. (Тут я советую вообще всем направо и налево) Поставить nginx на отдачу статических файлов (не забыв включить сжатие), разгрузив апач. Этим немного снизится нагрузка при отдаче многочисленных JS и CSS-файлов. Т.е. общее самочувствие немного улучшится.
2. Включить slow-log в MySQL, чтобы увидеть медленно выполняющиеся запросы и запросы, которые не используют индексы. Люди часто забывают про составные индексы и в результате SELECT на пару полей, который должен в результате вернуть два значения, лопатит всю таблицу в несколько сотен тысяч записей.
3. Профилирование PHP. Поставить для PHP xdebug или XHProf. На примере xdebug - включил модуль, рестартнул/релоаднул апач, походил по самым тормозным ссылкам (или подождал несколько секунд, пока пользователи по ним походят), закомментил модуль, опять релоаднул апач, чтобы вернуть в нормальное состояние. Ну а затем QCacheGrind в руки, открываем самые жирные файлы дампов и смотрим, куда тратится время при выполнении...

Answer 4

[Макс]

slow_query_log, потом EXPLAIN для медленных запросов, затем индексы.
следующий шаг - PROCEDURE ANALYSE. Нередко данные хранятся совсем не оптимально - и можно хорошо выиграть на оптимизации типов данных.