Тема избита... много прочитано... но, возможно, форумчане что-то посоветуют:

1. Железо (сервер 1С):
* Сервер: Supermicro
* CPU: х2 Xeon E5-2670
* ОЗУ: 128 Gb DDR3 800 GHz
* ОС - SSD;
* БД и логи SQL - RAID 10 (HDD);
Все отдано под сервер 1С (физика, без VM)

2. Софт (сервер 1С):
* WS 2016
* SQL Server 2017
* Сервер приложений 1С (8.3.12.1412) - порты стандартные

3. Текущие настройки кластера:
* все стандартно

4. Текущие настройки рабочего сервера:
* все стандартно

5. БД и пользователи:
* 15 активных пользователей;
* ~ 110 БД (пожалуйста, не нужно комментов: "зачем так много?", "удалите лишнее" и т.п. - все БД нужны, с каждой из них периодически работает 1~3 разработчика);
* подключение к серверу 1С через RDP (VM: 65 Gb ОЗУ; 12 ядер из 16)

6. Дополнения:
* с большинством БД идет работа через Хранилище конфигураций

Сама проблема:
* тест Гилева показывает 32 попугая;
* любые утилиты мониторинга показывают что сервер (память, CPU, дисковая подсистема) - не бывают загружены более чем на 35 ~ 55%
* при этом любая операция по захвату в Хранилище и/или помещение в Хранилище занимает от 3 до 10 минут;
* сравнение/объединение: от 10 до 25 минут;

Испробовано:
* файловое хранилище;
* сетевое хранилище;
* прописали в hosts ip сервера 1С;
* пробовали менять "Количество ИБ на процесс" / "Количество соединений на процесс" с 8 /128 в сторону уменьшения - стало еще хуже.

Есть обоснованные предложения - куда копать?

1) "Количество ИБ на процесс" / "Количество соединений на процесс" - не пробовали ставить 1/128?
2) любая операция по захвату в Хранилище и/или помещение в Хранилище занимает от 3 до 10 минут; - а при чем тут производительность? Скорее проблемы сети. Как доступ к храну организован? Оптимизацию храна пробовали делать?

(1)

именно 1 / 128 - не пробовал, максимум что ставили ставили 4 / 25 (возможно до конца не понимаю сути этих настроек: количество ИБ - понятно: сколько конфигураций могут "занять" 1 процесс... а по количеству соединений - не понимаю, как их просчитать/оценить?)

хранилище физически на сервере 1С - доступ либо к папке, либо через tcp (служба сетевого хранилища поднята и запущена). Сеть - гигабит, даже удаленщики работают через терминал (второй сервер, 4 гигабитных линка на связь с сервером 1С). Что подразумевается под оптимизацией хранилища?

(1) Почему 1/128, а не 1/8

(2) ИМХО
"Количество ИБ на процесс" - сколько баз будет обслуживать каждый процесс. Значение = 1, говорит что под каждую ИБ будет запущен отдельный рабочий процесс

"Количество соединений на процесс" - сколько соединений каждый рабочий процесс будет обслуживать. Соединение это не только соединения клиента, но и все регламентные/фоновые задачи. Т.е. 128 это значит что к одному рабочему процессу сможет подключиться 128 пользователей (или 1 пользователь который одновременно запустить 127 фоновых задач). Новое соединение будет запущено на новом, отдельном рабочем процессе


У меня бухи обычно любят запускать ресурсоемкие задачи (типа перепроводка за год, или карточка по 41 за 5 лет с полной дитализацией). В результате рабочий процесс жрет дикое количество памяти и начинает это все тормозит. Соответсвенно уменьшая Количество соединений на процесс, я заставляю сервер 1с раскидывать пользователей по кучи разных рабочих процессов, что увеличивает стабильность, так как снижает вероятность что какой то процесс умрет из-за большого потребления памяти и в крайнем случае позволяет принудительно завершить отдельный процесс, на котором сидит максимум 2-3 пользователя, при этом остальные пользователи не пострадают.


У тебя же тестовый сервер с ограниченными ресурсами, а значит тебе наоборот лучше увеличить значения, чтобы 1с не плодили процессы и не отжирала дополнительные ресурсы сервера

По идеи 8/128 должно хватить, чтобы не плодить больше 1 рпхоста

(0) какой то из счётчиков производительности системы обязательно покажет что не так в момент когда идёт операция с хранилищем. Очередь к диску смотрели?

