Очень сильно тормозит 1с, по тесту Гилева на мощном сервере, как исправить?

Question

[sanzhinvo]

конфиг

CPU: xeon gold 6354 x2
cpus:72
RAM:512
Raid10:SSD 4TB x4
Raid10:HDD 6TB x4
hypervisor: PROXMOX
VM:
agent: 1
balloon: 0
bios: ovmf
boot: order=scsi0;ide2;net0
cores: 18
cpu: host
cpuunits: 1000
efidisk0: SSD_DATASTORE:vm-100-disk-0,efitype=4m,pre-enrolled-keys=1,size=4M
ide2: none,media=cdrom
machine: q35
memory: 260096
meta: creation-qemu=9.0.2,ctime=1744397102
net0: virtio=BC:24:11:75:A2:D3,bridge=vmbr0,firewall=1
numa: 1
ostype: l26
scsi0: SSD_DATASTORE:vm-100-disk-1,aio=io_uring,cache=writeback,discard=on,iothread=1
scsihw: virtio-scsi-single
smbios1: uuid=34c96bea-3536-4e67-bfd8-026315bb9726
sockets: 1
vga: std
vmgenid: 4ece6cf7-a0a0-4a2c-bafd-395b13955d73

Postgresql.conf

# Основные настройки подключения
listen_addresses = '*'                  # слушаем все адреса
port = 5432
max_connections = 100

# Память
shared_buffers = 64GB                   # 25–40% от RAM (в твоем случае 256ГБ)
work_mem = 512MB                        # для сортировок/хэшей
maintenance_work_mem = 4GB             # для VACUUM, CREATE INDEX и пр.
effective_cache_size = 192GB           # 70–80% от RAM

# Параллелизм
max_worker_processes = 18
max_parallel_workers = 18
max_parallel_workers_per_gather = 4
max_parallel_maintenance_workers = 4
effective_io_concurrency = 200

# Журнал WAL
wal_buffers = 64MB
commit_delay = 1000
checkpoint_timeout = 5min
checkpoint_completion_target = 0.9
max_wal_size = 4GB
min_wal_size = 2GB

# Кеш страниц
random_page_cost = 1.1
seq_page_cost = 1.0

# JIT отключён (1С не выигрывает от него)
jit = off

# Планировщик
plan_cache_mode = force_custom_plan

# Автоматическое обслуживание
autovacuum = on
autovacuum_max_workers = 9
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005
autovacuum_vacuum_cost_limit = 900

# Статистика и логирование
logging_collector = on
log_directory = 'log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_line_prefix = '%m [%p] '
log_timezone = 'Etc/UTC'

# Плантюнер и Online Analyze (Postgres Pro)
shared_preload_libraries = 'plantuner,online_analyze'
plantuner.fix_empty_table = on
online_analyze.enable = on
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary'

# Язык и локаль
datestyle = 'iso, dmy'
timezone = 'Etc/UTC'
client_encoding = UTF8
lc_messages = 'ru_RU.UTF-8'
lc_monetary = 'ru_RU.UTF-8'
lc_numeric = 'ru_RU.UTF-8'
lc_time = 'ru_RU.UTF-8'

# Конфигурация расширений
default_text_search_config = 'pg_catalog.russian'

брал с chatgpt,
тест гилева в файловой базе 113ед
тест гилева на базе развернутой на постгресе 6,43 единицы....

Comments

[Антон Антон]

Достать один процессор (можно не физически, а в биосе или иным способом, ну или как-то прибить rphost на один процессор а postgres на другой)
(и зачем в данной конфигурации виртуализация? планируется потом что-то ещё крутить?)

[Павел]

а сколько ядер выделено на саму VM? По рекомендациям proxmox нужно начинать с малого и добавлять по необходимости, если сразу 72 выделить могут быть проблемы

[sanzhinvo]

Павел, 1 сокет 18,
пробовал выдать 1 сокет 9 ядер и 2 сокета 36 ядер
в случае 36ядер сцал что виртуальные туда уйдут поэтому уменьшил, в любом случае вообще не менялся гилев на пострессе, все те же 6,43

[sanzhinvo]

Антон Антон, а можно немножко точнее, я буду все подряд тестить, все варианты

[Антон Антон]

sanzhinvo, NUMA бессердечная сука, может убить производительность на корню. + если есть недогруз по ядрам, то иногда лучше убрать HT, чтобы на ядро было больше кэша, но тут в реальной работе пользюков надо тестить.

[sanzhinvo]

