Как понять почему rphost и SQL не загружают ядро на 100%

[uhi]

Добрый день.
Огромное спасибо за такой удобный тест для анализа производительности.
Тестирую на обычном десктопе под win 10 LTSB. платформа 8.3.15.1778, SQL 2019.
Всё что можно в sql, в энергосбережнии windows и биосе настроил получил прирост с 31 до 39 баллов в тесте 8.3.
Я так понимаю для i5-8600 / 16Gb / samsung 970 pro результат должен быть выше...

Причем если (до настройки биоса) окно 1с8 не зависало, то теперь оно зависает на время тестирования(возможно это важно).

При тестировании я вижу что rphost и SQL не загружают ядро на 100%.
На картинке видно что одно ядро загружается на максимум 50+-% во время теста. нагрузки на диск нет.

Нормально ли это? или если нет куда можно копнуть?

[Дмитрий Юхтимовский]

Новые версии операционных систем Microsoft при высокой загрузке одного или нескольких ядер пытаются не перегреть процессор, постоянно перебрасывая потоки с одного физического ядра на другое.
Поэтому там, где в старых версиях ОС можно было спокойно видеть столбик 100% загрузки одного ядра при простое остальных - сейчас это легко может выглядеть как сглаженная загрузка скажем 4х ядер по 25%.

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

[uhi]

Запустил тест и взял графики для rphost.exe и sql.
если разделить 100% на 6 ядер, то график должен упираться в 16.66%
SQL выше 10.5 не поднимался, rphost выше 13.2 не поднимался, причем это вершины зубцов, по графику видно что средняя загрузка 7-10 %.

при таких графиках, логично что мы учли весь процесс(так как показан весь процессор) и не размазали по другим ядрам?

Просто результатов тестов много, а как во время этих тестов должен быть загружен ЦП не ясно.

мне кажется что график(хотябы один) должен упираться в 100% ядра хотябы секунд на 20-40(или даже подольше) во время тестирования...

так ли это?

[Дмитрий Юхтимовский]

выключите распараллеливание в свойствах сервера SQL (то есть установите параметр max degree of parallelism в 1), перезапустите службу MS SQL и повторите замер.

[uhi]

изначально был установлен 1:

настройка sql была сделана согласно этой статье:
https://its.1c.ru/db/metod8dev#content:5904:hdoc

кроме этих пунктов
*Разбить базу на 4 файла данных.
*Флаги трассировки
ну и так как всё запускается от админа то всё что связано с учетными записями не делал.

[Дмитрий Юхтимовский]

Видимо, есть ещё какие-то источники замедления.
В диагностике этого может быть полезен например windows performance monitor, и SQL activity monitor.

[uhi]

Подскажите, отрыл монитор ресурсов и диспетчер задач вкладку диск:
скорость записи в перой части теста не выше 10 мб и очередь не большая. Как понять хватает ли SQL и серверу 1с данных для обработки которые он считывает с диска?

в диск мы не упираемся?

[uhi]

Просто сложно искать совет/ответ.
У всех беда что rphost грузит процессор на 100% а у нас наоборот, не грузит.
Направьте пожалуйста как искать. по запуску мониторинга видно что rphost загружает 6 ядерный процессор на 7.5 %(средняя загрузка за тест) а SQL на 2.5%.
т.е. меньше 45% на rphost и меньше 15% в среднем на SQL

открыл результаты тестов, отсортировал по 6-8 ядер и частоту процессора 3100+-, максимум баллов увидел 45. у меня 38-39
Быть может вообще это норма? и я зря копаю?

[Дмитрий Юхтимовский]

Вот как-то подозрительно выглядит среднее время ответа диска в 554 мс, несмотря на то, что диск "модный".

[uhi]

Установил не модный kingston skc300 на 60 гигабайт. стало 50-52 балла.
Да, есть какая-то беда с nvm-e моим. буду искать.
спасибо.

[Дмитрий Юхтимовский]

Может быть банальный перегрев с троттлингом под нагрузкой, производительные NVMe SSD сильно греются, им нужен хороший радиатор, а иногда даже с обдувом.

[uhi]

все решилось установкой Samsung_NVM_Express_Driver_3.2 для win10
и подкидывания руками драйвера на nvm-e контроллер(не на диск!) для server 2016.

