на виртуальном сервере несколько баз с общим кол-ом пользователей ок 100
в определенный момент жд на сервере очень сильно грузятся
https://yadi.sk/i/1xdGHhpTvTdW8
очень сильно грузит базу temdb
https://yadi.sk/i/K-QD2fPevTdV9
и в паку srvinfo постоянно идет запись
-собственно вопрос может быть причина в платформе(8.3.6.2530)? Ранее более менее все было нормально
-реальные показатели perfmon если он в виртуальной среде ГиперВи ? Админы говорят что у них все ок, ни какой загрузки
-Может ли решить ситуацию покупка ЖД на 15000 rpm ?

Ну дык! Работает народ! Выполняются запросы - инфа пишется в tempdb. Тут целая наука... Вот сюда для начала загляни: Оптимизация 1с на уровне SQL Server.

(1) а разве sql не должен вычисления делать в ОЗУ ?

(2) Хороший вопрос. Почитай для начала про sql: как он использует память и для чего tempdb.

(3) в курсе про tempdb, но вот как он использует память, тут таки да провал в знаниях...

(0) Сейчас моветон на сервера покупать ЖД с rpm. Только SSD. (4) Озвучь сколько памяти выделили. У нас например SQL 2008  начал нормально работать только с 32 ОЗУ. На 16 ОЗУ тормозил.

И потом многие стали часто использовать временные таблицы в запросах, а они все пишутся в tempdb. А еще некоторые забывают уничтожать эти таблицы, так они потом доооолго в tempdb висят.
Если 100 человек, то один кривой часто используемый запрос с временными таблицами может дать результат как в (0)

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

(5) а некоторые дают советы, нифига не разбираясь

(0) - забить в поисковик про "1С8 утечка памяти"
- настроить SQL с джобами или с планом выполнения (регламенты для самого скуля)
- таки наконец открыть для себя замеры производительности
- проадминить скуль с настройками - чтобы всё не кушал )))

(2) виртуалка тем и плоха, что SQL не может определить какую ему память дали, из озу или из свопа дискового....

вообще настройка скуля на виртуалке - отдельная книга

(9) Виртуалка плоха тем, что ты можешь не видеть того, что на физической машине выполняется еще что-то окромя виртуалки.

(0)
Если проблема появилась после смены платформы то конечно проблема может быть в платформе. А может и не быть.
Средняя длинна очереди диска 36 это много даже для многодисковых массивов.
Покупка ЖД на 15000 rpm принципиально ничего не изменит. Нужно разбираться с причинами.

(10) И проблемы на уровне железа хоста не увидеть.
К примеру вот поменял диски и начались траблы
"ata7.00: failed command: WRITE FPDMA QUEUED" а в виртуалке это просто фризы/тормоза и все

> Админы говорят что у них все ок, ни какой загрузки

админы должны уже шуршать вокруг серверной стойки в мыле, какие-то они у вас оборзевшие

по картинкам конечно напрашивается проблема с йопсами, но конечно надо вешать мониторы, смотреть что где происходит

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