Перегрузка подсчета к базе. Нужен рефакторинг имхо.

Главные вкладки

Аватар пользователя jura12 jura12 25 июня в 17:53

на сайте есть 2 самописных модуля и вычисляемые поля. подсчитывается с помощью них статистика , т.к. сайт большой около 150тыс записей сайт тормозит на 12 ядрах. перегружают его запросы к БД.
постоянно идут запросы типа :

SELECT COUNT(*) AS "expression" FROM (SELECT 1 AS "expression" FROM
и
Creating sort i SELECT "node_field_data"."

задача 1. переписать или разобраться как считается статистика и перенастроить на более редкий пересчет чтоб разгрузить процессор.
задача 2. на некоторых типов материала заголовки необязательны. говорят такая ситуация давно. при сохранении с пустым заголовком весь материал теряется.

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

Комментарии

Аватар пользователя jura12 jura12 27 июня в 22:18

первую задачу решили собственными силами.
уменьшил нагрузку рефакторингом темы. 200тыс страниц 5 представлений на каждой и 5 условий в каждом про сканировании 20ю ботами получается 40 млн условий. я снизил кол-во представлений с 5 до 2х. ожидал 30% прирост а оказался 60%.

Аватар пользователя kosskren kosskren 6 июля в 9:21

Привет.

Обычно по такой схеме действую, список в порядке важности:

1. Включить логирование медленных запросов к базе (slow_query_log). Время выполнения у запросов (long_query_time) выставить 0.5 для начала. На самом деле тут от специфики сайта зависит. Я обычно начинаю с 0.5, если в лог попадет мало запросов, то уменьшаю время - 0.5, 0.4 и т.д. Если в логе запросов будет очень много, то увеличиваем время, что бы найти самые долгие.
Время выставляется в секундах, 0.5 это пол секунды.

2. Найденные медленные запросы копируем и запускаем в консоли с параметром EXPLAIN.
Пример: EXPLAIN SELECT * FROM categories;
В интернете много статей про работу с EXPLAIN, тут не буду расписывать.

3. Индексы очень важны при работе с базой, надо понять, по каким условиям идет выборка в медленных запросах и настроить индексы. У меня на одном сайте есть таблица с 360 млн. строк. Без индекса выборка занимала 2-3 секунды, а с индексами 0.26-0.09 сек.

4. Смотреть код сайта, если тормозят все страницы, то ищем подозрительные участки кода в общих файлах, которые за страницу отвечают. Был случай, когда на всех страницах отрабатывал код, который в цикле делает 1040 запросов к базе с полной выборкой всех столбцов. Это замедляло открытие страниц на 3-4 сек.

5. Размер изображений. Чем меньше, тем лучше. Как вариант сделать подгрузку фотографий при скроле. Опят же история из практики). Был сайт с логотипом в шапке, размер логотипа 10 МБ. Были сайты, где фотографии весили по 4-15 МБ в каталоге.

6. Если на сайте есть сторонние JS библиотеки или сайт на бэке обращается к сторонним сервисам, то вполне может быть долгий ответ от сервиса.

7. Когда на сайте будут решены проблемы, то задуматься о кешировании. Тут в помощь кеш друпала, так же можно использовать Redis или Memcache.

8. Бывает сайт грузят боты поисковых систем, можно по юзер-агенту на бэке отдавать 404 ошибку, либо сделать нужные настройки в конфигах Apach/Ngnix.

Аватар пользователя jura12 jura12 22 сентября в 7:35

спасибо за подробный ответ. я провел 2 расследования.
1. на предмет использования поискового модуля. его отключить не дали. хотел разгрузить ядра. написал программу логирования запросов. оказалось что пользуются им не часто. но бывают ДДОС атаки по поиску. каптчу установить на поиск для друпала 10 пока не удалось. буду думать насчет капчи.
2. программа mytop выдает частые запросы с поиском количества записей (count *). я написал программу чтобы выяснить кто эти запросы посылает. и оказалось debug_print_backtrace() выдает что это обыкновенный views, причем вызывается их index.php и зачастую использование кэша БД. получаются что боты долбят стартовую и другие страницы, и даже кэшированные страницы перегружают ядра запросом count *. В общем решил делать кэширование на статику на уровне апачи. сначала на диске, а при удачном тестировании в памяти. в ближайшее время займусь.
Все дело в деньгах. ежемесячно выделяется на VPS 10тр. при уменьшении ядер (если нагрузку удастся снять) и увеличении оперативы (она дешевле) получится экономия и скорость работы.
3. fail2ban тоже запретили ставить. он блочит подсети клиентов.
4. потом уже займусь включением http2 и уменьшением изображений . если заплатят.