Я правильно понял что скуль и сервер 1с на хосте, а все пользователи в гостевой ВМ на этом хосте? Не первый раз такое слышу. Мне интересно где и кем такая схема рекомендована?

(4) 110 бд, там вероятно "ошибки памяти" овер дофига т.к. конечно никакие кеши не влезут

(0) у вас серверу 1С оставлено 4 ядра и 63 Гб ОЗУ?

"Значение = 1, говорит что под каждую ИБ будет запущен отдельный рабочий процесс" - да, так и есть. В курсах подготовки к эксперту от 1С слышал что так вышли из ситуации похожей на вашу: когда много баз. Правда там был еще тот нюанс, что при большом количестве ИБ одновременно задействовалось небольшое количество баз. Но лектор утверждал, что эту настройку можно рекомендовать и в других ситуациях. Я на практике не проверял, не было возможности. Интересен ваш опыт, если поставите - отпишитесь, пожалуйста)
Оптимизация храна - зайдите в администрирование хранилища, там есть кнопка оптимизировать на последней закладке. Файлы сжимаются, операции с храном выполняются быстрее.

(8) дичь какая-то

(0) Если подключаться без RDP, по сети, что со скоростью?

(4)
C$ (SSD) - очередь: 0,11 ~ 0,32
D$ (RAID 10) - очередь: 2,5 ~ 12,54

(5)

Не совсем:
1C + SQL -> физический сервер
VM (терминал к которому по RDP подключаются и который обращается к серверу 1С) - второй сервер

...раньше оба сервера были VM - было хуже

(6)
к сожалению, не знаю как проверить есть ошибки памяти или нет... активно работают с 10 ~ 15 БД, все регламентные и фоновые отключены...

(7)
нет, серверу 1С отдано все:  2 Xeon по 8 ядер каждый, все 128 Gb ОЗУ

SQL ограничен в 104 Gb памяти, 24 Gb по ОС и сервер приложений 1С

(8)
вчера ночью попробовал установить:
Количество ИБ на процесс = 1
Количество соединений = 64

...стало немного лучше

"хранилище физически на сервере 1С - доступ либо к папке, либо через tcp (служба сетевого хранилища поднята и запущена)."

Убрать доступ к папке, всех пускать через tcp, перезагрузить сервер, доложить о результатах

БД хранилища где лежит?

(8)

"Оптимизация храна - зайдите в администрирование хранилища, там есть кнопка оптимизировать на последней закладке. Файлы сжимаются, операции с храном выполняются быстрее."

Попробовал, пока без особых изменений... оптимизирую остальные 6 хранилищ - отпишусь по итогу

(10)

без изменений - пробовали запускать всех разрабов напрямую на сервер... ставить 1С локально на компы... эффект если и есть - то не особо заметен (на 5 - 10 секунд быстрее)

(16)

Принято, попробую и отпишусь

скорее всего в проц упирается. ибо конфигуратор однопоточен

нужно смотреть по загрузке 1 ядра

(17)

файловые хранилища - на другом (не 1С) сервере;
сетевое хранилище (как эксперимент) - физически на сервере 1С

..что так, что так - симптомы те же

(22)

В том-то и дело, что когда 1С + хранилище висит, нагрузка на сервер (диск, память, ядра процессоров) - невелики (не более 20%)... бред какой-то: сервер не нагружен, но все зависает...

конкретно сейчас: нагружены 4 ядра из 16, каждое не более чем на 60% в пике... 15 рабочих процессов 1С

(12) и все это гуляет между серверами по одному гигабитному каналу?

(0) антивирусы стоят?

(22) это про сервер 1с? rdp сервер тоже мониторить?

* мониторишь

Сетка гигабитная у клиентов? Ну и на сервере.

P.S. Поднять несколько служб CRServer пробовали?

Sergeo,
1) "* тест Гилева показывает 32 попугая;
* любые утилиты мониторинга показывают что сервер (память, CPU, дисковая подсистема) - не бывают загружены более чем на 35 ~ 55%" - ЭтоНорма(с) На наших серваках и при 300 и при 100 пользователях - попугаев и процентов выше не видел, увы.

