Почему сервер 1С + PostgreSQL на Linux под Hyper-V работает медленно и как это исправить?

Рассмотрим ситуацию, с которой часто сталкиваются системные администраторы при развертывании сервера 1С на базе Linux и PostgreSQL в виртуальной среде Hyper-V. Даже при выделении достаточного объема оперативной памяти производительность системы (например, по тесту Гилева) может оказаться катастрофически низкой. Проанализируем основные причины такого поведения и разберем по шагам, как оптимизировать систему для получения приемлемой скорости работы.

Влияние процессора и тактовой частоты на работу 1С

Разберем архитектурную особенность взаимодействия сервера 1С и СУБД. Платформа 1С крайне требовательна к тактовой частоте процессора (желательно от 3.0 ГГц и выше). Если используется низкочастотный процессор (например, 1.1 ГГц), производительность будет упираться в физические ограничения.

Взаимодействие 1С и PostgreSQL строится по принципу "пинг-понга": такт тратится на интерпретацию байт-кода и формирование запроса в 1С, затем запрос передается в SQL. PostgreSQL начинает выполнять запрос, а ядро 1С в это время простаивает. После возврата данных ситуация меняется. При этом PostgreSQL при работе с 1С не умеет распараллеливать выполнение одного тяжелого запроса на несколько ядер. Вся нагрузка ложится на одно ядро. Если система не настроена на максимальную производительность, ядра процессора постоянно сбрасывают и повышают частоту (состояния C-State). Пока ядро "разгоняется" с 0.5 ГГц до номинальной частоты, задача уже передается другому сервису. В итоге система работает на минимальных частотах.

Для исправления этой ситуации выполним следующие настройки:

1. Включим Turbo Boost в BIOS хост-сервера.
2. Настроим профиль электропитания. В Windows Server (на хосте) необходимо установить план электропитания "Высокая производительность" (High Performance).
3. Зафиксируем частоту в гостевой ОС. В Linux-системе изменим алгоритм управления частотой процессора (governor). Установим значение GOVERNOR="performance", чтобы предотвратить снижение частоты при кратковременных простоях.

Оптимизация виртуализации в Hyper-V

Проанализируем влияние гипервизора. Hyper-V может существенно снижать производительность гостевых Linux-систем, если виртуальная машина настроена неоптимально.

1. Поколение виртуальной машины. Если машина создана как "Поколение 1" (Gen 1), Hyper-V использует режим эмуляции устаревшего оборудования (например, IDE-контроллеров), что критически замедляет работу. Необходимо использовать только "Поколение 2" (Gen 2) с поддержкой шины VMBus и драйверов интеграции.
2. Фиксация оперативной памяти. В свойствах виртуальной машины необходимо строго отключить "Динамическую память". Динамическое изменение объема доступной памяти на лету конфликтует с механизмами кеширования PostgreSQL и платформой 1С.

Настройка ОС Linux для баз данных

Подготовим операционную систему Linux к интенсивной работе с данными:

1. Отключение Transparent Huge Pages (THP). Алгоритмы механизма прозрачных огромных страниц памяти вызывают сильную деградацию производительности PostgreSQL. Данный функционал рекомендуется отключить на уровне параметров ядра.
2. Настройка планировщика ввода-вывода (I/O Scheduler). Чтобы избежать двойного планирования очередности записи (на уровне гостевой ОС и на уровне хоста Hyper-V), переведем планировщик Linux в режим noop или none.
3. Управление памятью. Настроим параметр ядра vm.overcommit_memory. Это убережет PostgreSQL от принудительного завершения процессом OOM Killer в моменты пиковых нагрузок.

Тюнинг параметров PostgreSQL

Посмотрим на настройки самой СУБД. При использовании медленных SATA-дисков (например, 7200 оборотов) дисковая подсистема становится узким местом. Помимо расчета базовых параметров через утилиты (такие как pgtune), обратим внимание на следующие настройки:

1. При недостатке оперативной памяти (параметр work_mem) PostgreSQL начинает сбрасывать промежуточные данные сложных сортировок во временные файлы на жесткий диск, что вызывает колоссальные тормоза. Значение work_mem необходимо увеличить.
2. В некритичных базах для повышения скорости можно отключить параметры fsync и full_page_writes. Также снижение накладных расходов даст отключение online_analyze.

Использование RAM-диска (tmpfs) для временных файлов

Платформа 1С очень интенсивно использует временные таблицы. Перенос временных файлов в оперативную память (RAM-диск) способен дать многократный прирост скорости на слабых дисковых подсистемах.

Рекомендуется перенести на RAM-диск:

1. Каталог статистики PostgreSQL (параметр stats_temp_directory).
2. Временные табличные пространства СУБД (temp_tablespaces).
3. Сессионные данные сервера 1С (каталоги вида snccntx*).

Рассмотрим пример скрипта для автоматического создания RAM-дисков под каталоги сессионных данных сервера 1С (без претензий на идеальность, но работающий как простое решение для повышения производительности):

echo $action | /bin/grep -q start ] && {
[ -z $SRV1CV8_USER ] && SRV1CV8_USER=usr1cv8
SRV1CV8_GROUP=`id -gn $SRV1CV8_USER`
[ -z $SRV1CV8_GROUP ] && SRV1CV8_GROUP=grp1cv8

if [ -z $SRV1CV8_DATA ]; then
    datadir=`getent passwd $SRV1CV8_USER | /bin/sed 's/.\+:\(\/.\+\):.*/\1/g'`/.1cv8/1C/1cv8
else
    datadir=$SRV1CV8_DATA
fi

/usr/bin/install -o $SRV1CV8_USER -g $SRV1CV8_GROUP -d "${datadir}" > /dev/null 2>&1
echo ${datadir} > /tmp/SRV1CV8_DATA

/usr/bin/find "${datadir}" -type d -name "snccntx*" | while read x; do
    /usr/bin/install -o $SRV1CV8_USER -g $SRV1CV8_GROUP -d "$x"
    /bin/mount | /bin/grep -q "${x}" || /bin/mount -t tmpfs -o noatime,nodiratime,uid=$SRV1CV8_USER,gid=$SRV1CV8_GROUP tmpfs "${x}"
    /bin/mount > /tmp/SRV1CV8_DATA
done
} > /dev/null 2>&1

Применив описанные выше шаги (фиксацию высокой частоты процессора, настройку электропитания хоста и перенос временных файлов на RAM-диск), можно увеличить производительность даже на откровенно слабых серверах в несколько раз, обеспечив комфортную работу небольшого количества пользователей.