Драйвер брать здесь:
https://www.win-raid.com/t29f25-Recomme ... ivers.html
L. Samsung NVMe Drivers
c) for Win10 (32/64bit):
>"pure" 32bit Samsung NVMe Driver v3.2.0.1910 WHQL for Win10 x86< (>MIRROR<)
>"pure" 64bit Samsung NVMe Driver v3.2.0.1910 WHQL for Win10 x64< (>MIRROR<)

это не помогает:
http://www.gilev.info/2018/09/samsung-n ... -2016.html

спасибо.

[Дмитрий Юхтимовский]

это не помогает:
http://www.gilev.info/2018/09/samsung-n ... -2016.html

Ну так то был рецепт двухлетней давности и для Windows Server 2016, с тех пор много воды утекло.
Понятно, что могли и более свежий драйвер выпустить (только ему было бы больше веры, если бы он лежал например на сайте samsung.com )

[uhi]

если нужно больше доверия, вот схема

Here're the steps:
- Install the SSD into a Win 10 machine
- Then install Samsung's drivers, reboot.
- Navigate to C:\Windows\System32\DriverStore\FileRepository
- Arrange folders by date, the folder you want will be named similarly to "C:\Windows\System32\DriverStore\FileRepository\secnvme.inf_amd64_b85d12e8825d30fc" perhaps the GUID part will be different.
- Grab the driver files inside the folder, then manually update to these drivers in Windows Server machine via Device Manager.

[uhi]

Что-то после исправления проблемы с драйвером nvme, я забыл что изначально проблему увидел в том что при выполнении первой части теста, процессы SQL+rphost+rmngr не забирают каждый по одному ядру процессора, или к примеру SQL одно ядро а rphost+rmngr второе ядро и каждое загружают под завязку.
вот пример тестирования файловой базы:

файловая база(одно ядро из 6 загружено на 100%(16.6))

2020-12-19_23-27-31.png (7.44 KiB) Просмотров: 859

а вот тестирование SQL

SQL база(используется одно ядро)

2020-12-19_23-32-30.png (85.59 KiB) Просмотров: 859

видно что суммарно загружено 15,4% процессора, меньше ядра.(для наглядности тест запускал на виртуалке с 4 ядрами, там красиво всё упирается в 25%(т.е. в одно ядро)) win 2016

вот SQL activity monitor

2020-12-19_23-46-16.png (15.58 KiB) Просмотров: 859

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

Может кто-то может у себя посмотреть, sql и 1С используют одно общее ядро или у вас по другому.

[Дмитрий Юхтимовский]

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

А насчёт оценки - попробуйте развернуть рамдиск гигабайт на 10, разместить на нём tempdb и базу, и выполнить тест в таком виде. Это позволит сильно уменьшить негативное влияние дисковой подсистемы.

[uhi]

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

[uhi]

рам диск создал SoftPerfect RAM Disk.
переустановил sql и 1с на рам диск.
тестил на i9 так как там памяти для рамдиска достаточно есть. 16 потоков, 100/16 = 6,25
результат не изменился:

2020-12-20_10-50-37.png (23.48 KiB) Просмотров: 840

используется 6.06%

в sql пакетов/с стало больше(хотя и тестовое железо изменилось):

2020-12-20_10-59-28.png (15.65 KiB) Просмотров: 839

может всё таки кто-то глянуть у себя. быть может так не только у меня

[Дмитрий Юхтимовский]

Сравните например с более свежей платформой 8.3.16 (желательно последней версии). Более новые версии 8.3.17 и дальше - пока не предлагаю.

[uhi]

2020-12-21_08-25-03.png (32.19 KiB) Просмотров: 812

8.3.16.1814

[Дмитрий Юхтимовский]

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

[uhi]

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

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

Вот видео:
https://youtu.be/qhBz6uEu33g

Но по видео видно что только в один момент на 2-3 секунды загрузка одного ядра поднимается до 67-75% это SQL, а в остальное время крутится около 50% и второй процесс ооочень редко поднимается до 50.

Возможно, я не понимаю схему выполнения однопоточного теста, но мне казалось что если у нас в обработке этого теста участвуют 3 разных экзешника которые поочередно что-то делают на 3х ядрах(соответственно каждый одним потоком) то мы должны видеть периодически 100% загрузки ядра одним из процессов. Тут, такое ощущение что то держит в пределах производительности одного ядра все 3 процесса.