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

rsync -avz на продакшен у п’ятницю ввечері, рестарт php-fpm — і сайт відповідає 502, бо в .settings.php залишилися локальні налаштування БД. Деплой «по-старому» — лотерея. Оновлення модуля через адмінку ламає кастомний шаблон компонента, правки не зафіксовані в Git — відновлення займає години.

Ми проєктуємо передбачуваний DevOps-цикл для проєктів на Бітрікс: від Docker-середовища до алертів у Telegram. Кожен деплой стає рутиною, а не стресом.

Проблеми, які ми вирішуємо

Бітрікс історично жив у парадигмі «правимо файли по FTP на бойовому сервері». Результат: двоє розробників одночасно правлять init.php, затираючи зміни один одного. Оновлення модуля через адмінку ламає шаблон компонента — файли не зафіксовані в /local/templates/. Про падіння сайту дізнаються від клієнта, staging-середовища немає, перевірки йдуть на проді. Вартість такого підходу — години відновлення та втрата бізнес-логіки.

Чому DevOps критичний для Бітрікс-проєктів?

Проєкти на Бітрікс мають специфіку: важкий торговий каталог, обмін з 1С через CommerceML, безліч агентів та подій. Без CI/CD та моніторингу кожна зміна — ризик. Ручний деплой може спричинити тижневий простій. Після впровадження DevOps середня економія трудовитрат — до 12 годин ручної роботи на місяць, а бюджету підтримки — 15 000–25 000 грн на місяць. Наш 5-річний досвід (понад 50 проєктів на Бітрікс) і ліцензійна чистота рішень — гарантія стабільності.

Інструменти та конфігурація

CI/CD: від коміту до продакшену без рук

Git — переводимо проєкт з FTP на Git (GitLab, GitHub, Bitbucket). Структура гілок: main, staging, develop, feature-гілки. .gitignore під Бітрікс — нетривіальне завдання:

/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/upload/
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/license_key.php

Пропустиш managed_cache/ — репозиторій розпухне на гігабайти. Забудеш виключити license_key.php — ключ витече.

CI-пайплайн перевіряє код: PHPStan level 5+ ловить звернення до неіснуючих методів CIBlockElement, PHP_CodeSniffer з Bitrix-стандартом, PHPUnit для бізнес-логіки, composer audit, збірка фронту. CD-пайплайн розгортає без участі людини. Мерж у staging — деплой на staging. Мерж у main — деплой на production (з ручним підтвердженням або без). Zero-downtime через symlink-стратегію: нова версія в окремій папці, current → symlink перемикається за мілісекунди. upload/ живе поза релізними директоріями. При помилці healthcheck після деплою symlink відкочується. Інструменти: GitLab CI/CD, GitHub Actions, Deployer (PHP). Deployer зручний для Бітрікс — є готові рецепти для symlink-деплою та shared-директорій.

Як Docker вирішує проблему «у мене працює»?

Docker-середовище фіксує версії всіх компонентів: nginx, PHP, MySQL, Redis. Docker скорочує час розгортання нового розробника в 10 разів порівняно з ручним налаштуванням. Локальна розробка — docker-compose.yml включає nginx + php-fpm 8.1/8.2 + MySQL 8.0 (або MariaDB 10.6) + Redis + Memcached. Новий розробник: git clone + docker-compose up -d — за 5 хвилин пише код. Паралельна робота над різними версіями PHP — через окремі compose-файли.

Особливості Бітрікс у Docker: /upload/ монтується як named volume (не bind mount — інакше на Windows/Mac проблеми з правами та швидкістю). Cron-завдання (/bitrix/modules/main/tools/cron_events.php) — через окремий контейнер з тим же образом або supervisord. Модуль «Проактивний захист» (security) блокує запити через reverse proxy — потрібен правильний REMOTE_ADDR через set_real_ip_from та realip_module. bitrix/php_interface/dbconn.php та .settings.php задаються через змінні оточення.

Production: мультистейдж-збірка (build-стадія для асетів, production-стадія з легким образом), Docker Registry для тегованих образів, оркестрація через Docker Swarm або Kubernetes для великих проєктів.

Як правильно налаштувати nginx та php-fpm для Бітрікс?

Різниця між «сайт гальмує» та 200 ms TTFB — у конфігурації. nginx: location-блоки під Бітрікс обробляють urlrewrite.php для ЧПУ. /bitrix/admin/ закриває доступ по IP через allow/deny. expires 30d для статики — CSS, JS, зображення кешуються браузером. Brotli (стиснення на 15-20% ефективніше gzip) вмикається brotli on; brotli_comp_level 6;. Rate limiting на /bitrix/tools/ захищає від брутфорсу. HTTP/2 push для критичних ресурсів.

