Оптимізація MySQL/MariaDB під навантаження Бітрікс

Дефолтна конфігурація MySQL після встановлення розрахована на сервер з 256 МБ RAM. Бітрікс на реальному магазині — це тисячі запитів за хвилину до b_iblock_element, b_sale_order, b_catalog_price. Без налаштування my.cnf сервер працює з буферними пулами в 128 МБ при 16 ГБ доступної пам'яті, робить дискові I/O там, де має читати з кешу, і тримає пул з'єднань на рівні, що викликає черги при піковому навантаженні.

Ми провели десятки аудитів для інтернет-магазинів на Бітрікс: у 90% випадків дефолтна конфігурація призводила до падінь latency при 100+ одночасних замовленнях. Наш досвід — 10+ років у бітрікс-розробці, 50+ проєктів з оптимізації БД. Компанія працює на ринку з 2015 року. Пропонуємо послугу під ключ: від діагностики до фінального тюнінгу з гарантією покращення продуктивності. Детальніше про MySQL та MariaDB.

Вартість аудиту — від $500, комплексна оптимізація — від $1500. Середня економія на серверних ресурсах після впровадження — до $2000 на місяць.

Оптимізація MySQL для Бітрікс: покроковий підхід

Процес включає аудит поточних налаштувань, розрахунок параметрів під навантаження вашого магазину, тестування на staging та поетапне впровадження на production. Ми використовуємо стандартні утиліти: mysqltuner.pl, pt-variable-advisor, та моніторинг через SHOW GLOBAL STATUS. Після змін проводимо повторний замір метрик — hit rate буферного пулу має бути вище 99%, тимчасові таблиці на диску — відсутні.

Ключові параметри конфігурації

# InnoDB Buffer Pool innodb_buffer_pool_size = 12G # 70-75% RAM innodb_buffer_pool_instances = 8 innodb_buffer_pool_chunk_size = 128M # InnoDB Log innodb_log_file_size = 1G innodb_log_buffer_size = 64M innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT # Connections max_connections = 300 thread_cache_size = 64 table_open_cache = 4000 table_definition_cache = 2000 # Temporary tables tmp_table_size = 256M max_heap_table_size = 256M # Slow queries slow_query_log = 1 long_query_time = 0.5 log_queries_not_using_indexes = 1 min_examined_row_limit = 1000 

Налаштування InnoDB Buffer Pool

InnoDB Buffer Pool — найважливіший параметр. Має вміщувати робочий набір даних цілком. На виділеному сервері БД встановлюємо 70–75% RAM. Правило: якщо hit rate буферного пулу (дивимось через SHOW GLOBAL STATUS) нижче 99%, значить пам'яті не вистачає. Збільшуємо до 80% RAM, але не більше 90%, щоб залишити місце ОС. Враховуйте mutex contention: при великій кількості потоків розбивайте пул на інстанси (innodb_buffer_pool_instances).

InnoDB Log та flush

Для Бітрікс з інтенсивними записами (замовлення, сесії, агенти): innodb_log_file_size = 1G, innodb_log_buffer_size = 64M. innodb_flush_log_at_trx_commit = 2 дає до 30% приросту продуктивності при записі ціною втрати даних останньої секунди при жорсткому падінні сервера — для більшості e-commerce сайтів це прийнятно. Якщо є суворі вимоги щодо ACID (фіскальні операції) — залишаємо значення 1.

Чому важливе налаштування тимчасових таблиць?

Розумний фільтр та пошук Бітрікс активно створюють тимчасові таблиці. Якщо тимчасова таблиця не вміщується в пам'ять — MySQL пише її на диск (spill to disk), що сповільнює запит у 10–50 разів. Моніторимо через SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'. Якщо значення зростає — збільшуємо розміри.

З'єднання та потоки

Бітрікс використовує постійні з'єднання через PHP-FPM. При 20 воркерах PHP-FPM і пулі в 10 процесів кожен — 200 одночасних з'єднань із запасом. Ставити max_connections = 1000 без потреби — резервувати RAM під невикористовувані thread stacks.

Специфіка MariaDB

MariaDB 10.4+ має ряд параметрів, відсутніх у MySQL:

innodb_adaptive_hash_index_parts = 8 aria_pagecache_buffer_size = 512M # для MyISAM/Aria таблиць сесій 

Бітрікс за замовчуванням зберігає PHP-сесії у файлах, але при використанні сесій у БД або модуля bitrix.session таблиці сесій можуть бути MyISAM — враховуємо це при налаштуванні.

Рекомендовані значення для різних об'ємів RAM

Порівняння: дефолт vs оптимізація

Оптимізована конфігурація дає час відповіді в 6–7 разів швидше за дефолтну: hit rate буферного пулу піднімається з 60% до 99.9%, тимчасові таблиці на диску зникають, середній час запиту падає з 200 мс до 30 мс. Таким чином, оптимізований сервер працює в 5-7 разів швидше за дефолтний. Для типових запитів каталогу швидкість зросла в 3-5 разів.

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

1. Аудит поточної конфігурації за допомогою mysqltuner.pl та pt-variable-advisor, аналіз SHOW GLOBAL STATUS.
2. Розрахунок параметрів під ваш сервер: RAM, CPU, навантаження, дискова підсистема.
3. Застосування змін на staging з навантажувальним тестуванням.
4. Розгортання на production у вікно технічного обслуговування.
5. Моніторинг після змін через Zabbix/Prometheus + mysqld_exporter.

Що входить в роботу?

1. Аудит конфігурації та slow query log аналіз.
2. Надання документації з рекомендаціями.
3. Повний доступ до сервера на час робіт.
4. Навчання команди моніторингу.
5. Підтримка протягом 30 днів після впровадження.

Результат оптимізації MySQL для Бітрікс

Коректна конфігурація MySQL під Бітрікс знижує середній час відповіді БД на 40–70%, прибирає піки latency при конкурентних запитах, знижує дисковий I/O на сервері в 2–5 разів.

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

— Рекомендації з налаштування продуктивності MySQL в документації Oracle (InnoDB Startup Options).

Ключові метрики нашої компанії: понад 10 років досвіду в оптимізації БД, 50+ успішних проєктів, з 2015 року на ринку. Середня економія клієнтів на серверних ресурсах — $2000/міс.