Тяжелое использование MySQL CPU или памяти

Question

У меня есть экземпляр Amazon s3, и проект, который мы имеем на сервере, выполняет много INSERT и UPDATE, а также несколько сложных SELECT.

Мы обнаруживаем, что MySQL довольно часто занимает много ресурсов ЦП.,

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

Ниже приведен вывод cat /proc/meminfo

MemTotal:      7347752 kB
MemFree:         94408 kB
Buffers:         71932 kB
Cached:        2202544 kB
SwapCached:          0 kB
Active:        6483248 kB
Inactive:       415888 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:          168264 kB
Writeback:           0 kB
AnonPages:     4617848 kB
Mapped:          21212 kB
Slab:           129444 kB
SReclaimable:    86076 kB
SUnreclaim:      43368 kB
PageTables:      54104 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   3673876 kB
Committed_AS:  5384852 kB
VmallocTotal: 34359738367 kB
VmallocUsed:       180 kB
VmallocChunk: 34359738187 kB

Текущая настройка:

Экстра-большой экземпляр с большим ЦП

7 ГБ памяти 20 вычислительных блоков EC2 (8 виртуальных ядер с 2,5 EC2 ComputeЕдиницы измерения) 1690 ГБ хранилища экземпляров. 64-разрядная платформа ввода-вывода. Производительность: высокое имя API: c1.xlarge

Возможные настройки:

Двойной очень большой экземпляр с высокой памятью

34,2 ГБ памяти 13 вычислительных блоков EC2 (4 виртуальных ядра с вычислительными блоками EC2 по 3,25 каждый) 850 ГБ хранилища экземпляров Производительность ввода-вывода 64-разрядной платформы: высокое имя API: m2.2xlarge

Answer 1

Я бы выбрал 32 ГБ памяти и, возможно, больше жестких дисков в RAID. Процессор не сильно поможет - у вас достаточно мощности процессора. Вам также необходимо правильно настроить mysql.

• Оставьте 1-2 ГБ для кэша ОС и временных таблиц.
• Увеличить tmp_table_size
• удалить своп
• оптимизировать query_cache_size (не делайте его слишком большим - см. Документацию по mysql)
• периодически запускать FLUSH QUERY CACHE. если ваш кеш запросов <512 МБ - запускайте его каждые 5 минут. <strong>не очищает кэш , а оптимизирует его (дефрагментирует). Это из документации MySQL:

Дефрагментация кеша запросов для лучшего использовать свою память. FLUSH QUERY CACHE не удаляет запросы из кеш, в отличие от FLUSH TABLES или RESET QUERY CACHE.

Однако я заметил, что у другого решения есть половина дискового пространства: 850 ГБ, что может уменьшить количество жестких дисков. Это вообще плохая идея. Самая большая проблема в базах данных - это жесткие диски. Если вы используете RAID5 - убедитесь, что вы не используете меньше жестких дисков. Если вы вообще не используете рейд - я бы предложил рейд 0.

Answer 2

Используйте vmstat и iostat, чтобы выяснить, является ли узким местом ЦП или В / В (если В / В - добавить ОЗУ и загрузить данные в память).Запустите из оболочки и проверьте результаты:

vmstat 5
iostat -dx 5

• , если проблема в процессоре vmstat покажет высокие значения в столбце us, а iostat покажет низкое использование диска (util)
• , если проблема с вводом / выводом, тогда vmstat покажет низкие значения в столбце us, а iostat покажет высокую загрузку диска (util);под высоким я имею в виду> 50%

Answer 3

Используйте «Экземпляр High-CPU Extra Large Instance».

В вашей текущей настройке MySQL не ограничен памятью:

MemTotal:      7347752 kB    
MemFree:         94408 kB    
Buffers:         71932 kB    
Cached:        **2202544 kB**

Из 7 ГБ памяти 2 ГБ не используются и используются ОС в качестве кэша ввода-вывода.

В этом случае увеличение количества процессоров даст вам больше отдачи.

Answer 4

Разве EC2 по требованию не упрощает аренду возможных настроек на один день и выполняет нагрузочное тестирование? Измерения говорят громче, чем слова.

Answer 5

У MySQL не так много причин использовать много ЦП: это либо обработка хранимых подпрограмм (хранимых процедур или хранимых функций), либо продолжающаяся сортировка, которая может съесть ЦП.

Если выиспользуя много ЦП из-за сохраненных подпрограмм, вы делаете это неправильно, и ваша душа все равно не может быть спасена.

Если вы используете много ЦП из-за сортировки, некоторые вещи могут быть выполнены, в зависимости ото характере ваших запросов: вы можете расширить индексы для включения столбцов ORDER BY в конце, или вы можете отбросить предложения ORDER BY и выполнить сортировку в клиенте.

Какой подход выбрать, зависит от фактической причиныиспользования процессора - это запросы и сортировка?И по фактическим запросам.Так что в любом случае вам в первую очередь потребуется более качественный мониторинг.

Не имея информации о мониторинге, общий совет всегда таков: покупайте больше памяти, а не больше ЦП для базы данных.

Answer 6

Зависит от приложения.

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

С другой стороны, если это невозможно в зависимости от типа приложения, я бы порекомендовал более высокую загрузку ЦП.