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 кон., 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 вибору)
[Добре] Запит на чорнослив в день: 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 небезпечно високе ***
  *** Додайте оперативну пам'ять перед збільшенням змінних буферів MySQL ***
    key_buffer_size (> 9,4М)

Але я трохи розгублений, як зменшити максимальне використання пам'яті? Здається, він базується на key_buffer та max_connections, але має бути ще щось задіяне?

my.cnf:

key_buffer = 8М
max_allowed_packet = 12М
thread_stack = 128K
thread_cache_size = 8
max_connections = 20
table_cache = 128
tmp_table_size = 256М
max_heap_table_size = 256М
join_buffer_size = 256K
query_cache_limit = 8М
query_cache_size = 64М

Я намагався читати статті про налаштування MySQL, але вони здаються орієнтованими на людей, які вже знають, що роблять! Будь-яка допомога буде вдячна. Спасибі!

У вас є сервер з 256M, але ви не можете використовувати все це - пам’ятайте, що тут є деякі операційні системи. Додайте до цього той факт, що ви закінчилися, як згадували інші люди, і ви обов'язково натрапите тут. 256M достатньо лише для невеликої БД, 20 підключень - це багато з тим, що ви налаштували.

1) зменшіть максимальне з'єднання до 4 (ви використовуєте 3 з 20)

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

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

4) у вас насправді є 128 таблиць? Спробуйте розрізати цей table_cache навпіл до 64 або 48

5) зменшити розмір теми_cache_size до 4

6) оптимізуйте ці таблиці, щоб зменшити фрагментацію

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

Я не гуру 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 тюнер використовує наступну формулу для оцінки максимального використання:

read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size

Майте на увазі, що це не на 100% правильно, а насправді є лише оцінкою, оскільки деякі параметри в MySQL не мають визначеного обмеження.

Ви можете почати тонізувати деякі налаштування у вашому конфігураційному файлі та запустити тюнер знову, але я радив би отримати допомогу фахівця, якщо у вас немає часу витрачати на зміну my.cnf, перезапустити його та запустити тюнер.

Використання програмного забезпечення mysqlcalculator.com може заощадити багато годин.