mysql сильно грузит процессор
Всем добрый день! Прошу помощи, совета, подсказки в моей проблеме. Имеем выделенный сервер 2х Xeon E5-2670, 64Gb RAM, 240Gb SSD. На сервере расположен единственный проект среднего уровня. В проекте присутствует база данных из 3 таблиц. Загруженность MySQL: root@d:/var/log/mysql# mysqladmin status Uptime: 5562 Threads: 132 Questions: 581856 Slow queries: 0 Opens: 359 Flush tables: 1 Open tables: 322 Queries per second avg: 104.612 К таблицам выполняется достаточно большое количество запросов SELECT, UPDATE, INSERT. Первая таблица — SELECT и UPDATE запросы, редко INSERT. Таблица InnoDB, примерно 12000 записей. Вторая таблица основная, «рабочая», в ней постоянно присутствует ~500 000 записей. INSERT, UPDATE, SELECT присутствует в полном объеме, в час пик порядка 300-400 запросов в секунду именно к этой таблице. MyISAM. Третья таблица MyISAM, самая «тяжелая» — порядка 150 миллионов записей. Запросы к ней не частые, это INSERT (по 500-1000 строк) и SELECT (полнотекстовый). Ключи на месте, запросы выполняются быстро. Расставлены ключи на основные поля, запросы выполняются достаточно быстро, slow-запросы в логах отсутствуют. На сервере сайт расположен всего неделю, но уже сейчас в часы активности наблюдаются серьезные «провалы» в работе сайта. MySQL сильно грузит процессор, в htop’е периодически появляется При этом Load average в пределах нормы и в целом сервер работает стабильно. Ищу причины происходящего. Что делал: -расставлял дополнительные ключи, сейчас практически все поля по которым -выполняются запросы являются ключами. — ковырялся в конфигурации mysql. Признаюсь честно, не эксперт в этом вопросе — поэтому ничего конкретного тут не сделано и пользы от этого не замечено Подозреваю — нужно что то менять в конфиге mysql Возможно — переводить рабочую таблицу в InnoDB. В интернете попадаются похожие проблемы, но решения найти не удалось.. Прошу помощи, друзья, в решении моей проблемы.
Отслеживать
задан 17 сен 2018 в 8:05
Сергей Белов Сергей Белов
127 1 1 серебряный знак 11 11 бронзовых знаков
последий раз когда я видел подобную проблему оказалось, что были скрипты, которые постоянно перечитывали мелкими запросами одно и то же, множество раз в секунду. Вылечилось исправлением ошибки в тех скриптах. Выявлялось с помощью show full porocesslist на глазок, с целью найти наиболее частые запросы, которые попадаются в выполняемом состоянии.
17 сен 2018 в 8:30
«сейчас практически все поля по которым -выполняются запросы являются ключами» — наличие ключей во первых серьезно замедляет вставку, во вторых часто портит планы выполнения, MySQL при наличии не правильного ключа может пойти по нему, что будет значительно медленнее, чем если бы он решил идти по другому. Фактически после принятия решения о создании нового ключа надо перепроверять все старые запросы, которые хоть каким то боком могут захотеть его использовать
17 сен 2018 в 8:31
Примерно такое у меня и происходит — постоянно пересчитываются мелкие count(*) и т.д., этого не избежать — пользователи просматривают статистику постоянно обновляющуюся.
17 сен 2018 в 20:14
Основное дополнение! На сайте постоянно запускаются «долгоиграющие» скрипты, выполнение которых может занимать от 10 минут до часа и более.. Каждый скрипт в начале открывает соединение с mysql, и взаимодействует с ней в процессе. Т.е. соединение может быть открытым до часа, при этом действия выполняются раз в 2-3 секунды. Может в этом корень «зла»?
17 сен 2018 в 20:17
нет, это как раз хорошо. открытие соединения то же отнимает время и у открывающего и у MySQL. У нас например вообще используется полный fastcgi, обработчики web-запросов всегда подгружены в памяти и держат соединения с БД постоянно, сутками. И уж с этим точно никаких проблем, только выигрыш. Все мелкие справочники при этом вообще у себя в памяти держат и обновляют только когда те поменялись, о чем узнают из redis. Кстати, мелкие count() я бы то же в redis держал, уже готовые, только надо решить как обновлять
Mysql грузит проц > 100%
пашут mysql 3.23.58 и апач 1.3.28 c PHP-4.3.2,mod_perl-1.28,mod_ssl-2.8.15(OpenSSL 0.9.6g) . Кол-во баз — 58 . Базы были перенесены после краха диска на пред. системе — просто скопированы на новый сервер. Версия пред. мускула — та же — 3.23.58 . Где то через часа 2 после старта мускул начинает грузить проц более чем на 100 %, ещё через пару часов зависает мускул, а ещё через часок вешается уже вся система . Были предприняты меры по восстановлению баз данных (путём запуска myisamchk -r) — НЕ помогло. Запускал мкскул с пониженным приоритетом (nice -n 16) — НЕ помогло . Запускал мускул с параметром —skip-thread-priority — помогло на 2 часа, далее использование проца снова подскочило до 190-200 % как ни в чём не бывало . Вот что кажет top : PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9632 mysql 15 0 524m 20m 2484 S 198 0.6 59:40.86 mysqld
Скажите какие переменные мускула вам привести для анализа — все приводить список охренеть какой длинный получится .
На апач конечно серьёзная нагрузка, постоянно висит где то 20 процессов, я запускаю его с параметрами :
Timeout 300 KeepAlive Off MaxKeepAliveRequests 20 KeepAliveTimeout 15 MinSpareServers 5 MaxSpareServers 10 StartServers 5 MaxClients 150 MaxRequestsPerChild 2000
Есть у кого версии что ещё можно придумать чтобы убрать проблему с такой нагрузкой (а то уже за***** реально !) ? На пред. сервере такого не наблюдалось .
Форум пользователей MySQL
Помогите пжл разобраться — не понятно почему mysqld грузит процессор 40-80%.При 7 подключении к примеру.
Сервер:Quad Xeon 2.13Ghz
RAM:2Gb (половина свободна)
Крутится сайт на Nginx в связки php-fpm
Вот вывод mytop:
Queries: 1.5M qps: 357 Slow: 465.0 Se/In/Up/De(%): 87/01/00/01
qps now: 264 Slow qps: 0.0 Threads: 3 ( 1/ 63) 83/01/01/01
Cache Hits: 1.1M Hits/s: 252.4 Hits now: 202.3 Ratio: 81.8% Ratio now: 92.8%
Key Efficiency: 93.8% Bps in/out: 39.7k/ 2.4M Now in/out: 44.3k/783.4k
Id User Host/IP DB Time Cmd Query or State
— —- ——- — —- — ———-
28589 root localhost site 0 Query show full processlist
4390 root localhost 18 Sleep
169 root localhost 3841 Sleep
При этом mysql 82 20 0 2577M 514M uwait 3 57:47 52.05% mysqld
Может я где то что то не так настроил?
Или как можно выяснить из-за чего?Из кривого сайта или настроек mysql..
#2 20.09.2012 19:20:57
rgbeast Администратор Откуда: Москва Зарегистрирован: 21.01.2007 Сообщений: 3877
Re: Mysql грузит процессор — но подключений практически нету
mytop вам пишет, что 300 запросов в секунду, но почему-то не показывает сами запросы. Попробуйте SHOW FULL PROCESSLIST несколько раз, подключившись к mysql под рутом.
#3 20.09.2012 20:32:07
SSD Участник Зарегистрирован: 20.09.2012 Сообщений: 10
Re: Mysql грузит процессор — но подключений практически нету
rgbeast написал:
mytop вам пишет, что 300 запросов в секунду, но почему-то не показывает сами запросы. Попробуйте SHOW FULL PROCESSLIST несколько раз, подключившись к mysql под рутом.
В предыдущем примере тоже было все под рутом.(а может mytop не показывать запросы — так как они закешированы? query_cache_size=256M — 56мб занято)
Вот с SHOW FULL PROCESSLIST
MySQL on localhost (5.5.20-log) up 0+00:28:50 [19:27:33]
Queries: 783.8k qps: 464 Slow: 0.0 Se/In/Up/De(%): 87/00/00/01
qps now: 702 Slow qps: 0.0 Threads: 17 ( 5/ 21) 86/01/00/01
Cache Hits: 614.3k Hits/s: 363.6 Hits now: 533.3 Ratio: 89.9% Ratio now: 88.2%
Key Efficiency: 92.2% Bps in/out: 49.5k/ 1.2M Now in/out: 76.2k/ 1.6M
Id User Host/IP DB Time Cmd Query or State
— —- ——- — —- — ———-
8829 root localhost site 0 Query show full processlist
13758 site localhost site 0 Query select * from video where id_lang=1 and st
13774 root localhost site 0 Query SELECT * FROM extension WHERE `type` = ‘mo
13776 root localhost site 0 Sleep
13759 site localhost site 1 Query select * from video where id_lang=1 and st
13762 root localhost site 1 Sleep
13763 site localhost site 1 Sleep
13768 root localhost site 1 Sleep
13769 site localhost site 1 Sleep
13770 root localhost site 1 Sleep
13771 site localhost site 1 Sleep
13772 root localhost site 1 Query SELECT * FROM (SELECT id.title AS title, i
13773 site localhost site 1 Sleep
13777 site localhost site 1 Sleep
13775 site localhost site 1 Sleep
9126 root localhost 347 Sleep
8491 root localhost 564 Sleep
Отредактированно SSD (20.09.2012 20:37:04)
#4 20.09.2012 20:44:50
rgbeast Администратор Откуда: Москва Зарегистрирован: 21.01.2007 Сообщений: 3877
Re: Mysql грузит процессор — но подключений практически нету
Бросается в глаза, что везде SELECT *
Может быть все поля требуются не всегда.
#5 16.02.2013 23:29:43
SSD Участник Зарегистрирован: 20.09.2012 Сообщений: 10
Re: Mysql грузит процессор — но подключений практически нету
Вынесли Mysql на отдельный сервер.
Все отлично — но иногда вывод странички тормозит — ожидание ответа от»сайта» — и при этом mysqld грузит процессорное время ..
Вот конфиг
innodb_flush_log_at_trx_commit=1
sync_binlog=1
key_buffer_size = 1G
max_allowed_packet = 1M
table_open_cache = 256
sort_buffer_size = 64M
read_buffer_size = 12M
read_rnd_buffer_size = 24M
net_buffer_length = 2K
thread_stack = 128K
max_connections=1000
max_join_size=1000000
thread_cache_size=64
query_cache_size=512M
ft_min_word_len=2
log-slow-queries=/var/log/mysql/slow_queries
tmp_table_size=64M
max_heap_table_size=64M
table_cache=1024
————————
Версия
mysql-server-5.5.28 Multithreaded SQL database (server)
——————————-
MySQL on localhost (5.5.28-log) up 0+00:14:34 [21:00:53]
Queries: 349.5k qps: 409 Slow: 0.0 Se/In/Up/De(%): 90/00/01/01
Cache Hits: 267.1k Hits/s: 313.0 Hits now: 0.0 Ratio: 84.9% Ratio now: 0.0%
Key Efficiency: 99.6% Bps in/out: 36.8k/586.4k
Master: mysql-bin.000030/2684553 do: ign:
Id User Host/IP DB Time Cmd Query or State
— —- ——- — —- — ———-
4459 tvi3 172.16.0.1 tvi2012103 0 Query DELETE FROM whos_online WHERE time_last_click < '1361040295'
4460 tvi3 172.16.0.1 tvi2012103 0 Query INSERT INTO whos_online SET customer_id = ‘0’, full_name = ‘Guest’, session_id = ‘q5veap1m4i511on4qpgp48h9a3’, ip_address = ‘85.246.217.235’, b
4461 root localhost test 0 Query show full processlist
4462 tvi3 172.16.0.1 tvi2012103 0 Query SELECT news_id as uid, date_public as date, title, purple_new as isPriority, file_local as video FROM news WHERE in_list = 1 and status = 1 and
4453 tvi3 172.16.0.1 tvi2012103 1 Query SELECT n.*, DATE_FORMAT(n.date_public , ‘%H:%i’) AS public_time, DATE_FORMAT(n.date_public, ‘%e,%c,%w’) AS public_date, DATE_FORMAT(n.date_efir
4454 tvi3 172.16.0.1 tvi2012103 1 Query UPDATE news SET views = views + 1 WHERE news_id = ‘13686’
4455 tvi3 172.16.0.1 tvi2012103 1 Query UPDATE news SET video_views = video_views + 1 WHERE news_id = ‘13674’
4456 tvi3 172.16.0.1 tvi2012103 1 Query SELECT news_id, image, file_local FROM news WHERE news_id = ‘13689’
4457 tvi3 172.16.0.1 tvi2012103 1 Query SELECT alias, type_id, UNIX_TIMESTAMP(date_public) AS rss_date FROM news WHERE news_id = ‘12491’
4458 tvi3 172.16.0.1 tvi2012103 1 Query SELECT news_id FROM news WHERE alias = ‘mCSB_buttons.png’
2269 root localhost test 4 Sleep
319 replicato 172.16.0.1 820 Binlog Master has sent all binlog to slave; waiting for binlog to be updated
Может еще подскажите что не так или куда смотреть.
P.S.»Стоит ли доверять mysqltuner?
Цитирую
——— General Statistics —————————————————
[—] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.28-log
[OK] Operating on 64-bit architecture
——— Storage Engine Statistics ——————————————-
[—] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[—] Data in MyISAM tables: 2G (Tables: 219)
[—] Data in InnoDB tables: 11M (Tables: 7)
[—] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 15
——— Performance Metrics ————————————————-
[—] Up for: 17m 7s (434K q [423.396 qps], 5K conn, TX: 596M, RX: 39M)
[—] Reads / Writes: 89% / 11%
[—] Total buffers: 1.7G global + 100.2M per thread (1000 max threads)
[!!] Maximum possible memory usage: 99.6G (1106% of installed RAM)
[OK] Slow queries: 0% (0/434K)
[OK] Highest usage of available connections: 2% (20/1000)
[OK] Key buffer size / total MyISAM indexes: 1.0G/227.2M
[OK] Key buffer hit rate: 99.7% (24M cached / 82K reads)
[OK] Query cache efficiency: 84.9% (333K cached / 392K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 5K sorts)
[!!] Temporary tables created on disk: 41% (842 on disk / 2K total)
[OK] Thread cache hit rate: 99% (20 created / 5K connections)
[OK] Table cache hit rate: 76% (314 open / 410 opened)
[OK] Open file limit used: 4% (544/11K)
[OK] Table locks acquired immediately: 97% (81K immediate / 83K locks)
[OK] InnoDB data size / buffer pool: 11.1M/128.0M
——— Recommendations ——————————————————
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours — recommendations may be inaccurate
Reduce your overall MySQL memory footprint for system stability
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
*** MySQL’s maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
tmp_table_size (> 64M)
max_heap_table_size (> 64M)
MySQL грузит процессор на все 100
Сразу предупреждают, что я плохо знаком с mysql, но мне понадобилось его использовать.
Я создал такую таблицу:
CREATE TABLE stack
(
id INT NOT NULL AUTO_INCREMENT,
infa VARCHAR(64) UNIQUE NOT NULL,
view BOOL,
PRIMARY KEY (id)
);
Всего есть три запроса:
взять для обработки:
db.query(‘select infa from stack where view=0 limit 1’)
пометить как взятое:
db.query(«update stack set view=1 where infa=’%s’» % infa)
и вставить полученные данные запросом:
insert ignore into stack (infa, view) values (‘foo’, 0),(‘bar’, 0) итд.
Я знаю, что запросы уязвимы, но тут данным можно доверять.
Проблема в том, что когда работают 10 экземпляров скрипта загрузка процессора mysql’ем составляет уже 60-70%, а мне нужно 20-30 экземпляров, дабы они обеспечивали полное использование интернет канала. Сейчас в базе 4.5 млн записей.
Все это происходит на Debian Squeeze, Pentium-4 2.6, 1024 ram. Сам скрипт на питоне с использованием mysql-python.
Собственно вопрос — что, где подкрутить дабы исправить ситуацию?
И да, я включал и смотрел mysql-slow.log и ничего там не обнаружил.