LINUX.ORG.RU
Форум — Admin  

Как узнать, что нагружает mysql

 


0

1

Приветствую! Сабж. mysql Ver 15.1 Distrib 10.1.21-MariaDB, for Linux (x86_64) using readline 5.1 В лог медленных запросов особо ничего не падает server.cnf: 

[mysqld]
skip-name-resolve
skip-networking
#low-priority-updates
key_buffer_size = 384M
max_allowed_packet = 8M
table_open_cache = 100000
sort_buffer_size = 64M
read_buffer_size = 64M
join_buffer_size = 384M
read_rnd_buffer_size = 32M
net_buffer_length = 2K
thread_stack = 128K
max_connections=1000
query_cache_size = 128M
query_cache_limit = 2M
tmp_table_size = 512M
max_heap_table_size = 512M
thread_cache_size = 64
ft_min_word_len=3
wait_timeout = 600
interactive_timeout = 120
innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 512M
innodb_flush_log_at_trx_commit = 0
innodb_lock_wait_timeout = 5
#Slow Query Log
slow_query_log = 1
long_query_time = 1
slow_query_log_file = /var/log/mysql_slow.log
log_slow_verbosity = query_plan
#log_queries_not_using_indexes
open_files_limit = 8192
После обновления mariadb, а может это просто совпадения выросла нагрузка на cpu, иногда доходит до 300. Заранее благодарю за помощь.


запросы, которые заставляют жрать цпу, не обязательно будут попадать в slowlog

expelled ★★
()
Ответ на: комментарий от afanasiy 
MySQL on localhost (10.1.21-MariaDB)                                                                                                            up 5+05:00:33 [15:23:51]
 Queries: 136.0M  qps:  317 Slow:   573.0         Se/In/Up/De(%):    155/00/02/00
             qps now:  711 Slow qps: 0.0  Threads:    3 (   3/  36) 170/00/00/00
 Cache Hits: 92.2M Hits/s: 214.8 Hits now: 534.3  Ratio: 43.8% Ratio now: 44.2%
 Key Efficiency: 100.0%  Bps in/out: 36.6k/854.7k   Now in/out: 62.6k/713.5k
mrxk
() автор топика

Долго и нудно курить mytop. А еще в slow-log посмотреть.

tazhate ★★★★★
()
Ответ на: комментарий от WARNING

наверное, нет. по поводу slowlog, как и писал выше - туда почти ничего не попадает. Иногда типа такого в лог падает: UPDATE table set views=views+1 where id='84952', таблица в innodb, вроде не должно попадать такое?

Может какой-нибудь бот шальной создает нагрузку?

mrxk
() автор топика
Ответ на: комментарий от mrxk

Может какой-нибудь бот шальной создает нагрузку?

Ну посмотри access-логи, долбит тебе сервер кто или нет.

Попробуй выставить log_queries_not_using_indexes, может чего интересного всплывёт.

WARNING ★★★★
()
Ответ на: комментарий от WARNING

изначально у меня по неизвестной причине mariadb заработало на конфиге из папки my.snf., после обновления появилась новая папка, которая и должна быть my.snf.d, но mysql судя по логу подгружает данные из старой папки my.snf. увеличил innodb_buffer_pool_size в два раза, до 8G и query_cache_size до 256M, вроде нагрузка спала, а может боты ушли)) памяти всего 32G

выставил log_queries_not_using_indexes - хорошо начало туда падать)) неужто по всем смотреть и индексы ставить, где их нет?

mrxk
() автор топика

Как самый простой вариант это вхвключить логирование запросов в mysql и посмотреть explain популярных

Исходя из этого делать кеш и прочие настройки

ism ★★★
()
Ответ на: комментарий от mrxk

С конфигами, конечно, знатный фейл вышел.

неужто по всем смотреть и индексы ставить, где их нет?

Это правильный вопрос. Правильный вопрос - почему у тебя вообще есть запросы не по индексу? Да, бывают ситуации, когда лучше без индексов, но они очень редки.

WARNING ★★★★
()
Ответ на: комментарий от WARNING

Спасибо, а вот хз где правильный путь прописать для конфига mariadb, т.к. просит же не правильный (my.snf.) )) Заранее благодарю за подсказку. По поводу индексов - хорошее идея, нагрузка падает, но наверное хорошо отжирает место на диске и тормозит вставку? Индексы были, но походу было не достаточно, что показал log_queries_not_using_indexes

mrxk
() автор топика
Ответ на: комментарий от mrxk

Спасибо, а вот хз где правильный путь прописать для конфига mariadb

Скорее всего в чистом инстале там просто инклуд из my.snf.d прописан, так что если ваш старый файл остался на месте и работает то все нормально.

anc ★★★★★
()
Ответ на: комментарий от mrxk

По поводу индексов - хорошее идея, нагрузка падает, но наверное хорошо отжирает место на диске и тормозит вставку?

Тут уже зависит от деталей: как часто вставка, как много, как часто удаление, как часто выборка и т.д. В общем случае, индексы - это хорошо. Но бывают исключения.

WARNING ★★★★
()
Ответ на: комментарий от WARNING

В общем случае, индексы - это хорошо.

Неверно. Следуя такой логике можно насоздавать кучу индексов и «желательно» составных на какой-нидь varchar, а еще более «желательно» на поля которые не используются в запросах и будет «счастье».
Тут надо искать «золотую середину» в зависимости от (как вы верно написали) частоты запросов на модификацию данных и запросов( и каких именно) на выборку. Например есть отчет который формируется раз в год и только в нем используются поля f1,f2,f3 при этом в течении года эти поля модифицируются 100500 раз, смысла делать индекс по ним никакого, лучше раз в год «30 мин» подождать, чем весь год тормозить. Другой пример всякие автоматизированные системы сбора информации, в сырой таблице индексы нафиг не нужны (даже вредны), а вот в агрегированной уже необходимы.

anc ★★★★★
()
Ответ на: комментарий от anc

Всё верно. В общем случае, индексы хороши. Ими надо пользоваться, создавать их, делать выборку по ним. А то что вы написали, это как раз те самые детали/исключения, за знание которых, много денег платят.

WARNING ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin