Можно ли назначить конкретные процессоры (ядра) процессам 1С или серверу 1С полностью?
Цель - отдать SQL свои процы, а 1С свои.
Хочется посмотреть, сможет ли SQL в таких случаях точнее паралеллизировать запросы.

В Диспетчере задач я могу "Задать соответсвие (схожесть)" процессам rphost, но после их рестарта всё по дефолту - кушают все процы.
Есть решения?

А до рестарта - есть какой-нибудь положительный эффект от привязки процессов к ядрам?

свои это как?по цвету или как?

(0) со стороны сиквела решение есть - в лоб назначить ядра

(1) если sql планирует свои ядра "сама" и в них не лезет 1С, то ИМХО (!) должно быть меньше ошибок при паралеллизации запросов.
По простому - хочется уменьшить параметр CXPACKET в SQL при большом количестве процев.

(3) это ничего не даст, если я не уберу 1С от этих ядер

(2) по номеру

свойство affinity, если не путаю. Но делать это нужно уж не знаю как - батником, cmd или еще как... в самой консоли сервера такая возможность отсутсвует
https://en.wikipedia.org/wiki/Processor_affinity

http://www.eightforums.com/tutorials/40339-cpu-affinity-shortcut-program-create-windows.html

(8) процесс уже стартован, ему можно изменить?

интерактивно - да, как сделать программно - не знаю.

(9) Легко

Чтобы прямо вот назначить процессоры раз и навсегда, надо виртуальные машины поднимать и процессоры средствами гипервизора им назначать. Это будет ровно та изоляция, которую вы хотите.
Только какой смысл в этой изоляции?

1) Включить привилегию отладки
2) Получить дескриптор процесса по PID
3) Получить текущую маску
4) Сформировать новую маску битовым сдвигом.
5) Установить новую маску.

(13) дело за малым - угадать pid

Нет, нельзя.
Этим занимается ОС, и вы ничего не измените.

Можно конечно придумать какой нибудь костыль и таки сделать это, но как правило ценой потери производительности на работу костыля.

(6) если вы хотите, чтобы ваши запросы меньше параллелились - рулите максдопом.. привязка к ядрам тут не нужна

(14) Получить по имени процесса разве нельзя?

(16) не хотим "меньше", хотим "лучше"

по сути SQL кидает запрос на ядра
проблемы CXPACKET возникают
1) не угадали с данными (индексами) и мы ждём несколько потоков (suspended)
2) мы угадали с данными, но наше ядро процессора кто-то загрузил "не нашими" задачами - мы ждём этот поток (suspended)

Моя нетленка может выставить процессу ядра. Завтра кину тестовую демку.

(19) Распараллеливание запросов в большинстве случаев - зло. Отключение только на пользу.

(0) Пара вопросов ТС: 1) сколько ядер в наличии? 2) После ручного назначения ядер через диспетчер задач до рестарта какое-либо заметное увеличение производительности есть?

Вопросы в никуда: Что такое NUMA знаем? А осознание того, что неправильно разделение потоков может _уменьшить_ производительность межпроцессного обмена есть?

(0) Идея изначально бредовая - любое ограничение накладываемое на многопоточный процесс не может как то увеличить производительность последнего.

(23) а как насчет производительности другого процесса?

(21) ну для этого можно выставить "Стоимостной порог для паралеллизма"

А в запросах, которые на 3 минуты грузят 20 ядер на 100% почему бы и нет?

(24) Зависит от кол-ва простаивающих потоков других процессов на этом процессоре в системе. Если их много - то никак.

(22)
1) Окончательно будет 40 ядер (4 проца)
2) Чем измерить?

В деление потоков не лезем - пусть SQL и система сами рулят.

Насчет NUMA завтра админов спрошу.
Но допустим делим по процам - 10 ядер 1С, 30 - SQL

(23) Ваше заявление более бредовое.
Почитайте про рекомендации при высоких CXPACKET на SQL-сервере. Режут паралеллизацию вплоть до 1 ядра.

вот оно как..

Процы назначенные ragent.exe копируются в процессы  rphost.exe

(27) Ну не знаю, чем померять... APDEX, например. Или, в крайнем случае, попугаи от Гилева. Результат любого действия должен быть измерим. Иначе смысла в действии нет.

Совсем необязательно спрашивать админов. Хотя спросить, ради определения их компетентности, конечно стоит. Достаточно почитать нелюбимую википедию: https://en.wikipedia.org/wiki/Non-uniform_memory_access даю ссылку на английскую статью, так как в русской версии информации крайне мало.

