Повышенная нагрузка на сервер баз данных

[saigontov 2]

Добрый день! Сайт: alcoexpert (dot) ru, версия DLE 13.2

Хостер одолел сообщениями о повышенной нагрузке на сервер баз данных:

Вас приветствует компания .masterhost!

Уведомляем Вас, что работой базы данных MySQL uXXXXXX создается повышенная нагрузка на сервер баз данных. Примеры запросов находятся в прикрепленном файле.

Оптимизируйте, пожалуйста, Ваши скрипты, SQL-запросы и дайте нам знать о результатах.  Например, Вы можете использовать метод EXPLAIN для выяснения "тяжелых" запросов и создание индексов (CREATE INDEX), тем самым снизив нагрузку на базу данных:
* http://masterhost.ru/support/faq/technical/mysql-optimization/

Обращаем Ваше внимание, что при сохранении нагрузки, мы будем вынуждены заблокировать
услугу MySQL.

 

 

Информация из прикрепленного хостером файла: 

SET timestamp=1578650391;
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE date < '2020-01-10 12:59:31' AND approve=1 ORDER BY fixed DESC, date DESC LIMIT 0,4;

SET timestamp=1578650391;
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE date < '2020-01-10 12:59:33' AND approve=1 ORDER BY fixed DESC, date DESC LIMIT 0,4;

SET timestamp=1578650391;
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE date < '2020-01-10 12:59:34' AND approve=1 ORDER BY fixed DESC, date DESC LIMIT 0,4;

SET timestamp=1578650391;
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE date < '2020-01-10 12:59:23' AND approve=1 ORDER BY fixed DESC, date DESC LIMIT 0,4;

SET timestamp=1578650391;
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE date < '2020-01-10 12:59:24' AND approve=1 ORDER BY fixed DESC, date DESC LIMIT 0,4;

SET timestamp=1578650391;
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE date < '2020-01-10 12:59:24' AND approve=1 ORDER BY fixed DESC, date DESC LIMIT 0,4;

SET timestamp=1578650391;
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE date < '2020-01-10 12:59:24' AND approve=1 ORDER BY fixed DESC, date DESC LIMIT 0,4;

SET timestamp=1578650391;
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE date < '2020-01-10 12:59:24' AND approve=1 ORDER BY fixed DESC, date DESC LIMIT 0,4;

SET timestamp=1578650391;
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE date < '2020-01-10 12:59:24' AND approve=1 ORDER BY fixed DESC, date DESC LIMIT 0,4;

SET timestamp=1578650391;
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE date < '2020-01-10 12:59:24' AND approve=1 ORDER BY fixed DESC, date DESC LIMIT 0,4;

 

 

 

Я далеко не силен по части SQL и потому не могу сообразить, каким образом снизить нагрузку на базу данных. 

Может есть с ходу какой-то вариант? В какую сторону разбирать проблему? 

 

Из предполагаемых причин рассматриваю следующие:

• На главной странице сайта действительно много конструкций с функцией { custom category= ... } для вывода превью новостей из разных категорий с разным внешним видом, но строго говоря, раньше я никогда не получал претензий от других хостеров используя такие конструкции
• Основные 10 категорий новостей являются дочерними категории с ID=2 (на сколько я понимаю именно она фигурирует в SQL запросах?) . При этом, мы почти не используем саму категорию ID=2 при добавлении новости. Может категории вынести из под родительской?
• На сайте 42 000+ новостей. При обращении запроса обрабатывается вся база? 
• Может у хостера стоят относительно низкие пороги? 

 

Подскажите пожалуйста, что думаете на этот счет? 

[Datagor 31]

Кастомы кэшированы?

 

[celsoft 6 077]

10 часов назад, saigontov сказал:

каким образом снизить нагрузку на базу данных. 

В самих запросах никаким. Они простые. Поэтому либо смена хостинга, либо уменьшение custom. Я бы сменил хостинг. При условии что на сайт вообще нет DDOS по какому то адресу например по адресу категории.

 

10 часов назад, saigontov сказал:

Основные 10 категорий новостей являются дочерними категории с ID=2 (на сколько я понимаю именно она фигурирует в SQL запросах?) . При этом, мы почти не используем саму категорию ID=2 при добавлении новости. Может категории вынести из под родительской?

