В какой-то момент практически все коммуникации компании ушли в Битрикс24.
А это и мессенджер, и проекты, и задачи практически на любой чих. Количество пользователей постепенно выросло примерно до 200 человек, из которых около 100 были активными пользователями.
Вместе с этим росло и количество запросов к системе.
Изначально коробка Битрикс24 была развёрнута в облаке одного из хостинг-провайдеров. Процессора и памяти вроде как хватало, но периодически вся система начинала здорово тормозить.
Причём тормозить уже не просто так, чтобы это было неприятно администратору. Пользователи начинали это замечать, а значит, тормоза уже реально мешали рабочим процессам.
Техподдержка провайдера всё валила на сам Битрикс:
У вас тяжёлый Битрикс, смотрите код и оптимизируйте приложение.
В принципе, версия вполне правдоподобная. Битрикс действительно нельзя назвать лёгкой системой.
Но что-то не сходилось.
Начали искать, что именно тормозит
CPU не был постоянно загружен под 100%, свободная память тоже была. При этом в моменты активности пользователей система могла резко становиться очень медленной.
Постепенно подозрение перешло на дисковую подсистему.
Для начала на Linux вообще полезно смотреть не только загрузку процессора, но и iowait:
topили:
vmstat 1В vmstat нас в первую очередь интересует колонка:
waЭто время, которое CPU фактически проводит в ожидании операций ввода-вывода.
Для более подробной картины можно использовать iostat:
sudo dnf install -y sysstat
iostat -xz 1Особенно интересны:
%util
await
r_await
w_await
aqu-szСам по себе высокий %util ещё не приговор, но если одновременно растут задержки await, очередь запросов и Битрикс начинает вставать — повод смотреть на хранилище уже очень внимательно.
Ещё один полезный инструмент:
iotopОн позволяет посмотреть, какие процессы в данный момент активно работают с диском.
В случае Битрикса среди кандидатов вполне ожидаемо могут оказаться:
mysqld
php-fpmи процессы, которые работают с файлами.
Точных исторических графиков и цифр у нас, к сожалению, не сохранилось. Тогда задача была не написать статью и построить красивый тест, а просто понять, почему всё тормозит.
Но после серии проверок стало понятно, что основное узкое место находится именно в дисковой подсистеме виртуального сервера.
При большом количестве обращений к базе задержки резко увеличивались и вместе с ними начинал тормозить весь Битрикс.
Почему виртуальный сервер может тормозить даже при свободных CPU и RAM
У виртуального сервера красивые цифры по процессору и памяти ещё не означают, что в вашем распоряжении такая же хорошая дисковая подсистема.
Условно можно иметь:
CPU — свободен
RAM — свободна
↓
Хранилище — очередь
↓
MySQL ждёт диск
↓
PHP ждёт MySQL
↓
пользователь ждёт страницуОсобенно хорошо это проявляется на системах с большим количеством мелких операций с базой.
Сам Битрикс в этой ситуации может быть вообще ни при чём — он просто достаточно активно пользуется ресурсом, который оказался узким местом.
Конечно, это не означает, что любой тормозящий Битрикс нужно немедленно переносить на железный сервер. Сначала надо проверить PHP, MySQL/MariaDB, кеширование, фоновые задания, агенты и сам код.
Но в нашем случае картина всё больше указывала именно на дисковую подсистему.
Вторая проблема — S3
Отдельно было подключено S3-хранилище для пользовательских файлов.
И оно тоже не отличалось высокой скоростью.
Здесь важно уточнить: проблема не в самом S3 как технологии.
Речь именно о хранилище, которое было доступно у нашего тогдашнего провайдера, и о его работе в нашей конфигурации.
В результате получалось два потенциально медленных участка:
Битрикс
│
├── база данных → дисковая подсистема VM
│
└── файлы → S3Поэтому вместо дальнейшей борьбы с виртуальной инфраструктурой решили посмотреть, сколько будет стоить обычный выделенный сервер.
Выбираем железный сервер
После недолгих поисков нашли в аренду выделенный сервер у одного из крупных провайдеров:
Intel Xeon E-2236 3.4 ГГц
32 ГБ RAM
2 × 512 ГБ SSD
2 × 4 ТБ HDDНичего космического.
Но здесь было важное отличие от виртуалки: сервер полностью наш.
Нет соседней виртуальной машины, которая внезапно решила активно писать на ту же дисковую подсистему. Нет неизвестной нам схемы распределения IOPS внутри облака.
Цена при этом отличалась от виртуального сервера не настолько сильно, чтобы продолжать мириться с периодическими тормозами.
Как разложили данные
Получилась примерно такая схема:
Bitrix24
│
┌─────────┴─────────┐
│ │
2 × 512 GB SSD 2 × 4 TB HDD
│ │
RAID 1 RAID 1
│ │
ОС + Bitrix файлы Bitrix
+ база /uploadSSD оставили под систему, Битрикс и базу данных.
Два HDD по 4 ТБ объединили в RAID 1 и использовали для пользовательских файлов.
Почему RAID 1?
Потому что объём файлов на тот момент составлял около 400 ГБ и эффективных 4 ТБ нам хватало с большим запасом.
При этом отказ одного HDD не означал немедленную потерю файлов.
Но здесь важный момент:
RAID — не backup.
Он спасает от отказа одного диска. Он не спасает от:
- случайного удаления файла;
- повреждения данных;
- ошибки администратора;
- шифровальщика;
- повреждения файловой системы;
- физической потери всего сервера.
Поэтому резервное копирование всё равно понадобилось.
Мини-гайд: RAID 1 под файлы
Если RAID собирается средствами Linux через mdadm, сначала полезно посмотреть, как система видит диски:
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTДопустим, два диска под файлы определились как:
/dev/sdb
/dev/sdcПроверяем ещё раз, что на них нет нужных данных.
После этого RAID 1 можно собрать примерно так:
sudo mdadm --create /dev/md0 \
--level=1 \
--raid-devices=2 \
/dev/sdb /dev/sdcСостояние синхронизации:
cat /proc/mdstatБолее подробная информация:
sudo mdadm --detail /dev/md0После создания массива его можно отформатировать, например в XFS:
sudo mkfs.xfs /dev/md0Создать точку монтирования:
sudo mkdir -p /data/bitrix-uploadи смонтировать:
sudo mount /dev/md0 /data/bitrix-uploadДля постоянного монтирования лучше использовать UUID:
sudo blkid /dev/md0и добавить его в:
/etc/fstabНапример:
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data/bitrix-upload xfs defaults 0 0Конкретные имена дисков, файловая система и точки монтирования, конечно, зависят от сервера.
Операционная система и окружение
На сервер установили Oracle Linux и стандартное Bitrix Environment.
Само окружение разворачивалось по штатному руководству Битрикс24.
Идея была как раз в том, чтобы здесь не изобретать ничего лишнего.
Если производитель даёт готовое окружение под свою систему, для обычной установки проще сначала использовать его и только потом менять то, для чего действительно есть причина.
После установки обязательно проверить хотя бы базовые вещи:
df -h
free -h
lsblkи состояние сервисов:
systemctl --failedОтдельно стоит проверить, что база и web-сервисы действительно находятся на SSD, а не случайно попали на HDD.
Перенос файлов Bitrix на отдельный массив
От S3 решили отказаться и вернуть пользовательские файлы на локальное хранилище.
В Битриксе основная масса загружаемых файлов находится в каталоге upload.
Идея простая:
старый upload
│
▼
/data/bitrix-upload
│
▼
симлинк из каталога сайтаПеред такими операциями Битрикс желательно вывести из активной работы, чтобы пользователи не продолжали загружать файлы во время переноса.
Копирование можно сделать через rsync.
Условный пример:
rsync -aHAX --info=progress2 \
/home/bitrix/www/upload/ \
/data/bitrix-upload/После копирования проверить объём:
du -sh /home/bitrix/www/upload
du -sh /data/bitrix-uploadПосле этого старый каталог лучше не удалять сразу, а переименовать:
mv /home/bitrix/www/upload \
/home/bitrix/www/upload.oldи создать симлинк:
ln -s /data/bitrix-upload \
/home/bitrix/www/uploadПроверяем:
ls -ld /home/bitrix/www/uploadПосле запуска Битрикса обязательно проверить:
- загрузку нового файла;
- открытие существующего файла;
- картинки;
- документы;
- права доступа;
- генерацию превью.
И только когда точно понятно, что всё работает, старую копию можно удалить.
Права на файлы
После переноса нельзя забывать о владельце файлов.
Проверить:
ls -la /home/bitrix/www/
ls -la /data/bitrix-upload/Владельца нужно выставить таким же, какой используется существующим Bitrix Environment.
Здесь специально не привожу универсальный chown, потому что пользователь и группа могут отличаться в зависимости от конкретной установки.
Лучше сначала посмотреть владельцев исходных файлов и только после этого повторить их на новом хранилище.
Что делать с бэкапами
Переезд на физический сервер добавил очевидный вопрос:
А что будет, если этот сервер завтра просто умрёт?
У выделенного сервера есть минус по сравнению с виртуалкой — нельзя нажать пару кнопок и за минуту увеличить CPU, RAM или перенести виртуальную машину на другой узел.
Физическое железо тоже может выйти из строя.
Поэтому файлы и резервные копии должны находиться не только на самом сервере.
Хотя, если честно, для виртуальной машины правило ровно то же самое.
В итоге резервные копии Битрикса стали храниться в нескольких местах:
Bitrix
│
├── локальная резервная копия
│
├── облако Bitrix24
│
└── собственное внешнее хранилищеСамая тяжёлая часть — пользовательские файлы
База данных и конфигурация занимают относительно немного места.
Главный объём — upload.
У нас это было около:
400 ГБКаждый раз копировать все 400 ГБ заново смысла нет.
Поэтому для файлов используется rsync.
Раз в три дня содержимое файлового хранилища синхронизируется с отдельным сервером хранения.
Принцип работы rsync здесь как раз удобный: после первой полной передачи дальше передаются в основном изменения.
Упрощённо:
Bitrix server
/data/bitrix-upload
│
│ rsync
▼
Backup server
/backup/bitrix/uploadМини-гайд: копирование файлов через rsync
Например, через SSH это может выглядеть так:
rsync -aHAX --info=progress2 \
/data/bitrix-upload/ \
backup@backup-server:/backup/bitrix/upload/Для автоматической работы обычно используется SSH-ключ.
Создать отдельный ключ:
ssh-keygen -t ed25519Скопировать публичную часть на backup-сервер:
ssh-copy-id backup@backup-serverПосле этого проверить:
ssh backup@backup-serverЕсли авторизация работает без пароля, можно автоматизировать rsync.
Например, через cron:
crontab -eи запускать раз в три дня.
Саму команду удобнее вынести в отдельный скрипт, чтобы писать лог и отслеживать код возврата.
Пример:
#!/bin/bash
SOURCE="/data/bitrix-upload/"
DEST="backup@backup-server:/backup/bitrix/upload/"
LOG="/var/log/bitrix-upload-backup.log"
rsync -aHAX \
--stats \
"$SOURCE" "$DEST" >> "$LOG" 2>&1
EXIT_CODE=$?
echo "$(date '+%F %T') exit=$EXIT_CODE" >> "$LOG"
exit $EXIT_CODEПосле этого уже cron запускает сам скрипт.
Осторожнее с --delete
У rsync есть очень удобный параметр:
--deleteОн удаляет на backup-сервере файлы, которых больше нет в источнике.
Это удобно для зеркала.
И одновременно опасно.
Если пользователь случайно удалил каталог на основном сервере, следующая синхронизация может аккуратно удалить его и из зеркала.
Поэтому обычное зеркало через rsync не заменяет версионный backup.
В нашем случае это нужно учитывать отдельно при построении общей схемы резервного копирования.
Проверяем RAID
Сам RAID тоже желательно периодически контролировать.
Самая простая проверка:
cat /proc/mdstatНормальное состояние массива RAID 1 выглядит примерно так:
[UU]Если вместо двух U одна позиция отсутствует — один из дисков выпал из массива.
Подробно:
mdadm --detail /dev/md0А состояние самих HDD полезно смотреть через SMART:
sudo smartctl -a /dev/sdb
sudo smartctl -a /dev/sdcДля физического сервера это уже не факультативная информация.
Если диск начинает умирать, лучше узнать об этом до того, как пользователь сообщит:
Битрикс что-то сегодня странно работает.
Что получилось
В итоге схема стала выглядеть достаточно просто:
INTERNET
│
▼
┌──────────────┐
│ Bitrix24 │
│ Oracle Linux │
└───────┬──────┘
│
┌─────────────┴─────────────┐
│ │
▼ ▼
2 × SSD RAID1 2 × HDD RAID1
│ │
▼ ▼
ОС + Bitrix + DB /upload
│
│ rsync
▼
Backup server
+ локальный backup Bitrix
+ облачный backup Bitrix24Никакой особой магии.
После переезда общая отзывчивость системы стала заметно лучше, а те самые периодические дикие тормоза, из-за которых всё и начиналось, ушли.
Точных цифр «до» и «после» у нас не сохранилось, поэтому придумывать проценты ускорения не будем.
На тот момент задача была проще:
Битрикс тормозит
↓
ищем причину
↓
находим дисковую подсистему
↓
меняем инфраструктуру
↓
тормоза уходятПлюсом мы получили понятную схему хранения файлов и резервного копирования, которую уже полностью контролировали сами.
Конечно, выделенный сервер не является универсальным лекарством от проблем Битрикса.
Если приложение упирается в PHP, плохие запросы к базе, кривой модуль или отсутствие кеширования, покупка более быстрого железа просто отодвинет проблему.
Но в нашем случае узким местом оказалось именно хранилище.
И иногда вместо очередной попытки добавить виртуальной машине ещё несколько ядер действительно полезнее посмотреть, чего именно она всё это время ждёт.