2) на (16) вы так и не отписались. Мы решали именно так. Симптомы: у одних разрабов хранилище тормозит, у других - нет. Оказалось что тормозит у тех, кто по tcp (tcp:), при наличии подключений через шару (//serv/share). Отключили доступ через папку, оставили tcp - нормализовалось.

Также уже было сказано про оптимизацию хранилища (и режим совместимости хранилища тоже выставить в "не используется") - но это скорее для профилактики.

Еще фишка: увеличить размер кеша в настройках хранилища (общего), и - главное - кеш локальный: конфа-хранилище-настройка использования локальных данных хранилища. Бронебойный прием: сперва уменьшить, потом увеличить (прилично так, пару гигов), перезапустить конфигуратор.

Надо попробовать вместо raid10 на hdd какой нибудь серверный ssd вроде Intel DC P3700/P4500. Иопсы они и в Африке иопсы.
ну или хотя бы samsung 960/970 Evo/Pro вставить в переходник под pci-e и для теста запустить. Для длительной работы не пойдет, но для оценки вполне.

базы все в одном кластере? разносить базы по кластерам не пробовали?

Когда один пользователь на сервере такая же картина? если да то дело не в железе.

Не увидел чистку кэша. Тормоза базы с хранилище часто из за него.

ну и 8.3.12.1412 так уж необходима? на старых релизах то же самое было?

(25) 4 гигабитных линка
(26) нет, стандартный брендмауэр отключен
(28) тоже мониторим - особой нагрузки нет

(29) сетка гигабитная - все в одном офисе (повторюсь, доступ к серверу 1С через терминал - соседний сервер)

CRServer - пока один, как писал H A D G E H O G s попробуем все хранилища перевести на CRServer (сетевое хранилище конфигураций)

(30) благодарю, испробуем совет

(31) думали над этим - если не поможет ничего из советов форумчан, будет пробовать серверный SSD PCI-E

(32) напробовались по уши... только больше головной боли, улучшений никаких

(33) по ночам работает периодически 1 разработчик - не лучше...

(34) если вы про C:\Users\localuser\AppData\Local\1C - постоянно и неоднократно: и на терминале и на сервере 1С...

(35) от релиза к релизу - соглашусь, что обновление без необходимости - зло... но на 8.3.10... 8.3.11 - особо разницы не видно было...

(37) у вас ожидания на сети и блокировки умной 1с в файловом по сути режиме, купите ему винил Колибри

Коллеги, благодарю за советы, промежуточный итог на 18.05.2018:

1. Настройка параметров рабочего сервера:
Количество ИБ на процесс = 1
Количество соединений на процесс = 32

...стало чуть быстрее и лучше (по крайней мере изоляция БД по отзывам разработчиков принесла больше комфорта в работе и немного улучшили скорость)

..действительно, 1С однопоточен - разные процессы при такой настройке раскидываются на разные ядра (выставлено отключение остановленных процессов через 300 секунд - так что процессы не плодятся: не более 20 ~ 22 в пиковые периоды)

2. Выполнено:
* оптимизация всех хранилищ - результат не изменился;

3. По плану:
* перевести все хранилища на CRServer по совету H A D G E H O G s и cons74 (сетевое хранилище конфигураций) - по итогу обзательно отпишусь;
* попробуем совет cons74 в части кэша - так же дам обратную связь;
* ничего не поможет - SSD PCI-E.

Еще раз благодарю всех за советы!

Насколько я понимаю, все операции с хранилищем - это операции с файловой базой, неважно, доступ через TCP или через шару. Хранилищу пофиг, сколько ресурсов вы отдаете серверу 1С и скулю. Поэтому хранилище в любом случае останется узким местом, в том числе из-за блокировок.

Поэтому мой совет - уменьшать количество разработчиков, работающих с одним хранилищем. Распределять все на много хранилищ, если возможно. И соответственно много обслуживающих процессов по TCP.

(0) >* ОС - SSD;
>* БД и логи SQL - RAID 10 (HDD);

Постоянно вижу такие конфиги и удивляюсь: зачем люди покупают SSD, чтобы он простаивал? Для ОС он нафиг не нужен, ОС и так вся в памяти. SSD нужен там, где большой ввод/вывод, а именно:
> D$ (RAID 10) - очередь: 2,5 ~ 12,54

(47) Вы правы, но в данном случае sdd для БД SQL мало чем поможет, какое место одно - хранилище, об этом ниже

(46) Вы правы, это подтвердили сегодняшние тесты. Хранилищ и так 7 (переведены все на сетевые) - но к сожалению, нельзя сделать несколько хранилищ для одной конфигурации.

Коллеги, резюме сегодняшних опытов:

1. Взяли взаймы у коллег по цеху SSD PCI-E (2 TB);
2. Перенесли на него всё: WS + SQL + сервер приложений + БД SQL + хранилища - ожидали чуда... Скорость, конечно, выросла в части работы клиентской части и конфигуратора... НО, упёрлись в работу хранилища (как тупило, так и тупит) и в тактовую частоту ядер (не умеет 1С работать с NUMA) - тупо грузит одно или два ядра под 100%... Остальные - в простое.
3. Наш вывод, по состоянию на сегодня:
* попробуем поставить другие CPU с большей тактовой частотой: 3,6 - 4,0 (сейчас: 2,6 - 3,3);
* выставим настройки 1 - ИБ на процесс / 16 соединений на процесс (сейчас 32);
* от SSD PCI-E пока решили отказаться, т.к. покупка не принесет ощутимого прироста скорости в нашем случае.

P.S. Все хранилища переведены в сетевой режим работы - разницы по сравнению с файловым вариантом не выявлено.

Благодарю всех за советы!

Ну да, с появлением SSD на SATA винт не является узким местом, и все упирается в частоту проца. Поэтому и нужно при выборе процессора смотреть не тестах не общую производительность, а производительность на 1 ядро. А вот тут уже почти 10 лет никаких подвижек со стороны разработчиков процессоров :(

SSD PCI-E принесет пользу при "многопоточной" работе. Т.е. когда 1000+ юзверей будет долбиться в файловую базу, вот тут этот SSD и сможет себя проявить

(50) У вас случайно на сервере, на котором расположена папка с хранилищем, кэширование дисков в ОС не отключено? Например из-за того, что на этом же сервере поднята роль контроллера домена?

Похожая тема была https://www.forum.mista.ru/topic.php?id=673445

(50) может спрашивали но.... антивиры/брэндмауэры не включены случаем?

Да что с бубном то плясать, если процессора фактически нет? 2.6 ГГц - с тем же успехом можно у бабушки Pentium 4 отжать.

3 минуты... при отключенной базе (соответственно полной загрузки конфы) еще норм
но уже подключенная... может у вас в appdata где кэш чистится при входе на терминал и конфа полностью приезжает из хранилища?

(0)количество РП и  иб на процесс довольно легко посчитать. берете общее число сеансов, и делите в вашем случае на 16(ну можно на 15 на всякий случай) Так, чтобы было по одному процессу на одно физическое ядро.

(52) Проверил - кеширование включено (ОС + сервер SQL + сервер 1С + хранилище - на данном диске: SSD)

DC - физически на другом сервере

(53) Брендмауэр - отключен, антивирус - не установлен

(55) к сожалению, не могу прокомментировать - просто не знаю, что выполняет 1С при подключении к хранилищу - как я понимаю копирует всю конфу из хранилища в папку локального юзера

(54) Надеюсь, вы правы и это поможет - но пока никто не подтвердил, что смена процессора на другой с большей тактовой частотой помогло... будем пробовать

(30) cons74, можно уточнить:

"...главное - кеш локальный: конфа-хранилище-настройка использования локальных данных хранилища. Бронебойный прием: сперва уменьшить, потом увеличить (прилично так, пару гигов), перезапустить конфигуратор"

Размер локального кэша нужно увеличить у каждого пользователя в отдельности?

Сейчас 500 МБ - сколько рекомендуете указать: 2... 3 ГБ?

(0) все не читал


Количество ИБ на процесс = ставь 5
Количество соединений на процесс = ставь 25...30


C$ (SSD) - очередь: 0,11 ~ 0,32 - более менее нормально
D$ (RAID 10) - очередь: 2,5 ~ 12,54 - никуда не годится


запусти в рабочее время https://wiki.mista.ru/doku.php?id=it:analiz_sql_block будет понятно что именно тормозит диск

(60) Ну чуда то может и не случиться, но линейный прирост скорости пропорционально частоте в любом случае будет.

DFSS отключить, если это гуано включено

(Disk Fair Share в более свежих виндах)

(62) Благодарю за ссылку, запустим - отпишусь

(65) Windows Server 2016 - нет такой ветки... все ссылки в Google ведут к Windows Server 2012 / 2012R2

(67) Речь о ветке в реестре? Поищи по "fair" глобально

(68) В Windows Server 2016 такой ветки нет - глобальный поиск не дал ничего.

(69) http://www.gilev.ru/dfss/

(68) (70)

PowerShell:
(gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices").enabledfss
0