php-fpm: pm = dynamic, розрахунок pm.max_children за формулою (RAM - RAM_інших_сервісів) / avg_memory_per_process. Для Бітрікс avg зазвичай 40-80 MB. OPcache: opcache.memory_consumption=256 (стандартних 128 MB недостатньо — Бітрікс тягне тисячі файлів), opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 у продакшені (скидання через cachetool opcache:reset при деплої). php.ini: memory_limit=256M (для важких операцій імпорту до 512M), max_execution_time=60, upload_max_filesize=100M. Slowlog з request_slowlog_timeout=5s знаходить вузькі місця до скарг користувачів.

Інфраструктура та автоматизація

Моніторинг, логування та резервне копіювання

Як відбувається моніторинг та реагування на інциденти? Prometheus + Grafana: метрики CPU, RAM, диска, мережі, стану сервісів. Алерти: CPU > 80% за 5 хвилин, вільна RAM < 500 MB, диск > 85%, php-fpm queue > 0. Node Exporter, MySQL Exporter, PHP-FPM Exporter збирають дані з кожного компонента. Uptime check кожні 60 секунд — алерт у Telegram за хвилину при падінні сайту. Sentry для PHP-помилок — структуровані помилки з контекстом. Моніторинг агентів Бітрікс (b_agent): завислий агент може тихо ламати обмін з 1С годинами — перевіряємо NEXT_EXEC < NOW() - INTERVAL 1 HOUR. Логування: ELK Stack або Loki + Grafana — nginx access/error, php-fpm slow log, MySQL slow query log, помилки Бітрікс. Ротація через logrotate — без неї через півроку access.log займе 50 ГБ.

Staging-середовище ідентичне production: ті ж версії nginx, PHP, MySQL, модулі, налаштування php.ini. Автоматичне оновлення при мержі у staging-гілку. Періодичний клон БД з production з знеособленням персональних даних — UPDATE b_user SET EMAIL = CONCAT('user', ID, '@test.local'), PHONE = ''. HTTP Basic Auth або IP-фільтрація. Robots.txt з Disallow: /. Sandbox-режим платіжних шлюзів для тестування оплати.

Ansible як інфраструктура як код: ansible-playbook site.yml -l production — через 15 хвилин сервер налаштований ідентично. Ролі: common (users, SSH, NTP), web (nginx + php-fpm), db (MySQL + backup), monitoring (Prometheus + exporters). Ansible забезпечує налаштування сервера за 15 хвилин замість 3 годин вручну.

Географічна розподіленість — S3-сумісне сховище + окремий сервер в іншому ЦОД. Тестове відновлення щомісяця — бекап без перевірки лише ілюзія безпеки. Cron з повідомленнями: якщо беказ не пройшов — алерт одразу.

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

• Документація DevOps-процесу (схема деплою, політика гілок, опис інфраструктури)
• Налаштовані CI/CD пайплайни (GitLab CI / GitHub Actions) з робочими тригерами
• Docker-середовище (docker-compose.yml, Dockerfile, конфіги)
• Ansible-плейбуки для відтворення серверів
• Моніторинг (Grafana дашборди, алерти в Telegram/Slack)
• Захищені доступи з ролевою моделлю
• Навчання команди: два заняття з роботи з CI/CD, Docker та деплоєм
• Підтримка на етапі впровадження (два тижні після запуску)

Приклад GitLab CI для Бітрікс (фрагмент):

stages:
  - test
  - build
  - deploy

cache:
  paths:
    - vendor/

unit_tests:
  stage: test
  script:
    - composer install --no-progress
    - php vendor/bin/phpunit

deploy_staging:
  stage: deploy
  script:
    - ansible-playbook deploy.yml -l staging
  only:
    - staging

Як проходить впровадження?

1. Аудит поточного стану — оцінка інфраструктури, софту, процесів. Займає 2-3 дні.
2. Проектування архітектури — вибір стеку (Docker/K8s/Ansible), узгодження політик CI/CD, налаштування репозиторію.
3. Налаштування середовищ — Docker-середовище для локальної розробки, staging-середовище, production-сервери.
4. Реалізація CI/CD — написання пайплайнів, тестування деплою, інтеграція з моніторингом.
5. Моніторинг та алертинг — встановлення Prometheus + Grafana, налаштування дашбордів та оповіщень.
6. Навчання команди — два заняття з роботи з інструментами.

Типові терміни впровадження

DevOps — не проєкт з фінальною датою, а перехід від «закинув по FTP і молюся» до передбачуваних процесів. Кожен деплой — рутина, кожен інцидент — алерт з контекстом, кожен новий розробник — docker-compose up замість триденного налаштування середовища. Отримайте консультацію — зв'яжіться з нами, і за 2-3 дні підготуємо план впровадження. Замовте DevOps-впровадження під ключ — отримайте стабільність і контроль над інфраструктурою.