Не играет никакой роли родительская или дочерняя выборка идет по ID, т.е. выборка идет с запросов именно только из категории 2, смотрите в шаблонах, где вы осуществляете показ из ее категори. Или например идет много обращений по адресу просмотра самой категории, это логи сервера нужно смотреть.

 

10 часов назад, saigontov сказал:

На сайте 42 000+ новостей. При обращении запроса обрабатывается вся база? 

Что вы имеете ввиду? При любом SQL идет обработка всех базы. Всегда и независимо от запроса. А вот по критериям в запросе отдается уже то что нужно. Но чтобы найти нужное нужно осмотреть всю базу, для этого и существуют например ключи БД, чтобы сделать это быстро. Ваш запрос простой и ключи точно есть для этих полей, упростить его по сути нельзя.

10 часов назад, saigontov сказал:

Может у хостера стоят относительно низкие пороги? 

Вполне может быть. От тарифа вашего зависит. Узнавайте лимиты и пороги для каждого тарифного плана у хостинга.

[saigontov 2]

В 11.01.2020 в 01:10, celsoft сказал:

Не играет никакой роли родительская или дочерняя выборка идет по ID, т.е. выборка идет с запросов именно только из категории 2, смотрите в шаблонах, где вы осуществляете показ из ее категори. Или например идет много обращений по адресу просмотра самой категории, это логи сервера нужно смотреть.

@celsoft, спасибо за развернутые ответы. Должен извиниться, я немного ошибся! Все же при добавлении новостей на сайте, Редактор отмечает несколько категорий: (например ID=5 и ID=2 в качестве второстепенной) и так во многих новостях.

 

Посмотрел базы: с начала по конец 2019 года к категории ID=2 присвоено 2600+ новостей (вроде не так много). 

А вот посмотрев логи за вчера ужаснулся:  так или иначе в 60 000 из 130 000 строк фигурирует категория ID=2 . 

 

Какие вижу причины: 

• Наверное не нужно редактору ставить категорию ID=2 в качестве второстепенной, если она и так является материнской для (например той же) категории ID=5, куда и рассчитана новость. 
• За этот вариант меня не ругайте сильно, но есть ли разница при последовательном порядке выбора категории во время добавления новости?
  Например если мы выбираем в порядке [2,5] то новость сначала присваивается к категории 2, как к основной?
  А если выбираем [5,2] то новость присваивается к категории 5, как к основной? 
  Просто мне помнится, я где-то с этим уже сталкивался.

@celsoft, подскажите, есть ли в этом логика?

 

В 11.01.2020 в 01:10, celsoft сказал:

Не играет никакой роли родительская или дочерняя выборка идет по ID, т.е. выборка идет с запросов именно только из категории 2, смотрите в шаблонах, где вы осуществляете показ из ее категори. Или например идет много обращений по адресу просмотра самой категории, это логи сервера нужно смотреть.

 

Если один из двух верхних пунктов имеет значение, то все мои конструкции {custom} разумеется «дико давят» на базу.  При этом не так много обращений идет по адресу просмотра самой категории. Словом не так-то и много трафика на сайте (менее 1000 посетителей в сутки – это же смех), чтобы существенную нагрузку на страницу категории давать в моменте (даже в моменте).

 

В 11.01.2020 в 01:10, celsoft сказал:

Вполне может быть. От тарифа вашего зависит. Узнавайте лимиты и пороги для каждого тарифного плана у хостинга

Хостер не очень адекватный имхо, посредственно ведет себя в диалогах. 

[mr. Freeman 11]

11 часов назад, saigontov сказал:

• Наверное не нужно редактору ставить категорию ID=2 в качестве второстепенной, если она и так является материнской для (например той же) категории ID=5, куда и рассчитана новость. 
• За этот вариант меня не ругайте сильно, но есть ли разница при последовательном порядке выбора категории во время добавления новости?
  Например если мы выбираем в порядке [2,5] то новость сначала присваивается к категории 2, как к основной?
  А если выбираем [5,2] то новость присваивается к категории 5, как к основной? 
  Просто мне помнится, я где-то с этим уже сталкивался.

Не имеет смысла, сохраняются всё равно в порядке возрастания ID.

[celsoft 6 077]

18 часов назад, saigontov сказал:

