Как заставить сервер c 2xE5-2630 v4, 128GB, raid ssd грузить процессор на 100% (тест Гилева 21,65)?
1. Загрузить процессор на MSSQL можно так : 
- Должна быть задача на SQL серваке, которая потребует этих ресурсов (в простое или при малых задачах SQL проц не загрузит)
- Ставим параллелизм = количеству ядер
- Ставим Стоимостной порог в 0. 
После завершения текущих проверок, советую вернуть MAXDOP/MaxThreshhold на (1/4 или 1/8 от количества ядер а порог выявить методом проб и замеров). Дело в том, что загрузка проца 100% не значит что всё будет быстрее (только в некоторых случаях типа проверки целостности). Т.к. при распараллеливании запросов по ядрам, появляются "Накладные расходы" на распараллеливание и сбор обратно результатов воедино. Это будет выглядеть как ожидания CXPACKET и Latch. (См "закон Амадала" + CXPACKET в гугле)
2. "Проверка целостности базы данных" - на ежедневной основе смысла не имеет, особенно если база достаточно крупная. Её имеет смысл делать или при возникновении проблем, или раз в квартал/месяц ... зависит от размеров базы. UPD: Лучше всё же её делать, если позволяет размер и тех. окно. Т.к. можно упустить ошибку целостности и перенести её в бэкап.
3. Если есть проблемы с производительностью, это вопрос не простой, и требует кучу опыта. Навскидку рекомендую сначала проверить :
- Нагрузку на дисковую подсистему, и если там будет проблема (Очередь к диску более 2 в среднем) выполнить разнесение *.mdf, *.log, tempdb, инстанс кластера 1c серверов на отдельные диски.
- Нагрузку на оперативку от MSSQL (можете гуглить это может вызывать большую активность IO на дисковую подсистему)
- Проверить способ коннекта к MSSQL ("Shared memory" должно быть "on" и использоваться, если 1с сервак и mssql сервак физически на одно машине .. это +10% к производительности.
ну и куча чего ещё ... в одном посте всего не расписать.
и т.д. вариантов очень много.
главный совет: решайте проблемы , только если она есть и мешает, если это лично ваше мнение, а пользователям не мешает, лучше делайте настройки по дефолту (см. APDEX, анализ производительности)
UPD: И да, виртуалки для 1C + MSSQL = зло, и не потому что "фирма 1С плохая", а потому что у вас не сможет 1С и MSSQL не сможет общаться через оперативку, и между оператором чтения на MSSQL до железа сервера будет 4 прослойки (SQLOS, OS виртуалки, Гипервизор, OS сервера, вместо SQLOS + OS сервера).
На прошлой работе админил, 150+ активных пользователей 1С
1) 1C утекает по памяти, настраивайте автоматический перезапуск процессов. Например каждые 40 часов.
2) количество процессов для 1С вообще не интересно, можно оставить 1 процессор и будет работать так же. Тупняки были решены путём установки интела из "голд" серии, с рабочей частотой >3ГГц. На самом деле, на i5 10й серии будет быстрее работать 1Ска под ваши потребности. Тест гилёва покажет кратное преимущество.
3) переиндексация и всё остальное для БД, как показывает мой опыт, делается долго только первый раз. И эффекта нет никакого.
В целом - проблему тупняков простым вливанием денег в железо не смог победить. Мы пробовали разные версии БД, пробовал postgresql, линукс/винда - работает одинаково безобразно, видимо где то внутри движка проблемы. На этом моя история закончена.