Что может грузить mysql

Причины нагрузки на сервер баз данных Mysql

Если Вы используете базу данных для своего сайта, то рано или поздно обязательно столкнётесь с проблемой нагрузки на сервер со стороны Вашей базы данных.

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

Многие говорят, что если сайт использует надёжную CMS систему, то в таком случае работать с базами данных одно удовольствие и работа баз продумана до мельчайших подробностей. Это так, однако это не может гарантировать отсутствие нагрузки со стороны БД на сервере.

Есть 2 способа решения данной проблемы: самостоятельное и с помощью разработчика сайта.

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

Если у Вас есть желание и навыки работы с базами данных, можете попробовать сначала самостоятельно оптимизировать запросы и таблицы для Вашей базы.

Быстрее всего информацию по процессам для базы данных на сервере можно получить с помощью панели управления WHM

и функции MySQL Process List.

Также такую информацию можно получить, подключившись к серверу по SSH, используя команду mysqladmin proc stat

( опять же если у вас root доступ к серверу) :

mysqladmin proc stat

Более полную статистику по запросам к базе данных сайта также можно подучить с помощью PHPMYADMIN:

Проверку и оптимизацию таблиц базы данных можно выполнить через панель управления cPanel c помощью опций Check DB, Repair DB.

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

После запуска и завершения процесса оптимизации и восстановления повреждённых таблиц базы данных, мы можем увидеть, что процесс завершился успешно, однако в нашем случае одна из таблиц базы данных всё таки не оптимизировалась. Это мы увидели благодаря сообщению: note : The storage engine for the table doesn’t support repair

Появление ОК напротив таблицы базы данных показывает, что оптимизация таблицы прошла успешно ( например, lovingst_imedicaldirectory.idx_default_field OK), появление Table is already up to date показывает, что таблица БД не нуждается в оптимизации так как уже оптимизирована.

Подобные оптимизации желательно делать несколько раз в месяц.

Если же и после оптимизации нагрузка не будет снижена, то, вероятно, вы исчерпали возможности Вашего хостинга и Вам нужно

переходить на более мощный тарифный план.

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

Модератор: SLEDopit

Сообщение igorif » 18.05.2009 23:47

Сообщение danger08 » 19.05.2009 06:22

и анализируйте результат.

Еще в природе существует утилита mytop (аналог top, но предназначенный чисто для mysql). Смотреть здесь и здесь.

Сообщение drBatty » 19.05.2009 09:39

Скоро придёт
Осень

Сообщение igorif » 19.05.2009 10:51