Коротенько: SQL и 1С общаются между собой через общую память. В NUMA память разделяется между процессорами и один процессор напрямую получить доступ к памяти другого процессора не может - приходится делать кучу дополнительных движений и в результате тормоза. Поэтому, если 1С и SQL будут висеть на разных ядрах одного процессора, то работать это будет быстрее, чем если бы они висели на разных процессорах. Винда, начиная с Server 2008 R2, это знает и сама раскидывает процессы по процессорам так, чтобы общая память и процессы, работающие с этой памятью находились на одном процессоре.

Короче, настройка афинности, это последнее что бы я делал у связки 1С и SQL.

(30) а как же тогда физическое деление "сервер 1С" и "сервер SQL" ?

Да и нет уверенности, что 1С может передать/получить данные в SQL используя NUMA

(28) Для сервера 1С упоминается единственная путная рекомендация, указанная в (21), но для конфигурации в (27)- подумать надо.
(31) Передать/получить данные процессы смогут в любом случае, дело во времени.

(32) Ну скажем так, по NUMA больше разговоров, нежели реальных замеров и примеров.

Резать паралеллизацию простое дело. Но есть реальные тяжёлые запросы, которым это поможет. "Стоимостной порог для паралеллизма" выставим побольше.

(25) Такие запросы надо переписывать.

Если уж играть с NUMA, то можно на проце 5 ядер отдать 1С, а 5 ядер SQL

(33) Если у вас запрос на 3 минуты грузит 20 ядер на 100% - что-то в консерватории нужно менять имхо.

(34) Ну там прогноз закупок + прогноз производства -> прогноз снабжения (поставок материалов)

что-то можно ускорить, но немногое
сам по себе он тяжёлый

Проблема не в SQL запросах, проблема потом когда 1С начинает лопатить и на экран выводить.

(36) обязательно передам ваши рекомендации руководству.

(37)  "проблема потом когда 1С начинает лопатить и на экран выводить"
При чем тут тогда параллелизм sql-сервера?

(39) в данном случае - не причём
Просто это скорей наоборот - пример хорошего запроса.

(37) Прогнозы вот эти все, трехминутные, которые грузят 20 ядер - вы ведь их выполняете не часто? Точно хотите их ускорить до 2 минут 40 секунд?

(41) часто, по несколько раз в день
строят прогноз обеспечения пр-ва материалами, при этом им обязательно видеть "последние изменения внесённые менеджерами совместно с диспетчерами производства"

Кроме них есть ещё планирование производства (диспетчеризация), тоже ресурсоёмкая.

Для этого новый сервер и покупали.

(42) Мысль конечно бредовая, но, а что если их фоном выполнять каждые 5 минуты и пихать куда нить?

*минут

(43) не наш вариант
мы занимаемся оптимизацией этих отчётов.

да и тема не об этом..

(45) Пытаюсь осилить вумного дядю: http://sqlspirit.blogspot.ru/2015/03/cxpacket-waits-theyre-not-evil-theyre.html
но не дает покую то, что сервер 1С х.з. на каком узле окажется и как там должен оказаться поток организатор SQL запроса я не знаю, ибо если будет (а он будет) в другой ноде - то будут тормоза.

(46) CXPACKET - по сути показывает, сколько SQL ждёт, пока все потоки, раскинутые на разные ядра, закончат своё выполнение и можно будет дальше по плану выполнять след. пункт

а) если запрос на 2 сек, то кидать его на 10 ядер, тратить время на подготовку и деление данных, потом ждать выполнения - смысла мало
в данном случае большой CXPACKET относительно самого времени выполнения = плохо

б) если запрос на 10 мин (грубо), то имеет смысл потратить 1 сек на его деление, потом он выполнится за 1 мин на 10 ядрах, но на некоторых из них чуть позже, нам придётся дождаться все 10. пусть мы ждём 5 сек (от 1го до 10го)
Итого 1мин 6сек (грубо)
И наше ожидание 5 сек не так страшно

47+ как раз и есть идея - чтобы 1С не лез на ядра SQL и цифра "задержка в 5 сек" была более прогнозируема (для SQL)

Походу решения 3
1. Прописать старт сервиса "через 3и руки" - чтобы сервер 1С стартовал с нужными ядрами.
Потом сервер запускает процессы с теми же ядрами.

2. Process Lasso - прога висит в памяти, мониторит и корректирует сама

3. Просто руками поправить для ragent.exe, а так как он у нас рестартует процессы с определённой периодичностью, то через некоторое время всё будет как надо.


п.2 наверное удобнее и менять можно

по NUMA - спасибо что напомнили.
возможно правильней взять у проца часть ядер

(49)
забыли про wmi события. можно даже на vbs написать обработчик.

(50) обработчик чего?

