Почему не получается оптимизировать mysql?

Question

[annonimus]

Всем доброго времени суток! Ребят, что-то никак не получается оптимизировать mysql. Вчера даже в техподдержку обращался, они провозились несколько часов и бесполезно, даже медленней сайт стал работать. Сейчас конфиги my.cnf ихние и знаю что нужно например повысить "max_connections до 70", просто оставил все как есть, чтобы вам показать. Но многие конфиги, которые советует поправить "phpmyadmin" никак не реагируют, прибавляешь или убавляешь, все равно просят прибавить или убавить до бесконечности. До этого пару раз оптимизировал при помощи mysqltuner и советчика phpmyadmin, а на этот раз что-то никак. Сейчас mysqltuner просит подправить пару конфигов, но все равно проблему не решит. Ну ладно к делу:
Система 2 СPU/2 GB RAM/30 GB SSD. mysql Ver 15.1 Distrib 10.1.38-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2, PHP 7.0.33

my.cnf

phpmyadmin Все переменные состояния

Советчик phpmyadmin

Несколько дней назад включал запись журналов медле...

Спасибо!

Answer 1

[Кирилл Горелов]

Парень, этого мало, что ты рассказал.
Ты бы описал что за проект у тебя, может тебе в принципе стоит сменить сервер?

Но это ладно.
Обязательно проштудируй этот раздел, раз на то пошло дело!
https://ruhighload.com/mysql

Comments

[annonimus]

Блоговый портал вот демо. Картинки, текст.
До этого работал на менее мощном сервере проблем со скоростью не было в 200 мс, а сейчас меньше 1000 мс не могу снизить. Да и сейчас, если не досят или не парсят нагрузки нет. Мне наверно нужно из my.cnf убрать лишнего, прописать самые минимальные настройки и уже потом запускать mysqltuner и править.
Спасибо!

[Кирилл Горелов]

annonimus, Я как понял это просто верстка,а не реальный проект?
Но реальный проект ни чем не отличается от текущего, правильно?

В идеале лучше конечно же реальную ссылку.

[annonimus]

Кирилл Горелов, Я вам на почту сбросил. Спасибо!

[annonimus]

Кирилл Горелов, Вы посмотрели? А то у меня с почтой маленькие неполадки, письма не приходят. Меня интересует почему долгая "Первая отрисовка контента (FCP)
4,3 s" . Может это из-за dns или что нибудь другого?
Спасибо!

[Кирилл Горелов]

annonimus, А вы сами где находитесь территориально?
У меня в первый раз страница загрузилась за 30 секунд.
Потом даже с отключенным кешем грузилась в районе 1,5 секунд.
Что в принципе достаточно не плохо, по сравнению с 30 секундами)

Случайно такие лаги начались не с установкой https? Потому что достаточно долгое соединение идет. И конечно же надо оптимизировать бэкенд. Запросы и прочие занимает 1,37 секунды. Я как понимаю ларавель стоит? Для него это долго.
Но дело не в самом mysql, потому что параметры сервера позволяют не плохо работать для блогового сайта. А скорее всего просто где-то не очень грамотно составлен запрос к самой БД.
Или может наоборот, очень много идет запросов к БД что бы собрать страничку.

Сколько записей в таблице со всеми статьями, больше миллиона? Если да, посмотри каких не хватает индексов, проставь.
Если меньше, то включи профилировщик и посмотри что долго исполняется.

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

[annonimus]

Кирилл Горелов, Привет! У вас страница долго загружалась наверно тогда когда я оптимизировал, совпало. Все проблемы начались после переезда на это сервер. Кстати, как мне кажется и с DNS есть проблемы, в REG обращался сказали что нормально. Да ларавель стоит. Записей чуть больше 400 тысяч. И насчет профилирования. Вот я сделал и вижу что с...

#    1 0x7E8A19E98B409193 2641.9772 29.2%  5880 0.4493  0.11 SELECT posts popularity_stats
#    2 0x9A98859D349B0134 2568.4028 28.4%  5831 0.4405  0.09 SELECT entries
#    3 0x4D075C8C784F3121 1581.7169 17.5%  6491 0.2437  0.06 SELECT posts popularity_stats
#    4 0xE80587EEE3B13558 1210.2278 13.4% 58332 0.0207  0.01 SELECT popularity_stats
#    5 0x34D1DDB7C630E891  501.0524  5.5% 38054 0.0132  0.00 SELECT reactions
#    6 0x2CE1548273FDE4E9  146.9600  1.6%  8593 0.0171  0.01 SELECT reactions
# MISC 0xMISC              402.2141  4.4% 13802 0.0291   0.0 <93 ITEMS>