Наверное не нужно редактору ставить категорию ID=2 в качестве второстепенной, если она и так является материнской для (например той же) категории ID=5, куда и рассчитана новость. 

если вы вообще не публикуете новость в две категории и более, то поддержку мультикатегорий в настройках нужно отключить, это снизит нагрузку на сервер. Если категория родительская, а вы публикуете только в подкатегории, то будет ли она показываться также и в родительской или нет, зависит от настроек скрипта в админпанели, там можно включить или выключить показ новости в родительской.

 

18 часов назад, saigontov сказал:

За этот вариант меня не ругайте сильно, но есть ли разница при последовательном порядке выбора категории во время добавления новости?
Например если мы выбираем в порядке [2,5] то новость сначала присваивается к категории 2, как к основной?
А если выбираем [5,2] то новость присваивается к категории 5, как к основной? 

Это напрямую зависит не от ID, а от порядка сортировки категорий в разделе управления категориями. В каком порядке вы их отсортируете, в том они и будут. Основной соответственно будет первая которая идет по этому списку.

 

18 часов назад, saigontov сказал:

Если один из двух верхних пунктов имеет значение, то все мои конструкции {custom} разумеется «дико давят» на базу.  При этом не так много обращений идет по адресу просмотра самой категории. Словом не так-то и много трафика на сайте (менее 1000 посетителей в сутки – это же смех), чтобы существенную нагрузку на страницу категории давать в моменте (даже в моменте).

Выборка идет независимо от того как и что добавили. Это не влияет на нагрузку. Влияет на нагрузку уже другие настройки. Например есть ли поддержка мультикатегорий, количество этих самых custom. и т.д. В админпанели есть раздел анализ производительности, он покажет вам все настройки которые влияют на нагрузку сайта. Все что вам не нужно обязательно отключите. От цвета зависит степень нагрузки, красное отключайте в первую очередь.

[mr. Freeman 11]

20 часов назад, celsoft сказал:

Это напрямую зависит не от ID, а от порядка сортировки категорий в разделе управления категориями. В каком порядке вы их отсортируете, в том они и будут. Основной соответственно будет первая которая идет по этому списку.

Раньше же по ID в порядке возрастания они писались в колонку category?

[celsoft 6 077]

8 часов назад, mr. Freeman сказал:

Раньше же по ID в порядке возрастания они писались в колонку category?

Вы не знаете принципов работы DLE. Никогда и ни в одной версии подобного не было. Сортировка категорий всегда в DLE выставлялась в админпанели в разделе управления категориями. Начиная с самой первой версии DLE.

[webair 178]

Тоже сайт клиента был на masterhost и получал такие же сообщения. Сменили хостинг (на timeweb, не реклама), никаких сообщений не приходит больше.

Два года назад у masterhost даже memcache не было и let's encrypt не подключали(только платные SSL сертификаты), сейчас не знаю как. Бегите )

Изменено 16 января 2020 пользователем webair

[mr. Freeman 11]

3 часа назад, celsoft сказал:

Вы не знаете принципов работы DLE. Никогда и ни в одной версии подобного не было. Сортировка категорий всегда в DLE выставлялась в админпанели в разделе управления категориями. Начиная с самой первой версии DLE.

Причём тут сортировка отображения категорий, если человек спрашивал про то как оно "внутри" DLE хранится при привязке новости к категориям?
На что я ответил что в колонку category выбранные категории попадают по ID в порядке возрастания.

2 часа назад, webair сказал:

Тоже сайт клиента был на masterhost и получал такие же сообщения. Сменили хостинг (на timeweb, не реклама), никаких сообщений не приходит больше.

Два года назад у masterhost даже memcache не было и let's encrypt не подключали(только платные SSL сертификаты), сейчас не знаю как. Бегите )

Ну да, побежим к тем кто не видит ничего такого, что одни их клиенты бомбят спамом других их клиентов, и считают такое в порядке вещей. Попутно забывают обновить свои сертификаты, по этому часто то один их сервис ляжет, то другой.
Анекдот про мышей и кактус слышали? Вот это про них в точности, по этому советовать их как пример качества и надёжности мягко говоря как то не очень, по уровню ничуть не лучше текучего хостера ТСа.

[celsoft 6 077]

19 часов назад, mr. Freeman сказал:

