MySQL: как мне снизить «максимально возможное использование памяти»?

У меня недавно были проблемы с перебоями из-за нехватки памяти. (Мой VPS имеет 256M всего)

Я пытаюсь настроить MySQL, используя mysqltuner.pl, и получить следующие результаты:

-------- Общая статистика ---------------------------------------- ----------
[-] Пропущена проверка версии для скрипта MySQLTuner
[OK] В настоящее время работает поддерживаемая версия MySQL 5.0.51a-3ubuntu5.4-log
[OK] Работа на 64-битной архитектуре

-------- Статистика подсистемы хранения --------------------------------------- ----
[-] Статус: + Архив -BDB -Federated -InnoDB -ISAM -NDBCluster 
[-] Данные в таблицах MyISAM: 114M (таблицы: 454)
[!!] Всего фрагментированных таблиц: 34

-------- Показатели эффективности ---------------------------------------- ---------
[-] В течение: 40 с (570 q [14,250 qps], 23 conn, TX: 154K, RX: 23K)
[-] Чтение / запись: 100% / 0%
[-] Всего буферов: 338,0М глобально + 2,7М на поток (не более 20 потоков)
[!!] Максимально возможное использование памяти: 392,9 МБ (153% от установленной ОЗУ)
[OK] Медленные запросы: 0% (5/570)
[OK] Максимальное использование доступных соединений: 15% (3/20)
[!!] Размер буфера ключа / всего индексов MyISAM: 8,0M / 9,4M
[!!] Частота попаданий в ключевой буфер: 57,1% (7 кэшированных / 3 чтения)
[OK] Эффективность кэша запросов: 21,9% (7 кэшированных / 32 выбора)
[OK] Запрос обрезки кеша в день: 0
[OK] Сортировка, требующая временных таблиц: 0% (0 временных сортировок / 1 сортировка)
[OK] Временные таблицы, созданные на диске: 0% (0 на диске / 32 всего)
[OK] Частота попаданий в кэш потоков: 86% (3 созданных / 23 подключения)
[OK] Частота попаданий в кеш таблиц: 26% (128 открытых / 484 открытых)
[OK] Используемый лимит открытого файла: 25% (259 / 1K)
[OK] Столовые блокировки получены немедленно: 100% (492 немедленных / 492 блокировки)

-------- Рекомендации ----------------------------------------- ------------
Общие рекомендации:
    Запустите OPTIMIZE TABLE, чтобы дефрагментировать таблицы для повышения производительности.
    MySQL запустился в течение последних 24 часов - рекомендации могут быть неточными
    Уменьшите общий объем памяти MySQL для стабильности системы
Переменные для настройки:
  *** Максимальное использование памяти MySQL опасно высоко ***
  *** Добавьте RAM до увеличения буферных переменных MySQL ***
    key_buffer_size (> 9,4 млн)

Но я немного озадачен тем, как снизить максимальное использование памяти? Кажется, он основан на key_buffer и max_connections, но должно быть что-то еще?

my.cnf:

key_buffer = 8M
max_allowed_packet = 12M
нить стека = 128 КБ
thread_cache_size = 8
max_connections = 20
table_cache = 128
tmp_table_size = 256M
max_heap_table_size = 256M
join_buffer_size = 256K
query_cache_limit = 8M
query_cache_size = 64M

Я пытался прочитать статьи по настройке MySQL, но они, похоже, ориентированы на людей, которые уже знают, что они делают! Любая помощь будет оценена. Благодарность!

У вас есть сервер с 256M, но вы не можете использовать все это - помните, что есть некоторые издержки ОС. Добавьте к этому тот факт, что вы слишком много делаете, как уже упоминали другие люди, и вы определенно будете здесь. 256 Мбайт достаточно только для небольшой БД, 20 соединений - это много с тем, что вы настроили.

1) уменьшите максимальное количество подключений до 4 (вы используете 3 из 20)

2) лучше оптимизировать кеш запросов; 8M действительно велико, а всего 64M очень много, основываясь на ваших хитах / черносливах; попробуйте комбинацию 4/32 и посмотрите, как она идет. На самом деле я думаю, что 2/24 комбо будет работать для вас.

3) у вас нет сортировок, требующих временных таблиц, почему там глагол max_heap_table_size? Прокомментируйте это, используйте значения по умолчанию

4) у вас есть 128 таблиц? Попробуйте разрезать этот table_cache пополам до 64 или 48

5) уменьшить thread_cache_size до 4

6) оптимизировать эти таблицы для уменьшения фрагментации

Вот некоторые вещи для начала. Похоже, вы бросили кучу чисел в конфигурации без какого-либо фактического профилирования, чтобы знать, что вам нужно, и создали беспорядок; если ничего не помогает, вернитесь к настройкам по умолчанию, избавьтесь от своих пользовательских настроек и начните сначала, используя некоторые руководства по настройке производительности, которые вы можете найти в Google. Получите выходные данные SHOW VARIABLES и SHOW STATUS, найдите любое из руководств по настройке bajillion и включите ваши реальные, действительные числа в их уравнения, и они подскажут вам точные цифры, которые вам нужно добавить в файл конфигурации.

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

server_buffers + total_per_thread_buffers * max_connections

Где:

server_buffers = key_buffer_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size + query_cache_size

и:

total_per_thread_buffers = read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + max_allowed_packet + join_buffer_size

Теперь вы должны проверить каждое из этих значений и выяснить, какое из них отвечает за это огромное число. И не доверяйте этому сценарию безоговорочно - я попытался запустить его на одном из моих серверов БД, и он подсчитал, что максимальный объем памяти составляет 140% от общего объема физической памяти, но система работает годами без проблем со стабильностью.

Удачи!

Если я правильно помню, MySQL Tuner использует следующую формулу для оценки максимального использования:

read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size

Имейте в виду, что это не на 100% правильно, а на самом деле является лишь оценкой, поскольку некоторые настройки в MySQL не имеют определенного предела.

Вы можете начать настраивать некоторые параметры в своем конфигурационном файле и снова запустить тюнер, но я бы посоветовал обратиться за помощью к эксперту, если у вас нет времени тратить время на изменение my.cnf, его перезапуск и запуск тюнера.

Использование программного обеспечения mysqlcalculator.com может сэкономить вам много часов.