gifts2017

Ускорение запуска конфигуратора и DFSS

Опубликовал Юрий Гончарук (yukon) в раздел Администрирование - Системное

Известный и уважаемый Вячеслав Гилёв опубликовал рекомендации по ускорению запуска конфигуратора - http://www.gilev.ru/dfss и http://infostart.ru/public/348963 https://plus.google.com/114728939911168275213/posts/96v6bNvnLJP. При все моем уважении к автору, я тем не менее не соглашусь с приведенными рекомендациями. Точнее не самими рекомендациями - они как раз приводят к нужному результату, а к постановке вопроса и самому решению.

Собственно, у меня два замечания к указанной статье:

1. Подача в общем-то низкоуровневых исправлений без малейшего объяснения побочных эффектов и каких-либо ссылок на документацию. Для автора такого уровня компетенции это выглядит странно.

2. Решения задачи можно добиться и менее радикальными методами, чем изменение опций ядра Windows.

Для начала немного лирики.

Работа в терминальной многопользовательской среде, безусловно, имеет свою специфику. К сожалению, далеко не все приложения эту специфику учитывают. Здесь и использование ресурсов сверх необходимости - режим "я дома один" см. 1С:Предприятие 7.7 и ВК Terminal Sleep, и непродуманные визуальные эффекты - та же заставка 1С:Преприятие 7.7 и градиентная заливка 1С:Предприятие 8.2 Турбо-милк.

С другой стороны, не всем приложениям учет такой специфики требуется - для них вполне достаточно стандарных требований к разработке Windows приложений. К числу последних я отнесу и обсуждаемый Конфигуратор.

Теперь про DFSS.

Возьмем гипотетический пример. Имеем терминальный сервер с 4 процессорами, имеющими производительность 1000 попугаев каждый. Итого 4000 попугаев. Запускать на серверах мы будем только программы 1С. Поскольку 1С однопоточное приложение (строго говоря это не так, но на практике влиение остальных потоков малозначительно), то каждое 1С приложение может использовать только один процессор и максимально сможет работать со скоростью 1000 попугаев.

На терминал заходит мега-разработчик и открывает Конфигуратор. При запуске Конфигуратор получит свои 1000 попугаев. Все нормально. Закроем приложение. И запустим одновременно 4 Конфигуратора. Что произойдет? А ничего, все получат свои 1000 попугаев. Опять все закрываем. 

Теперь в терминал зашел пользователь и запустил в Предприятии отчет с большой постобработкой результата встроенным языком. ОК. Получит 1000 попугаев. Пока все как обычно.

А если запустить формировать отчет и открывать Конфигураторы? Выделить 5000 попугаев операционка уже не сможет, поэтому выдаст всем поровну - по 800 попугаев каждому. Это стандарное поведение системы, опять же ничего необычного. Но все ли здесь нормально? Нет, не все. Получается, что чем больше пользователь запустит ресурсоемких операций тем больше он будет мешать другим пользователям работать.

Для исправления ситуации Microsoft начиная с Windows Server 2008 R2 на уровне ядра выделила еще один разрез для распределения ресурсов - сессию. Соответственно, появился механизм DFSS - Dynamic Fair Share Scheduling (вольн. -Динамическое честное распределение ресурсов).

Что произойдет при включенном DFSS в третьем сценарии? Система отработает уже по другому - сначала поделит ресурсы пополам (у нас две сессии), т.е. каждый пользователь получит 2000 попугаев. Теперь формирование отчета получит 1000 попугаев, а каждый конфигуратор 500. Все по честному (fair) - у каждого пользователя одинаковое количество ресурсов, а дальше уже его право распоряжатся выделенными ему ресурсами как угодно (можно даже запускать 1С:Предприятие 7.7 без ВК Terminal Sleep). Теперь никакая нагрузка пользователя не повлияет на работу других пользователей.

Как это выглядит в документации, можно посмотреть здесь: https://technet.microsoft.com/en-us/library/dd560667(v=ws.10).aspx#BKMK_4

