Mysql InnoDB размер таблицы производительности

У меня есть таблица, которая приближается к 2 миллионам записей. В этой таблице хранится история транзакций. Это на веб-сайте с высоким трафиком, но к таблице регулярно нет доступа. В настоящее время у нас нет медленных запросов из-за этой таблицы, но мы ожидаем, когда мне нужно будет перенести данные из этой таблицы в метод архивации данных.

Сервер является средним процессором Amazon Ec2 High Box.

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 и на самой таблице (т. Е. В формате строки), чтобы обеспечить максимальную производительность, которая мне нужна?

  • Какие метрики я должен собрать, чтобы вычислить производительность с течением времени?

Источник

1 ответ

Решение

Так много вопросов!! Прежде всего, вы, вероятно, начнете замечать проблемы с производительностью, если начнете вызывать полные сканирования или объединения таблиц, которые создают временные таблицы. Вы можете отследить это, посмотрев вывод 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
Источник
Другие вопросы по тегам