Антон Антон, пожалуйста, друг, больше деталей, уже 3 сутки без сна. я с 1с в жизни не связывался, а таск стоит

[Антон Антон]

sanzhinvo, ну и ещё - синтетические тесты не показывают реальной картины, особенно писькомер Гилева - очень упирается в скорость одного ядра и задержку между БД и сервером 1с (ну т.е. для бОльшего количества очков они должны быть на одной машине).

[Антон Антон]

надо тестить на реальной работе пользователей

[sanzhinvo]

в том то и дело, грузанул боевую, страшно тормозит особенно при проведении документов.
в данный момент 1с и бд на 1 вм расположены.
самое интересное, я как и говорил выше, меня конфиг файл потсгрески, вообще нет изменений, как это работает?

[Alexey Dmitriev]

как уже сказали выше, нужно смотреть в сторону numa нод. ВМ на двух numa нодах может работать медленнее, чем менее мощная, но на одной.

[sanzhinvo]

Alexey Dmitriev, спасибо тоже буду тестить, но все еще открыт для разных вариантов, а вообще в целом, как много в моем случае возможных причин, и если не сложно можно подробнее про numa и как это решить

[Дмитрий]

Можно попробовать режим энергопотребления в настройках материнской платы выставить в Max Performance, и в самом Proxmox автозагрузку добавить команду (через systemd/crond/rc.local по вкусу)

/usr/bin/cpupower frequency-set --governor performance

Производительность может подрасти очень хорошо.

[Rsa97]

Антон Антон,

очень упирается в скорость одного ядра и задержку между БД и сервером 1с