(51)
события создания процесса.

(52) Вам бы в Microsoft резюме кинуть, а то их тупые дятлы не могут прописать в реестре ветку с ИИ, который понял бы как балансировать потоки на физ. процах в зависимости от хотелок других процессов и пользователя.

(52) мы попробуем пока более протоптанным путём, но спасибо за инфу ))

Тема еще интересна?

кому?

(40) Это пример плохого запроса. Хороший запрос выдает мало данных.

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

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

(56) Вам. Могу дать внешнюю компоненту, которая расставить процесс rphost.exe по нужным вам процессам.

(59) не откажусь
1c.work <гав> mail.ru

(60) Вечером ждите.

(61) спс!

А не проще разнести 1С и SQL на разные физические сервера?

(63) зачем?

Чтобы все нормально работало, нет?

(65) Так оно нормально и на одном сервере работает.

(66) Если бы нормально работало - не надо было бы эту тему заводить :)

(67) ну мы так, цилиндры расточить, кнопку "нитро" приделать ..

(68) Ну и чисто из интереса, памяти на сервере сколько?

(69) Если упирается в проц - добавление памяти выборку не ускорит.

(70) Просто интересно, сколько памяти на сервере где вместе живут 1С и SQL и выполняются такие тяжелые запросы.

(69) 250Гб, база в районе 180Гб
(70) в проц на старом упиралось конкретно, сейчас лучше намного - 30-50% загрузка, пропали конфликты блокировок, фоновые расчёты не мешают работе, Бух базы получше (но закрытия всё равно тупятЮ ибо не на SQL там ложится нагрузка)

вот у людей проблемы: SQL, сколько тестов и замеров ни делал, к SQL вопросы в последнюю очередь были

(73) добавлю, видел несколько случаев когда реально висел запрос на SQL, и это было по причине плохой статистики, оптимизатор построил неправильный план, после исправления запрос пролетал легко

(37) попробуйте временные файлы сервера 1с и tempdb скуля перекинуть на быстрый ССД диск или даже страйп из ССД дисков.

(74) у нас не висят вроде
делаем 2 раза в неделю реиндекс и апд. статистики

смотрим на тяжёлые запросы - в основном когда строят по куче данных отчёты, т.е. обоснованно они тяжёлые

(75) очереди на нём нет, в мониторе SQL tempdb не узкое место в вводе/выводе (время ответа = 0..8 мс)
SSD от перезаписи дохнут быстро (уже похоронили один Рейд на SSD), есть мысль а) разделить на несколько файлов (не знаю актуален ли для SQL_Server_2014 этот старый совет)  б) закинуть на RAM-диск

+(75) 1С со времен 7.7 очень любит активно писать читать временные файлы, особенно при работе с отчетами.

(77) в счётчиках SQL нет жалоб на I/O

(78) я про собственные врем файлы 1С сервера

(76) Серверные SSD не дохнут быстро... 2 года полет нормальный, сдохло пара штук по гарантии.

(76) ну если прямо проблема в SQL (верится с трудом), то смотрели индексы, анализ в DTA делали?

(78) I/O лишним никогда не бывает

(82) не согласен, если диск холодный, зачем его трогать

+(79) советую не просто так. нам помогло. отчеты с большим количеством информации на вывод начали работать в разы быстрее.

(84) а где настраивается каталог темп-файлов сервера 1С?
Или вы о темп-файлах на клиенте?

(85) системный параметр TEMP пользователя, под которым запускаются процессы

+(86) серверные. клиентам тоже не помешает, но накладно выйдет

Регламенты SQL надо делать каждую ночь. 180 гиг конечно много, но обновление статистики можно делать без fullscan-а ночью и с fullscan-ом на выходных.

(87) Им достаточно прописать в исключениях антивирусов

(86) Это получается "Юзер..\AppData\Local\Temp" - эту чтоли? Вроде по диску C очереди не наблюдается.

Попробуем, как сервак ребутать будем ..

(88) старый не справлялся, поэтому так стояло.
Там правда скрипт запускали, который анализировал какие индексы юзаются и тока их апдейтил.
На новом наверное сделаем ежедневное.

(90) еще бы вы очередь наблюдали. тогда бы совсем плохо было.

Интересные наблюдения про своппинг процесса rphost.exe
Для rphost.exe получил:
минимальный размер рабочего набора 205 Кбайта
максимальный размер рабочего набора 1,5 мегабайта.
(стандарт)

Ежам на смех.

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

Ну и посмотрите на ваш сервер 1С, проработавший день и на счетчик "Page Fault" в диспетчере задач.

Будет свободное время - назначу на наш сервер набор в 2 гига, потестирую.