MySQL 5.1 и память перемещаются медленно. с графиком - PullRequest
1 голос
/ 31 января 2012

Мы находимся на RHEL 5.4 64-битной, 16 ГБ ОЗУ 6x AMD Opteron.

Итак, мы столкнулись с этой проблемой:

http://imgur.com/LMHi4

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

В основном используется Innodb со следующей конфигурацией:

key_buffer      = 512M
max_allowed_packet  = 128M
thread_stack        = 192K
thread_cache_size       = 8
table_cache            = 812
thread_concurrency     = 10

query_cache_limit       = 4M
query_cache_size        = 512M
join_buffer_size        = 512K

innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 10G
innodb_file_io_threads = 4
innodb_thread_concurrency = 12
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 8M
innodb_log_file_size = 512M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120

Я много слышал об отключении «swappiness» или установке его на «10»,Но разве это не вызовет OOM и не убьет mysql?почему это происходит?

1 Ответ

1 голос
/ 15 мая 2013

Просто чтобы ответить на мой собственный вопрос через 1+ лет после свершившегося факта. Это из опыта. MySQL имеет тенденцию поменяться, медленно. Особенно, если он настроен на использование всей необходимой памяти.

В этом случае я просто понизил размер buffer_pool_size до чуть ниже рекомендованного для документов (<80% физической памяти), а также изменил swappiness до 10. Установка этого значения в 10 не приведет к OOM, так как система будет по-прежнему использовать своп при необходимости, но не так агрессивно. </p>

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...