Windows Server 2008 использовал DFSS только для регулирования ресурсами процессора, но идея оказалась столь хороша, что в Windows Server 2012 DFSS рулит еще и дисковыми операциями и полосой пропускания сети. 

Замечу также, что DFSS включается по умолчанию при установке роли Remote Desktop Services и явлется опцией ядра - т.о. его изменение требует перезагрузки ОС.

Решение проблемы.

Вернемся в медленному запуску конфигуратора. Можем ли мы как-то ускорить его запуск без отключения DFSS? Конечно, можем! Вспомним, что DFSS для управления использует сессии пользователей, т.е. если мы можем выделить мега-разработчиков из сонма пользователей, то, возможно, для них получится более "честно" настроить политику выделения ресурсов. Ну а если не можем (да у нас каждый второй запускает конфигуратор), то, возможно, получится выделить процесс конфигуратора из всех остальных.

Для решения задачи используем WSRM - Windows System Resource Manager https://technet.microsoft.com/en-us/library/cc755056.aspx (Q&A на русском: https://technet.microsoft.com/ru-ru/windowsserver/bb405954.aspx )

В оснастке WSRM есть раздел "Process Matching Criteria". При создании нового критерия отбора процессов можно указать конкретное приложение (можно даже просто имя файла 1cv8.exe) и пользователей (группы пользователей) входящих в критерий. В разделе "Resource Allocation Plolicies" можно установить, что для определенного критерия (например 1cv8.exe и i.petrov) установить выделение 50% процессорной мощности системы. И мы решили проблему медленного запуска конфигуратора у пользователя i.petrov. Правда под критерий попадает еще и толстый клиент, но это скорее бонус для i.petrov.

К сожалению, в Windows Server 2012 WSRM признана устаревшей, и заменена Hyper-V имеющий схожую функциональность. https://technet.microsoft.com/library/hh831568.aspx Здесь Microsoft лукавит - Hyper-V не занимается регулированием процессов, но оставим это на совести Microsoft. Возможно, эта функция будет полезна в Windows Server Next, гда появится поддержка Docker, но это будет уже завтра. http://news.microsoft.com/2014/10/15/dockerpr/

Но и здесь есть выход. Вспомним, что DFSS рулит еще и дисковыми ресурсами, а конфигуратор при открытии как раз и занимается усиленной работой с диском. Т.е. вполне достаточно установить в "0" TSFairShare (п. 2 в статье). Кстати появится еще один полезный эффект - повысится скорость работы с локальными файловыми базами 1С:Предприятия 8, и с базами 1С:Предприятия 7.7 (ну вдруг!) как для файлового, так и для SQL-варианта.

Теперь подойдем с другой стороны. Есть ли необходимость изменения опций ядра для запуска Конфигуратора 1С?

Скорее всего, нет. Сценарий, когда есть терминальный сервер или терминальная ферма, на которой разработчик будет работать наравне с пользователями, нарушает как минимум принцип разделения рабочей и тестовой среды. Если же запуск конфигуратора является эпизодическим (например, для удаленного внесения изменений), то такое решение носит избыточный характер, см. "от головной боли помогает топор". Особенно на фоне выгоды в 30 секунд.

Окончание.

Вернемся обратно к озвученным мной замечаниям:

1. Необходимо добавить ссылки:

1.1. про DFSS https://technet.microsoft.com/en-us/library/dd560667(v=ws.10).aspx#BKMK_4

1.2. Фрагмент "(gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices").enabledfss" заменить на полный формат

Get-WmiObject -Class win32_terminalservicesetting -Namespace root\cimv2\terminalservices | 
	Format-List EnableDFSS,EnableDiskFSS,EnableNetworkFSS

и дать ссылку на https://msdn.microsoft.com/en-us/library/aa383640(v=vs.85).aspx

1.3. Дополнить п.1 возможностью устанавливать значение групповой политикой: Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connection\Turn off Fair Share CPU Scheduling https://technet.microsoft.com/ru-ru/library/ee791922(v=ws.10).aspx