ЕМНИП, сервер 1С не умеет в многопоточность, посему всегда занимает только одно ядро. А ещё он любит блокировки, особенно на проведении, так что и база данных работает практически в однин поток. Так что всё упирается именно в скорость одного ядра и задержки обмена с базой данных (лучше всего на одном компе с обменом через shared memory или unix socket.

[Антон Антон]

Rsa97,

сервер 1С не умеет в многопоточность, посему всегда занимает только одно ядро

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

А ещё он любит блокировки, особенно на проведении, так что и база данных работает практически в однин поток.

не совсем так. зависит от криворукости авторов конфигурации. в принципе, типовые докрутили до вменяемого состояния.

[Rsa97]

Антон Антон, May be. Но ни разу не видел, чтобы наша типовая KA2 ела больше одного ядра, хотя работает до сотни человек.

[Alexey Dmitriev]

sanzhinvo, подробнее в гугле.
А перед этим неплохо бы прочитать еще раз п.5.12 https://qna.habr.com/help/rules

[DeathRAMCC]

Мой тебе совет.
Скачай с https://1c.postgres.ru/ свежую сборку и поставь ее не трогай файл конфигурации.
18 ядер за глаза.
Так же напоминаю что там не только ядра там ещё гипервизор и у тебя всего 36 ядер на два процессора.
Hyper-threading я бы сразу выключил. Равно как и все возможные и невозможные зелёные опции и все бы выставил в Макс производительность.
Судя по тесту - диски хорошие, а вот тюнинг через чатгпт говно. При установке дистриб с 1С - сам настроит автотюном. Сохрани конфиг.
Да и операционка какая?

[sanzhinvo]

Всем большое спасибо, сейчас буду тестить буквально по списку, по логике я думал то что в конфиге сервера не может быть проблем так как файловая база то выдает 113 гилева(хоть какой то показатель), а именно постгрес плохо работает, поэтому был почти уверен что проблема именно в бд

[sanzhinvo]

DeathRAMCC, ubuntu

[d'Ivan]

sanzhinvo, покажи снимок экрана от утилиты atop в момент нагрузки.

[Ivperivm]

Попробуйте отключить параллелизм и online analyze. Последние явно вызывается платформой 1С

[aleks-th]

sanzhinvo,

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

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

Про процессоры забудь, в твоем случае должно до сотни юзеров хватить производительности с лишком...

После этих действий, проверяй производительность и высылай ящик пива.

[emka2k]

sanzhinvo, убей виртуализацию . Поставь на железо. Север 1с и бд на железо . Ты сам у себя крадешь производительность.

И ms SQL developer edition позволит тебе

[emka2k]

sanzhinvo, в жизни не связывался - когда в пример был приведен результат с файловой базы - так и понял

[emka2k]

sanzhinvo, тут ты и теряешь производительность. Зачем ты дропишь на VM ?

Answer 1

[oller]

1 почитайте что Гилев вообще о посгре пишет
2 6354 это не фига не мощный проц, это медленное унылое говно, предназначенное для не менее унылых vps
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeo...
Да многопоточность, но в один поток вы сравнимы с 2667v4 10 летней давности

3 проксмокс для виртуализации винды крайне хреновое решение
4 ssd это уже прошлый век, тем более для 1с, nvme онли
5 io uring, writeback, даже коментить не хочется...

Comments

[mogaec]

Да многопоточность, но в один поток вы сравнимы с 2667v4 10 летней давности а лучше и не скажешь. В топку такой проц. Если базовая частота меньше 3.7, то я сочувствую программистам. Хотя если оплата почасовая, то вы их не хило приподнимаете.

[Ivperivm]

mogaec, у нас 3 тыс пользователей живут на четырёх 6230 и ни у кого нет тормозов. Два ядра по 2.2 быстрее одного 3.7

[emka2k]

Ivperivm, нет. 1с нужна производительность на ядро . Лучше голд с 8 ядрами , чем Сильвер с 16.

Далее вопрос про виртуализацию - кто бы чего не говорил , 1с на виртуализации - это плохо. Далее , база данных на этой же машине ? Всё патчи стоят ?
Ради интереса поставь на эту же машину ms SQL и настрой её. Сравни цифры

[mogaec]

Ivperivm,
Процессов 1С сколько? Пользователи как к базам 1С подключены? Для 1С не важно количество пользователей. Гораздо больше имеет значение в каком режиме используется база. Если в час в базе сотни документов создаются и проводятся, или в базе есть очень тяжелые документы с расчетом себестоимости продукции. И рассчитывают эту себестоимость по несколько раз в день (попадаются и такие клиенты). То одно ядро гораздо шустрее двух более медленных. Если же у вас больше аналитическая работа основанная на анализе отчетов, то тогда возможно лучше два ядра. Но я не верю что какой-либо сервер потянет 3000 процессов 1С. Максимум пока 600-650 удавалось запустить для более менее комфортной работы в очень боевых базах на одном сервере. На сервере несколько виртуалок для работы пользователей по РДП, и пара виртуалок сервер 1С + СКЛ сервер. Если несложно, распишите как у вас структура баз и серверов 1С реализована.

[Ivperivm]

emka2k, работает на виртуалках proxmox, база на PostgreSQL. Раньше стоял mssql, в оперативных операциях разница 5-7%

[Ivperivm]

mogaec, 4 виртуальных машины на debian. Настройка 1 база на процесс, 80 сеансов на процесс. Регламентные задания на отдельном сервере. Остальное стандартно

[emka2k]

Ivperivm, версия сервера какая ?

[emka2k]

mogaec, 1 процесс = 1 пользователь ?
Бред какой то

[Ivperivm]

emka2k, у вас каша между понятиям сеанс, пользователь, соединение, процесс

[Ivperivm]

emka2k, 8.3.25.1286

[emka2k]

Ivperivm, не это. Проф или корп ?

[emka2k]

Ivperivm, выше написал 3000 процессов . До этого человек писал о 3000 пользователях . Исходя из этого , 3000 пользователей = 3000 процессов

[Ivperivm]

emka2k, корп, проф максимум 12 ядер умеет

[Sladky]

А никого не смутило, что на 2-сокетном хосте у товариша ВМ с огромной оперативой, явно с 2 нод, но у ВМ 1 нода в конфиге?
Это же прям рецепт тормозов.
Далее, в биосе хоста какой план питания? Паверсейф или Перфоманс?
Надо перфоманс с ориентиром либо на частоту проца, либо на управление от ОС.

[sanzhinvo]

народ, такой странный вопрос, какой в целом билд 1с (версия) + постгрес (версия) по вашему мнению и опыту самые стабильные/производительные

[hint000]

sanzhinvo,

какой в целом билд 1с (версия) + постгрес (версия) по вашему мнению и опыту самые стабильные/производительные

Странный вопрос. Бухгалтерия требует обновления несколько раз в год. Устарела версия конфигурации - разошлась с требованиями регламента, бухгалтера имеют проблемы при сдаче отчётов. Обновления конфигурации тянут за собой необходимость обновлять платформу (хоть и реже), на старую платформу новые конфигурации не налазят. Вы можете некоторое время (один-два месяца?) оттягивать обновление, и даже захотите его оттягивать, чтобы успели исправить самые злые глюки и выпустить следующую минорную версию. Но слишком долго оттягивать не позволят бухгалтера - им нужна свежая версия.

Хотя да, на чисто "управленческих" базах, (тех, которые не являются "регламентными", чьи данные не выходят из стен компании) можно использовать и очень старые версии.

[emka2k]

sanzhinvo, отдай эту ситуацию другому человеку

Answer 2

[Renbow]

1с не любит виртуалки от 15-30% производительности теряется это я находил в официальных документах 1с. Может конечно что то и изменилось. Тест гилева сколько им пользовался пришел к выводу он рассчитывает балы относительно локальной машины и скорости передачи данных. Могу конечно ошибаться. У меня сервер райзен 5, 64Гб ОЗУ nvme m2 samsung под постгрес, для Кеша 1с hdd, 1ssd под систему ubuntu server 21 бухгалтерия работает нормально 10 пользователей

Comments

[emka2k]

на таком и 40 пользователей будут нормально работать

Answer 3

[Dimandorf]

Попробуйте отключить nested loop соединение
В некоторых конфигурациях 1с это очень сильно повышает производительность. В некоторых наоборот убивает в 0

Answer 4

[AndreyRz]

А подскажи какой рейд используешь и его настройки и что выдают тесты скорости диска из виртуалки

Comments

[sanzhinvo]

raid 10, если имеете ввиду контроллер, то позже могу скинуть, в кристале чето около 9000+

Answer 5

[user0k]

Я недавно мучал 1С на 2х процессорном железе.
Пришел к выводу, что 1С упирается в производительность дисков (рейда).
Стоял рейд контроллер 6Гб/с. Я поменял на 12Гб/с. Рейд собрал 5й. Диски SAS 12Gb/s 10k.
Фото не могу скинуть, не делал. Но по тестам скорость чтения вышла в районе 3500-3700. Запись чуть меньше, - 2100.
1С начала работать более менее.
Но и этого бухам мало было. Проводиться документы стали намного быстрее, с 30мин до 2х.
Затем для теста я поставил обычный писюк на базе i7 12 поколения, 128гб озу (мать msi pro какая то) и ssd m2 самсунг. Без рейдов, но с бэкапами. И эта сборка по производительности превосходит серверное 2х процессорное железо.
Так что думайте сами.

Comments

[emka2k]

5 по эйд под базы - очень плохо. 5 рэйд забирает на своё обслуживание ресурсы . И вопрос не в чтение / записи , а в iops'асх

[Crazy_Cooler]

Есть разные конфиги под 1С,но по факту понял одно, ни какой виртуализации для 1с сервера, или обязательно база и 1С сервер на 1м сервере (лучше физическом). Лучше всего летает на i7 14700k 20 ядер 4,8-5,2GHz /128ram (больше десктопная мать не ест)/nvme диски для ОС, и темп (srvinfo) + ОС темп +1С темп. tempdb от mssql только в RAM. Базу на sas ssd R1. Горячий бэкап sas hdd. На postgre есть тестовые базы но скорость не мерял.

[sultanenok]

Получается так:
Для пользователя чтобы открывались формы быстро, надо суперскоростной диск c для кэша.
Для операций на сервере надо чтобы хватало проца для вычислений и диска для записи/чтения, но диск уже может быть более простым.
Если есть возможность, надо службу 1с и скуль выводить на железо, а терминал с пользователями в виртуалку.
Т. К. У каждой операции ввода-вывода есть время выполнения и время задержки, то сначала проходят все тайминги в виртуальной ос, затем передаются на запись на хост, где опять все эти тайминги проходят, поэтому долго.

[user0k]

Вчера проводил разделение сервера 1С и базы данных mssql. Базу перенес на другую машину, тоже Core I7 14gen ssd m2. Но сделал хитрее: в ядре сети стоит 10гб/с элтекс. Так вот сервер 1С и база mssql соединены оптическим шнуром на 10гб/с.
Количество одновременных сеансов 1С - за 100. Почти все клиенты пользуются тонким клиентом.
От виртуальных машин ушел давно, производительность низкая.
Сейчас mssql съедает из 128гб озу 110.
rphost на сервере жрет тоже много памяти. В настройках электропитания стоит режим максимального быстродействия. Проц работает на максимальных частотах.
Пока полет нормальный.
Бэкапы делаются скриптом самописным и выгружаются на сетевой NAS.
Гилев показывает результаты в райне 65. Что это я так и не понял.

Answer 6

[Tur8008]

Да она сама по себе тормозит и 1с этот факт похоже совсем не беспокоит. Чудовищно тормознутый отклик, отсутствие асинхронности на клиенте это в большинстве типовых решений вендора просто дефолт. На виртуалках это усугбляется значительно, особенно если не выделять физические диски.