Два параметра PostgreSQL утонули в разбросе теста 1С

Пять раз подряд мы прогнали один и тот же тест 1С. Сервер тот же, база та же, настройки никто не трогал. Результат - от 16,39 до 26,04 балла. Лучший результат в 1,6 раза выше худшего.

Затевалось всё ради другого. Мы искали, что крутить в PostgreSQL, когда 1С тормозит, и хотели проверить на цифрах два совета: побольше shared_buffers и выключенный synchronous_commit. Но при таком разбросе любая настройка легко “помогает” или “мешает” случайно.

Отсюда первый шаг, который стоит сделать до любой настройки: прогнать свой замер несколько раз подряд, ничего не меняя, и записать разброс. У нас пять прогонов заняли около часа.

Где и чем мерили

Мерили не на боевом сервере и не у клиента, а на тестовом. Debian 13, четыре ядра, 41 ГБ памяти, сервер 1С 8.3.27 и PostgreSQL 18.4-1.1C на одной виртуальной машине. Клиент 1С - на соседнем сервере Windows.

Рядом живут десять копий рабочих баз 1С со своими регламентными заданиями. Задания работали и днём, и ночью.

Инструмент - однопоточный тест Гилева на синтетической базе около 80 МБ. Медленные отчёты, планы запросов и индексы не трогали. Вопрос стоял узко: видит ли тест разницу между двумя значениями параметра.

Пять прогонов без изменений

Медиана - 20,08. Самые короткие прогоны дали лучшие баллы.

Куда уходило время? В прогонах с третьего по пятый vmstat показывал простой процессора в среднем 5,7 %. Однопоточный тест столько не съест.

После серии, уже без теста, rphost сервера 1С то брал от 90 до 368 % ЦП из 400 % на четырёх ядрах, то почти отпускал. В выводе rac session list по очереди мелькали сеансы BackgroundJob семи баз из десяти.

Картина согласуется с тем, что процессор у теста забирали регламентные задания соседних баз. Доказательства нет: задания мы не останавливали.

Сравнивать два числа без разброса рядом я не берусь. А в первой же серии лучший и худший прогоны разошлись почти на десять баллов.

Как меняли shared_buffers

Дальше меняли по одному параметру и чередовали режимы: A, B, A, B, по четыре прогона на режим. Пока шёл прогон, примерно раз в пять секунд писали фон: сеансы кластера 1С через rac session list и загрузку ЦП через vmstat.

Значение shared_buffers меняется только при старте сервера. Поэтому PostgreSQL перезапускали перед каждым прогоном в обоих режимах и писали значение в лог. Режим A - 6 ГБ, как в нашем postgresql.conf. Режим B - 128 МБ, типичное значение по умолчанию:

alter system set shared_buffers = '128MB';   -- прогон B
alter system reset shared_buffers;           -- прогон A: снова 6GB из postgresql.conf

Смена на 128 МБ и обратно: команда, перезапуск, проверка. Кадр снят отдельно от серии.

Перезапуск рвёт подключения всех баз кластера. Однажды он прервал копию соседней базы по расписанию - разбор в статье “Копия базы 1С оборвалась, а gzip -t и psql вернули 0”.

synchronous_commit - только для одной базы

synchronous_commit меняли только для базы теста, остальные базы не задеты. Режим A - off, как в нашем postgresql.conf. Режим B - on, значение PostgreSQL по умолчанию:

alter database <база теста> set synchronous_commit = on;   -- прогон B
alter database <база теста> reset synchronous_commit;      -- прогон A: как в кластере, off
select pg_terminate_backend(pid) from pg_stat_activity where datname = '<база теста>';

Настройка базы действует на новые сеансы, а сервер 1С держит подключения открытыми. Поэтому перед каждым прогоном их закрывали через pg_terminate_backend.

Следующий запуск клиента падал через три секунды: “Соединение с сервером баз данных разорвано администратором”. Похоже, сервер 1С выдаёт подключение из запаса без проверки. Внутрь мы не смотрели, скрипт серии просто запускал клиент снова.

Получили ли сеансы теста on, проверили только косвенно: все пять подключений базы открыты после смены настройки. Значение внутри сеанса не смотрели. Не смотрели и роль подключения, а её собственный synchronous_commit перекрыл бы настройку базы.

