Нагрузка сервера, MySQL. Решения, выявляющие скрипты, которые нагружают базу

Polzovinst,
Эвакуируйтесь оттуда. Я помогу.

Polzovinst,
Эвакуируйтесь оттуда. Я помогу.

Ris, спасибо большое!) Держу на заметке. И хостеров, которых порекомендовали. Пока потерплю. Обстановка покажет сколько времени.

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

Пока потерплю

Они так и будут над вами издеваться, бегите от них.

Polzovinst, возможно, Вам действительно лучше сменить хостинг.
Но перед этим было бы интересно всё-таки выяснить, где и отчего тормоза. Сделайте два шага:
1. У Вас есть какие-то графики поминутной нагрузки на ЦП. Выберите на нём одну из последних "тяжёлых" минут.
2. Посмотрите в access.log (лог запросов Апача), какие запросы и от каких юзер-агентов приходятся на эту минуту. Файл access.log может либо лежать в папке с логами в Вашем пользовательски каталоге, либо быть доступен к просмотру через панель управления хостингом.

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

kirkr, спамеров нет, упаси Инстант. Если бы были я б уже тут хай поднял.

1. У Вас есть какие-то графики поминутной нагрузки на ЦП. Выберите на нём одну из последних "тяжёлых" минут.
2. Посмотрите в access.log (лог запросов Апача), какие запросы и от каких юзер-агентов приходятся на эту минуту.

WebMan, спасибо. Тоже хороший пункт анализа. Проверю.
Единственное, однажды отключил access.log лог посещений. В службе поддержки хостера посоветовали. Из-за того что с Улогином не получалось.
Сейчас включу, проверю.

У Вас есть какие-то графики поминутной нагрузки на ЦП.

Поминутных графиков нет. только по дням вроде.

Сейчас сформулирую мысль, а потом день-два нужно на проверку, чтоб посмотреть нагрузку.

Хорошо, что WebMan напомнил за access.log (лог посещений).

Или нет, я сначала проверю, а потом, если подтвердится, то отпишусь. А то опять на людские компоненты чтоб лишнего не говорить.

На сайте 350к записей в одном типе контента, категории отключены, тип таблиц БД innobd, инстант 2.10.

При включенном режиме отладки на странице списка выдает такое:


Время загрузки страницы 2.92s, и дальше запросы к БД:


Страница записи, время загрузки 4.71s, длинные запросы:



Что можно с этим сделать? Как ускорить? Спасибо.

А в админке всё летает.

При этом на сайтах, где мало записей (до 50к), всё работает гораздо быстрее и в списке, и в записи. А если до 1000 записей, то загрузка вообще занимает доли секунды.

шэльдэ бердэ бельдэ,
Попробуйте создать в вашем типе контента датасет all, по образцу датасета "Все" в статьях в демоконтенте. Причем можете его даже не отображать на сайте.
А дальше посмотрим, что можно сделать.

создать в вашем типе контента датасет all, по образцу датасета "Все" в статьях в демоконтенте

На понял, если честно, что нужно и где создать. На сайте один тип контента, у него есть один набор (это датасет, правильно?). Сортировка:

поднять вверх (флаг — ставится отредактированным записям) — по убыванию
просмотры — по убыванию
заголовок — по возрастанию
дата публикации — по возрастанию

Где еще нужно создать такой набор? Создать тестовый тип контента?

Сама запись тупит понятно теперь из-за чего — из-за поля навигации. Сделал сортировку по полю "поднять вверх" — время загрузки страницы 0.09 секунд.

Но потом перешел на соседнюю страницу, и получил другой длинный запрос:

У меня такая же проблема instantcms.ru/forum/thread29867-1.html#291892

Удалось снизить нагрузку.

(Путём попадания компонента под подозрение вычислением времени и подтверждением подозрения через отключение компонента и его отдельных функций)

За Пинг извиняюсь.
Это не он. Может он какую-то нагрузку и создаёт, но явно не такую.

В те же сутки устанавливал платный компонент.
Хорошо, что везде можно отследить время: платежи, скачивания. Буду обращаться к автору, может что-то подхимичит.

Вывод такой:
1) Не нужно всё одновременно устанавливать.
2) Нужно отслеживать реакцию организма сайта после установки вещей, которые устанавливаешь первый раз.


Уже даже сначала НеоМесседжер заподозревал, из-за того что лог посещений был усыпан им ежеминутно, и здесь instantcms.ru/addons/firemessages.html
прочёл это
Но подозрения не подтвердились.

Из потока вашей информации так и не понял, какой же конкретно компонент давал повышенную нагрузку на БД.

Из потока вашей информации так и не понял, какой же конкретно компонент давал повышенную нагрузку на БД.

Пока лучше не говорить. Компонент платный. Завтра автору напишу, пусть сделает что-нибудь.

Подниму-ка эту тему снова.

Итак, новый сайт. 105к статей. Никаких сторонних дополнений, инстант 2.10.1. Из виджетов только персональное меню и облако тегов. Причем, если убрать их, то картина не меняется. База innobd. Кеширование включено.

Отладка показывает такое для списка записей:


Как это можно оптимизировать и ускорить? Или может вообще отключить эти запросы? Как это сделать? И на что это повлияет? Планируется 500к статей. Но если при 100к такие тормоза, то при 500к сайт вообще ляжет, видимо.