Производительность SQLServer 2012R2

просто так, по проделанным рецептам, без результатов мониторинга, предметно не получится ничего подсказать.
запускайте профилировщик SQL Server Profiler и смотрите, какие запросы и почему начинают тормозить.
можно также запускать встроенный монитор windows-сервера (activity monitor кажется называется), которые может показывать различные системные метрики sql-сервера (ввод/вывода, использование памяти и т.п.)
дальше, имя какие-то факты, можно о чем-то делать выводы.

вопрос то стоял, какие причины могут быть в спаде производительности
а так запустил я профильровщик не которое время (5 минут) просмотрел время выполнения запросов, результат 1 сек.,
начал грешить на RAM все таки на сервере установлено 24 Гб свободно 2,5 Гб
на сервере запущено 3 экземпляра каждый 5,5 Гб съедает (ограничение выставлено 5,2 Гб, но ему SQL пофиг)

блокировок как не было так и не появляются

вот хочу узнать кто в этом SQL Server эксперт или хотя бы обладает знаниями, которые смогут понять куда копать или написать причины торможение сервера?

хорошо, в общем случае причин всего три:
1. проблемы с памятью (ее нехваткой, ее неоптималльным использованием, распределением и т.п.)
2. проблемы с вв/выв, а именно с диском (чтение/запись на диск)
3. проблемы с сетью (хотя по сравнению с первыми двумя, эта очень маловероятная причина; обычно объемы, которые перемалывает сервер внутри себя, гораздо меньше объемов, которые он отдает клиенту в ответ на запрос; хотя клиенты бывают разные)

запросы нужны разделять:
1. запросы на запись (обновление данных)
2. запросы на чтение

итак,
какие запросы вы увидели за 5 минут, какое процентное соотшение SELECT/INSERT/UPDATE, одни и те жи таблицы фигурируют в эти хапросах??, какие индексы использовались/перестраивались за эти 5 минут, сколько памяти съелось под конкретный запрос (join, sort), под конкретную сортировка для построения конкретного индекса, что записалось на диск/считалось с диска при выполнении запросов, а попали ли эти страницы в кеш сервера (не процессора!!!), какой был процент попадания в кеш, а хватило ли памяти в кэше для обработки??

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

еще, я упоминал про server performance monitor, если вы ограничились только профилировщиком, то этого недостаточно для полной картины работы ваших трех экземпляров. может быть они косвенно влияют друг на друга при конкуренции за какой-то ресурс (память, диск и т.д.). попробуйте отключить остальные экземпляры, если этого возможно, и сравнить работу.

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

Еще можно словить забавные тормоза из-за NUMA, когда один экземпляр SQL-сервера размазывается по нескольким нодам. SQL умеет работать c NUMA, но на когда свободной RAM мало, ему негде развернуться.
Проверить можно привязав инстанс SQL к процессорам (ядрам) одной ноды NUMA.