Что вышло днём

У shared_buffers разница средних - 1,06 балла, а прогоны одного режима расходились на 2,3-2,7 балла. Среднее с 128 МБ выше, но в первой паре впереди 6 ГБ. Итог узкий: на базе около 80 МБ в этом тесте разницы не видно.

Один прогон с 128 МБ завис: клиент за 15 минут ничего не записал, причину мы не нашли. Прогон сделали заново через два с половиной часа, вне чередования. Если повторный прогон не считать, среднее для 128 МБ - 24,75.

Счётчики pg_stat_database разницу всё-таки показали. За прогон с 128 МБ PostgreSQL не нашёл в своём буфере около 37 тысяч блоков, с 6 ГБ - около 9,5 тысячи. Это меньше 0,1 % обращений: остальные 40-42 миллиона блоков нашлись в буфере.

Счётчик blks_hit не учитывает попадания в кэш ОС, а под этот кэш было занято 31 ГБ. Пришли недостающие блоки из кэша или с диска, по двум счётчикам я не различу. Да и числа - порядок величины: статистика отстаёт от реальной работы.

Блоков мимо буфера мало. На базе в гигабайты картина может быть другой, а такую мы не мерили.

Плюс 3 % с off, но внутри разброса

С synchronous_commit off тест в среднем на 3 % выше, по медиане - на 4,7 %. Разница средних - 0,69 балла при разбросе внутри режима 1,4-2,3 балла. Лучший прогон серии, 22,83, - с on. В двух парах из четырёх режимы разошлись не больше чем на 0,1 балла.

Тест однопоточный. Когда пишут много пользователей сразу, synchronous_commit может влиять сильнее, но этого опыт не показывает.

Цена synchronous_commit off известна: при сбое могут потеряться последние транзакции, о фиксации которых клиент уже получил ответ. Сама база останется согласованной. Совета выключать synchronous_commit я из этих цифр не делаю.

А ночью тот же тест выше на треть

Серию shared_buffers повторили ночью: тот же скрипт, перезапуск перед каждым прогоном, A, B, A, B.

Ночью тест дал 31-35 баллов, днём 22-26. Диапазоны не пересеклись. Между 6 ГБ и 128 МБ разница опять в пределах разброса.

Фон ночью ниже, но не нулевой. Сеансов BackgroundJob в среднем 0,7-1,1 против 1,4-2,2 днём, простой ЦП 39-47 % против 21-29 %.

Ночной прогон, запущенный вручную из окна теста: 34,01 балла при shared_buffers 6 ГБ.

Между днём и ночью средние разошлись примерно на 8 баллов, между режимами любого из двух параметров - не больше чем на 1,06 балла. Ночной прирост согласуется с тем, что фоновых сеансов BackgroundJob было меньше. Но регламентные задания мы не останавливали. День и ночь могли различаться и загрузкой гипервизора, клиентского Windows и сети, а эту загрузку мы не мерили.

Пар режимов A и B мало: по shared_buffers четыре днём и две ночью, по synchronous_commit четыре. Ночь была одна.

Как мерить у себя

1. Прогоните замер несколько раз без изменений и запишите разброс. Разница меньше разброса - не результат.

2. Меняйте один параметр и чередуйте режимы. Порядок полезно менять от серии к серии: мы этого не делали.

3. Делайте условия перед прогоном одинаковыми в обоих режимах. Требует параметр перезапуска - перезапускайте и в режиме “как было”.

4. Значение параметра - в лог рядом с результатом. У настройки уровня базы мы сравнили только время открытия подключений со временем её смены. Значение в самом сеансе и настройку роли не смотрели.

5. Рядом с каждым прогоном пишите фон: rac session list для сеансов 1С и vmstat для процессора.

6. До сравнения настроек посмотрите, что ещё работает на сервере. У нас день и ночь разошлись сильнее, чем режимы любого параметра.

Один вопрос эта серия так и не закрыла. Ночью сеансов регламентных заданий соседних баз было меньше, а тест дал на треть больше баллов. Днём мы эти задания ни разу не выключали. Что покажет тот же тест днём без них - ближе к ночным 31-35 баллам или к дневным 22-26?

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.