Выбивает

]# show processlist
-bash: show: command not found
root@server [

]# show processlist;
-bash: show: command not found
root@server [

]# processlist
-bash: processlist: command not found
root@server [

]# show status
-bash: show: command not found
root@server [

p.s: У меня стоит Centos..

мну нужно научится както вычислять какою Изер например перегружает БД и т.д..

Сообщение Frank » 20.05.2009 13:11

Сообщение igorif » 20.05.2009 19:34

Сообщение drBatty » 20.05.2009 23:20

Скоро придёт
Осень

Сообщение IMB » 20.05.2009 23:31

Сообщение igorif » 21.05.2009 10:47

Е почему засоряете мою тему.

Сообщение danger08 » 21.05.2009 11:05

Сообщение skeletor » 21.05.2009 12:45

Сообщение igorif » 21.05.2009 15:16

Сообщение infra_hdc » 05.06.2009 20:30

Сообщение infra_hdc » 10.06.2009 15:42

Сообщение drBatty » 10.06.2009 17:10

Источник

Как снизить нагрузку на MySQL?

есть сервер статистики веб приложения, на нем крутится nginx, php-fpm, memcached, mysql.
Все работает стабильно, но mysql по ТОПу почти постоянно 112-118% загрузки LA в районе 15-30 в зависимости от нагрузок.

Сервер 8 ядер по 2,4Ghz, 2Gb RAM

запросов на nginx в районе 2-3 тысяч в секунду

Cама база очень маленькая, около 75мб

Что можно подкрутить не трогая железо? или это упор и надо менять железо?

Средний 34 комментария

Степан И., там вообще нет сложных запросов со всякими вложенными таблицами, инерами/джоинами, и прочим
Каждый отдельно взятый запрос выполняется за 0,0001 сек.

вроде везде индексы проставлены, если вы знаете как можно проанализировать, подскажите

Abdula Magomedov, как я понял это со стороны программиста,

а как проанализировать со стороны системного администратора?

запросов на nginx в районе 2-3 тысяч в секунду

Cама база очень маленькая, около 75мб

Сервер 8 ядер по 2,4Ghz, 2Gb RAM

по ТОПу почти постоянно 112-118% загрузки

Копать настройки nginx, что то в количестве одновременных подключений к серверу.

Источник

Как ускорить работу MySQL и снять нагрузку с дисковой подсистемы

Любой успешный проект рано или поздно сталкивается с проблемой роста. Число посетителей веб-сайта увеличивается, веб-сервер обрабатывает бóльшее количество соединений, растёт поток запросов к базе данных. В определённый момент времени отзывчивость сайта снижается: страницы загружаются медленнее, что, согласно многочисленным исследованиям, влияет на конверсию.

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

В первую очередь следует выяснить характер нагрузки на диски. В этом поможет утилита iostat. В Ubuntu она устанавливается с пакетом sysstat:

Как ускорить чтение

Допустим, диски загружены запросами на чтение. Что можно сделать, чтобы ускорить отдачу данных? Закэшировать данные в памяти. MySQL предоставляет возможность использования разных хранилищ, или движков (storage engines), для доступа к данным, поэтому подход к кэшированию разный. Рассмотрим два наиболее популярных движка: MyISAM и InnoDB.

Движок MyISAM не имеет кэша для данных. Но мы по-прежнему можем ускорить чтения из таблиц MyISAM. Дело в том, что ядро Linux кэширует все прочитанные файлы в области оперативной памяти, которая называется pagecache. Разумеется, файлы с таблицами MyISAM также попадают в этот кэш. Объём pagecache можно узнать из вывода команды free:

Максимальной производительности чтения можно добиться, если объём pagecache равен объёму данных MyISAM.

Как ускорить запись

Увеличить производительность MySQL при большом объёме записи можно с помощью тонкой настройки параметров сервера.

По умолчанию InnoDB сбрасывает изменённые данные на диск с помощью системного вызова fsync(). При этом операционная система не гарантирует, что данные попадут в хранилища сию секунду, т.к. данные сперва проходят через буфер, поддерживаемый ядром. Буферизация необходима для ускорения ввода/вывода.

При задействовании кэша RAID-контроллера повысить производительность операций записи в БД можно, отключив ненужную буферизацию на уровне операционной системы. Для этого требуется выставить переменную MySQL innodb_flush_method в значение O_DIRECT, после чего перезагрузить систему управления базы данных. Снизить нагрузку на диски также может изменение переменной innodb_flush_log_at_trx_commit. Для соответствия требованиям ACID движок InnoDB хранит логи транзакций, или redo-логи, в которые записываются все запросы на изменение данных. Эти логи используются в процессе восстановления после аварийного останова системы управления базами данных.

Оптимизировать дисковые операции записи помогает правильный выбор размера redo-логов. Для этого есть несложное правило. Достаточно замерить объём данных, который записан в лог за одну минуту. Эту операцию нужно выполнять в момент дневной пиковой нагрузки:

Из примера видно, что за минуту в лог InnoDB записывается 2,44 Мб данных. Объём лога следует подбирать таким образом, чтобы в него умещался объём данных за час. В таком случае у InnoDB будет достаточно времени, чтобы изменить порядок запросов на ввод/вывод для достижения последовательной записи. В нашем примере за один час через redo-логи проходит 150 Мб данных, поэтому переменную innodb_log_file_size следует выставить в значение не менее 75M. Если объём лога выбрать слишком большим, то увеличится время InnoDB Crash Recovery, что увеличит даунтайм при аварийном перезапуске (стоит отметить, что в MySQL 5.5 время Crash Recovery зависит от размера InnoDB-лога в меньшей степени).

Вывод

Разумеется, все эти советы не являются исчерпывающими. Ключом к быстрой работе БД является понимание ваших данных, грамотно спроектированная схема и удачно составленные запросы. Тем не менее ряд эффективных оптимизаций можно произвести на уровне сервера.

Источник

MySQL грузит все ядра проца. Глюк?

Лучше всего проблему иллюстритует сия картинка

Если описать это словами, то выходит так. Сервер работает как ни в чём ни бывало. Нагружено около половины ядер. И не на 100%, а на 50-70%. Потом внезапно нагрузка улетает в космос. При этом база встаёт раком, ответы происходят очень долго. Всё это длится 10-50 секунд, и потом опять перерыв на минутку.

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

Причем по мониторингу (htop) видно что проц то загружен системным вызовом. Т.е. это или огромное количество некоторых вызовов к ядру, или интенсивное выделение-забирание памяти, или ввод-вывод.
Но как промониторить самые топовые вызовы ядра я не знаю. Память судя опять же по мониторингу массово не выделяется и не забирается (по меньшей мере гигабайтами, чтобы это было заметно).
iotop показывает ввод-вывод не сильно отличающийся от такового в нормальном состоянии.

Запросы во время глюка выполняются самые обычные. Не сказать чтобы как-то менялась пропорция выбор/обновление, или запрашивались особые таблицы. Думал может что-то по крону запускается из переодических заданий. Но я пробовал останавливать их все на время. Проблема остается.

К слову о сервере и системе: 2 x Xeon E5-2680v3 @2.5GHz (24 реальных ядра), 64Гб DDR4. SSD энтерпрайз уровня на 960Гб. Быстрые. Ну то есть сервер очень даже ничего. ОС Centos 7 (ядро 3.10), юзаю Percona 5.7. База на отдельном разделе (впрочем рояли это особо не должно играть). Кроме мускуля на сервере не стоит вообще ничего.
Собственно неделя как переехали со старого сервака, который был ровно в 2 раза слабее и перестал тянуть нагрузку.
Так вот на нём по началу я тоже видел такую же картину переодически. Но потом подобрал такие параметры в конфиге мускула, что всё вроде как улеглось. Но все ж сервак перестал тянуть, и мы переехали на новый. а тут опять эта проблема.

Важное замечание: проблема наблюдается только в час пик. Так что всё это явно коррелирует с нагрузкой на мускул сервер. В остальное время дня всё окей.

Что еще я хочу сказать. я не настоящий сварщик. В смысле не DBA. Просто рядовой Linux-админ. Я плохо понимаю как внутри устроен mysql, innodb и так далее. Поэтому и прошу помощи. Разобраться сам не смог.

Ниже прикреплю на всякий случай шапку от mytop:

Сейчас конечно не час-пик уже. Но хоть какая-то инфа.

И заодно конфиг мускула

Если интересно, могу опубликовать скрин Mysql Workbench Dashboard во время того когда мускул глючит.
Или Perfomance Statistics. Все равно я в ней ничего особо не понимаю.

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

Источник