Имеется asp mvc приложение, использующее linq2sql в качестве провайдера к БД. БД находится на SSD-диске серверного класса (скорости — 1,5 ГБ/с)
Оно генерирует запросы, которые по отдельности достаточно быстро выполняются (самый сложный — не более 400мс на более простом SSD Samsung 850 EVO).
Но когда все пользователи в силу внешних причин ломятся в систему, то СУБД затыкается при 60 запросах в секунду и съедает всю доступную память (16ГБ).
Дедлоки отсутствуют.
Приложение структурно состоит из DAO и модели. Самые сложные запросы (из найденных) используют проекции, т.е. не вычитывают много лишних данных.
Как исследуют такие проблемы?

Здравствуйте, B7_Ruslan, Вы писали:

B_R>Как исследуют такие проблемы?

Для начала стоит профилировать всю систему в целом (СУБД + приложение + ОС) в период пиковой нагрузки, определить какие ресурсы используются и выявить узкие места. Инструменты: Perfmon, Process Monitor.

Затем, если подтвердится, что проблема именно на уровне СУБД (использование 16 Гб памяти само по себе еще не показатель), то можно спуститься на уровень отдельных запросов и выявить наиболее ресурсоемкие либо порождающие излишние блокировки. Инструменты: SSMS, Pefmon.

B_R>Но когда все пользователи в силу внешних причин ломятся в систему, то СУБД затыкается при 60 запросах в секунду и съедает всю доступную память (16ГБ).
— оперативка массово отжирается
а) на bpool
б) на memory grants под спулинг, сорты и хэш-джойны в основном
подробности — в гугле
— 16гб памяти это вообще ни о чем, это не сервер БД вообще ни при каких обстоятельствах
— отожрать всю доступную память это нормальное поведение для sql-я, ни о чем не говорит

B_R>Как исследуют такие проблемы?
Громкое заявление "исследуют" и "проблемы" Просто linq2sql генерирует говнокод, вменяемый ДБА с этим расправится за несколько дней.
Могу поделиться контактом, если что

Здравствуйте, B7_Ruslan, Вы писали:

B_R>Но когда все пользователи в силу внешних причин ломятся в систему, то СУБД затыкается при 60 запросах в секунду и съедает всю доступную память (16ГБ).

Ограничьте максимум отжираемой памяти — чтобы свободно было хотябы 0,2ГБ. MS SQL всегда отжирает всю память, при этом случается что операционке не остается и начинаются тормоза из-за этого.

Здравствуйте, _ilya_, Вы писали:

__>Здравствуйте, B7_Ruslan, Вы писали:

B_R>>Но когда все пользователи в силу внешних причин ломятся в систему, то СУБД затыкается при 60 запросах в секунду и съедает всю доступную память (16ГБ).

__>Ограничьте максимум отжираемой памяти — чтобы свободно было хотябы 0,2ГБ. MS SQL всегда отжирает всю память, при этом случается что операционке не остается и начинаются тормоза из-за этого.

системе лучше оставить даже побольше (хотя бы гиг), но max server memory надо ограничивать обязательно.

если это ситуацию не исправит, можно посмотреть планы выполнения запросов на предмет оптимальности, плохие запросы/планы выполнения/статистика/индексы запросто могут высадить сервер в ноль