Почему mySQL постоянно уходит в swap?

Question

[mmib]

Есть Ubuntu 12.04 server c 8GB памяти. На нем стоит mysql 5.5.24-0ubuntu0.12.04.1-log
Конфиг вот такой

key_buffer              = 128M
thread_stack            = 256K
thread_cache_size       = 8
myisam-recover         = BACKUP
table_cache            = 8192
table_definition_cache = 8192
max_heap_table_size    = 256M
query_cache_limit       = 8M
query_cache_size        = 128M
open_files_limit=10000
innodb_buffer_pool_size = 2GB
innodb_additional_mem_pool_size = 80M
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_file_size = 256M
innodb_log_buffer_size=64M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
innodb_file_per_table

expire_logs_days        = 10
max_binlog_size         = 100M
log-error = /var/log/mysql/mysqld.err

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

Comments

[balloon]

SHOW STATUS можно посмотреть?

[mmib]

mysql> SHOW STATUS;
+------------------------------------------+-------------+
| Variable_name                            | Value       |
+------------------------------------------+-------------+
| Aborted_clients                          | 1           |
| Aborted_connects                         | 535         |
| Binlog_cache_disk_use                    | 47          |
| Binlog_cache_use                         | 74147       |
| Binlog_stmt_cache_disk_use               | 0           |
| Binlog_stmt_cache_use                    | 775         |
| Bytes_received                           | 147         |
| Bytes_sent                               | 16909       |
| Com_select                               | 1           |
| Com_show_status                          | 3           |
| Compression                              | OFF         |
| Connections                              | 229727      |
| Created_tmp_disk_tables                  | 0           |
| Created_tmp_files                        | 735         |
| Flush_commands                           | 1           |
| Innodb_buffer_pool_pages_data            | 129494      |
| Innodb_buffer_pool_pages_dirty           | 177         |
| Innodb_buffer_pool_pages_flushed         | 701844      |
| Innodb_buffer_pool_pages_free            | 0           |
| Innodb_buffer_pool_pages_misc            | 1578        |
| Innodb_buffer_pool_pages_total           | 131072      |
| Innodb_buffer_pool_read_ahead_rnd        | 0           |
| Innodb_buffer_pool_read_ahead            | 44076       |
| Innodb_buffer_pool_read_ahead_evicted    | 600042      |
| Innodb_buffer_pool_read_requests         | 2044009137  |
| Innodb_buffer_pool_reads                 | 3362671     |
| Innodb_buffer_pool_wait_free             | 0           |
| Innodb_buffer_pool_write_requests        | 3891889     |
| Innodb_data_fsyncs                       | 339765      |
| Innodb_data_pending_fsyncs               | 1           |
| Innodb_data_pending_reads                | 0           |
| Innodb_data_pending_writes               | 0           |
| Innodb_data_read                         | 55840591872 |
| Innodb_data_reads                        | 3481457     |
| Innodb_data_writes                       | 498339      |
| Innodb_data_written                      | 11765979136 |
| Innodb_dblwr_pages_written               | 350922      |
| Innodb_dblwr_writes                      | 20301       |
| Innodb_have_atomic_builtins              | ON          |
| Innodb_log_waits                         | 0           |
| Innodb_log_write_requests                | 353942      |
| Innodb_log_writes                        | 184889      |
| Innodb_os_log_fsyncs                     | 203038      |
| Innodb_os_log_pending_fsyncs             | 1           |
| Innodb_os_log_pending_writes             | 0           |
| Innodb_os_log_written                    | 257838080   |
| Innodb_page_size                         | 16384       |
| Innodb_pages_created                     | 26821       |
| Innodb_pages_read                        | 3408105     |
| Innodb_pages_written                     | 350922      |
| Innodb_row_lock_current_waits            | 0           |
| Innodb_row_lock_time                     | 39129       |
| Innodb_row_lock_time_avg                 | 235         |
| Innodb_row_lock_time_max                 | 1670        |
| Innodb_row_lock_waits                    | 166         |
| Innodb_rows_deleted                      | 82561       |
| Innodb_rows_inserted                     | 114255      |
| Innodb_rows_read                         | 1246503074  |
| Innodb_rows_updated                      | 223175      |
| Innodb_truncated_status_writes           | 0           |
| Key_blocks_not_flushed                   | 0           |
| Key_blocks_unused                        | 107155      |
| Key_blocks_used                          | 127         |
| Key_read_requests                        | 1599608     |
| Key_reads                                | 2184        |
| Key_write_requests                       | 508800      |
| Key_writes                               | 2371        |
| Last_query_cost                          | 0.000000    |
| Max_used_connections                     | 30          |
| Not_flushed_delayed_rows                 | 0           |
| Open_files                               | 17          |
| Open_streams                             | 0           |
| Open_table_definitions                   | 8192        |
| Open_tables                              | 8192        |
| Opened_files                             | 8802118     |
| Qcache_free_blocks                       | 15752       |
| Qcache_free_memory                       | 49185176    |
| Qcache_hits                              | 37441738    |
| Qcache_inserts                           | 7995967     |
| Qcache_lowmem_prunes                     | 7051915     |
| Qcache_not_cached                        | 1466085     |
| Qcache_queries_in_cache                  | 52277       |
| Qcache_total_blocks                      | 135288      |
| Queries                                  | 61238738    |
| Questions                                | 4           |
| Rpl_status                               | AUTH_MASTER |
| Select_full_join                         | 0           |
| Select_full_range_join                   | 0           |
| Select_range                             | 0           |
| Select_range_check                       | 0           |
| Select_scan                              | 0           |
| Slave_heartbeat_period                   | 0.000       |
| Slave_open_temp_tables                   | 0           |
| Slave_received_heartbeats                | 0           |
| Slave_retried_transactions               | 0           |
| Slave_running                            | OFF         |
| Ssl_session_cache_mode                   | NONE        |
| Table_locks_immediate                    | 18648370    |
| Threads_cached                           | 4           |
| Threads_connected                        | 5           |
| Threads_created                          | 49          |
| Threads_running                          | 4           |
| Uptime                                   | 413776      |
| Uptime_since_flush_status                | 413776      |
+------------------------------------------+-------------+
310 rows in set (0.00 sec)

