Повышенная загрузка Windows 2008 R2.
 

Добрый день, коллеги, помогите разобраться.
С 2 недели назад начались какие-то непонятные тормоза на сервере.
Конфигурация:
MB Intel S5520SC
CPU Intel Xeon E 5506 x 2
Intel Raid Controller SRCSASRB - 2 RAID: система стоит на RAID-1 - 2 HDD Seagate 150 GB SAS, для данных - RAID-10 из 4 HDD SEAGATE 150 GB SAS.
32 GB RAM
( на контроллере мертва батарейка, поэтому он сейчас работает в режиме Write Through)
Intel Raid Controller RS2BL040 - RAID-1 из двух Intel 520 SSD, ни для чего не используется ( батарейка в режиме Degraded(needs attention), manual learn не помогает)
На сервере находится сервер терминалов(Remote App) только для 1с предприятия 8.3.
Установлен непосредственно сам сервер предприятия 1с.
Одновременная работа 35 человек.
SQL 2014 Standard(Выделено 10 Гб памяти).
30 человек работает в базе на SQL, 5 человек в обычной файловой.
Размер SQL базы 10.5 Гб.
Счетчики производительности бегло просматривать, но критического ничего не увидел.
Что вижу глазами - на скриншоте диспетчере очень высокая загруженность всех ядер всех процессоров.

В какую сторону смотреть, чтобы выявить причину столь большой загруженности? Железо уже не тянет?

В сторону процессов, которые грузят процессор.

Среди загружающих процессов rphost, 1c8.exe и sqlserver. Значит ли это, что время менять железо?

35 пользователей вряд ли загрузят эти процы больше 5%

у всех этих пользователей в терминале запущен 1с8.exe, которые в сумме с легкостью съедают 10%.
Насколько "сломанная" батарейка может сказаться на производительности, в данном случае я говорю о чтении с массива. Я так понимаю - без разницы?

не то чтобы сразу менять, но лучше все яйца в одну корзину не складывать.
1. взять хорошего 1С-ника и поглядеть что за запросы имеют наибольшую продолжительность.
2. вынести файловые базы на сас диски, а SQL переложить на SSD.
3. поглядеть как там с ОЗУ, что как свободно?
4. почитать ИТС на предмет обслуживания SQL DB (там есть пара хороших инструкций с картинками).

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

вообще вопрос - зачем?
new release - donwload - next-next - NO PROFIT? O_o

Лучше наоборот, SQL пофигу на SSD, т.е. быстрее работать не будет, а вот файловая будет работать намного быстрее.

даже в последней редакции:
вы уверены, что для SQL дисковая пофиг, а 5 пользователей в мизерных (а файловые базы они такие), ощутят сильный профит?
да и думается мне, что в SQL лежат базы CRM/Торговли, а файловые это бухгалтерия/ЗУП, для которой скорость не нужна почти никак.

Абсолютно, пробовали на работе на 4 sas 15к raid 10 и 4 ssd (intel s3700) raid 10 - минимальная разница в производительности в SQL, т.е. оно того не стоит.

Понимаю. Но на данный момент другого сервера нет.
У 1с есть такая штукенция - SQL Runtime, стоит он подешевле, если на нем использовать только базы 1с. Собственно сабж и был куплен этим летом. Купить SQL 2012 ( до этого база стояла именно на 2012 Express, но ввиду того, что база дошла до 10 Гб, купили 2014 Runtime. Downgrade к нему нет.
Регулярно, каждую ночь делаю реиндексацию базы, дефрагментацию индексов и обновление статистик.
Ну тут ничего не менялось, поэтому считаем, это не причем.

2all:
база SQL - это УТ 10.3
база файловая - БП 2.0.

Я всё же грешу на то, что раньше был SQL 2012 Express а теперь 2014. Возможно, что полная версия SQL стала по полной использовать все процессоры и в целом замедлить систему, в отличии от SQL Express 2012.

Я заходил как то ночью на сервер, стали даже дольше открываться такие вещи как "Список заказов" даже когда я один на сервере.
Я с самого начала перенес базу tempdb на массив SSD. После возникновения проблем переложил обратно на RAID10, но ничего не изменилось.
Я мониторил счетчики производительности, но особых отклонений от нормы не заметил. Средняя длина очереди дисков < 2 намного, 0,7 или 0,8.
Беспокоит только Контекст переключений в секунду - он был выше нормы, но я не нашел четкого обоснования того, что процессор не выдерживает.

Сколько пользователей в данной базе одновременно работает?

угадала ;)
это всё 8,1/8,2. тогда можно ещё поглядеть на настройки рабочих процессов (rphost) в сервере 1С. там, кроме кол-ва процессов можно указывать таймауты (и размеры потребляемой памяти) для перезапуска - это полезно в случае с 8,2.
но не все платформы 8,2 корректно это отрабатывают.
у нас .19 какая-то, она понимает.
дальше нужно смотреть на кол-во процессов - там нет нормальной методики расчёта. ни ph_CPU*2, ни log_CPU*1 - всё методом перебора.
посему предлагаю вам, всё таки, понасиловась 1С-ников.
несколько сотен.

