нагрузка на mysql что это
Оптимизация 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 пользователей онлайн
Ни одного зарегистрированного пользователя не просматривает данную страницу
Мониторинг нагрузки пользователей
Я владелец небольшого хостинга (около 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
Быстрый старт
Устранение нагрузки состоит из двух этапов: простой и сложный. Простой заключается в исправлении мелких или очевидных ошибок и в проведении базовой оптимизации сайта. Он занимает не очень много времени, хотя во многих случаях даёт приемлемый результат. Сложный требует подробного изучения сайта и может затянуться на месяц и более.
Вот что необходимо сделать в первую очередь:
Рассмотрим теперь анализ и оптимизацию сайта более подробно.
Анализ нагрузки
Для анализа нагрузки существует несколько методов: изучение логов, аудит кода, профилирование.
Изучение логов позволяет провести статистическое исследование того, какие запросы чаще всего используются при обращении к сайту, кто именно больше всего скачивает страниц и к каким страницам вообще есть обращения. Для получения приблизительной статистики по логу можно было бы воспользоваться средствами вроде Webalizer и AWStats, но они предназначены для сбора более долговременной статистики посещаемости сайта, поэтому для более детального анализа в любом случае придётся просматривать логи вручную.
Посмотрите данные о нагрузке, приведённые в панели управления и сравните, чем отличаются участки лога во время небольшой нагрузки от участков с высокой или критической нагрузкой. Обычно становится ясно видно, что именно изменяется: либо приходит робот и начинает выкачивать сайт, либо на сайт начинает заходить много посетителей, либо в это время в логах присутствуют какие-то ошибки, либо чаще происходят обращения к какому-либо скрипту, который может требовать ресурсы и т. д.
Команда time позволяет определить, сколько реального и сколько процессорного времени было затрачено на выполнение программы. Для того, чтобы определить время выполнения конкретного скрипта, нужно задать команду его запуска в качестве аргумента команде time :
Устранение нагрузки
Изучите ваш код. Постарайтесь определить, какие именно места вызывают наибольшую нагрузку. Начните их оптимизировать.
Кэширование данных
В первую очередь подумайте о возможности кэширования страниц. Если ваш движок много времени и сил тратит на генерацию каждой страницы, а содержание страницы при этом изменяется редко, то можно один раз сгенерировать страницу и сохранить её в файл, а при новых обращениях отдавать данные из файла.
Ограничение скорости отдачи страниц
Решением против «качалок», которые стараются за короткое время обойти все страницы вашего сайта и создают этим повышенную нагрузку, может стать лимитирование скорости отдачи страниц.
Простые ошибки
Исследуйте код на наличие простых ошибок. Бесконечная рекурсия SSI. Условие, которое должно было бы ограничивать перебор миллиона вариантов, но не ограничивает из-за ошибки. Вечный редирект mod_rewrite. И так далее.
И загляните в error_log, возможно, проблема очевидно отражена именно там.
Избавление от ненужного кода
Посмотрите, нет ли в ваших скриптах ненужного старого кода, который, например, использовался когда-то для ведения статистики, которую так никто и не стал смотреть (статистику всё равно лучше собирать с помощью Google Analytics), или который пытается просчитать и вывести данные, которых уже нет, или которые морально устарели. Бывает, в каком-нибудь скрипте вызывается функция, которая получает и формирует какие-либо данные, но эти данные впоследствии нигде не выводятся. Проверьте, весь ли код является полезным на вашем сайте.
Может быть, на сайте есть забытый форум, которым пользуются только спамеры и поисковые роботы? Возможно, такой форум можно будет безболезненно удалить и заменить его блогом. Практика показывает, что даже редко обновляемый блог лучше и интереснее для посетителей, чем потерянный форум.
Оптимизация и рефакторинг кода
Если движок был написан быстро, то наверняка не все использованные алгоритмы идеальны. Возможно, какие-то части работают довольно медленно, потому что были реализованы первым пришедшим в голову способом. Возможно, то же самое можно сделать проще и быстрее, нужно просто придумать более совершенный алгоритм. Или вы узнали о том, что существует специальная функция, которая за один вызов делает всё то, для чего в движке используется несколько вложенных циклов обработки трёхмерных массивов.
Если движок был создан давно и с тех пор много раз обновлялся, возможно, накопилось много частей, плохо согласованных друг с другом. Вероятно, если в течение года для движка было написано множество заплаток тут и там, имеет смысл пересмотреть внутреннее взаимодействие скриптов, а может быть даже провести полноценный рефакторинг кода.
Ограничение поисковых роботов
Не все разделы сайта нуждаются в индексации поисковыми системами. В самом деле, постарайтесь оценить для каждого раздела насыщенность информацией, которую бы вы хотели видеть в выдаче поисковика. Например, содержание гостевой книги или небольшого форума, прицепленного к сайту, вряд ли будет настолько же интересно, как тематические статьи, размещённые в специализированном разделе. Части сайта с низкой концентрацией полезной информации можно (и даже полезно!) исключить из индексации. В конце концов, самые интересные посты с форума всегда можно перенести в постоянный раздел сайта со статьями.
Создание структуры сайта
Посмотрите на сайт и составьте карту всей информации, которая на нём находится. Возможно, сразу окажется, что нужно что-то реорганизовать, переместить в более подходящий раздел, просто сгруппировать. Обратите внимание на навигацию, на ссылки, по которым доступна информация: все ли они сгенерированы по одинаковому принципу? Возможно, одни и те же страницы доступны по нескольким разным ссылкам, и все они используются для навигации. Такие ссылки лишь «раздувают» сайт повторяющейся информацией, и уникальность информации на страницу сайта падает. При этом поисковики, качалки, да и просто браузеры пользователей считают такие страницы разными и выкачивают дубли, что, естественно, повышает нагрузку на сайт.
Если вы пришли к выводу, что из всех ссылок на страницу можно оставить действующей только одну, но не хотите терять пользователей, у которых в закладках сохранен альтернативный вариант ссылки, просто сделайте постоянный редирект на основную ссылку со всех альтернативных.
Тоже выход
Впрочем, всё это может быть вам не интересно. Иногда проще купить тариф с большими лимитами или сервер помощнее и не заботиться об оптимизации. Тоже выход.
Тем не менее обратите, пожалуйста, внимание, что некоторые советы, данные здесь, относятся не только к снижению нагрузки, но и к повышению качества информации, представленной на сайте. И даже к повышению качества кода, высокий уровень которого может оказаться очень важным подспорьем при развитии вашего проекта.
Как ускорить работу 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-лога в меньшей степени).
Вывод
Разумеется, все эти советы не являются исчерпывающими. Ключом к быстрой работе БД является понимание ваших данных, грамотно спроектированная схема и удачно составленные запросы. Тем не менее ряд эффективных оптимизаций можно произвести на уровне сервера.