Строки со значением 0 убрал

Answer 1

[script88]

Слишком много! Надо попробовать уменьшить

table_cache            = 8192
table_definition_cache = 8192

query_cache_limit       = 8M уменьшите до 2M
innodb_buffer_pool_size - желательно ставить по объему страниц
max_heap_table_size    = 256M уменьшите до 64M

а также добавьте

tmp-table-size = 64M

временные таблицы – в памяти

tmpdir = /dev/shm

Comments

[mmib]

Спасибо, попробую

[script88]

Посмотрите также вывод:

SHOW ENGINE INNODB STATUS\G

Если Buffer pool hit rate 998 / 1000 выглядит примерно так, не привышая 1000, то InnoDB buffer pool настроен корректно.

P.S. диапозон хит рейта от 900 до 1000 это нормально

[mmib]

Buffer pool hit rate 1000 / 1000

[mmib]

Подправил конфиг по вашим советам, за ночь отъедено 4.8GB, в своп не ушли. Посмотрю, что будет через пару-тройку дней.

[script88]

Ну как результат?

[mmib]

Спасибо, все хорошо пока.

Answer 2

[Nail]

У InnoDB есть свой справочник таблиц, который оно держит в памяти. Там содержится инфа обо всех открывавшихся таблицах, в стандартной версии MySQL он никогда не очищается — отсюда рост памяти.

В Percona xtradb против этого добавили настройку innodb_dict_size_limit
www.percona.com/doc/percona-server/5.5/management/innodb_dict_size_limit.html

Once a table is opened, it is never removed from the data dictionary unless you drop the table or you restart the server. In some cases, the data dictionary grows extremely large. If this consumes enough memory, the server will begin to use virtual memory. Use of virtual memory can cause swapping, and swapping can cause severe performance degradation. By providing a way to set an upper limit to the amount of memory the data dictionary can occupy, this feature provides users a way to create a more predictable and controllable situation.

Answer 3

[balloon]

Исходя из Innodb_buffer_pool_pages_free = 0 предположу, что следует увеличить innodb_buffer_pool_size.

Comments

[mmib]

вот только в своп мы попадем еще быстрее тогда

Answer 4

[egorinsk]

Так а в чем ваша проблема? MySQL выделяет столько памяти, что ОС вынуждена часть его вытеснить в свап, или MySQL потребляет столько, сколько и должен, просто частично вываливается в свап? Во втором случае вам надо играть с параметрами ядра, отвечающими за swappiness и подобные вещи. В первом — смотреть, почему так много памяти потребляется.

Comments

[mmib]

проблема в том, что по моим подсчетам и данным mysqltuner.pl mysql должен кушать не более 6GB, а эта прожорливая сволочь отъедает все 10

Answer 5

[demimurych]

Используйте
mysqltuner.pl/mysqltuner.pl

или аналоги

Comments

[mmib]

Выше писал, что использовал, но мускул все равно жрет память, хотя по данным тюнера не должен

Answer 6

[pentarh]

Одно из двух.

1. Либо конфигурация параметров памяти слишком велика, как и велика нагрузка, чтобы все это влезло в оперативу. Чес говоря, я смотрю и думаю что маловероятно.
2. Либо конфигурация параметров памяти слишком велика, а нагрузка для такой конфигурации слишком мала. По этому память не используется и ядро скидывает ее в своп для оптимизации.

Ситуация 2 может возникнуть например, при вашей настройке innodb_buffer_pool_size (2Г) и общим объемом таблиц INNODB в 100М.

innodb_buffer_pool_size должен быть на уровне 130-200% от планируемого объема таблиц. Остальная память попросту может не использоваться.

Comments

[mmib]

Странное заключение. А если таблиц на сервере 10Г (что не так уж далеко от истины), а памяти всего 8Г?

[pentarh]

Тогда будет активнее использоваться диск с соотв тормозами. Хотя зависит от нагрузки. Но к вопросу это не имеет отношения.