что-то не так. Как мне можно их подправить? slow_query_log на четыре часа включал.
Спасибо!

[Кирилл Горелов]

annonimus, Слушай, 400 тысяч, это как кот наплакал. К тому же с твоими характеристиками сервера.

1. За сколько ты хочешь что бы у тебя грузилась страница?
2. За сколько у тебя она сейчас грузиться?
3. Сделай отдельно explain

[annonimus]

Кирилл Горелов, Кирилл, мне нужно добиться чтобы значение показателя "FCP" было меньше 2 секунд. Гугл ввел экспериментальную функцию "скорость загрузки" и как мне кажется выкидывает из топа сайты, которые не укладываются в 2 секунды.


Ну а по третьему, как разберусь отпишусь.

[Кирилл Горелов]

annonimus, Ничем не подкрепленные факты, что выкидывает.
Он пока ввел, что бы показывать пользователям, что сайт медленный, но не значит, что он выбрасывает из топа.

Кстати, проанализируй тут https://gtmetrix.com

И я сейчас глянул, у тебя dns стал лучше работать, сейчас от него нету больших задержек.
Посмотрим на explain и от этого оттолкнемся.

[annonimus]

Кирилл Горелов, Привет Кирилл. Сделал EXPLAIN трех основных запросов, которые сыпятся в mysql-slow.log, вот результат.







что с ними не так?
Спасибо!

[Кирилл Горелов]

annonimus, Привет. У тебя нету индексов. У тебя запрос ищет по всей таблице.
НО, это в принципе не очень критично, потому что у тебя таблица маленькая. Даже таблица на 300 тысяч записей не так критично. Я тебе это еще в самом начале сказал, что возможно дело не в таблице.

Так на наверняка запросы выполняются за 0,005 секунд, примерно, но не целые секунды, ведь так? У тебя просто на скриншоте этого нету. Я и предположил.
К тому же в предыдущих ответах, где ты прислалал slow_query_log, там у тебя запрос, самый тяжелый выполняется за 0,11. остальные за 0,06-0,09. Это не идеально, но мало.

Проставь индексы ......
Если не поможет, то разбирайся в коде.
Я тебе пример приведу. У нас есть проект, там есть простенькая аналитика. Она грузилась за 20 секунд. Предыдущий программист просто поленился подумать, что бы сделать грамотно. У него шел цикл и в каждом цикле шел запрос к таблице. Это была основная причина тормозов.
Сделали рефакторинг, стало грузиться за пару секунд.

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

Но лучше сначала разберись в коде. Поставь профилировщик, их огромное количество вариантов.
Оставь таблицу в покое ))

[annonimus]

Кирилл Горелов, Спасибо, Кирилл. Индексы добавил, медленных запросов практически нет. Проблему скорее всего нужно искать в другом месте, а не MYSQL.

[Кирилл Горелов]

annonimus, блин, дружище))) я же с самого начала сказал)!

Ну хорошо, что помогло))

[annonimus]

Кирилл Горелов, Привет, Кирилл. Проблему скорее всего нашел. По всей видимости дело в большом "меню". Практически сразу после переезда на другой сервер и обновления, я добавил категории, их не было совсем. В общем-то, я выяснил это после того, когда загрузил базу на локальный сервер. Даже там были тормоза, но когда я по удалял категории скорость заметно прибавилась. У меня к вам такой вопрос, что делать? =) В гугле толком ничего нет (может не так ищу), но я встречал похожую ситуацию вот тут человек советует в PHP увеличить "max_input_vars", но я как-то увеличивал и не заметил прироста. Вообще сайт до переезда и т.д. работал вот так или так (сайты работают на том же скрипте). Можно конечно категории поудалять, но как-то не то будет =). Спасибо.

[Кирилл Горелов]

annonimus, привет.
Мне сложно сказать что-то без кода. Но раз дело в меню.
ТО сделай его статическим. Оно все равно будет изменяться раз в полгода, максимум(по крайней мере по своему опыту сужу).
Без кода и узкого места очень сложно сказать.

Посмотри вот это https://phprussia.ru/2019/abstracts/5154 найдешь для себя что-то, это точно.