У меня есть таблица, которая приближается к 2 миллионам записей. В этой таблице хранится история транзакций. Это на веб-сайте с высокой посещаемостью, но и к таблице регулярно не обращаются. В настоящее время у нас нет медленных запросов из-за этой таблицы, но я ищу, когда мне следует ожидать необходимости переноса данных из этой таблицы в метод архивирования данных.
Сервер представляет собой средний блок amazon ec2 с высоким процессором.
High-CPU Medium Instance
1.7 GB of memory
5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each)
350 GB of instance storage
32-bit platform
I/O Performance: Moderate
API name: c1.medium
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 1677878
Avg_row_length: 71
Data_length: 120209408
Max_data_length: 0
Index_length: 246497280
Data_free: 0
Auto_increment: 1914179
Create_time: 2011-08-07 20:15:29
Update_time: NULL
Check_time: NULL
Collation: latin1_swedish_ci
Checksum: NULL
Create_options:
Comment: InnoDB free: 7168 kB
Несколько вопросов:
В какой момент я могу увидеть снижение производительности из-за количества записей в этой таблице?
Какие настройки я должен проверять на сервере mysql с помощью SHOW INNODB STATUS и в самой таблице (то есть в формате строки), чтобы обеспечить максимальную производительность по мере необходимости?
Какие показатели мне нужно собирать, чтобы рассчитывать эффективность с течением времени?
Так много вопросов!! Что касается вашего первого пункта, вы, вероятно, начнете замечать проблемы с производительностью, если начнете вызывать полное сканирование таблиц или объединения, которые создают временные таблицы. Вы можете отследить это, посмотрев на вывод EXPLAIN для ваших запросов. Вот некоторая информация об EXPLAIN:
http://weevilgenius.net/2010/09/mysql-explain-reference/
Что касается настроек, в идеале было бы здорово, если бы вы поместили всю свою базу данных в память. Вот переменные, которые, вероятно, лучше всего настроить:
innodb_buffer_pool_size=8192M
innodb_additional_mem_pool_size=512M
innodb_log_buffer_size=8M
innodb_flush_method = O_DIRECT
key_buffer_size=4096M
read_buffer_size=1M
read_rnd_buffer_size=10M
sort_buffer_size=1M
join_buffer_size=1M
tmp_table_size=32M
Вы захотите сделать большинство из них настолько большими, насколько это разумно (вы захотите изучить некоторые из них, поскольку некоторые из них относятся к каждому соединению, а некоторые являются глобальными). Вы упомянули SHOW INNODB STATUS, это отличное место для начала, попробуйте посмотреть на эти поля:
--------
FILE I/O
--------
Pending normal aio reads: 0, aio writes: 0,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
28889 OS file reads, 52982178 OS file writes, 35063424 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 2.67 writes/s, 2.67 fsyncs/s
Они должны показать вам, если вы где-то связаны IO. Тогда проверьте:
----------------------
BUFFER POOL AND MEMORY
----------------------
Free buffers 342668
чтобы убедиться, что у вас есть свободные буферы.
Что касается вашего последнего вопроса о том, что нужно отслеживать, то чем больше, тем лучше. Я использую OpenNMS для мониторинга производительности нашего сервера MySQL. Вот то, что мы в настоящее время отслеживаем / предупреждаем о резких изменениях:
EventCount
Uptime
Bytes_received
Bytes_sent
Com_delete
Com_delete_multi
Com_insert
Com_insert_select
Com_select
Com_stmt_execute
Com_update
Com_update_multi
Created_tmp_disk_tables
Created_tmp_tables
key_buffer_size
key_cache_block_size
Key_blocks_unused
Key_read_requests
Key_reads
Key_write_requests
Key_writes
Open_files
Open_tables
table_open_cache
Questions
Slow_queries
Connections
Threads_created
Threads_cached
Threads_connected
Threads_running