Причём тут сортировка отображения категорий, если человек спрашивал про то как оно "внутри" DLE хранится при привязке новости к категориям?
На что я ответил что в колонку category выбранные категории попадают по ID в порядке возрастания.

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

[kolyma 2]

Много лет сидел на DLE и началось, новостей более 90 000, посещаемость была 6000-8000 уников, просмотров 18-22000 в сутки. И сейчас все. Запросы к базе поперли тяжелые. Хаков нет, сторонних модулей нет. VPS не держит нехилый (RAM 8GB,
vCPU Cores 6x1GHz, SDD 60GB).

 

10 дней админы не могут побороть запросы к базе от скриптов DLE.

Лицензия пожизненная. Версия 12.1, не стал переходить на 13 из-за UTF т.к. по опыту других проектов базу грузит больше. Короче DLE не для больших проектов. Сайт для модеров Kolyma.ru
 

Сервак просто ложиться от запросов от DLE. И обычно во время, когда пользователи идут на сайт, в рабочее время по Магадану. 

 

запросы

 

73550 kolyma_k       localhost kolyma_ma     27   0.0  Sleep                                                                                                                                                                                              
    73733 kolyma_k       localhost kolyma_ma     26   0.0  Sleep                                                                                                                                                                                              
    73567 kolyma_k       localhost kolyma_ma     24   0.0  Sleep                                                                                                                                                                                              
    73768 kolyma_k       localhost kolyma_ma     22   0.0  Sleep                                                                                                                                                                                              
    73652 kolyma_k localhost:38498 kolyma_ko     19   0.0  Query Copying to tmp  SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    73793 kolyma_k       localhost kolyma_ma     19   0.0  Sleep                                                                                                                                                                                              
    73587 kolyma_k       localhost kolyma_ma     17   0.0  Sleep                                                                                                                                                                                              
    73840 kolyma_k       localhost kolyma_ma     14   0.0  Sleep                                                                                                                                                                                              
    73609 kolyma_k       localhost kolyma_ma     13   0.0  Sleep                                                                                                                                                                                              
    73886 kolyma_k       localhost kolyma_ma     12   0.0  Sleep                                                                                                                                                                                              
    72585 kolyma_k localhost:33014 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72592 kolyma_k localhost:33044 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72616 kolyma_k localhost:33160 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72636 kolyma_k localhost:33300 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72651 kolyma_k localhost:33410 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72661 kolyma_k localhost:33456 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72692 kolyma_k localhost:33718 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72698 kolyma_k localhost:33748 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72705 kolyma_k localhost:33780 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72713 kolyma_k localhost:33814 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72816 kolyma_k localhost:34208 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 
    72821 kolyma_k localhost:34242 kolyma_ko     11   0.0  Query Waiting for tab SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, 

 

Изменено 7 июля 2020 пользователем kolyma

[proba 57]

Для отображения главной страницы в районе 40 запросов идёт?

[kamensk 86]

32 минуты назад, kolyma сказал:

новостей более 90 000, посещаемость была 6000-8000 уников

Может сервер настроен не правильно.

У других сайтов дле, размещенных на хостингах - посещалка 40-60тыс. в сутки и ниче - живые, робят...

А у тебя на вдс посещалку в 6тыс, сайт не держит.

Есть над чем задуматься.

[kolyma 2]

Админ: Queries: 30.8k    qps:  281 Slow:    6.8k         Se/In/Up/De(%):    86/01/01/00
 Sorts:   2116 qps now:  538 Slow qps: 111.1  Threads:  126 ( 112/   5) 86/02/01/00
 Handler: (R/W/U/D) 18343/    9/   10/    0        Tmp: R/W/U:  6303/ 3297/ 3143
 ISAM Key Efficiency: 99.7%  Bps in/out: 46.1k/507.8k   Now in/out: 88.2k/950.8k
вот статистика по запросам. И она очень херовая
538К медленных запросов в секунду

 

это от админов

 

есть идеи?

Изменено 7 июля 2020 пользователем kolyma

[alex32 942]

А почему столько запросов? Кэшировование вообще никакое не включено?

[kolyma 2]

12 минут назад, alex32 сказал:

А почему столько запросов? Кэшировование вообще никакое не включено?

все включено мемкэш

