Нагрузка на mysql что это
Ограничения по нагрузке
Как считается нагрузка
Лимиты нагрузки
По умолчанию суммарная нагрузка в день не должна превышать следующие показатели:
| Тариф | Нагрузка на CPU | Нагрузка на MySQL |
|---|---|---|
| Year+ | 50 | 1000 |
| Optimo+ | 300 | 5000 |
| Century+ | 400 | 7000 |
| Millennium+ | 600 | 10000 |
| Eterno | 1000 | 15000 |
| Premium | 3000 | 25000 |
| 1Сайт | 1000 | 15000 |
С дополнительной услугой «Увеличение лимита нагрузки» лимиты могут быть расширены до следующих показателей:
Лимиты по умолчанию:
Лимиты с учетом максимально возможного увеличения:
110 cp на CPU, 2200 единиц на MySQL для обычного хостинга и тарифов «Старт» CMS-хостинга;
Отображение нагрузки в ПУ
На графиках в панели управления (раздел «Нагрузка на сервер») можно увидеть динамику нагрузки за последние 2 часа / 24 часа / 30 дней. Превышение лимита отрисовывается на графике желтым цветом.
Обратите внимание, что суточные превышения будут отображены только на графике «30 дней»; на графиках за 2 и 24 часа превышений видно не будет (если, конечно, суточный лимит нагрузки не был превышен за 15 минут или 1 час соответственно).
Мониторинг нагрузки пользователей
Я владелец небольшого хостинга (около 200 активных клиентов) и меня заинтересовала тема мониторинга нагрузки на CPU и MySQL.
На некоторых крупных хостингах нагрузка на CPU измеряется в «CP» и на MySQL в «секундах».
Предлагаю Вашему вниманию идею и теоретическую реализацию данной схемы мониторинга на основе Process Accounting и Percona User Statistics.
Нагрузка на CPU
Единица измерения — CP (cpu points). Измеряется системой Process accounting в Linux.
Схема работы
Установим сначала демон psacct (RedHat) или acct (Debian).
yum install psacct или apt-get install acct
Первая строка — общее потребление в системе. Далее, построчно, информация о потребляемых ресурсах каждым пользователем.
В третьем столбце то, что нам нужно, нагрузка на процессор в CP.
Нагрузка на MySQL
Единица измерения — секунды. Измеряется с помощью Percona User Statistics.
Схема работы
Данные каждого запроса записываются в системную таблицу. В нашем случае, к колонке CPU_TIME прибавляется время каждого запроса.
К сожалению, для получения статистики на MySQL 5.5 требуется переустановка MySQL. Я нашел патч User Statistic, но только для MySQL 5.0.77
Вывод информации о нагрузке производится запросом к базе данных INFORMATION_SCHEMA:
Я только начал тестирование данного подхода, который имеет конкретные цифры и алгоритмы расчета нагрузки, но уже видно кого из пользователей можно двигать на тариф выше.
Я реализовал такой подход:
Нагрузка на mysql что это
Причины нагрузки на сервер баз данных Mysql
Если Вы используете базу данных для своего сайта, то рано или поздно обязательно столкнётесь с проблемой нагрузки на сервер со стороны Вашей базы данных.
Первое время возможно Вы не будете испытывать подобных проблем, однако как только размер Вашей базы данных возрастёт, а количество её таблиц увеличится в несколько раз, Вам нужно будет регулярно анализировать работу базы данных.
Многие говорят, что если сайт использует надёжную CMS систему, то в таком случае работать с базами данных одно удовольствие и работа баз продумана до мельчайших подробностей. Это так, однако это не может гарантировать отсутствие нагрузки со стороны БД на сервере.
Есть 2 способа решения данной проблемы: самостоятельное и с помощью разработчика сайта.
Какой бы надёжной ни была структура базы данных, со временем она начнет создавать нагрузку на Ваш сервер. Причиной может быть накопление большего количества ненужного материала в базах данных, также невыполнение регулярной оптимизации базы, под которой подразумевается возобновление таблиц, дефрагментация, обновление статистики и сортировка индексов.
Если у Вас есть желание и навыки работы с базами данных, можете попробовать сначала самостоятельно оптимизировать запросы и таблицы для Вашей базы.
Быстрее всего информацию по процессам для базы данных на сервере можно получить с помощью панели управления WHM
и функции MySQL Process List.
Также такую информацию можно получить, подключившись к серверу по SSH, используя команду mysqladmin proc stat
( опять же если у вас root доступ к серверу) :
mysqladmin proc stat
| Id | User | Host | db | Command | Time | State | Info |
| 44327 | eximstats | localhost | eximstats | Sleep | 0 | | |
| 44639 | DELAYED | localhost | eximstats | Delayed insert | 0 | Waiting for INSERT | |
| 44643 | burzhuy_burzhuy | localhost | burzhuy_burzhuy | Query | 0 | Sending data | SELECT * FROM ext_releases where label=’Elux Records’ order by id desc LIMIT 0,30 |
| 44644 | vseprovs_pasha | localhost | vseprovs_wordpress | Sleep | 0 | | |
| 44646 | ilta_user | localhost | ilta_ilta | Query | 0 | Sorting result | SELECT * FROM pages WHERE parent=’1178′ AND enable_ru=1 AND type!=’13’ AND type!=’26’ AND type!=’39’ |
| 44647 | ilta_user | localhost | ilta_ilta | Query | 0 | Sorting result | SELECT * FROM pages WHERE parent=’1187′ AND enable_ru=1 AND type!=’13’ AND type!=’26’ AND type!=’39’ |
| 44648 | root | localhost | | Query | 0 | | show processlist |
Более полную статистику по запросам к базе данных сайта также можно подучить с помощью 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 показывает, что таблица БД не нуждается в оптимизации так как уже оптимизирована.
Подобные оптимизации желательно делать несколько раз в месяц.
Если же и после оптимизации нагрузка не будет снижена, то, вероятно, вы исчерпали возможности Вашего хостинга и Вам нужно
переходить на более мощный тарифный план.
Оптимизация MySQL чрезмерная нагрузка на сервер
Рекомендуемые сообщения
Похожий контент
Всем доброго времени суток!
Возникла такая проблема! Вот уже несколько дней с хостинга приходят такие письма:
Ваш аккаунт хххххх оказывает чрезмерную нагрузку на сервер.
Нагрузка на CPU характеризует суммарное время, затраченное процессорами сервера на обработку процессов аккаунта. Для снижения нагрузки следует оптимизировать скрипты, исключить выполнение процессов, требующих значительных вычислительных ресурсов.
Нагрузка на MySQL характеризует суммарное время, затраченное на обработку запросов к базам данных аккаунта. Для снижения нагрузки на MySQL следует оптимизировать базу данных и запросы к ней, исключить чрезмерное количество запросов, а также длительно обрабатываемые запросы.
По данным статистики нагрузка на сервер:
Дата, нагрузка на CPU, нагрузка на MySQL
2015-10-31 9.37cp 2457
2015-10-30 12.02cp 3799
2015-10-29 13.76cp 2277
2015-10-28 10.42cp 2212
2015-10-27 9.82cp 1478
2015-10-26 13.97cp 2178
2015-10-24 9.99cp 1210
Это превышает допустимые значения на текущем тарифном плане: нагрузка на CPU до 50 cp, MySQL до 1000.
В течение 7 дней (до 2015-11-08 включительно) Вам необходимо снизить создаваемую нагрузку до ограничений тарифного плана либо принять решение об адекватной смене условий размещения. Если по истечении этого срока будет по-прежнему наблюдаться повышенная нагрузка, дальнейшее обслуживание на прежних условиях будет невозможно.
В случае если нагрузка будет вызывать нестабильную работу сервера, мы будем вынуждены приостановить работу сайтов аккаунта.
С уважением, TIMEWEB.
На 1 сайте 8 000 на 2 около 4 000 товаров. Подскажите как снизить нагрузку на MySQL
Можно ли снизить количество запросов к бд..
Если кто сталкивался с такой проблемой подскажите решение.
Спасибо!
.
Последние посетители 0 пользователей онлайн
Ни одного зарегистрированного пользователя не просматривает данную страницу
Как ускорить работу 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-лога в меньшей степени).
Вывод
Разумеется, все эти советы не являются исчерпывающими. Ключом к быстрой работе БД является понимание ваших данных, грамотно спроектированная схема и удачно составленные запросы. Тем не менее ряд эффективных оптимизаций можно произвести на уровне сервера.