cameron, да то-то и оно. rphost выше 500 мегобайт не поднимается, процесс всего 1. У меня 8.3 сервер, здесь утечек, как это было раньше я не наблюдаю.
Пока что я грешу лишь на 3 вещи:
- батарейку контроллера(бог его знает, вдруг без батарейки снижается общая производительность массива)
- некорректная реиндексация/дефрагментация индексов(пока не нашел как проверить этот момент)
- SQL Server 2014 был установлен updat-ом с 2012. Вот теперь думаю, а не удалить ли его полностью( с совместимостью баз экспериментировал, выставлял в 2012 и в 2014, разницы никакой. В SQL Server 2014 новый механизм оценки количества элементов, но реальной пользы от него неизвестно.)

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

странно. а сервер 1С х64? какая ОС вообще?
да, а в чём профит гонять конфы в режиме совместимости?
включите "FORCE WB" и увидите. если сервер на ИБП и выключается штатно (через команду от ИБП на выключение ОС), то ничего страшного.
можно выключить обслуживание, рестартнуть SQL, чтобы точно получить "холодный запуск" и поглядеть.
я пока не использовала SQL 2012/2014 для 1С - нет времени на игры :(
а причём тут изменения?
отчёт без фильтра с 1900 года парсит данные ;)
или продажа в далёком будущем.

изменения конфигурации мало связанны с быстродействием.
и, раз уж вы 1С-ник, то это надо знать.

Значит 22 sas было не достаточно, для такого большого количества пользователей, т.е. все тормозило.
Речь идет о 30 пользователях, а 4 sas им за глаза, можешь хоть 40 ssd установить, в данном случае разницы не будет никакой, только лишняя трата денег.
HellFire_MZ, твоей конфигурации на 30 пользователей вполне достаточно, проблема однозначно не в железе.
Снижает, но не как не влияет на производительность процессора.
Сервер не греется?

Сервер кстати x86, я что-то совсем об этом забыл. Нужно посмотреть, на что это влияет.
А профита никакого, просто на 8.3 и 8.2 лицензии разные, покупали тоже совсем недавно 8.3.
Попробую.
Меня честно удивляет вот такая ситуация как на картинке.
Это я каждый день делаю дефрагментацию индекса, а он у меня по куче таблиц фрагментирован!

Да как сказать, помнится я как то подключил обработчик ожидания - вся база висела.

Я думаю, Вы хотели сказать, чтоб проблема не в том, что железо устарело и не тянет.
Судя по датчикам, всё в полном порядке. Кондиционер на 16 градусов включен.

Фрагментация индекса.

на адресацию памяти.
лицензии разные на х64 и на х86. у нас на одном аппаратном ключе (на одном сервере) стоят и 8.2 и 8.3 (одинаковой разрядности).
впрочем на программных ключах тоже самое.

то есть хотите сказать, что разницы нет какой запускать? У меня программный ключ, тогда не понимаю смысла покупать ключ от 8.2, если я потом не смогу перейти на 8.3.

кто вам сказал, что вы не можете перейти?
ещё раз:
серверные ключи делятся по разрядности.
клиентские не делятся вовсе (клиента х64 нет).

Это всё ясно:) Просто при покупке на выбор были позиции для 8.2 и для 8.3. Поэтому и взяли для 8.3

UPD: Для чистоты эксперимента решил я отнять один процессор у SQL сервера. Завтра доложу, что изменилось.

Честно говоря нагрузка так и не снялась и я не понял, как запретить SQL серверу использовать оба процессора. Разве не так как на картинке?