Тяжелый процессор или память использования mysql

у меня есть экземпляр Amazon s3, и проект, который мы имеем на сервере, делает много вставок и обновлений и несколько сложных вариантов

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

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

ниже выводится значение 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

Текущие Настройки:

High-CPU Extra Large Instance

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

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

Двойник Высоко-Памяти Экстренный Большой Пример

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

6
amazon-s3 mysql performance

6 ответов

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

  • оставьте 1-2 ГБ для кэша ОС и временных таблиц.
  • увеличить tmp_table_size
  • удалить swap
  • оптимизируйте query_cache_size (не делайте его слишком большим - см. документацию mysql об этом)
  • периодически запускать кэш флеш-запросов. если кэш запросов не очищает кэш, он оптимизирует (дефрагментирует). Это из mysql docs:

Дефрагментация кэша запросов к лучшему используйте его память. КЭШ ЗАПРОСОВ FLUSH не удаляет запросы из кэш, в отличие от таблиц FLUSH или RESET КЭШ ЗАПРОСОВ.

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

4

использовать vmstat и iostat чтобы узнать, является ли CPU или I/O узким местом (если I/O - добавить больше ОЗУ и загрузить данные в память). Запустите из оболочки и проверьте результаты:

vmstat 5
iostat -dx 5
  • если CPU является проблемой vmstat покажет высокие значения в и iostat покажет низкое использование диска (util)
  • если I / O является проблемой, то vmstat покажет низкие значения в и iostat покажет высокую загрузку диска (util); под высоким я подразумеваю >50%
2

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

можно использовать memcached кэшировать запросы mysql. Это немного облегчит использование ЦП, однако с помощью этого метода вы захотите увеличить ОЗУ для хранения запросов.

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

0

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

Если вы используете много CPU из-за сохраненных процедур, вы делаете это неправильно, и ваша душа не может быть сохранена в любом случае.

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

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

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

0

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

0

используйте "High-CPU Extra Large Instance".

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

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

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

в этом случае увеличение количества ЦП даст вам больше взрыва для доллара.

0