При развертывании высоконагруженных систем 1С на базе Linux и PostgreSQL перед администратором неизбежно встает вопрос выбора файловой системы и среды эксплуатации. В данной статье мы разберем практический кейс сравнения производительности систем под управлением Debian в виртуальной среде VMware и на «голом железе» (Bare Metal), проанализируем поведение файловых систем EXT4 и XFS, а также выясним, почему тесты в виртуальной машине могут показывать обманчиво высокие результаты.
Рассмотрим ситуацию, когда тесты (массовое проведение документов, выгрузка dt) под VMware показывают лучшие результаты, чем на физическом сервере. Разберем основные причины этого явления, которые часто вводят в заблуждение:
PVSCSI позволяет более эффективно обрабатывать очереди команд по сравнению со стандартными драйверами физических контроллеров.fsync (команда СУБД на обязательный сброс данных из кэша на диск) может имитироваться. PostgreSQL «думает», что данные в безопасности, хотя они все еще в энергозависимой памяти. Это дает колоссальный прирост в тестах, но чревато потерей базы при сбое питания.Выясним, почему результаты тестов неоднозначны: XFS лидирует в закрытии месяца, а EXT4 — в массовом перепроведении документов. Проанализируем архитектурные особенности этих систем.
Файловая система EXT4:
Традиционный выбор для Linux. Она демонстрирует отличные показатели при работе с метаданными. Поскольку 1С при активном перепроведении документов создает и удаляет огромное количество временных файлов, EXT4 за счет более простой структуры работы с инодами (inodes) справляется с этим быстрее. Это объясняет ее лидерство в тестах на перепроведение.
Файловая система XFS:
Эта система изначально проектировалась для работы с большими файлами и параллельного ввода-вывода. В XFS реализована концепция Allocation Groups (группы распределения), что позволяет PostgreSQL писать в разные части файла данных одновременно, используя разные ядра процессора без блокировок. Именно поэтому на тяжелых операциях, таких как «Закрытие месяца», где идет массированная работа с таблицами базы данных, XFS вырывается вперед.
Для оптимизации работы обеих систем при монтировании обязательно используйте параметры noatime и nodiratime, чтобы исключить лишние операции записи при каждом чтении файла:
# Пример в /etc/fstab
UUID=xxxx-xxxx /var/lib/postgresql xfs defaults,noatime,nodiratime,logbufs=8 0 2
Если в системе используются быстрые диски NVMe, выбор файловой системы — лишь половина дела. Проанализируем настройки планировщика ввода-вывода. Для современных SSD старые планировщики типа cfq или deadline создают искусственное «бутылочное горлышко».
Рекомендуем установить планировщик none (для NVMe) или mq-deadline. Это позволит операционной системе передавать запросы напрямую контроллеру диска, который сам эффективно управляет очередями. Проверить текущий планировщик можно командой:
cat /sys/block/nvme0n1/queue/scheduler
# Изменение на лету:
echo none > /sys/block/nvme0n1/queue/scheduler
Также крайне важно проверить выравнивание разделов (alignment). Если раздел начинается не с границы ячейки памяти SSD, каждая операция записи превращается в две, что снижает производительность вдвое и сокращает ресурс диска.
Чтобы потенциал выбранной ФС раскрылся полностью, необходимо настроить операционную систему. Рассмотрим ключевые параметры для сервера с большим объемом RAM (как в нашем примере 198 ГБ):
Huge Pages: Использование «огромных страниц» памяти позволяет сократить накладные расходы процессора на управление адресным пространством PostgreSQL. При объеме базы 30 ГБ и RAM 198 ГБ, настройка Huge Pages может дать ощутимый прирост стабильности времени отклика (latency).
Параметр vm.swappiness: По умолчанию Linux агрессивно сбрасывает данные в swap. Для сервера БД это недопустимо. Рекомендуем установить значение 1 или 10, чтобы система использовала swap только в самом крайнем случае.
# Настройка в /etc/sysctl.conf
vm.swappiness = 1
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
Подведем итог нашему исследованию. Выбор между EXT4 и XFS не является критическим фактором, если база невелика, однако для долгосрочной перспективы и больших объемов данных XFS выглядит предпочтительнее из-за масштабируемости.
Основные советы по итогам разбора:
EXT4.XFS.fsync=on в настройках PostgreSQL.Btrfs и ZFS для баз данных 1С, если не являетесь экспертом в их настройке, так как механизм Copy-on-Write (CoW) приведет к катастрофической фрагментации файлов БД.Помните, что стабильность 1С зависит не только от файловой системы, но и от слаженной настройки всей цепочки: «Железо — Гипервизор — ОС — СУБД — Платформа 1С».