MySQL та MariaDB: налаштування для 1С-Бітрікс без гальм

MySQL та MariaDB: налаштування для 1С-Бітрікс без гальм

Ми часто стикаємося з ситуацією: сервер з 32 ГБ RAM, але MySQL використовує лише 2 ГБ. Дефолтний innodb_buffer_pool_size — 128 МБ або навіть 8 МБ. На каталозі з 500 000 SKU робочий набір даних — 4–8 ГБ. Без нормального буфера кожен запит до незакешованих сторінок йде на диск: 5–10 мс замість 0,1 мс з пам'яті. Результат — сторінки завантажуються по 10–15 секунд, адміністратори скаржаться, клієнти йдуть. Налаштування MySQL та MariaDB для Бітрікс — це завдання, яке ми вирішуємо регулярно. Економія на обладнанні за рахунок грамотної конфігурації становить до 30% бюджету на хостинг.

Чому налаштування MySQL критичне для Бітрікс?

Бітрікс активно використовує InnoDB для зберігання інфоблоків, торгових каталогів, властивостей та подій. При дефолтній конфігурації база даних стає вузьким місцем, навіть якщо інші ресурси сервера надлишкові. Ми оптимізували MySQL для десятків проектів на Бітрікс і знаємо, які параметри дають максимальний приріст. Зниження навантаження на диск також знижує витрати на підтримку та продовження.

Правильне налаштування InnoDB buffer pool

Розмір буфера — найважливіший параметр. Встановіть 60–70% від RAM для виділеного DB-сервера. Для 32 ГБ це 20 ГБ. Додайте кілька буферних пулів, щоб зменшити конкуренцію за м'ютекс: innodb_buffer_pool_instances = 8. Якщо у вас 64 ГБ RAM, можна 40–45 ГБ з 8–16 інстансами. На серверах з високою конкурентністю кількість пулів має бути приблизно рівною кількості ядер CPU. Це дає приріст до 20% у багатопотокових навантаженнях.

Параметри InnoDB: Файл /etc/mysql/conf.d/bitrix.cnf:

[mysqld] # ===== InnoDB Buffer Pool ===== # 60-70% від RAM для виділеного DB-сервера innodb_buffer_pool_size = 20G innodb_buffer_pool_instances = 8 # ~1 instance per 1-2GB # ===== InnoDB I/O ===== innodb_io_capacity = 2000 # для SSD: 2000-4000 innodb_io_capacity_max = 4000 innodb_flush_method = O_DIRECT # обхід OS page cache innodb_flush_log_at_trx_commit = 2 # не fsync на кожну транзакцію # ===== Redo Log ===== # MySQL 8.0+: керується автоматично # MariaDB / MySQL 5.7: innodb_log_file_size = 1G innodb_log_buffer_size = 64M # ===== Connections ===== max_connections = 500 thread_cache_size = 50 wait_timeout = 300 interactive_timeout = 300 # ===== Query Cache ===== # MySQL 8.0: Query Cache видалено # MariaDB / MySQL 5.7: вимикаємо (краще використовувати Memcached/Redis) query_cache_type = 0 query_cache_size = 0 # ===== Temp Tables ===== tmp_table_size = 256M max_heap_table_size = 256M # ===== Slow Log ===== slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = 1 

innodb_flush_log_at_trx_commit = 2 — транслог скидається на диск раз на секунду, не при кожному COMMIT. Ризик втрати транзакцій за 1 секунду при збої — прийнятно для більшості інтернет-магазинів. Дає 3–5x зростання запису. innodb_flush_method = O_DIRECT — MySQL пише безпосередньо в блочний пристрій, минаючи OS page cache. Виключає подвійне кешування.

Що дає налаштування для NVMe SSD?

На сучасних NVMe дисках можна агресивніше:

innodb_io_capacity = 10000 innodb_io_capacity_max = 20000 innodb_read_io_threads = 8 innodb_write_io_threads = 8 

Це збільшує пропускну здатність до 30% порівняно зі звичайним SSD. Наприклад, нещодавно ми налаштували сервер клієнта з каталогом 200 000 товарів — час генерації сторінки знизився з 12 до 2 секунд.

Порівняння продуктивності при різних конфігураціях:

Таблиці Бітрікс: специфіка

b_search_content — повнотекстовий індекс. Таблиця зростає до 2–5 ГБ на великих сайтах. Якщо використовується Elasticsearch — цю таблицю можна утнути та вимкнути вбудовану індексацію.

b_iblock_element_prop_m* — множинні властивості. При 1М+ рядків без індексів — гальмо розумного фільтра. Ми додаємо індекси за полями IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID.

b_event — лог подій системи. На активних сайтах зростає на 10–50 МБ на добу. Чистити через агент або крон:

DELETE FROM b_event WHERE DATE_COLUMN < DATE_SUB(NOW(), INTERVAL 90 DAY); 

Також зверніть увагу на b_catalog_price та b_sale_basket — без індексів вони сильно сповільнюють роботу кошика та прайс-листів.

Як перевірити ефективність налаштування?

Моніторинг стану InnoDB:

-- Ефективність buffer pool (має бути > 99%) SELECT (1 - ( (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads') / (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests') )) * 100 AS buffer_pool_hit_rate; -- Топ очікувань SELECT * FROM sys.innodb_lock_waits; 

buffer_pool_hit_rate < 95% — innodb_buffer_pool_size занадто малий, дані постійно читаються з диска.

Ключові параметри MySQL для Бітрікс: дефолт проти оптимізації

Процес роботи

1. Аналітика — збір поточної конфігурації, профілювання навантаження, вимірювання часу запитів.
2. Проектування — підбір параметрів під ваш обсяг даних, трафік та обладнання.
3. Реалізація — зміна конфігураційних файлів, рестарт MySQL (5-10 секунд простою) або застосування параметрів через SET GLOBAL.
4. Тестування — перевірка через slow log, моніторинг buffer pool hit rate, виправлення індексів.
5. Деплой — фінальне налаштування та документування.

Що входить в результат

• Оптимізація параметрів MySQL/MariaDB під вашу версію та навантаження.
• Перевірка та доналаштування індексів на таблицях Бітрікс.
• Увімкнення slow log та інструкція з аналізу.
• Звіт з аргументацією кожного параметра.
• Підтримка 7 днів після налаштування.
• Економія на обладнанні за рахунок підвищення продуктивності.

Ми маємо 5+ років досвіду в налаштуванні MySQL для Бітрікс і провели оптимізацію на більш ніж 50 проектах. Гарантуємо приріст продуктивності бази даних у 3-5 разів.

Замовте аудит бази даних прямо зараз — ми підберемо оптимальну конфігурацію під ваші завдання. Отримайте консультацію з налаштування вашого сервера — зв'яжіться з нами для аудиту.

Детальніше про InnoDB на Wikipedia