2. Достаточно выполнить только п.2 из статьи.

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Иван Устьянцев (nSpirit2) 24.04.15 12:57
Спасибо автору отличная статья!
Redokov; Infactum; +2 Ответить
2. Женя Ткаченко (zhenyat) 24.04.15 22:40
Тем не менее отключение dfss на server 2012r2 с ролью remote app полностью решило проблему с 1с 7.7 - порядка 70 пользователей работают совершенно спокойно, в то время как с настройками по умолчанию после 25 все начинали тормозить со страшной силой...
3. Гость 25.04.15 09:23
(2) zhenyat, Вячеслав, перелогиньтесь
Silmariil; +1 1 Ответить
4. Юрий Гончарук (yukon) 27.04.15 11:11
(2) zhenyat,
в то время как с настройками по умолчанию после 25 все начинали тормозить со страшной силой

И вы конечно, провели расследование, сняли показатели производительности и т.п., и начали аккуратно настраивать сервер и отслеживать изменения?
Если возможно, расскажите подробнее.

В общем ожидаемое поведение для 1С:Предприятия 7.7 - т.к. идет интенсивный обмен с диском - mlg-файл, временные файлы, чтение/запись dbf "по дефолту" в WS2012R2 квотируются по сессиям. Необходимо в первую очередь посмотреть на дисковые операции, и раз уж дело дойдет до механизмов DFSS, то постараться ограничится только отключением квотирования дисковых операций.

А вот по процессорам интересно, у вас ВК Terminal Sleep (или аналог) используется?
5. Женя Ткаченко (zhenyat) 27.04.15 11:31
(4) yukon, Переход с 2003 на 2012 производили на новогодние праздники, когда 11 января народ вышел на работу и все просто колом встало, было очень не весело. При этом настроили работу с временными файлами на быстрый массив RAID0. Сломали голову что же происходит - диски простаивали, процессорное время занимали "фейковые" процессы, уже сейчас не вспомню, как они там назывались, на каждую сессию - по процессу, по ним вышли на описание этой самой DFSS и рекомендации как ее отключить...
Да, 1С патченная, сервер 8-и процессорный, один процесс 1С при максимальной загрузке занимает максимум 15% времени одного процессора, так что сейчас даже при 60+ пользователях 100% загрузка всех процессоров достигается очень редко
6. Юрий Гончарук (yukon) 27.04.15 12:07
(5) zhenyat,
Переход с 2003 на 2012 производили на новогодние праздники, когда 11 января народ вышел на работу и все просто колом встало, было очень не весело.


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

При вводе новых серверов в эксплуатацию протестируйте только отключение DFSS в части дисковых операций, возможно, для вас, этого будет достаточно.
7. Анянов Михаил (insurgut) 28.04.15 11:30
Если честно, непонятно, чем ваша статья принципиально отличается от статьи Гилёва. То, что вы ее дополнили ссылками и описанием DFSS? Google с Яндексом вроде еще никто не запрещал, и кому надо легко найдут всю необходимую информацию.
8. Юрий Гончарук (yukon) 28.04.15 12:30
(7) insurgut,
Если честно, непонятно, чем ваша статья принципиально отличается от статьи Гилёва.

Вы же и ответили: "Дополнили ссылками и описанием DFSS"

Google с Яндексом вроде еще никто не запрещал, и кому надо легко найдут всю необходимую информацию.

Собственно, основную причину я написал в самом начале "Подача в общем-то низкоуровневых исправлений без малейшего объяснения побочных эффектов и каких-либо ссылок на документацию". Ключевые слова "низкоуровневую" и "без объяснений". В таком виде статья типичное техножречество - сделай вот эти пассы руками и получишь результат. А почему, зачем - "нет времени объяснять" ™. Для автора уровня Вячеслава подобная подача выглядит несколько странно, а учитывая, что меняются параметры ядра Windows еще и опасно.

Когда было готово уже порядка 80% текста появилась и вторая причина - Вячеслав попросил конкретные дополнения в статью и одновременно забанил, видимо для добавления конструктивности в дискуссии. Так что статья получилась "двойного назначения".
segatron; JohnyDeath; tormozit; Mick2iS; ToTMoM; DitriX; zhenyat; qwinter; Evil Beaver; MRAK; +10 Ответить
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа