Высокий iowait на экземпляре MySQL Amazon EC2 с объемом EBS
Нет никакого продукта как Групповая политика для всех дистрибутивов (например, мягкая фетровая шляпа или человечность). Каково существует, эксклюзивные решения (подобный Microsoft WSUS) для каждого дистрибутива: как Среда для Ubuntu или RHN для Redhat, но этих решений заплачены и фокусируются на обновлениях, контроле, исправляя серверы.
Можно ввести ограничения или пределы Ubuntu (я живо мягкая фетровая шляпа или другой дистрибутив, которые используют Gnome также) с решениями как Sabayon для определения настольных профилей и Pessulus для ограничения функций. Но AFAIK, это решения не централизованы.
Было бы полезно, если бы вы разместили свой my.cnf, и используете ли вы таблицы InnoDB или MyISAM, и независимо от того, интенсивно ли у вас чтение или запись. В противном случае мы просто гадаем. Вот мои:
Во-первых, я бы посмотрел и убедился, что ваши запросы правильно проиндексированы. Высокий объем операций ввода-вывода в базах данных MySQL вызван либо чрезвычайно высокой степенью параллелизма, плохо настроенным сервером, либо плохо выполняющимися запросами, которые должны выполнять полное сканирование таблиц или индексов. Некоторые подсказки о том, как найти неэффективные запросы, можно найти в моем сообщении в техническом блоге Ideeli .
Проверьте свой my.cnf. Если вы используете InnoDB, убедитесь, что innodb_buffer_pool_size и innodb_log_file_size достаточно большие. Поскольку EBS имеет такую переменную задержку, максимальное увеличение innodb_log_file_size может иметь существенные преимущества в производительности. Если вы используете MyISAM (а вам не следует этого делать), убедитесь, что размер вашего key_buffer достаточно велик.
Если вы уверены, что ваши запросы хорошо оптимизированы и ваш сервер хорошо настроен, мы можем перейти к следующий пункт. ext3 далеко не идеален для баз данных. Одна из основных причин этого заключается в том, что ext3 позволяет только одному потоку обновлять индексный дескриптор за раз (пытаясь найти для этого документацию). Если вы не используете innodb-file-per-table, это означает, что существует множество конфликтов файловой системы для файла ibdata. xfs не имеет этого ограничения и, как было показано, работает намного лучше (нужен источник) для рабочих нагрузок базы данных.
Если вы не можете перейти на xfs, убедитесь, что вы используете innodb-file-per-table и, как минимум, убедитесь, что у вас нет noatime, nodiratime на монтировании.
Далее, переходим к вашему размер экземпляра. А c1. средний - не идеальный размер экземпляра для большинства баз данных, если только набор данных не маленький. MySQL обычно выигрывает от памяти над вычислительной мощностью. c1.medium имеет всего 1,7 ГБ ОЗУ! Насколько велик ваш набор данных? Как правило, m1.large (с 7,5 ГБ ОЗУ) превосходит c1.medium, за исключением очень редких случаев. Это также вдвое дороже - 0,34 доллара в час
Теперь о RAID томов EBS. Да, RAID значительно увеличит ваши IOPS. (Как и увеличение размера вашего экземпляра). Не RAID0 ... По крайней мере, если вам небезразличны ваши данные. Я объяснял это во многих местах, в том числе в моем блоге , в качестве докладчика на Percona Live NYC в 2011 году и здесь на serverfault . Вкратце, тома EBS выходят из строя нетипичными способами, и возможность удалить том из набора оказалась полезной в некоторых случаях, особенно во время большого отключения EBS в 2011 году, когда некоторые сайты были отключены в течение нескольких дней ... Мы были в автономном режиме 45 минут в 4 утра, несмотря на то, что проблема EBS затронула десятки экземпляров.
Вот несколько тестов для томов EBS с RAID с использованием MySQL.
Наконец, Percona Server имеет огромное количество оптимизаций масштабируемости. Вот технический документ об опыте моей компании при переходе с MySQL на Percona Server. Каждый день мы сталкивались с остановками и отключениями баз данных. Простое переключение на Percona Server с MySQL решило эту проблему буквально в мгновение ока благодаря ряду улучшений масштабируемости.
Итак, в итоге ...
- Настройте свои запросы
- Настройте свой сервер
- Получите лучшее «оборудование»
- Используйте xfs, а не ext3
- RAID10, а не RAID0
- Переключитесь с MySQL на сервер Percona
Что касается MySQL Cluster, это совершенно другое животное, чем MySQL, и обычно не подходит для большинства приложений OLTP. Galera / Percona XtraDB Cluster также являются новыми и интересными продуктами кластеризации. Однако у вас есть много вариантов, прежде чем вы доберетесь до любого из них. Мы обслужили 24k qps на пике с одного m2.4xlarge с RAID10 в EC2.
Удачи!
это совершенно другое животное, чем MySQL, и обычно не подходит для большинства приложений OLTP. Galera / Percona XtraDB Cluster также являются новыми и интересными продуктами кластеризации. Однако у вас есть много вариантов, прежде чем вы доберетесь до любого из них. Мы обслужили 24k qps на пике с одного m2.4xlarge с RAID10 в EC2.Удачи!
это совершенно иное животное, чем MySQL, и, как правило, не подходит для большинства приложений OLTP. Galera / Percona XtraDB Cluster также являются новыми и интересными продуктами кластеризации. Однако у вас есть много вариантов, прежде чем вы доберетесь до любого из них. Мы обслужили 24k qps на пике с одного m2.4xlarge с RAID10 в EC2.Удачи!
Это проблема, с которой столкнулись многие, многие компании, и ее решения довольно хорошо обсуждаются на различных онлайн-форумах.
Обычно для увеличения потенциального iops, два или более EBS тома объединены в массив RAID0. Однако это не без риска. Как вы знаете, с RAID0 все, что нужно, - это чтобы на одном из томов EBS возникла проблема, и ваши данные стали всплывать. Таким образом, вы можете рассмотреть возможность использования более устойчивого уровня RAID, например, RAID 10.
3- Do you believe such scenario is heavily impacting our apps? Would they perform much better in case we move to a RAID 0 and/or cluster solution?
Since you are running an SQL server, it would make more sense to take a look at the SQL server metrics instead to know if queries are served quickly. Looking at your single-digit average request wait times (await), I do not think I/O would be much of a concern yet.
Also, as what you mostly see is read load, you could reduce it by having a larger cache / increasing the amount of RAM and tuning the cache parameters of your MySQL instance. I would expect this to have a significantly larger performance impact than having your storage changed to handle more I/Os.
Поскольку 500 Гбит / с - это довольно небольшая нагрузка на сервер sql, я предлагаю посмотреть процент временных таблиц, созданных на диске, и начать оптимизацию ваших запросов и настроек сервера MySQL.
1, Не делайте этого. примените подход Raid0, он в конечном итоге потерпит неудачу, и вы пожалеете об этом.
2, Нет, при таком низком количестве запросов в секунду вам не нужен кластер MySQL.
3, Да, это определенно влияет на производительность приложения , чтобы измерить, сколько вы могли бы включить журнал медленной работы и убедиться в этом сами.
Сколько памяти использует mysql в настоящее время, есть ли еще запас?
Если нет, вам следует подумать о переключении на более крупный экземпляр и начать оптимизацию настроек с помощью другого скрипта настройки mysql:
http://www.day32.com/MySQL/tuning-primer.sh