и сервак лежит https://kolyma.ru повторюсь, конфигурация vps не плохая

Изменено 7 июля 2020 пользователем kolyma

[celsoft 6 077]

1. 40 запросов на главной сверх много. Это говорит о не работающем кеше, либо шаблон составлен так, что не использует кеш.

 

2. 

4 часа назад, kolyma сказал:

VPS не держит нехилый (RAM 8GB,
vCPU Cores 6x1GHz, SDD 60GB).

Если сам физический сервер перегружен другими vps и некорректно настроен это не играет никакой роли. Можно написать что угодно, физически сервер все равно обрабатывает всех по очереди и вас и соседей.

[alex32 942]

2 часа назад, kolyma сказал:

все включено мемкэш

Включите файловый

2 часа назад, kolyma сказал:

повторюсь, конфигурация vps не плохая

Это ни о чем не говорит, без должной качественной настройки вас может работать хуже шаринга. 

[Spywear 3]

У вас в верстке много ошибок,так грузить сервер наврятли конечно может,но все же...

Например:

<div class="slide1200none">
<div class="news-post image-post">
<a href="https://www.kolyma.ru/index.php?newsid=90384">
<div style="background:#000000;background: center;background-size:cover;height:100%;">
<a href="https://www.kolyma.ru/index.php?newsid=90384"></a>	
</div>

<div class="hover-box">
<div class="inner-hover">
<div class="titleslider"><a href="https://www.kolyma.ru/index.php?newsid=90384">Ответная благодарность депутату!</a></div>
<ul class="post-tagscustom">
<li><i class="fa fa-clock-o"></i>26-июн, 17:19</li>
</ul>
</div></div>
</a>
</div>
</div>

 

Изменено 7 июля 2020 пользователем Spywear

[Spywear 3]

Между <head> </head>

<div><img src="//top-fwz1.mail.ru/counter?id=52126;js=na" style="border:0;position:absolute;left:-9999px;" alt="" />
</div>

вообще не должно подобного быть.

После тега </body> и перед тегом </html> встроен iframe.

Перед </nav></header> два лишних </div>.

Очень-очень много ошибок в верстке и это тоже влияет на нагрузку.

[webair 178]

3 часа назад, Spywear сказал:

Между <head> </head>

<div><img src="//top-fwz1.mail.ru/counter?id=52126;js=na" style="border:0;position:absolute;left:-9999px;" alt="" />
</div>

вообще не должно подобного быть.

После тега </body> и перед тегом </html> встроен iframe.

Перед </nav></header> два лишних </div>.

Очень-очень много ошибок в верстке и это тоже влияет на нагрузку.

Это не влияет на нагрузку. Это говорит об уровне веб разработчиков проекта и о качестве настройки сервера. Не важно какое железо, хоть 32 ядер по 3.5 ггц и 64гб озу.

 

@kolyma p.s. Кстати, у вас vds около начального уровня. И это vds, а не выделенный сервер. 6 ядер всего по 1 ггц и всего 8 гб озу. Этого, конечно, достаточно для вашего проекта, но если всё хорошо настроено. Для настройки бд советую использовать mysqltuner - это лучше, чем наугад тыкать.

Изменено 8 июля 2020 пользователем webair

[Spywear 3]

20 часов назад, webair сказал:

Это не влияет на нагрузку. Это говорит об уровне веб разработчиков проекта и о качестве настройки сервера. Не важно какое железо, хоть 32 ядер по 3.5 ггц и 64гб озу.

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

[alex32 942]

27 минут назад, Spywear сказал:

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

Ваш комп к серверу не имеет никакого отношения, а тут речь о нагрузке на сервер.

[kolyma 2]

уже поубирал кучу custom, проект в какашку превращается, скоро титул будет из одной колонки просто(((, но админ упорно пишет, что проблемы в движке(((( 
Сейчас админ просто пишет, что надо на выделенный переходить, много запросов, а это дополнительные расходы еще(  повторюсь новостей 90000, уникальных сейчас 5000 в сутки, регистрация пользователей отключена, все кэширования, там gzip сжатия включены. Хоть блин уже календарь, публикацию на период, вывод похожих и т.д. отключай!!! . Но админ упорно пишет, что вся проблема в движке.

Изменено 12 июля 2020 пользователем kolyma