производительность параллельного сервера SQL

Мы столкнулись с проблемой производительности в нашей производственной среде.

мы обнаружили, что когда количество активных сессий поднимается выше 25, загрузка ЦП достигает 100%, а снижение времени занимает много времени.

Окружающая среда у нас есть:

Продукт Microsoft SQL Server Enterprise Edition 9.3 (версия 2)

Процессоры 2 (Xeon 2.13)

Память 7G

снимок сеанса detail1

Активные Сессии 25

Активные транзакции 496

Свободные сессии 289

Заблокированные транзакции 29

снимок сеанса detail2

Активные Сессии 59

Активные транзакции 885

Свободные сессии 267

Заблокированные транзакции 49

Я хотел бы знать:

1. могут ли 2CPU хорошо обрабатывать 25 активных сессий (500 активных транзакций). PS: мы проверили, что без запроса на параллелизм одна транзакция, которая считывает / записывает 5 таблиц, занимает около 1 секунды на уровне приложения.

2. ли блокированные транзакции потребляют больше ресурсов ЦП. PS: заблокированные транзакции в основном из-за блокировки двух таблиц.

что решение: добавить процессоры? или настроить приложение (java / hibernate), чтобы сократить эту транзакцию и уменьшить количество блоков в таблице?

Ваши варианты, чтобы иметь хорошее представление о ситуации, когда все ползет:

• использовать трассировки на стороне сервера, чтобы увидеть самые длинные и тяжелые сеансы
• использовать хранимую процедуру « Кто активен» Адама Мачаника - чтобы сохранить информацию о моментах загрузки сервера - фантастический бесплатный скрипт
• используйте Activity Monitor из Management Studio просто для визуального взгляда (Cpu и IO - те, которые я нашел наиболее полезными) - довольно хороший инструмент, включенный в Management Studio
• используйте сторонний бесплатный инструмент - Confio Ignite Free - это очень хорошо для моментов, когда все идет медленно и нужно посмотреть подробную информацию о статистике ожидания, блокировании и т. д. - фантастический бесплатный инструмент
• проверить статистику, чтобы быть в курсе
• проверить фрагментированы ли индексы и, если да, дефрагментировать их
• следуйте другим советам проверки отсутствующих индексов, дизайна
• проверьте возможность использования уровня изоляции моментальных снимков в вашей базе данных (у вас высокая степень блокировки, поэтому приятно видеть, действительно ли вам нужен текущий уровень изоляции)

И удачи в расследовании проблем :-).

Ваша проблема, скорее всего, связана с низкой производительностью запросов

• плохой дизайн
• плохая индексация

Блокировки / блокировки происходят из-за плохой индексации из-за того, что все время сканирования таблиц идет от начала до конца. Процессор здесь не имеет значения.

В качестве быстрого исправления проверьте наличие отсутствующих индексов, используя информацию в этой статье: http://blogs.msdn.com/b/bartd/archive/2007/07/19/are-you-using-sql-s-missing- индекс-dmvs.aspx

Я согласен с GBN и Marian.

Чтобы ответить на ваш вопрос о двухпроцессорных системах, обрабатывающих 25 запросов: у меня есть двухпроцессорная система, которая поддерживает около 750 пользовательских подключений и среднее значение 4K пакетных запросов в секунду. Для меня важно несколько вещей: дизайн, управление и настройка. Если вы начнете с плохого дизайна вашего приложения и базы данных, вы потерпите неудачу при загрузке (подумайте о масштабировании).

Высокая загрузка ЦП может указывать на давление памяти. Вы упоминаете, что для SQL Server доступно только 7 ГБ памяти. Если у вас плохо работают индексы (слишком много индексов, неверные индексы или нет индексов), это приведет к тому, что система будет выгружать в память больше базы данных для различных запросов, чем при наличии соответствующих индексов. Я бы предостерег от чрезмерного создания индексов, поскольку неправильные индексы также повредят вам, поскольку каждый из них может потребовать обновления в ходе операции обновления строки (Create-Update-Delete).

Кроме того, использование DMV с отсутствующим индексом требует использования того, что вы знаете о вашем приложении и базе данных, а не просто реализации каждого рекомендованного индекса. Я хотел бы проверить записи в блоге Кимберли Триппа относительно индексов здесь . После раздела «Индекс» рассмотрение других категорий может оказаться полезным для вашей ситуации.

Если обновление Java / Hibernate для 5 таблиц в одной транзакции выполняется через несколько обращений к базе данных, то вы оставляете себя открытым для конкуренции (заблокированные запросы CRUD). Проблема усугубляется, если приложение не может своевременно вернуться в базу данных. Находясь в приложении, связанная активная транзакция может блокировать обработку других запросов и вызывать тайм-ауты запросов.

Добавьте два вышеуказанных вопроса вместе, и у вас начнутся неприятные проблемы с производительностью.

Сокращение числа обращений к базе данных в контексте одной транзакции было бы очень полезно. Возможно, хранимая процедура поможет.

Остальным потребуется работа, чтобы масштабировать приложение. Вы могли бы также рассмотреть вопрос о памяти, но это должно произойти после того, как будет проведен анализ проекта и производительности, и необходимые изменения, внесенные сразу после добавления памяти, замаскируют ваши проблемы.

Абсолютно следуйте предложениям, изложенным Мариан.

Я бы сказал, что вы оказались в прекрасном испытании и желаю вам больших успехов!

1. В моем опыте у нас есть MS SQL Server 2000 с 2 процессорами и более 30 активных сессий и более 1000 транзакций. Это было трудно для сервера, но это работало.
2. Я не уверен, что блокировки используют больше процессора. Блокировки и загрузка процессора, на мой взгляд, две разные проблемы производительности.

Что касается решения, сначала вы должны быть уверены, что вашей основной проблемой является процессор. Попробуйте прочитать эту проблему, чтобы найти источник ваших проблем и найти подходящее решение. Finnaly, если вы можете сделать вашу транзакцию как можно меньше - сделайте это.

Мои первые мысли - уменьшить количество транзакций и уменьшить количество блокировок. Можете ли вы разделить некоторые транзакции на несколько частей? Можете ли вы вытащить некоторые запросы из транзакций? Как отметил Alex_l, здесь идеальная транзакция наименьшего размера.

Я согласен с gbn, добавление индексов также может помочь.

Еще одна мысль - я бы тоже посмотрел на твои замки. Вы снимаете блокировки на уровне таблицы, когда обновляете только одну строку? Вы можете подумать о предложении блокировки на уровне строк для SQL Server. Это решило бы много проблем. (Конечно, если у вас есть 5 таблиц, это, вероятно, не так, а просто мысль.)

Наконец, я бы посмотрел на ваши таблицы, которые вы используете. Если все блокируют определенную таблицу, можете ли вы переместить логику этой таблицы в конец транзакции? Если вы можете сократить время удержания блокировки в этой таблице с высоким спросом, это может помочь.